A Short Introduction to Serverless Architecture

serverless architecture and functions-as-a-service (faas) are hot trends in cloud computing. besides microsoft and amazon, there are many other vendors providing faas. this article is a short introduction to serverless architecture where i try to explain what it is and why we need it.

evolution of the cloud

during its evolution, the cloud has had multiple forms and abstraction levels.

the data center, be it on-premises or provided by a vendor as a service, was the first step to the cloud as we know it today. it abstracted the physical hosting environment, and we started scaling those environments with hardware units. as virtualization evolved, we started hosting virtual machines on cloud environments. we abstracted the hardware and used operating systems as the unit of scale. soon after this, we built hosting environments to the cloud and abstracted the operation system. our new scaling unit was the application. but this was not the end of the journey, as now we've moved to functions or serverless architecture.

different cloud models leave us different responsibilities. having the data center on-premises means that we have full responsibility over everything that is going on there. when moving to the cloud, each step in the evolution leaves us fewer and fewer responsibilities.

serverless architecture actually came later than saas, but it is before saas in the chart because in the case of saas, consumers don’t control anything about the application or its infrastructure.

serverless architecture

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

serverless architecture doesn’t strictly specify 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 a timer that runs a 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 from 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 a good fit for serverless architecture.

functions services

there are already companies that run 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 allows us to build pieces of code that do something useful, and at the same time, run quickly without consuming big amounts of server resources. it doesn’t mean that faas is usable only in small scenarios. although a function is a small unit, it can be invoked millions of times per second, for example. the question is what small functionalities we should move from other components or layers of our application to functions.