Building a quality product does not mean you have to always start with microservices
Having come into light just a few years ago, Microservices are still getting a lot of attention today. I am sure you may have heard how Microservices can help defeat and overcome the issues and problems inherent in Monolithic applications. By listening to hundreds of conference talks, tech sessions, and testimonials by large organizations, explaining how they have eventually overcome most of their issues by transitioning from monolith to microservice architecture, seems it's the go-to solution in today's world.
While this transition from monolith to microservices marketecture makes sense for a large organization with a well-set product/solution, does this mean it is always good for a startup or small business? Is this the end of monolith architecture?
Monolithic applications also referred to as monoliths are those which are huge systems, it’s just one computer, which is running the entire system. All the clients who are connected to the application must connect to a single computer.
These are some of the misconceptions that I am highlighting here.
The monolith does not need to be a single computer, there might be multiple horizontally scaled instances of the same monolith and these clients can connect them with a database or more databases.
So, you can horizontally scale, or you can scale out even with a monolith.
They are large codebases, which contain all the logic required to run the application, are deployed together at the same time, and run together on the same server(s). In other terms, the monolith is a type of architecture in which all components of the application are packaged together as a single deployable unit.
Monoliths have several benefits,
Simple to develop: Everything will be in the same language and same framework. Communications are clearer and more explicit.
Easier debugging and testing. Compared to the microservices architecture, monolithic applications are much easier to debug and test. Since a monolithic application is a single indivisible unit, we can run end-to-end testing much faster.
Deployment and Scaling applications are straightforward: Single application to deploy and easily scale out to new instances behind a load-balancer.
Lower Latency: Because you are not making any calls over the network. All the logic and code are on the same computer.
Higher throughput: Monolith doesn't have the overhead of images and orchestration
We have talked about the good side of a monolith and now, the weaknesses of the monolithic architecture,
Too much Responsibility on each instance: If there is a mistake that will crash a server, all these servers can collapse.
When scales up, complicated to understand: When a monolith scales up, it becomes complex to understand and work with. The learning curve for a new developer will be high.
Scalability. You cannot scale components of the application independently, only the whole application.
Let's look at Microservices, There's nothing micro about a microservice.
The microservice represents a business vertical consisting of functionality and data grouped by a relevant business concern.
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
- Martin Fowler
A microservice architecture has several advantages over a monolith,
Strengths of a Microservice Architecture
Scalability, each service can be scaled independently.
Agility. Any fault in a microservices application affects only a particular service but not the whole solution.
Good separation of concern
Flexibility in choosing the technology, With microservices we can mix multiple languages and multiple technologies.
But these benefits will come with some costs;
Testing: a multitude of independently deployed services makes testing a microservice-based application hard.
Eventual consistency: In a distributed system, each system has to manage eventual consistency.
Extra complexity: Microservice-based applications are hard to develop, with high latency, and are always at risk of failure.
also, Microservices require profound expertise to develop them and get actual benefit from them.
Deciding what to choose:
In my Personal view, Starting with microservice architecture is not a one-size-fits-all strategy. Despite microservices being a popular buzzword, a monolith has its strengths and enduring advantages which work better for many cases.
When you need to validate your fresh million-dollar idea, you should start with a monolithic application. When planning for a simple solution with a small development team, I don't see a reason to implement microservices. The monolithic application will be much easier to build, make changes, deploy, and test.
In simple terms, if you can manage your system’s complexity with a monolithic design then you shouldn’t be using microservices.
The microservices architecture is more useful for complex and evolving applications. It will help to provide effective solutions for handling a complicated system of different functions and services within a single application. Microservices are ideal when it comes to complex domains, with many user journeys and workflows. But without proper microservices expertise in the team, applying this model would be troublesome.
Always remember that most of the success stories of microservices we may have heard on keynote speeches have started with a monolith that got too large, and then got broken up and migrated into microservices.