Microservice is a new hot trend in the Application Architecture Landscape. Everyone in the IT world is talking about microservices.
Every enterprise is either working on a microservice or porting their existing monolith to Microservices. This term has become really popular that people outside of the organization are also using it to explain something or the other.
In any case, if you are thinking that microservices are new, then don’t be fooled. The microservices has been there for quite some time (1997 to be exact). It is just that at that time, the need for such an architecture was sleek.
In fact, all the enterprises that are older than 10 years are still using monolith architecture.
Then how and why did Microservices became so famous recently?
Well, this article is going to be all about that.
Below is the outline of this article:
- What are Microservices?
- How big a microservice should be?
- Advantages of Microservices
- Disadvantages of Microservices
Feel free to start from anywhere 😉
What are Microservices?
First of all, there is no single definition for Microservices. The definition that I liked the most is from Sam Newman book Building Microservices. Microservices are –
Small autonomous services that work well together
The use of the word “Small” is controversial. But I will come to that later, the important thing in the definition is the “Autonomous services”.
The most important aspect of a Microservice is its autonomy. It is a very important characteristic. It is the ability of a Microservice to change and evolve independently.
The best way to understand its importance is to compare it with the Monolith architecture.
Suppose you have to make a small change in the application, just a single line, then these are things that you will have to do in order to deploy it (Very High Level):
- Make sure all the unit tests pass
- Make sure all the integration tests are successful
- Deploy the entire application to production
Now imagine the complexity of performing the above steps in a big monolith application vs a small microservice.
The first thing that gets impacted is time.
It takes a lot more time to run all the tests in a monolith application compared to a microservice.
In monolith applications, the risk percentage is higher as compared to the microservice. With microservices, a big module is divided into multiple smaller modules. And each of this small functional component can be deployed autonomously. Therefore, the risk of failure is minimized.
How Big A Microservice Should Be?
I’ve used the word “Small” in multiple places while describing microservices. Now I would like to explain what I really meant when I said the word: SMALL.
People usually measure the size of software by the lines of code it contains. Well, the number of lines of code is a tricky deal.
There are multiple factors that weigh in.
It can highly depend on the language that it is built-in. For example – writing a piece of code in Java would take more lines while writing the same code in Python.
Language plays a huge rule in deciding how many lines of code it will take to implement logic.
So, lines of code is not a good way to measure a microservice.
Then what is?
Well, I have worked on microservices containing 100 lines of code to 10,000 lines of code. So I can say it very firmly that lines of code are not the true measure of a microservice.
The true measure of size for a microservice is that it should focus on doing only one thing and one thing well.
Then it doesn’t matter if it takes 50 lines or 1000 lines or 10,000 lines of code to achieve that. Just make sure that your microservice is responsible for only one thing and doesn’t have external dependencies for its task.
I hope you got the point. If you have any opinion then feel free to share it in the comments below.
Advantages Of Microservices
There are a ton of advantages of Microservices. That is the reason every large enterprise is preferring this architecture to drive their business.
The first and the biggest advantage of having a microservice architecture is that it aligns well with your organization.
Better Alignment With The Organization
Microservices solves many of the organizational issues that were there with the monolithic architecture. It aids an organization to better manage multiple teams working on the service.
Since each service is autonomous, it is easy to divide these and spread across the geo-location in such a way that each team can completely own that service.
This makes parallelization easier. Multiple teams can work on different services at the same time without depending on other teams. This also speeds up the development.
“Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.”~ Melvin Conway
Not only that. It helps the enterprise to expand quickly.
Release Functionality Faster
As Microservices are autonomous, therefore multiple teams can work on each microservice in parallel. This results in faster development and quicker release cycles.
In today’s world, where the competition is fierce, staying up to date with the latest feature has become a necessity. If enterprises cannot keep up the pace they cannot sustain the business. And microservices gives them this speed and flexibility.
This was one of the major drawbacks with the Monolithic architecture.
Businesses use to wait for the next release date for any new feature to be effective. Since a lot goes in deploying the monolith systems, small changes are mostly avoided.
Whereas, with microservices, most of the time it as simple as making a new git commit and rest is taken care of by the CI/CD pipelines.
This is directly linked to autonomic nature of the services.
As each service is complete in itself and doesn’t have external dependencies, each can scale on its own.
Scaling a microservice is similar to the copy-paste command of your computer. Where a single instance is cloned into multiple instances.
Sure there are infrastructure level complexities present but once you have the infrastructure to support microservices, scaling is just a click of a button away.
Easier To Focus On Security Concerns
When you have multiple small components that interact with each other over the network, then security becomes a major concern.
With a monolith, there is only one gigantic component that does everything. And most of the time single security architecture takes care of all the different sub-components.
However, this is not the case with microservices. Each and every component is on its own and therefore it provides a higher degree of flexibility into implementing security.
There could be one service that doesn’t deal with secure information and a hence different set of security rules apply there. Similarly, there is another service that deals with secure data therefore a totally different set of security applies to that module.
Doing the same in a monolith can make it really complex.
Therefore, with Microservices architecture it is easier to focus on different security concerns.
Adopt Technology Faster
This is one thing that I love the most about microservices.
You are no longer bound to the same technology that you chose 15 years back. It is very easy to adopt and test new technologies with microservices.
Each microservice can be written using a completely different technology stack. This helps the organization to choose the right technology for a particular service without wondering about the compatibility.
And if certain technology is not working out well for your enterprise, you always have the option to replace existing with much fewer efforts compared to the Monolith.
With a monolith, you are bound to the same technology stack that you started a long time back.
I have worked with enterprises that are still using JAVA 6 and are afraid to move to the new tech stack because they have big monolith to handle.
Sure microservice will help enterprises adopt new technology faster and efficiently. It is a big advantage.
Disadvantages Of Microservices
There are many goods with Microservices but with all the goods comes downsides as well.
Some of the disadvantages that I can think of are:
Many, Many Options
There are multiple ways of implementing Service Oriented Architecture. And this flexibility does more bad to people than good.
Designing a microservice in the right way requires a good knowledge of business and technology. Lacking in any one of the fields can lead to a bad design.
Special consideration is required while trying to implement the service-oriented architecture.
Takes Time To Get There
Decomposing the monolith into microservice architecture takes time.
You wouldn’t see the Return on investment instantaneously. In fact, it might slow down the progress at first. But give it some time and it grows, and return starts to come in.
Below data shows the growth of Microservices architecture for an Australia based company http://realstateventures.com.au/.
Below data shows a similar pattern for Gilt
Testing Is More Complex
In a microservice world, it is a bit complex to come with the right test cases that would assure the functionality is working just the way it is expected.
The integration tests become more complex as the intercommunication between the services is required.
There are different tests suites for different services as the technology used to implement each service could be different.
All of this can increase the testing effort for microservices. Also one should have a complete Business knowledge of the entire system to make sure each and every scenario is covered.
Monitoring Is More Complex
With monolith architecture, when you encounter the problem, you know exactly where to look at. As there is only one place to look at. But this does not case with microservices. Microservices are a big mesh of nodes communicating with each other. Identifying the problem area could take time.
This led us to another problem of monitoring.
As there are a lot many components working in cohesion to run everything, monitoring is required at each component level on the production system. This results in a lot of logs, breakpoints and manual intervention to keep monitoring the health of all the services.
All-and-all the microservice architecture comes with its own set of complexity that needs to be taken care of.
Lots More Boxes!
To implement microservices architecture lots of different boxes (physical or virtual) are required. And for this, your enterprise needs to come with the architecture of dynamically serving virtual machine.
Virtual machines on-demand need to be in place.
Every new service is deployed on its own box (not mandatory but recommended) and therefore scaling the microservice requires you to spawn a new virtual machine on demand (as and when needed) and communication between each box.
A right mechanism like load balancers and service mesh needs to be brought to handle a lot of moving parts.
This increases the complexity by a lot.
When Should You Use Microservices?
If you are starting up right now, then you don’t need a microservice at all.
Starting with a microservice is a really bad idea.
An example that I can think of is about Snap-Ci. This product was created by my company ThoughtWorks which later moved to GOCD.
They start off with the microservices architecture. They had different services for different tasks. But this model didn’t really work for them well. The reason is – they had to make changes in more than one service in order to incorporate the changes.
Often times they found themselves breaking the service boundary to incorporate the change. And this was causing them more problems.
So they had to merge all the microservices into one.
Every large enterprise started with monolith architecture. Be it Facebook, Amazon, Microsoft etc… they all start with one big monolith structure and on the need bases adopted the microservice architecture.
I would recommend, always start with a monolith. And if and only if you are facing problems that microservices can solve, then only make the decision to switch. And I’m sure at that time you will resources and money to make it work.
Always look at the advantages of Microservices:
- Better alignment with the organisation
- Ownership of the services based on the geo-location
- Multiple teams can work together from different locations
- Helps to expand the enterprise quickly (scalability)
- Release functionality Faster
- Independent Scaling
- Easier to focus on Security Concerns
- Adopt Technology Faster
- Embrace Uncertainty in Digital
If you have made a decision to move to microservices then there are certain principles that you would want to stick to. These principles will help you to make a better choice and avoid confusion.
Let me know your thoughts on the same.
You should also read Principles of Microservices next.