Evolution of Serverless: Monolithic-Microservices-FaaS

The approach to digital transformation representing monolithic —> microservices —> serverless architecture(FaaS) is driven by the need for greater agility and scalability. To keep up with the competition, the organizations need to update its technology stack quickly, eventually making software a differentiating factor.

Thus microservices architecture emerged as a key method of providing development teams with flexibility and other benefits, such as the ability to deliver applications at warp speed using infrastructure as a service (IaaS) and platform as a service (PaaS) environments.

The concept of this idea was to break the monolithic applications into smaller services each with its own business logic. With a monolithic architecture, a single faulty service can bring down the entire app server and all the services running on it.

While in a microservice each service runs in its own container and thus application architects can develop, manage and scale these services independently.

The microservices can be scaled and deployed separately and written in different programming languages. But a key decision many organizations face when deploying their microservices architecture is choosing between IaaS and PaaS environments.

Microservices involve source code management, a build server, code repository, image repository, cluster manager, container scheduler, dynamic service discovery, software load balancer and a cloud load balancer. It also needs a mature agile and DevOps team to support continuous delivery.

Approaching Serverless

Though, serverless architecture takes the step further by making an application more granular to the level of functions and events. Thus, it is pretty clear that the unit of work is getting smaller and smaller.

We’ve gone from monoliths to microservices to functions. FaaS also improves the shortcoming of PaaS model ie. scaling and friction between development and operations.

Scaling a microservice hosted on PaaS is challenging and complex. The architecture might have elements written in different programming languages, deployed across multiple clouds and on-premise locations, running on different containers.

When demand increases for the app, all the underlying components have to be coordinated to scale, or you have to be able to identify which individual elements need to scale to address the surge in demand.

Even if you setup your PaaS application to auto-scale you won’t be doing this to the level of individual requests unless you know the traffic trend. So a FaaS application is much more efficient when it comes to costs.

Though, there will be always space for both microservices and FaaS to co-exist because there are certain things which you can’t do with functions at all. For example, an API/Microservice will always be to respond faster since it can keep connections to databases and other things open and ready.

Moreover, one more thing to note here is that by grouping a bundle of functions together behind an API gateway, you’ve created a microservice. This shows that both of these can co-exist in a nice way.

This high-level flow remains the same as the traditional approach. The key difference is that, in case of a function, the container is created and destroyed by algorithms used in FaaS platforms and the operational team have no control over that.

But with ease of function and reduced cost comes increasing complexity about which I have discussed in A Comprehensive Guide to Serverless Architecture along with in-depth benefits and drawbacks, working of Serverless Apps, FaaS, case study and much more.

If you've any doubts regarding serverless architecture, feel free to ask in the comment section.