Microservices vs monolithic architecture: Which comes first?
The smoldering conflict between the cheerleaders of microservices vs monolith architecture is ongoing as industry professionals cannot decide which should come first. Some claim that one should not start with a monolith if the goal is a microservices architecture while others put their faith in monoliths. Each side has a point, but it’s time to shed some light on this never-ending dilemma.
If you ask Martin Fowler, author and international public speaker on software development, which comes first -microservices or monolithic architecture-, he would say that monolith should be one’s first choice. The software development master explained in a blog post that nearly all the successful microservice stories began with a monolith that was eventually broken up as it got too big. Plus, almost all the cases where he has heard of a system built as a microservice system from scratch ended up in trouble. Meanwhile, Stefan Tilkov, co-founder and principal consultant at innoQ, explained in his rebuttal to Fowler’s piece over on the author’s website that one should not start with a monolith.
PwC offered microservices a vote of confidence two years ago when it published a piece suggesting that microservices is the better choice. “Companies such as Netflix, Gilt, PayPal and Condé Nast are known for their ability to scale high-volume websites,” Galen Gruman and Alan Morrison wrote. The duo explained that these companies have adopted “a more modular and loosely coupled approach based on microservices architecture with the goal to eliminate dependencies and enable quick testing and deployment of code changes.”
When to switch to a microservice architecture
Many industry professionals continue to cheer for a monolithic architecture and explain that the microservices approach is too complex. Fowler wrote in a blog post titled MicroservicePremium that one has to be prepared to devote time and other resources as they all come with the territory (microservices). He stated that microservices should not be an option unless the system is too complex to manage as a monolith and clarified that the complexity which drives some people to microservices comes from a plethora of sources, including supporting many user interaction models and dealing with large teams. However, the biggest factor is the following: “people finding they have a monolith that’s too big to modify and deploy,” Fowler said.
The author debunked another myth, namely that one should use microservices when a system increases in size in order to have parts which are easy to alter and replace. However, one can definitely make a monolith with well-defined module boundaries, Fowler judged as he reminded readers that “the microservices approach brings a high premium,” which means that development can be slowed down considerably.
Tilkov’s rebuttal came less than one month after Fowler’s piece — in which he clearly stated that “starting with a monolith is usually exactly the wrong thing to do.” According to innoQ’s co-founder, if you choose to start with a monolith, “the parts will become extremely tightly coupled to each other and will (almost) freely share domain objects, rely on the same, shared persistence model, assume database transactions are readily available so that there’s no need for compensation.” Although he acknowledged that sometimes a monolith is the better choice, he emphasized that one should realize that “while it will be a lot easier to make localized decisions in each individual part, it will be much harder to change the very boundaries that enable this.”
Microservices architecture goes hand in hand with complexity and comes with a baggage of costs and risks, but this does not mean that a monolithic architecture is automatically the correct choice. In the end, it all goes down to the company’s needs and expectations, as well as their willingness to take risks.