monolith vs microservices
In the software development world, it is no surprise that something new emerges every day, and becomes hype. And some of them are short-lived, but others may stay around longer, like microservices that everyone keeps talking about. Is it just another buzzword like blockchain or AI, or a breakthrough so it has still popular? In order to understand, you need to know the monolith system that is the opposite of microservices, which in fact just breaks a monolith system into multiple smaller systems. You can immediately see the benefit of manageable systems, narrowed down scopes, clear boundaries, and many more. But there is a price you have to pay in exchange for those benefits.
Whether it is an application started a decade ago or a greenfield project, monoliths are not going away. In fact, most new businesses may start as a single application that can easily end up being a monolith. And this is fine for various reasons such as it may be difficult to draw boundaries or may not be at the top of the priority list. However, it may go out of hand quickly as the complexity starts to grow. So, knowing when to start moving from monolith to microservices is crucial.
Even though some may choose to start with microservices from the beginning if they can, most of the time, it starts with breaking monoliths into microservices. That is, it has to be possible to draw boundaries between parts of the monolith so that the parts can go into independent microservices. Mostly, this first requires refactoring inside the monolith application.
As the parts or modules have become independent moving systems on their own, in a separate application, but just communication with the outside world through APIs, a new type of issues emerge such as the communication cost, who owns which data, when or where to retry, tracing a flow throughout the distributed system, distributing locking, etc… In short, with microservices, you will have subsystems that are easy to understand or grasp, while understanding the whole flow, making things work, or keeping data consistent become new type concerns you need to deal with.
As always, nothing is a silver bullet and we have to trade-off alternatives. That is, assessing the cost and benefits of application architecture depends on various factors such as time, priority, available resources, as well the complexity of the system. In uncertainty, it would be a straightforward approach to start with monoliths. When the application starts getting in shape, having conceptual parts, then you can start thinking of microservices.