On monoliths and microservices.

Just a decorative image for the page.

Introduction

Since around 2015, microservices have been sold as the revolutionary way to make businesses more agile and responsive. Promoted as the ultimate solution for modern software development, microservices have generated countless success stories on platforms like YouTube - often likely with a heavy dose of survivorship bias. An entire industry has emerged around tools and services for microservices, and many software engineers remain convinced that microservices are the answer to all software development challenges.

But microservices can destroy your business. And most often there are better alternatives.

You might also be interested in the following two posts related to this topic:

Table Of Contents

My Experience

In my experience, microservices are often the wrong choice for most projects. Adopting microservices can:

  • Reduce your team’s productivity
  • Result in a zoo of unmaintainable technologies
  • Lead to numerous hard-to-debug problems
  • Become very slow due to the shift from in-memory communication to network-based communication

What Are Microservices?

Microservices are small, independent services, each with its own domain (hopefully), communicating over a network and often running on Kubernetes. They have independent deployment cycles and require a high level of experience and skill to implement effectively.

Unfortunately, many companies adopt microservices for the wrong reasons, treating them as a playground for developers rather than focusing on building valuable features. The result is often a distributed monolith with very strong dependencies that you did not want to have in the first place.

Microservices can make sense - e.g. in scenarios where certain parts of the code need to be extremely performant and run on their own hardware. In such cases, the decision to isolate high-performance calculations into individual services will come naturally.

Creating microservice in order to create microservices will put you into trouble. And no - it’s not a good idea to start with a microservice architecture, because it will help you scale in 2 years from now.

The Microservice Risk

Microservices are neither inherently good nor bad; they are simply a tool designed to solve specific problems that you probably don’t have. The risks include:

  • Difficult setup and steep learning for new developers
  • Difficult debugging
  • Hard-to-trace communications (enter trace-id in your HTTP headers)
  • Error-prone and slow HTTP communication compared to in-memory communication in monoliths

The Alternative: The Monolith

Designing your application as a single unit is often the right choice for most cases, especially for SaaS applications. This is the standard architecture for almost every web framework, including Play, Laravel and Ruby on Rails. There is absolutely nothing wrong with this approach, and keeping things simple does not make you a bad developer. You can still apply all your Clean Code skills and keep things SOLID, leveraging Domain-Driven Design (DDD) and respecting the component principles from Clean Architecture.

Upside of Monoliths

  • Easy to debug
  • Easy to maintain
  • Easy to deploy
  • Trivial to setup on a developer’s machine

When You Outgrow the Monolith

You always have the option to operate multiple applications instead of combining everything into one. This doesn’t mean you are doing microservices; it’s just pragmatic software development.

Boundaries at the application level are very natural, and most companies do this intuitively, such as having separate applications for a shop, a PIM, and an Auth System.

Microservices vs. Properly Structured Applications

A properly structured monolith is a very viable alternative in most cases. Use as few additional systems as possible to keep things fast, simple, and crisp (e.g., PostgreSQL as document storage, RDBMS layer, and search appliance). Create a 12-factor app for easy deployment and use systems that facilitate deployment (Beanstalk, Blue-Green deployments, Zero downtime).

Important: You are paid for delivering value to clients, not for implementing a custom layer that can do zero downtime deployments on EC2 servers and breaks every second day.

Recommendations

  • Always start with a properly structured monolith. It reduces risk and effort.
  • Only use microservices when you have really good reasons for it.

By keeping these recommendations in mind, you can avoid the pitfalls of microservices and focus on delivering real value to your clients.

More:

Related posts

Imprint | Privacy Policy