Brief introduction for the uninitiated
A brief joke:
Serverless computing is a new computing breakthrough that helps you run your applications without ever needing any servers. Instead of servers/cloud resources, fogging is employed to carry out compute and storage tasks.
Heh! Just kidding!!
But I do beg anyone who is reading this to stop calling it Serverless computing. (Which kind of sounds like a rival to cloud computing although it is an innovation on top of the cloud) Because when someone who hears it without context, tends to think just what I have written in the last paragraph. Instead call it serverless architecture.
How Darwin would have seen it!
We have transitioned from full-fledged monitoring and management of servers to forgetting that they exist in the period of past decade. And thus our applications have moved from being server/platform centric to developer centric in the sense that now there is no obstructing layer between what the developer want to do and what he can accomplish.
Homo Habilis:
In the pre-cloud age, we used to have physical datacenters where we had to manage the physical and operational hassles. And along with the hassles came the need of having the need of expertise in organizations for knowing how to provision hardware, capacity planning, standing up servers, manage replacement of failing drives in the RAID array and maintaining backups.
Homo erectus:
Then came the public cloud, and it rained … not actually. In the public cloud world, most of the pains of management of the datacenters discussed above were eliminated via IaaS paradigm. VM on the cloud enabled amazing horizontal scaling and ability to provision the backend tier in virtual machine and the ability to interface with it in form of APIs within minutes. And it helped a lot of availability scenarios.
Corporations and enterprises rejoiced and their management load was limited to virtual machine and the baggage that comes with it.
But even with the PaaS providers like Heroku you have to worry about your dynos. So, what that means is that you have taken away the physical aspect but still have to manage the operations in some way or the other. However, IaaS is a huge play in the cloud market today.
Homo sapiens:
Then comes the Serverless architecture, or Function as a Service architecture, where you don’t have to worry about any of the VMs or the dynos or containers. This architecture enables you to even forget about the application uptime, which is out of your hand in this workflow. And since its amazon which is handling it for you, and you couldn’t have done it any better yourself. Thus you have a greater peace of mind.
Good thing about this kind of architecture is that you can focus on your end user and application instead of worrying about the server and having to have those expertise around to keep servers and running and monitoring VMs. So, it means that serverless effectively takes away the operations as well. It makes good on the promise of deploy and run made by the PaaS vendors.
Blend period
This all might sound like that every new thing that came, destroyed the one before it. That’s not true at all. When IaaS came to the market, people did not stop establishing and managing their own datacenters right away. Or when PaaS, came people did not immediately started devising a strategy to move on to those PaaS providers. This mostly depends on things like:
- state of the art
- business requirement
- organizational constraints
As in evolution, successor and predecessors co-exist for an indefinite time period, and when the time comes the fittest prevails (which often happens to be the successor).
Origins:
Serverless framework started when Austen Collins started refactoring one of his applications to use lambda exclusively on the backend. And while he was conducting this experiment, a framework started to emerge. Something that provided structure, best practices and principles on how to architect an application to be truly serverless. So he put this framework on the Github and posted it on Hacker news. And it gained traction with the community and a lot of appreciation. Ryan Pandergast was one of the first people to hop on the serverless wagon and now he is a big contributor of the project. Serverless framework is now maintained by a full-time, dedicated team.
Tagline
According to the Github page of Serverless framework:
“The Serverless Framework is a free and open source framework for building web, mobile and IoT applications with serverless architectures such as AWS Lambda, Azure Functions, Google cloudFunctions and more.”
Serverless = ‘Less’ thinking about ‘server’s
it allows you to cut out Platform as a Service, Backend as a Service middle-men.
By serverless it means that you don’t have to think about servers. They exist somewhere, but amazon has to deal with them, not you. Instead all you’re given as a developer is lambda which is an event driven compute resource, which is just sitting there, waiting for a trigger. It’s the instance of the code that you have deployed onto AWS, when it gets triggered, you’re only going to be charged for the duration and how many times it is called.
Another half of AWS serverless is API gateway (Amazon API Gateway is a fully managed service for defining, deploying, and maintaining APIs), and that’s the rest API URL routing layer for Lambda. Which means that …
Serverless = AWS Lambda Functions + API Gateway
So Why Lambda?
- Though lambda runs in containers, but you don’t have to deal with them.
- Orchestration/ Autoscale of containers is handled for you.
- API Gateway handles DDoS as well as Rate limiting.
- Distributed application logging and metrics are built-in.
So, what are the benefits of this workflow?
- Application isolation.
- Endpoint isolation.
- Multi-Container code deployment is handled for you.
- Quickly provision new stages and (AWS) regions.
- With as little DevOps as possible.
The paradigm shift
Simplest way of thinking about it is that it changes thinking from: “build a framework to sit on a server to react to multiple events” to: “build/use micro-functionality to react to a single event”
As we changed the way we were thinking about building applications when we moved from datacenter model to public cloud, we also have to think about changing how we architect applications when moving to serverless.
Someone might think that why I would want to put my ruby on rails application on a lambda, what good is it going to do for me? And google app engine is this exact same thing for python and Django, snapchat works on it and its going well.
But serverless isn’t just about moving the operation aspect of your business to the AWS but also the range of services that you can connect to in order to finish the end product. What serverless really says is that, think about thick client, like apps on a mobile phone and then also single page web apps that use javascript frameworks like angular or react. And eliminate that middle tier that everyone is so used to .. that’s running on a server.
And then the actual lambda part of it that’s running on a server actually tends to be very small because we are only tackling micro-functionalities through it via APIs. The key part of these applications are all the other services that make them run, for example:
- If you need to host your static assets you might be needing a service like netlifly or nginx/nginx+.
- You might need a place to put data, like firebase or parse.
- You often times need an image store like cloudinary etc.
- You might need a search provider like algolia or Amazon CloudSearch.
- And authentication service like Auth0.
So the thing to ponder here is to understand the workflow of the serverless architecture by considering the range of services that a person can hook into in order to accomplish their tasks. So we should shift our thinking to become more holistic about the application that is being delivered to users, while keeping the costs in the feasible window.
Serverless has this paradigm where more and more of your business logic is concentrated around the front end which has statically served content and this is from where you make API calls to all those microservices. For example, if your application is running on a mobile phone, you have to think how you can write your code in a way that it can hook into those microserves for which you can just pay. This kind of thinking has benefits like:
- Decreasing your dependency on the developer’s ability to code robust modules.
- Less dependency on Amazon Web Services.
- Reduction of the standard connective tissue code that everyone else has to write.
- 95% of the code is user and business logic centric.
Past vs. Present
Previously VM instances just sitting on the AWS cloud doing nothing like big monolithic structures and you have to pay for them like house rent. Yes, you can do some scale up scale down according to your requirements, but you have a pretty much static run rate bill per month. But now with packaging the microservices into lambdas and by distributing the cost to all those services you can drastically change your business cost model.
Also noteworthy, Amazon used to embrace the model that if you wanted your developers to run your servers you could do so, so if the servers goes down at any hour in the morning, who will be there to stand it back up. Now, with Lambda paradigm, you don’t have to worry about the server going down at night because Amazon handles traffic bursts and horizontal scaling out of the box and handles costs with respect to invocation of the services. And also if the server actually did go down, there is nothing you can do. Ironically this gives the architect and developer a peace of mind and focus in the way that the product can be very developer-led. Because there is no crusty IT guy telling you what you can and can’t do because its going to have an impact on availability.
What does the future hold?
As far as the current state of technology is concerned, Serverless architecture is unlikely to replace legacy applications because of the costs involved in replacing the stack. However, programmers starting on blank page projects, which have highly variable usage patterns and an event driven nature should definitely consider this new paradigm to reduce the burden of deploying, scaling, managing the infrastructure behind their code.
Resources and Further reading:
White paper: AWS Serverless multi-tier application architecture
A Lambda reference Architecture: depicting Real-time file processing.
StackHut: an opensource serverless platform
Cloudcast #242: Understanding Serverless applications
Rethinking Backend with WebTasks — Auth0
Serverless Framework, why we decided to move away from Ruby on Rails
A curated list of resources regarding the Serverless project