26 Dec 2016

Levels of Abstraction With Cloud Servers

I recently realised that backend-as-a-service is the next level of abstraction up in hosting servers. What does that mean?

Before the advent of the cloud, each physical machine was bound to a specific role. You could point to a machine and say, "This is the database server". If the machine failed, your app was down until it was fixed.

The cloud was one level up in abstraction from that. You no longer need to worry about an individual machine failing, because your job will be transparently relocated to another machine. You can reconfigure your machine in minutes, say to increase memory, rather than waiting a day or two for physical memory modules to arrive and be installed in a specific server. This is called infrastructure-as-a-service (IaaS).

However, scalability and high availability didn't come free. You can easily run a MySQL server, say, on the cloud, but as long as it's only one server, it won't scale beyond a certain point, and it's a single point of failure. You have to think about setting up a replica and configuring failover, backing your server up, restoring it, encrypting your backups, safeguarding the encryption key, and so on.

The next level of abstraction up is platform-as-a-service (PaaS), which includes Google App Engine, Aure App Services and Heroku. These abstract out individual machines, so you no longer say, "I have four VMs". Instead, you think in terms of services. A service is written using a framework that the provider supports, like node.js or Django, and automatically runs across multiple instances, as long as you follow the rules and guidelines of the platform. More instances are spun up when needed. If an entire datacenter goes down, your job is automatically moved to another datacenter. This is better than IaaS, which handles only failures of individual machines. You store your data in a replicated system, so you no longer need to worry about your database server going down, running out of disk space or memory, or losing its hard disc and your data along with it. PaaS gives you better reliability, scalability and availability free, or at much lower overhead in your time than IaaS.

Unfortunately, PaaS tends to be easier to lock yourself into than IaaS. If you write an app using App Engine's proprietary APIs, it won't run on AWS. It's not impossible to write a portable app; it just requires care.

In the last few years, an even higher level of abstraction was built, and that is a backend-as-a-service. If you have a native app, no matter how easy it is to build your server, your client app still needs a lot of plumbing, like fetching data from the server, caching it, perhaps showing old data while refreshing, saving edits back to the server, retrying if the network is flaky or offline, reconciling conflicts, and so on. A lot of this is standard, and doesn't make sense to reimplement for each of the more than four million apps that exist today. That's exactly what a backend-as-a-service gives you. It stores your app's data on the server, and gives you client libraries that take care of the aforementioned. It's the next level of abstraction up from platform-as-a-service, if you're building a native app.

The highest-profile backend-as-a-service was Parse, but it has been shut down. Firebase is an alternative, offered by Google. Which is a concern, given that Google's penchant for regularly shutting down their services. When a backend-as-a-service shuts down and you have to move to another one, you have to change both your client and server code, not just server code as with the lower levels of abstraction like PaaS or IaaS. That's the price you pay and the risk you take for the higher level of abstraction and the higher productivity you get from a BaaS.

I would want my BaaS to be open-source so that if the hosting provider shuts down, I can run it on another provider. Like running MySQL on Google Cloud, which is safe because, if Google Cloud shuts down, or discontinues their MySQL service, or becomes unattractive to you to run your service on, you can easily run MySQL on AWS or Azure. For the same reason, I would want my BaaS to be open-source.

I'm sure there are some open-source backends as a service, but they don't have the broad adoption and support that (say) MySQL or PostgreSQL have. These are critical to so many people and companies and projects that, should Oracle decide to stop developing MySQL, there'll be no shortage of people to step in and take it over. That can't happen with closed-source backends as a service, like Firebase. If Google decides to kill it next spring, you're in trouble.

I'd still go with a backend-as-a-service, simply because it eliminates so much plumbing I'll have to create, on both the client and server, that the risk becomes worth taking. It will save me a substantial fraction of development time.

Use the highest level of abstraction possible for what you're doing, so that you don't waste time reinventing the wheel, and instead spend that time adding value, doing things that will make your app great and users pay you.

No comments:

Post a Comment