Modern developers often confront terms like microservices and serverless functions used in conversations, at times without much of delineation between the two terms. This has lead to some confusion among the developers, leading to picking the wrong technology stack for their needs. In this blog post, we will try to distinguish the difference between these two architectures so that developers can use the right stack for their application needs.
What is a microservice?
Unlike a monolithic architecture, a microservice is more modular and implements a feature or a functionality of a much larger application. A very good definition for a microservice comes from Martin Fowler. Roughly,
A lightweight self containing service running in its own process or an instance and communicating with a lightweight interface like REST
Microservices usually encapsulate a feature or part of a functionality and they are usually encapsulated in a lightweight instance like containers with an REST end points handling the communication needs. Compared to a monolithic architecture, it offered a more fine grained approach to scaling and offered better resiliency for applications than monolithic architectures. While containers provided an easy encapsulation to microservices and Kubernetes provided a good orchestration platform for the containers, the microservices architecture added complexity at a much higher level than the infrastructural complexity associated in managing monolithic applications on cloud. Managing the end points and making them work seamlessly with other microservices that are part of the application is not an easy task if the number of microservices are high. Yet, microservices architecture is more suitable for modern applications running on cloud.
What is a Serverless Function?
Serverless architectures are similar to microservices and can be considered as a subset of the larger microservices architecture. A serverless function is a small chunk of code that can handle a specific task based on a trigger. Serverless functions can be used to build large applications and some of the modern serverless platforms like Catalyst offer a way to run even long running applications like a web application. However, these functions require a trigger for invocation as opposed to microservices that run at all times. This event driven approach to invoking functions is a distinguishing feature of serverless functions and it takes away the need to run an infrastructure 24×7 in order to run an application. The function is invoked by the serverless platform by a trigger and once the function is executed, the instance running the function is either shut down or repurposed. This allowed cloud providers to offer the cost advantage Serverless platforms offer to the application developers.
What exactly is the difference?
With modern serverless platforms, the lines between microservices and serverless functions are blurring. Some platforms have no limits on the execution time allowing long running jobs on their platforms. So, the difference comes to how it is invoked and the underlying infrastructure for deploying the code.
- A microservice is usually an implementation of complex functionality that is made available continuously without any need for a trigger. Based on this nature, a microservice requires a continuously running instance to serve the microservice. Microservices are usually encapsulated in a container and deployed using a container orchestration tool like Kubernetes. A microservice can also be run on a virtual machine but it is not an efficient way to deploy compared to a container. Scaling a microservice implies running multiple containers continuously to meet the needs of the microservice. A microservice is not as cost effective as a serverless function because the underlying instance runs continuously. Similarly, a microservice adds an operational overhead for managing the containers and a YAML complexity associating with containing various containers needed to serve the application functionality
- A serverless function is a small chunk of code which is usually invoked by a trigger. This implies that you don’t need to have an underlying infrastructure always available to execute the functions. The necessary infrastructure can be invoked in a moment’s notice based on the trigger and it can be shut down or repurposed for other users on other times. Even though this kind of infrastructure can be used on-premises, this model is more suitable as a public cloud service. This kind of on-demand infrastructure provisioning and use, which is even more fine grained and short lived than virtual machines on the cloud, offers a newer pricing model. With this pricing model, developers can get the necessary compute for a fraction of pennies, thereby, democratizing application development
A typical application can be composed of both microservices and serverless functions. It will make sense to use a serverless platforms wherever applicable (including the frontends which can be invoked using the http calls from the users) and use microservices for the application components that require continuous availability. Pick a stack based on the nature of the application component than the other way around. If you are a developer building both microservices and serverless functions, I would love to hear from you on how you decide between these two architectures.