Serverless Computing: The way ahead

AWS Lambda

To those who have not heard of this, the phrase ‘Serverless Computing’ may sound like science fiction. How can compute happen without a computer? While the phrase does give rise to such an interpretation, what is meant here is that we will compute without owning or setting up the servers.

When we embraced Cloud computing we gave up on ownership of the servers but not the control. The servers ‘belonged’ to you in the sense that you could login into the system and customize the OS and the application any way you wanted. With Serverless Computing, you give up both ownership and control. The service provider is responsible for setting up the servers and running your application seamlessly.

I will take up Amazon Lambda, which is what everyone thinks of when talking about serverless computing, and explain what it means to give up ownership and control. One way to use Amazon Lambda is as follows: a) Write you code and upload to Lambda b) Tell Lambda when you want your code to be run (scheduled or as response to an event) c) Lambda will setup the required environment and run your code. d)You will be charged only for the duration that your code ran.

Let’s take an application example. Assume you want to provide a service wherein the user loads a Word file and wants it converted to a pdf file. The application logic will work this way:

– The user file is loaded into Amazon S3,

– S3 generates an event

– The event is sent to Lambda,

– Lambda then invokes your code which downloads the file, converts it and uploads the resultant pdf file to another S3 bucket.

– The user is then informed that the pdf file is now available for download.

Assume the number of requests for conversion per day is not very large. In that case running a backend server to perform this logic will be costly as we have to keep the server running 24×7. In case you use Lambda you will only be charged for the duration for which your program ran. Setting up the servers and running your program is the responsibility of Lambda. So you have less headache and it costs you less.

There are limitations of course. Lambda doesn’t allow a job to run for very long time. They will terminate after 5 mins. Similarly, starting your app may take some time, especially if you have written the app in Java. You don’t get any persistent local storage. The amount of RAM you get is also limited. The languages currently supported by Lambda are: Java, Python, Javascript(Node.js) and C#.

All these limitations mean that developers must start thinking of serverless computing from the architecture stage itself. They must learn to think in serverless terms rather than assuming the availability of a server in the backend. Of course, not every application can use serverless architecture but in Microservices area this will definitely be beneficial. This excellent and quite exhaustive article by Mike Roberts in Martin Fowler’s site gives all sides of the picture and is definitely worth your time.

Here another article wherein we find how the company CloudSploit made the whole company serverless. This article has lot of technical details including some code snippets. Developers will get some nice insights into how they can implement serverless architecture.

It is not only AWS that has serverless computing. Google has Cloud functions, Microsoft Azure has Azure Functions and IBM BlueMix has OpenWhisk . So you can see that every cloud provider is interested in having a serverless computing solution. There are also frameworks like Serverless Framework which makes serverless development easy

It will take another two or three years to know how this succeeds but going by the idea, my take is that serverless computing has a bright future and we will see lot more applications adopting serverless computing