To Microserve or Not to Microserve
“You probably don’t need microservices” says this article. It’s easy to dismiss that as flame bait. The article is quite sensible though, looking at typical scenarios for employing microservices and how that can go wrong depending on the surroundings.
In a nutshell, here are the article’s examples for how microservices can go wrong:
Some companies end up having more microservices than developers. That’s a nightmare to maintain.
Low coupling and high cohesion are harder to get right in microservices. Lots of little services require lots of collaboration across teams if something needs to change.
Services are islands of knowledge, and the bus factor really hits hard that way. Fewer services make for more simplicity, not more services.
When a startup starts with microservices right away, then bam! we have an instant maintenance nightmare.
The article doesn’t really nail where the hidden costs of microservices are, but the examples give an idea. Its sensible bottom line is that if microservices limit a company’s ability to innovate, a strategy to reduce operational overhead should be introduced. This can be as simple as merging services. After all, they don’t magically turn into big ugly monoliths that way.