Back to the Backend Era
Part 4 — Provisioning
In this series of articles we explore not what we can do with serverless application platforms, but what we no longer have to do.
Previous parts:
In parts 1, 2 and 3 we focused on choosing the right technology for our backend. This time, we will focus on making that technology available. It’s a historical moment worth celebrating, because this is the first time that we will actually do anything. Up to this point we were only choosing.
We decided that on our Linux KVM VPS we’ll run Mongo, Node and Express on Ubuntu to implement a RESTful API serving JSON data; so let’s actually make it happen. We can now install all the software needed, which is not that hard but it’s worth writing down everything that is being done because we’ll need that information later.
First, we install a fresh Ubuntu image on the VPS. We have to choose a version because we are likely to have some options here. Some versions of Ubuntu have Long Term Support (LTS), which means that we’ll get updates for 5 years. The latest LTS version of Ubuntu is 14.04 from March 2014. There have already been 3 non-LTS versions released since then — the 14.10, 15.04 and 15.10 — with newer software, but they only get updates for 9 months. We have to carefully evaluate whether we want newer software at the price of having to install and test a new operating system version twice a year. This decision is not as easy as it may sound. Let’s say that we choose LTS because 15.10 is to new and untested right now, while 15.04 is going to be obsolete pretty soon and 14.10 is already out of the update cycle. We may also have a choice between 32- vs 64-bit versions of the same system, but let’s say that we go for 64 bits.
Next, we install the operating system and upgrade its packages. We are going to install all security patches as soon as they are released, so we need to monitor the ubuntu-security-announce mailing list to get fresh info. It’s also a good idea to read the debian-security-announce mailing list as well, to get closer to the source of upstream patches. Reading the Linux kernel mailing lists and Bugtraq is also mandatory.
Now we can install MongoDB. We can do it with the Ubuntu package management system if we are happy with the version that is available there, but chances are that we’re not, in which case we need to install the .deb package for Ubuntu provided by MongoDB. That will be done after installing the correct PGP keys and configuring our package management system to use the right Mongo repositories compatible with our system version.
Starting Mongo should be pretty straightforward, provided we have at least 3379MB available on our /var partition — a number that we’ll remember every time our Mongo refuses to start. Now — after we reconfigure the memory management system in the Linux kernel to disable transparent hugepage support that makes Mongo complain — we are almost done with Mongo. We now need to frequently monitor the MongoDB Alerts website for all security related info, in order to make sure that we patch our system every time any security update is released.
Next, we can install Node.js. The version available in the Ubuntu 14.04 package system is 0.10.25 and the current Node LTS version is 4.3.2 so we are probably going to install it from source. It’s not that complicated — we just download a tarball, verify the hashsum and GPG signature, configure, make, make test and make install. First, of course, we’ll need to install all of the required build tools on our system, and then we’ll be ready to build Node in no time. I mean we’ll be ready in no time; the actual building is likely to take some time, especially on a small and busy VPS.
Very rarely, we’ll need to apply some patches for a clean build. When any tests fail, it is usually fairly easy to find online information about what minor changes in the source code or build scripts need to be done to make all tests pass again. Every system is different, so any compilation of a project as huge as Node may fail occasionally but we’ll quickly learn how to deal with it. Now we have to monitor the Node mailing lists to install every new security patch as quickly as possible. This is crucial since our Node application will be exposed to the Internet.
This is a historical moment. We haven’t written a single line of code yet and we haven’t put a single byte into the database, but we have chosen a platform, operating system, programming language, web framework and the database, and what’s more we have installed everything that we have chosen. This time we actually did something.
We have it all installed, updated, up and running, and ready to go. In Part 5, we will write some code. I promise.
