When should I choose between serverless and microservices?
Serverless and microservices work well together, but they still have their unique qualities. We review their main differences and where one might accomplish goals the other can't.
The quest for greater agility, improved performance and scalability brought forth the advent of technologies like microservices and serverless computing. Although serverless computing shares some of the characteristics of microservices -- and developers can use them together -- there are several differences between them. And, sometimes, one is more suited for the job than the other. To know which to use, developers should learn how these two architecture types compare and contrast.
Microservices are best suited for long-running, complex applications that have significant resource and management requirements. You can migrate an existing monolithic application to microservices, which makes it easier to modularly develop features for the application and deploy it in the cloud. Microservices are also a good choice for building e-commerce sites, as they can retain information throughout a transaction and meet the needs of a 24/7 customer base.
On the other hand, serverless functions only execute when needed. Once the execution is over, the computing instance that runs the code decommissions itself. Serverless aligns with applications that are event driven, especially when the events are sporadic and the event processing is not resource-intensive. Serverless is a good choice when developers need to deploy fast and there are minimal application scaling concerns. For example, a good use of serverless computing is a scheduled task that needs to perform some data aggregation and will execute for just a few seconds.
As a rule of thumb, choose serverless computing when you need automatic scaling and lower runtime costs, and choose microservices when you need flexibility and want to migrate a legacy application to a modern architecture.
As a rule of thumb, choose serverless computing when you need automatic scaling and lower runtime costs, and choose microservices when you need flexibility and want to migrate a legacy application to a modern architecture.
An IT organization is more likely to be responsible for a microservices application's operational overhead -- deployment, configuration, support, maintenance and monitoring -- than for that of a serverless application. While it is technically possible to run serverless on in-house IT resources, a typical serverless computing model relies on a cloud vendor that performs all server management, capacity planning and support tasks for the underlying infrastructure.
Functions
Serverless architecture uses Functions, which is a named procedure that performs a distinct service and returns a value to the application. Typically, a microservice is larger than a serverless function. And, unlike a serverless function, a microservice can perform more than one function. In other words, a microservice may equate to one or more serverless functions.
Pricing
Cost can be an important differentiator between serverless and microservices. This relates back to the previously mentioned difference that serverless only operates when the application must execute a task, while microservices operate continually. Serverless computing products, such as AWS Lambda, work on a pay-as-you-go model, which means the provider only charges for the specific period of time that the server executes the function. While it is relatively cheap to provision microservices on containers, you pay for the instance to run 24/7, even if there is no load.
Can serverless and microservices work together?
The choice isn't always between serverless and microservices, because some applications rely on both. Microservices and serverless integrate and complement each other's strengths and weaknesses. You can choose to deploy microservices as part of a serverless architecture, or you can host them in containers. Remember to consider portability issues, because serverless applications can only deploy within their respective vendor's infrastructure.
