Many of us as developers are curious about Microservices. It’s pretty reasonable considering the trend created by the industry, where many big players have adopted Microservices.
But what made them so successful? Is it;
The problems they solved at scale?
The funding and guidance?
Architecture and technology?
The people?
As we all know, it’s a combination of all these and many more factors that drive their success.
Facts that we can’t deny
What brought these large tech players to where they are in the first place? At least to earn the first Billion. Was it the Monolith or using Microservices? I’m pretty sure we can’t deny the fact that most of these Unicorns make their initial fortune with a Monolith.
Then, they had enough money at hand to solve the problems that come with scale, like moving into Microservices. And you will also agree with me that there are many successful companies yet to adopt Microservices.
Is Monolith evil?
When we look at a Monolith, we see the common challenges that come at scale, like;
Longer build times.
Many developers work on the same code base.
Frequent code conflicts.
Coupling in code and modules.
Here, the controversial part is whether these challenges are applicable for everyone? The obvious answer is no! Some businesses might get these issues once they grow and in the future, but we hardly do big design upfront these days.
Therefore, in short, Monolith isn’t that bad. It has worked for software giants in their early days, and it should still work for you as well. So, we have to first answer;
What scale are we talking about?
The size of the Monolith?
How well was it architected and maintained?
How many developers working there?
How long does it take to iterate through code?
There are so many questions that you have to think about before changing your mind to move into Microservices because;
Microservices are hard
Building Microservices the right way is difficult. These are distributed systems we are talking about, which require more resource demand, high expertise, and effort involved to get them up and running.
In addition, if you are new to it, it will hinder your speed upfront or lead to expensive mistakes. In some cases, the technology effort would be costly enough to throw you out from the competition.
But, isn’t it worth the effort as a future investment?
One of the widespread misconceptions in the industry is, “Microservices have vast benefits in the long run if you are ready to pay the price now.”
If you are building a software application, think of a competitor using a simpler architecture, boosting speed, going to market first, and capturing it. Then will you be able to reap the future benefits?
And we have already learned BIG-DESIGN UPFRONT is not the way to go.
Who will benefit from Microservices?
If you build an enterprise application where you know more information about various subsystems or modernise an existing application, there could be genuine reasons to move ahead with Microservices.
This is where you need the expertise to analyse your situation and come up with a decision.
As an architect, the importance is focusing on the quality attributes and tactics to solve the business problem before choosing the architectural style. If you see that Microservices tactically works better than a Monolith to address these quality attributes in your system, go for it. Otherwise, you can stay with a Monolith architecture.
Should a Startup adopt Microservices?
As most of you have already experienced, Monoliths come with the least friction, to begin with. Since the speed to market is vital for any new business, we can’t waste time building the foundation that serves the company five years into the future. We have to focus on bringing in the speed and agility of the development for the short term and then inspect and adapt.
For instance, think of building a frontend and backend where the number of decisions you have to make is minimal. You can put all that time that you spend on microservices building a distributed system to code business logic.
This will speed up the application development even up to several years until the team size, and the application is massive enough to experience drawbacks of the Monolith.
Summary
Microservices is an excellent architectural style to address specific problems in large software applications and teams that appear with scale.
It’s not suited for many software products, especially at an early stage, but eventually, any successful business would come to a stage to decide on that transition. If you are an enterprise, microservices could become handy since you know most of your domain boundaries really well.
Besides, if you are moving into microservices, experience is vital, and therefore it’s essential to find the experts that could help in that transformation. Otherwise, the mistakes in architecture are costly and difficult to change with time.
