Ask HN: Why Not Microservices?

It’s pretty clear that microservices have fallen out of favor on HN. As someone who’s currently experiencing pain on both sides pro and con here, I’m curious to learn more about the argument. Is there more to it than “you’re not Google, don’t act like Google” for small startups? How about companies that are scale?

Careful consideration must be taken with a microservice architecture. The ideal situation is that each instance can work on its own and pass it along to the next microservice in your application. Having to reach out to other services for additional data would be kept to a minimum. This way, any given instance can be swapped out if or when it's needed without affecting the application.

However, as the application grows, it will most likely encounter scenarios where each microservice needs to do something more than what it was originally intended to do. A service might need information from an API or would need to access additional data from a database somewhere before it can work properly. And if that's the case, these hypothetical APIs and databases might be needed in other parts of the application as well. So now instead of everything being structured nicely with interchangable instances, you are now dealing with a network where any given node might not be able to be updated independently of the others. It can quickly become a large mess.

That aside, depending on the needs of your application and how it's set up, the various microservices can create a much larger cost than something like a monolithic system. Typically, each service would exist on its own instance, and your hosting provider will happily help you figure out your usage needs and the price that will come along with it.

Software development is about managing complexity. Think about it like this. If the number of lines of code in a piece of software is N, then the amount of effort required for managing that software is N^2 (or N^1.5, or whatever). Some people believe that by properly organizing software development, you can minimize or completely get rid of the exponential growth of the complexity. The idea is that the amount of effort for managing software containing N lines of code should be N.

Microservices tries to organize software so that complexity is minimized. In my experience, they completely fail to do so. Rather they actually increase the complexity by putting related pieces of systems far apart from each other. I think it is better to "embrace the complexity" and to concede that software development is difficult. Better developer tools and stronger developers are better methods for dealing with complexity than in vain trying to minimize complexity.

The most important benefit of microservices is that allows development teams to work and deploy independently of each other. For example, instead of having 100 developers working on a single app, you have 12 teams of 8 working on one microservices each. But you have to be careful how you structure your teams, since that is going to drive the overall design of the system. (See Conwayś law)

In real life many companies break their apps in too many small microservices and you end up with a "distributed ball of mud". Which is way worst than the original monolith.

As mentioned the most common motivation is for scaling the number of developers/teams. Other good motivations:

Differences in the maturity of software. You have a mission critical revenue generating core and newer experimental forays into new territory. You want to do this rapidly tolerating more risk but don't want to destabilize you cash cow.

Certain parts have differing requirements. e.g. a payments system may need greater auditing and compliance levels and separating it makes this easier to do.

The other often cited reason is ability to scale the infrastructure independently. This is still true even with cloud offerings, being able to size and configure parts differently can get you a long way into scaling. The alternative view is that you'll need to shard eventually and the sooner you figure this stuff out it can save you from having to implement a lot of intermediate scale solutions. Even with shards, you can still run into reasons to run parts of you system differently. e.g. choice of datastores, storage engines, isolation levels, etc.

I've worked in pretty much all these cases, as well as the let's do microservices from the start. That was hard as we were doing instant messaging and message delivery failure rates are critically important. At the same time, it wasn't unachievable with only a 3-4 pizza-sized number of devs. Not optimal though when the number of services =~ number of devs when you have turnover and have to learn/teach them all. I can say being able to change something and have CI run unit/integration/end-to-end/journey tests in a blue-green deployment to prod in 2 minutes is something I'll always miss.