Ask HN: Why Not Microservices?

In my experience, microservices are an emergent property of Conway's law [1], essentially that a system's architecture will tend to ship it's team(s)' communication structure. The biggest bottleneck to software engineering is communication between engineers, especially as teams grow beyond 3+ people working a single system. It becomes difficult to keep everyone on the same page about every design decision and change, which becomes obvious if your team does code reviews (imagine if every code change required 3+ approvals). Communication unfortunately scales O(n^2).

As a result, What makes a "team" is it's leadership structure, I.e it's determined by the number of engineers who want to be leaders (which includes accountability and ownership). If you have a team with multiple leader-types who want more ownership, and a natural seam in the solution space emerges to spin-off, they will tend to become the communication hubs for other engineers, and eventually spin out into their own subteam with their own microservice. They'll want their own abity to release when necessary, and choose dependencies without needing to convince everyone beyond their immediate subteam.

In short, if you're 1 person, microservices make little to no sense given the addition work and complexity involved. If you're more than 1 engineer, it depends on individual engineers willingness to be a lead and own a whole part of the system and become a communication hub. Companies like Google and Amazon will have lots of microservices because so many engineers want to be tech leads (either for promotion or self-fulfillment).

[1] https://en.m.wikipedia.org/wiki/Conway%27s_law

One disastrous way microservices architectures can fail is when they stop being aligned with features and therefore stop test-driven development from working.

The promise of test-driven development is that there is a vanishing amount of code that is not under some sort of meaningful test coverage. Those tests have to target the smallest possible parts of the system to be efficient, else tests are just too brittle and slow.

Test-driven development works best for self-contained systems that represent the whole feature. Using it encourages architecturing the system in this way.

There are three environments where it doesn't work: graphical user interfaces, monoliths and distributed systems. The biggest issue with these is the huge state space to test and their comparative slowness. Also, they are usually expensive to set up and maintain.

I think where people get into trouble is when they try to implement a true microservice architecture without actually understanding the tradeoffs and complexities. You will likely end up with a spaghetti rube goldberg mess with weird service dependencies.

I also think people tend to strive for too much purity. It's okay if you want to avoid the replication and event bus complexity of microservices and choose a monolith-esque database architecture. Just split your APIs across business domain, leave your database as it is, and be done with it.

Just make sure you stick to the fundamental principles of microservices. Scoped, fault tolerant, independently deployable. Fault tolerant does not 100% have to include database failures. Don't ever directly cascade API calls from one service to another.

The biggest "why not" is that you should choose the architecture that best solves the problem. Don't treat architecture as a playground to try out random shit. Solve the business problem in the simplest way possible. In most scenarios you probably don't need isolated, fault tolerant, distributed services. I would guess that 75% of microservices implementations fall under the premature optimization anti-pattern.

I already noticed that microservices fell out of favor with current high cargo cult culture. But which buzzword compliant type of architecture is next?

There is no such hypothetical book. I've read many of them and collectively don't cover what you'll need to know or do. There's also very few things everyone knows about microservices. Choosing the right bounded contexts is the biggest knowledge gap and most examples talk about noun1 service and noun2 service.

Learning about microservices by reading books that distill it into abstract examples is like learning Haskell by reading about category theory. Maybe possible but challenging and not for everyone.