Back to the Backend Era
Part 1 — The Fundamentals
In this series of articles we will explore not what we can do with serverless application platforms, but what we no longer have to do.
Some Background
Thanks to services like Syncano, we no longer have to worry about certain tasks that once used to be the main area of concern of every Web application developer. Today we have a young generation of front-end developers who write complex applications without even having to know about that not-so-distant past. But we also have a large number of developers who still live in that past and don’t even realize it. Both of those groups can benefit from learning about the transition from crafting custom backends every time for every project, to modern serverless application platforms — the former to better understand the underlying technology and the latter to improve their efficiency.
But the group that can potentially get the most out of the new way of thinking about backends are not developers but their clients, employers, startup founders and investors. Those are the people who traditionally are most interested in saving money; however, this may not even be the most important factor today. Even if money is not an issue, they simply don’t have any time for reinventing and maintaining their own versions of already developed and tested, robust, ready-to-use solutions. And today, time is what matters the most.
Presently, when the number of companies in The Billion Dollar Startup Club nearly doubled during the last year, no one has any time to waste. Even if you theoretically could develop a better backend in-house than what you get from serverless application platform providers (which in practice rarely turns out to be true) you will still lose the race to market with a competitor who won’t waste time on reinventing the wheel and who will focus on the front-end, the only user-facing part of the application.
But even today a surprising number of teams start every project from designing and implementing a custom backend. It seems reasonable because that is how it has always been done. But it is important to step back for a while to see a big picture of what unnecessary work could be saved in order to improve our efficiency and competitiveness, or to see what we already get if we use a serverless application platform. We usually focus on what we have to do, but the things that we no longer have to do are equally important to fully understand the value that we are getting.
A typical backend building
This is a typical thought process, along with fundamental decisions that need to be made:
Hardware
We need a Web application. So first we need a Web server that will answer requests. For that, we need a physical server or a virtual private server (VPS). Let’s say we choose a VPS because it’s cheaper and faster to set up. Then we need to choose an operating system to install. It needs to be something that we are familiar with because we’ll have to maintain it, install updates and patches, and keep it running smoothly and safely.
The Technology Stack
Let’s say we choose Linux with KVM virtualization. The other option would be Xen virtualization or using a system other than Linux, but here we’ll choose KVM for the sake of simplicity.
If we pick Linux, then we still need to choose a distribution. Out of Debian, CentOS, Ubuntu and Fedora, let’s say we select Ubuntu and install it on the VPS. The installation takes a few minutes and we’re up-and-running quickly, but the decision will have consequences for the entire project’s life cycle.
Every distribution has different update channels, different patches, different package systems and different init scripts. The software versions will be different. So will the security models. You have to carefully evaluate whether upstart is better suited for your need than systemd, or init.d. You have to decide if AppArmour will work better for your project than SELinux. Unfortunately, you need to decide these things before you know what your application will look like.
In theory, you can always switch an operating system if your application is written in a portable way. In practice, for any non-trivial application it is often problematic, at the least..
When you have a server with an operating system, you will then have to choose your language and runtime. It can be Python, Ruby, Perl, Java, PHP, Node, Go, Lua, Clojure… The list goes on, but let’s say we choose Node.js because we’re most experienced with it, so it seems like an easy decision to make. But is it?
