Is Serverless the way to go? – Part 1

If you are currently in the IT business and rely on Internet infrastructure to serve data you probably know what a pain it is to manage those IT systems. Constantly having to manage servers to increase throughput, lower costs, ensure autoscaling and keep latency at bay is a tremendous effort. It has even spun a new role in the industry, the Dev Ops.


Amazon Web Services (I’ll be using them as the example since they are the leader, but other providers have similar resources) have made giant efforts to try to help developers with this aspect. One of the resources they offer is what they call Elastic Beanstalk. This effectively is a system that allows you to provision code to a number of instances that are behind a load balancer. The load balancer is the key, as it can deploy code into instances by taking them out of the group until they are ready and it handles auto scaling. Auto scaling is handled via triggers, for instance, if you use a CPU trigger, when the overall CPU usage goes over X% the load balancer will spun a new instance with your code and add it to your group, and when it goes below X% it will remove instances. Basically, it helps you manage instances while you maintain full control of everything. So, everything covered no? Amazon felt it was so great three years ago they made a strange video with a curious voice over (honestly, with the budget these guys handle you think they could do better) you can watch below.

However, the truth is this system has immense limitations, the first of which is what happens if you get a traffic spike. When you know you are expecting heavy traffic you can get ready for it by provisioning more instances, but what when that catches you by surprise? Imagine a blog post you don’t expect or some other type of uncontrolled media like an influencer. You are basically screwed, since the load balancer is not particularly agile at sensing something that doesn’t grow in a linear fashion (it typically uses health checks every 1 to 5 minutes), so your system would probably go down as your instances serverlesswould get saturated.
So how do you solve this? How do you prepare for situations like this without having to spend vast amounts of money of infrastructure provision? One of the possibilties is going serverless, and we will analyse what it is and how it works in the next blog post 😉


Hope to see you there!


Parse closes down: Is Backend as a Service profitable?

Parse starting sending messages last week that it would be winding down it’s services. This came as a shock for many people who have come to rely on their services as a way to reduce the complexity of having to maintain, deploy and scale your own backend solution. For those of you who haven’t seen it, you can take a look at the announcement below.

Parse closes

It is clear that Facebook is not joking around and not keeping services and tools that are not as profitable as they need. This is a shock for companies and developers as it demonstrates that in the end trusting your backend to an external system can have nefarious consequences for you. From the moment you don’t control all the variables, the risk of this type of problems always exists.

Parse are going a give a full year until the sun sets on the platform, they are even open sourcing the Parse server (which is build on node.js and requires a Mongo Database). But mind you, self hosting a Parse server is by no means easy and never substitutes the ease of the original Parse panel, so other alternatives like setting up your own APIs and creating your own infrastructure, or another Backend as a Service should be considered.

A few years ago, I published a post named “Is Backend as a Service the new Gold rush?”. In this post I analysed if systems like Parse that made developing Apps with a server side were the new money making scheme of the tech world companies. However, after the Parse announcement, one can’t but help thinking that perhaps it is not such a profitable endeavour.

If you stop to think about it, big companies usually create their own Backends and host them on systems like Amazon Web Services, and those are the ones that pay the big bills. Small developers that use Parse, tend to have the free version (which has a ridiculously high limit usage before it starts charging) or pay very little money.

So, is backend as a service really profitable? Will it become an open source self hosted alternative? Or will companies use this as a launch pad for their new and reinforced Parse alternatives?

Let me know your thoughts!