Microservices - Serverless versus Containers

Serverless versus Containers is the hottest contested topic today’s times. For me is not an either/or” decision. Both technologies are here to co-exist in the ever-evolving world of Cloud and DevOps. There are many things common to Serverless and Containers. They are both platforms for a modern, highly available, scalable microservices architecture. However, there are specific use cases for the two technologies.

Before we get into that, let us first get some facts right. Serverless Architecture does not mean that there are no servers involved. It’s a service that enables us to fire specific functions in response to events or Function-as-a-Service (FaaS). It’s called Serverless because the service provider dynamically handles all the server-side IT at the backend. All you need to do is write code and deploy it and hence the Serverless experience, even if the underlying infrastructure is not.

When to choose Serverless

Serverless is a suitable candidate for smaller applications where there is an uneven traffic pattern changes which needs to be automatically detected and handled instantly. With Serverless design, you pay only for the resources you use. No usage- no costs. Applications suitable for Serverless architecture are applications handling backend tasks for a website or mobile application, applications processing real-time data uploads, or applications taking care of high-volume background processes.

Serverless Architecture is less expensive, requires minimal maintenance and has higher auto-scalability at a lower cost.

The biggest drawback of Serverless is the built-in restrictions on size, memory use, and inefficiency for longer running applications. This along with the limited list of natively supported programming languages, difficulty in monitoring and debugging are some of the practical constraints of Serverless architecture.

When to go for Containers

In Containers, applications are abstracted from the environment in which they run. They encapsulate a lightweight runtime environment of the application, presenting a consistent environment from the developer's desktop to testing to final production deployment across public and private cloud. Using containers was initially cumbersome as it required deep knowledge about Linux kernel internals and making home-grown scripts to put an application in a container and run it on a host machine. However, with the launch of Docker, containers became more popular. Docker was an easy to use platform which made it possible to build, distribute and manage containers easily.

1.      Control - Containers are good when you need control on the environment i.e. you can choose the underlying operating system and have full control of the installed programming language and runtime version. With control comes the additional cost of maintenance as Containers still require a lot of maintenance and set-up.

2.      Scalability - A container-based application can be as large and as complex as required. You can refactor a very large and complex monolithic application into container-based architecture to meet the requirements of the redesigned system.

3.      Allows Debugging – Containers allow comprehensive debugging and testing using a full range of resources. You can identify and analyze performance problems, and fine-tune performance to meet the specific requirements.

4.      Portability – Containers can easily be moved from one environment to another across a hybrid cloud environment and provided better consistency.

The biggest drawback of containers compared to Serverless is the higher maintenance costs, slower scalability and more manual interventions.

Who is the winner? 

Choosing a winner will be an oversimplification of the complex technology landscape of today’s times. As a rule of thumb, choose containers when you need Flexibility, Control & Portability or when you need to migrate monolithic legacy services. Choose Serverless for smaller applications with uneven traffic patterns and when you need speed of development, automatic scaling and significantly lowered run-time costs.