Short introduction to serverless architecture

Serverless architecture and Functions as a Service (FaaS) are new trends in cloud computing. Besides Microsoft and Amazon there are many other vendors providing FaaS services. This blog post is short introduction to serverless architecture and here I try to explain what it is and why we need it.

Evolution of cloud

During its evolution cloud has had multiple forms and abstraction levels.

Data center, be it in-premises or provided by vendor as a service, was the first step to cloud today. It abstracted the physical hosting environment and we started scaling these environments by hardware units. As virtualization evolved we started hosting virtual machines on cloud environments. We abstracted the hardware and used operating system as the unit of scale. Soon after this we built hosting environments to cloud and abstracted the operation system. Our new scaling unit was application. But this was not the end of journey as we got to functions or serverless architecture.

Cloud models

Different cloud models leave us different responsibilities. Having data center in premises means that we have full responsibility over everything that is going on there. When moving to cloud each step in evolution leaves us less and less responsibilities.

Serverless architecture came actually later than SaaS but in cloud models chart it is before SaaS because in the case of SaaS we don’t control anything as a consumers about application or its infrastructure.

Serverless architecture

Functions that are unit of scale in serverless architecture abstract the language runtime. We don’t talk about how much CPU or RAM or any other resource we need for function to run. We talk just about time it takes to run the function. All other metrics should not bother us. We write our functions, publishem them to cloud and pay only for time these functions ran.

Serverless architecture doesn’t specify strictly what our function technically must be. It is just some unit of work that we want to be done. Functions can be triggered many ways. It can be timer that runs function periodically but it can also be HTTP-request or some event in some related service.

In his excellent article Serverless Architectures Mike Roberts brings out six points about Functions as a Service:

1. Fundamentally FaaS is about running back end code without managing your own server systems or your own server applications.
2. FaaS offerings do not require coding to a specific framework or library. FaaS functions are regular applications when it comes to language and environment.
3. Since we have no server applications to run deployment is very different to traditional systems – we upload the code to the FaaS provider and it does everything else.
4. Horizontal scaling is completely automatic, elastic, and managed by the provider.
5. Functions in FaaS are triggered by event types defined by the provider.
6. Most providers also allow functions to be triggered as a response to inbound http requests, typically in some kind of API gateway.

Adrian Cockroft defines “serverless” clearly in his tweet:

If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless.

From this we can conclude that long running workflows and other massive tasks are not good fit for serverless architecture.

Functions services

There are already companies who provide running functions as a service. Here are some of these:

• Microsoft – Azure Functions
• Amazon – AWS Lambda
• Auth0 – webtask
• Iron.io – IronWorker
• Planet Rational – webscript

There are many other services available and all of these differ by their technical capabilities and implementations.

Wrapping up

Serverless architecture or Functions as a Service allow us to build pieces of code that do something useful and same time running short without consuming big amounts of server resources. It doesn’t mean that FaaS is usable only in small scenarios. Although function is small unit it can be invoked millions of times per second, by example. The question is about what small functionalities we move from other components or layers of our application to functions.