Back to the Backend Era
Part 6 — First Problems and Hope
In this series of articles we explore not what we can do with serverless application platforms, but what we no longer have to do.
- Part 1 — The Fundamentals
- Part 2 — The Programming Language
- Part 3 — The Database and the Rest
- Part 4 — Provisioning
- Part 5 — A Simple Matter of Programming
In Parts 1, 2 and 3, we were choosing the technology. In Part 4, we were installing what we had chosen, and in Part 5, we were using what we had installed. Finally, we actually wrote some code. Now it’s time to worry about what we have written.
The first problems that come to mind are:
- the security of our hardcoded password — we need to remove it from the source code and provide it to the program in a secure way
- the security of the HTTP connection — we need HTTPS and some kind of authentication and API keys
- exposing our internal database IDs — it’s a sign of a leaky abstraction
- error handling — needs to be much more robust
- tests — we have none
Additional concerns that we should have are:
- starting our app on the system boot — making sure Mongo is already loaded
- restarting our app if anything bad happens
- load balancing the web app
- database clustering
- database replication
- data backups
- updates of the system, Mongo, Node and the modules
- system and database administration
- new versions deployment
Which means that we are hardly finished yet. And it only gets more insane. Do we really need to do so much research, make so many decisions, and maintain all that software just to have such a simple thing running? We just need to have our news available to our Web app! Is it really that complicated?
Actually it is much more complicated than that. We hardly even started and it only gets harder down the road. Right now, we should already have some idea why so many projects like this one can’t get finished on time and within the budget. That’s because we tend to underestimate the complexity that is needed to implement our ideas, which seem quite simple when we describe them. The devil is in the details.
“We tend to underestimate the complexity that is needed to implement our ideas.”
Is there any hope?
It’s easy to get stuck in the cycle of solving the small problems. It’s not that it is impossible to develop a simple backend correctly. We’ll finally do it. Maybe missing deadlines, losing sleep, going way over budget, getting frustrated and being late to the market, but we’ll do it. The question is: Is it worth it?
We need to step back and look at the bigger problem. The problem is that we are stuck in the backend era. We are used to the old times where every backend was a custom-built piece of software. We didn’t have any ready-made solution, so we needed to reinvent it every time.
There is a reason why we no longer write our own databases any more. There is a reason why we use high-level languages. There is a reason why we use frontend frameworks. We use standard tools with well-defined interfaces because it allows us to focus on the big picture instead of reinventing yet another wheel. We are better at building from parts, not from raw materials. We need bricks instead of clay.
“We need bricks instead of clay.”
Times are changing
Today we have services like Syncano that we can use to create complicated backends in no time, which will work much better than what we could recreate by hand, in pain and frustration.
All of the work that we have done here in this basic example, was for solving small and unimportant problems that stood in the way of building an application. We haven’t even started thinking about our frontend, because we knew that we had to solve just that one little problem to be able to start the important work. But it is a work of Sisyphus. New “little problems” keep showing up just when we think we’re done. It can never end unless we step back and understand our bigger problem here, which really boils down to this: we are stuck in the past.
“We are stuck in the past.”
The time to market has never been so important as it is today. People demand attractive frontends, beautiful designs and amazing user experience. They don’t care about our custom backend, especially when our product hits the market a month after our competitor.
The times have already changed in many different areas. We don’t build power generators when all we need is electricity. We don’t dig wells every time we need water. Why do we still insist on building custom backends when all we really need are API endpoints?
“We don’t dig wells every time we need water.”
We need to start thinking about backends like we think about water. When we need water for the café that we are building we don’t start from the point of digging wells and designing a custom system of pumps that we’ll have to maintain forever. We sign a contract with a water supply network and we focus on more important things — like how to make our café unique and our customers happy. It happened to water, it happened to electricity, it happened to so many different areas in IT. Now it’s time for backends to follow that trend.
We need to stop being stuck in the backend era.
“It happened to water, it happened to electricity…”
This series of articles was an attempt to show not what we can do with serverless application platforms but what we no longer have to do.