Welcome to Microservices
See the above image. Those are Lego pieces. Each piece will serve its own purpose like a door and window, when we put these single pieces together we can paint a bigger picture. The architecture that I am going to talk about today will also act like these Legos.
If you are new to the software industry or are currently coming back to the industry after a break it is a must to learn about Microservices. Microservices has taken the industry by storm, nowadays a lot of enterprise level applications are built using this Microservices. After Martin Fowler released his book on Microservices in 2014, microservices became all the talk until today for service based architecture.
So software engineers such as yourself may be thinking of adopting to this architecture, in this article I will explain and compare Microservices and Monolithic Applications so that you guys will be able to get a good understanding on Microservices and whether or not you should develop your next big application using this Architecture.
Monolithic Applications
Monolithic application is what we used to do and currently still use for application development. Monolithic application means that we have a single executable file on one single system. In broader terms lets say that our application have 3 components the UI, Business logic and a database. In monolithic applications we will putting all these three components into one single package and then execute the application. This architecture has some major flaws that comes with it when we are moving to a newer version.
- If a change is to be made on one of the component be it large or small, the entire application must be repackaged and all the testing should be done including Regression testing to make sure that the application is running without any major problem. We may need to put down the entire application put it to offline and then put up the new version.
- As we are writing enterprise level application with this architecture we will be maintaining a huge codebase that has been worked on by more than 50 or even 100 engineers. If we face an issue during the production period we will have to go through this whole ocean of codes in order to find the issue as there is not a single person that knows every nook and cranny of this code. This is an extremely difficult, tiring and cumbersome task.
- Deployment is going to be a hard process for as well, if we are to launch the newer version of our application we need to make sure that all the dependencies are changed and the traffic are routed to the new location. This installation process will also take a lot of time and can become a headache for the engineers.
I can’t be biased and say only negative things about Monolithic Architecture, just like everything this architecture also have some advantages that comes with it.
- Easy to test : Integration testing is easy as the entire application is packed into one, so we can do these types of tests in monolithic applications easily.
- Easy to monitor : These types of applications are packed into one so we know where each component comes from. By that we know the exact path of each of the components.
Even though this Architecture gives some advantages, the disadvantages that it brings with it are major. For that Software Engineers wanted a newer approach that would make their life easier. That is where Microservices comes in.
Note : Regression testing is the process of testing the code to make sure that a recent change in the code does not leave behind any major defect on the application. To do that we run all the base test cases to make sure our application is working as it is intended.
Microservices Architecture
Microservices came after Service Oriented Architecture. Engineers expected Service Oriented Architecture (SOA) to be the next big thing but unfortunately that wasn’t the case. But Microservice Architecture took the best features from SOA, so some call Microservice Architecture as SOA 2.0. Now what is the definition of Microservice Architecture. There is no concrete definition for Microservice like we have for Scientific and Mathematical theory. The creators of Microservices Martin Fowler and James Lewis say that Microservices are;
“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. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
Simply put we build a big application using smaller independent services that will be communicating with each other through the internet but are loosely coupled so that one service can exist without the other and each service can be written in different programming language and use different databases. Look at the following diagram for a simplified look.
Note: Services are deployed to be isolated but depending on the need and scenario they may have slight dependencies. Even if they have dependencies each service should stay alive even if the other connected service fails.
Now that we somewhat know what it means to be a Microservice application lets take a deeper look to know the exact characteristics that an application must have in order for it to be identified as a Microservice Application.
Characteristics of Microservices.
Domain driven : Microservices are domain driven development, in other words microservices should have their own purpose for living. So in order to do that each service that we create should have a well defined scope. The scope of an object will be different from service to service.
Maintain Individuality : The services that are available in our applications should be able to run their own processes without needing the help of others. For example a service that will be doing encryption will be hosted on a web container is able do it its own process. As each service does its own process we say, “Do one thing but do it really well”.
Communication : They should be able to communicate with a light weight mechanism. As Microservices are built around the concept of being individual with loose coupling we normally use HTTP mostly with the REST architecture to do communication within the services.
Scale and Deploy : Microservices are built as independent so each service in a microservice applications should have the ability to scale and deploy independently. (Scalability will be explained deeper in the upcoming sections.)
Decentralized control : Decentralized control is what makes Microservices unique from other software Architecture design patterns. Decentralizing in the sense we hope to create our services as independent as possible without having heavy dependencies. For that each services will be doing their own jobs(Individuality). In order to get a decentralized control each service will be created with their own database as well. As each services are considered independent, services in a Microservice architecture can be created with different programming languages and different database schema for each services if the Engineers require that.
Smaller Teams : In a monolithic application there will be UI/UX engineers that will be designing the UI. Backend engineers that will be designing the business logic of the application and DB engineers that will be working on the DB. But each service in a microservice can be considered as a small application in itself. So a team that is responsible for a service will consist of The above mentioned engineers working together in smaller groups instead of working in their own bubble. So if a UI engineer finishes their task they are expected to do the backend as well. If a Backend engineer is free they are needed to work on the parts of the DB. Just like this every engineer in the team is expected to do all the tasks in order to create the Product. This is how individual engineers that specialize in only one field became full stack developers. So every single member of the team need to know top to bottom of how the service that they are building works. In the US in order to count the size of a team they use the term ‘Two large pizzas should fed the team’. This would be around 8 to 16 engineers on a project. And in Microservice we have a saying “you built it, you own it”. The engineer’s job isn’t done simply after deploying their service. If any issues comes up in production the entire team must even stay up all night to fix the issue. So if your working in the microservice project make sure to do an excellent job so that you won’t need to stay up all night fixing bugs.
The above mentioned are the important characteristics of a Microservice architecture. Now I would like to explain the Scalability much more deeper, so lets take a look into it.
Note: Martin Fowler and James Lewis also gave some of their own characteristics in their article, I have put the link in the references check it out.
Scalability
X axis : Application should scale out through X axis. What it means is that we will be creating new instances of the entire application if needed. We can use new datacenters to spawn out new copies of our application.
Z axis : We should be able to shard the databases and also splitting the services depending on the need. For example we can split the services according to the Geographical location by sending European customers to Europe servers and Asians to Asian Servers.
Y axis : We should be able to functionally decomposition our services. Functionally decomposition means we break down our system into smaller services. Lets say you have a microservice application for online shopping. During the sale season your application will have more users than normal. Specific services like a Search Service and Cart Service will be having more uses then a Service like Add new Item. So only creating new containers of Search Service and Cart Service will help to ease the traffic on the application. The main difference between X axis and Y axis is that. In X we will be creating copies of the entire application while in Y we will be creating copies of specific services.
Note : Functionally decomposition is to break down our application into smaller services so we should be careful not to break down our services into too much granularly. If we do that it will be hard to maintain. And services that go into changes parallelly can be merged into create a single service. So a right balance should be maintained when functionally decomposing a microservice application.
Note : Database sharding is a technique or architectural pattern that is used to scale databases. In sharding we can break a database either horizontally or vertically. Click here to learn more about database sharding.
Now that we talked this much about microservice architecture, lets summarize the advantages and the disadvantages that this Architecture provides.
Advantages :
- If an issue comes up in production we can diagnose it easily as every single member of the team will know the start to the end of the service that they are working on.
- Even though we use multiple services and the design of the application may look complex, we can identify which issue happened at which service.( This can be done by implementing proper logging to the application.) Because we create each service as independent as possible.
- Scalable and elastic. Elastic in the sense new instances of the services can be created when they are in demand and then can be decommissioned if they are not in use. We don’t need to create a new copy of the entire application.
- If language that we are using may feel outdated we can easily migrate to a other framework or language easily. And different services can use the language or framework and the database schema that they wish.
Disadvantages :
- In monolithic application we have a centralized process meaning we set the dependencies in one place. But microservices are decentralized, so we will be distributing the dependencies as each service is independent and isolated.
- It is hard to monitor the application as our application is a collection of smaller components. We need to be monitoring each and every single service to make sure that our application is running in the way it was intended.
- Some testing is hard to to do. For example unlike monolithic, integration testing in Microservice application is harder to do. As services are created and deployed to be independent as possible.
- Versioning and deployment need to be considered. As a newer version of a service may break another service that consumes this new one.
- Unlike monolithic where we just set it up and run, in microservice we need to make sure that every single service is up and running to ensure that our application runs as it was intended.
Conclusion
I hope that you all understand what a microservice architecture is and why this is all the talk in the current industry. There are some best practices that engineers can follow when they follow this architecture. I will share those in a future article. So keep your eyes open for it. And as always thanks for reading.
REFERENCES
This article was written with the help of the following video by Krishantha Dinesh. Check out his videos if you can.
The following link takes you to the official article that the creators of Microservices released in the year 2014.