EnglishSelf-professed minimalist developer Kelsey Hightower a few months ago wrote about monoliths being the future.
The microservice design pattern has been trending in software development for quite some now. Unfortunately, more often than not it’s been indiscriminately treated as a panacea to every software architecture and design problem out there.
Microservices can help with one aspect specifically: Reducing deployment risk.
If you have a large monolith and frequently need to make changes to a specific part or feature provided by that monolith the whole application will be affected by deployments. Not only will you have to rigorously test your entire application for each deployment – even if only a small part of it has supposedly been changed – but the application as a whole won’t be available during updates (not taking into account measures such as application server clustering for high availability here).
This used to be – and in fact still is – a common pattern within large organisations: Applications only get updated very rarely because of the risk and test requirements involved. This in turn reduces an organisation’s capabilities to quickly react to changes or introduce new features through rapid delivery of new software and software iterations. Therefore, risk and risk aversion directly lead to change aversion and inflexibility.
In those cases, a microservice architecture can be a profoundly useful tool to bring about organisational change by making an organisation more agile and able to more quickly react to market demands (see Conway’s law). However, applying the microservice design pattern for any other purpose than to improve an organisation’s ability to deliver software for the most part is a futile exercise.
I’ve long been arguing against what essentially amounts to using microservices for microservices’ sake or for – often largely imaginary or non-existing – non-functional requirements such as potential future scalability.
What we often get when indiscriminately using microservices is the worst of both worlds: A distributed monolith.
In lieu of just having to think about how to modularise our software and break it down into loosely coupled components with microservices we’ve introduced infrastructure concerns into our development process. Often, this means that the focus will shift from developing relevant code to building and struggling to maintain infrastructure that’s largely irrelevant to the business at hand.
For these reasons, Kelsey Hightower claims that in many cases a monolith won’t just be a sufficient but in fact the most appropriate architecture pattern.
I couldn’t agree more.