Member-only story
Stop Using Microservices. Build Monoliths Instead.
Why most companies would be better off avoiding microservices
Microservices can seem like the perfect solution.
In theory, they increase development speed while allowing you to scale different parts of your app independently.
But in reality, microservices come with hidden costs. That said, I don’t think you can truly appreciate their complexity without building them firsthand.
Here is what I learned building (and sometimes failing) with microservices.
Managing Data Is a Nightmare
Keeping data in-sync across microservices can be challenging.
A database per microservice is the recommended pattern. It allows loose coupling and permits service-specific teams to function independently without slowing down to collaborate on a shared code.
But what happens when one of two microservices that are supposed to fire in sync fails? For instance, one of those microservices updates its database but the other does not.
Situations like this create inconsistencies in data.
From personal experience, investigating data inconsistencies across services can be painful. The cross-service nature of the error requires a person to work across multiple services to rectify the error. Unfortunately, this then invalidates one of the benefits of microservices to begin with — team-specific services.
The same situation in a monolithic app could have easily been prevented by wrapping both DB calls in a single atomic transaction, so all inserts succeed or none of them do. Easy peasy.
But with microservices, loose coupling makes that more difficult.
More Time Setting Up
Building out a microservices architecture takes longer than rolling the same features into a monolith.
While an individual service is simple, a collection of services that interact is significantly more complex than a comparable monolith.
Functions in a monolith can call any other public functions. But functions in a microservice are restricted to calling…
