Sharing a new article by a seasoned software engineer and tech enthusiast Alex Babin (with his permission).

As of 2023, microservices are all-pervasive in the IT world. According to Statista, 85% of respondents from large companies (5,000 or more employees) claim they are currently using microservices architecture for their IT projects.

With microservices seemingly deemed to be a new norm in software development, why would anyone choose to get back to monolith? Well, there’s some substantial reasoning for this transition.

As Eberhard Wolff argues in his paper Why Microservices Fail: An Experience Report, in the microservices architecture, “excessive effort is spent on matters that do not really help the project” — mostly due to its complexity and massive use of diverse tools, languages and frameworks.

Today, I’d like to dive deeper into what makes monolith a better choice in certain scenarios. Let’s start!

Common issues with microservices

While microservices architecture offers numerous benefits, it also comes with some potential downsides that should be considered. Here are a few:

Increased complexity

Microservices require managing a larger number of services, each with its own deployment, monitoring, and management requirements. This introduces a higher level of complexity compared to monolithic architecture. With multiple services communicating with each other, there is a need for robust network communication and coordination mechanisms.

Distributed system challenges

Microservices architecture introduces the complexities of distributed systems, such as handling network latency, ensuring data consistency across services, and managing failures and errors. It requires implementing proper error handling, resilience mechanisms, and fallback strategies to maintain the overall system reliability and performance.

Testing and debugging issues

With microservices, testing and debugging become more complex due to the distributed nature of the architecture. Testing individual services in isolation and ensuring proper integration testing can be challenging. Debugging issues that span across multiple services requires additional effort and specialized tools to trace and diagnose problems.

Development and deployment dependencies

Microservices often require services to be developed and deployed independently. This can lead to dependencies between teams working on different services, potentially slowing down the development and deployment processes. Ensuring proper coordination and communication between teams becomes crucial to avoid compatibility issues and ensure smooth integration.

A sample microservices architecture on Azure Kubernetes Service (AKS). Source: Azure documentation

When does monolith offer a better fit?

Let’s now consider some scenarios where monolithic architecture typically works better than microservices.

• Firstly, a monolith can be a better choice for projects with fast turnaround times, since it is easier to develop and deploy as the entire application is built as a single unit. This simplicity can result in faster development cycles and reduced complexity in deployment and management.
• Additionally, monolithic architecture can be more suitable for smaller applications or projects with limited scalability requirements. It can also provide better performance as all components of the application are tightly integrated and can communicate with each other more efficiently.
• Another typical use case for a monolithic architecture is when the project has well-defined and stable requirements. In such scenarios, where the application’s functionality and features are not expected to change significantly over time, a monolith can offer a straightforward and predictable development process.

For example, Amazon recently shifted back to monolithic architecture for video monitoring stating that it “produced superior performance over a microservices and serverless-led approach.” Specifically, the tech team reported that moving their service to a monolith enabled them to reduce infrastructure costs by over 90% as well as increase the scaling capabilities.

The updated architecture of Amazon’s audio/video monitoring service. Source: Amazon Prime Video blog

So which one is better?

The short answer is: the one that better works for your purposes! More specifically, while microservices can be an ideal choice for highly scalable and complex systems that require flexibility and independent service management, there’s no reason to downgrade monolith simply because it’s not so widely used anymore.

In many scenarios like small-scale applications with limited resources or projects with well-defined and stable requirements, a monolithic architecture can actually be the optimal solution. It provides simplicity, easier development and debugging, and avoids the complexities of managing a distributed system.

In case you’re not sure whether you’ll need to switch to microservices as your system is scaling, a good solution is to use a language such as Elixir that offers a powerful combination of features. It provides a strong module system with built-in tools for analyzing dependencies and simplifying function calls through its macro system. Additionally, Elixir’s built-in actor system enables concurrent and fault-tolerant execution of code, allowing for easy scalability and distribution across multiple machines.

In general, starting with a monolithic architecture is often the optimal approach. However, if the need arises to extract certain components into separate services, you can do so with minimal code changes if you use Elixir. Furthermore, if the transition to microservices becomes necessary, you will already have the required modularity and DevOps setup in place.