betterprogramming, a Medium site, posted “Stop Using Microservices. Build Monoliths Instead.,” which… the title’s very click-bait, as many Medium titles are, but there’re some interesting points in the article nonetheless.

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.

The headings in the article sum up the points pretty well:

Managing Data is a Nightmare

This section describes how following the chain of data in the case of an error can be “interesting,” if only because it requires a lot of coordination to keep data synchronized in format and in consistency.

More Time Setting Up

This makes sense, because after all, you’re not deploying one service, you’re deploying multiple services, all to create one application. He also brings up code duplication, although this is a minor point in a world of endless disk space and easy modularity.

Microservices Work Best for Large Teams

The luxury of assigning microservices to individual teams is reserved for large engineering departments.

Although it’s one of the big touted benefits of the architecture, it’s only feasible when you have the engineering headcount to dedicate several engineers to each service. Reducing code scope for developers gives them the bandwidth to understand their code better and increases development speed.

Good point - engineers in smaller companies who don’t have the luxury of working in silos end up having to switch contexts entirely to work on various services, and context switches for engineers are time sinks. (Think of the trope where someone’s deep in thought, only to be asked if they’d read an email yet… thus losing all of the deep thought work they’d put in.)

DevOps Is More Complicated

The deployment requirements for multiple apps all vary, obviously, and this means more work analyzing what deployment should look like for each service.

The author also brings up failure conditions, but honestly, this sounds like he managed errors poorly in at least one case, but as I have no visibility here, there may be issues that were outside of his control.

Takeaways

A lot of companies use microservices without really needing them. And despite their current popularity, microservices aren’t for beginners.

Most companies would be better off building a monolith and then splitting off pieces of the monolith into microservices when absolutely necessary.

Leave rolling a microservice architecture from scratch for large tech companies with deep pockets.

Your early-stage startup probably isn’t ready. Mine wasn’t, and it cost us significant time and energy.