The monolith, microservices and serverless computing: pros and cons

Choosing between the monolith, microservices and serverless architecture for your product is essential to meet the business needs and ensure positive end user experience. How to choose right?

When a new software product has to be written, the developers must think of the product architecture beforehand. Will deploying a monolith product allow achieving the business goals? Perhaps, it would be better to split the app to several microservices that would interact through APIs? Or better still, maybe we should use some serverless computing services like Azure Functions or AWS Lambda and simply deploy our code and don’t worry about the underlying architecture at all? Let’s take a look at each of these possibilities and their pros and cons.

Monolith app architecture: complex development, simple operations

Monolith apps are the longest standing ones. The majority of enterprise legacy solutions is built using monolithic architecture, and despite all the jokes about the coding atop your dinosaur’s back these solutions have one undeniable advantage: they still work and do their job well.
Even if perceived as huge black boxes with unknown innards, these solutions have clear management algorithms, a restricted number of external interaction ports and predictable behavior.

Their largest flaw is the complexity of updating them, as disentangling the mess of code left by the original development process can be literally impossible. This can be due to the absence of initial developers or due to the code being written using a long-abandoned framework, etc.

Thus said, the biggest downside of legacy monoliths is their biggest advantage at the same time. They are limited and can pose a limited number of problems that have a limited number of solutions. This makes operating them predictable and relatively simple.

Microservices: simple development, complex operations

When instead a monolith solution you have a bunch of interconnected microservices, things seem to get a lot easier. Each component can be developed, tested and deployed by a separate team, it can scale horizontally with ease and can be reused as a part of other products. The recent advances in the functionality and popularity of Docker containers and Kubernetes container orchestration platform make using microservices for software delivery much more convenient and feasible.

The downsides of using the microservices include the increased complexity of developing each component to be able to respond to the other components’ requests; increased complexity of running the system operations; increased operational demands of ensuring the CI/CD process, etc. One of the most daunting challenges for many businesses is the fact that in order to use the microservice architecture efficiently for a software product, the business should employ an experienced DevOps team or opt for DevOps-as-a-Service from some Managed Services Provider.

Serverless computing: write the code, CSP handles the rest

Serverless computing allows executing any functions (thus the name for the Google, Microsoft and IBM offerings —Google Cloud Functions, Azure Functions, and IBM Cloud Functions) you might need without caring for the infrastructure — the servers, their software and tooling, the backup and scaling come with the offer. You simply write the code and run it, the platform handles the rest. While this might be an oversimplification, using serverless computing can be hugely beneficial for accomplishing one-time tasks or auxiliary processes.

No infrastructure setup, no load balancing and backup configuration, nothing of the usual pre-deployment routine —- you just write the code and execute it. Simple, yes? The main downside of these services, as well as their Amazon analog, AWS Lambda is their cost, as you have to pay for the intersystem traffic even within the AWS ecosystem. However, the convenience this service provides can by far outweigh the expenses in certain use cases, like the IoT, image processing, video stream data processing, and many more.

Final thoughts on the monolith, microservices and serverless computing

These 3 approaches are not contradictory, they should be considered merely a choice of tools. If your product is relatively simple and can run efficiently as a monolith — make it so, do not overcomplicate the situation by splitting it into microservices. If you need a code to be run after triggering by a certain event and do not want to pay unneeded attention to supporting the infrastructure for that — leverage the capabilities of serverless computing. Should you need to be able to recombine the parts of your product or update them separately — microservice architecture lends a hand. Thus said, we think the real winners of this competition are the developers, who now simply have more tools at their disposal.

We hope this article was an interesting read and invoked some considerations. Do you have an experience of splitting the monolith to microservices to share? Or do you use serverless computing to a great avail? Please share your thoughts and ideas on the matter! Should you need any help with configuring the microservices and serverless computing, or any other DevOps services — simply let us know, we are always glad to assist!