This post is a beginning of a long series which will cover Microservices, Devops, Containers, Dockers and many other futuristic concepts.
All these concepts are vast and range from simple to complex implementations. So let’s take it slow.
We should learn about Monolith application before learning about Microservices.
This is the regular way of application development we followed earlier. Typical 3 tier application with Presentation Layer, Business Layer, Data Access Layer. Below image explains what we call a Monolith application.
Let us assume the above application is a e-shop application. Its quite easy to develop, deploy and maintain. That’s one of the strengths of Monolith.
Now its holiday season, there will be lot of load on purchases department. So, we better be prepared for the expected additional load. What do we do, we deploy Business layer API component to multiple servers and load balance them? Exactly like shown below.
Now let me give you couple of scenarios.
1. What if there is a change in purchase process. We end up deploying whole API and test it on a whole again.
2. In Monolith we use one kind of database. What if users can be better managed with LDAP, and Product details can use structured SQL data and Purchases and invoices can be saved on to a No-SQL Document management system?
3. As the code grows, the manageability decreases. New developers need to understand whole API to do any changes in one section of business logic.
4. Once design is done, a monolith application sticks to a stack of technology. Due to its non-modularity updating it to a new framework or a whole new technology is quite tedious task.
5. Due to all kinds of data end up in one single DB, it will grow to terabytes in no time.
6. Finally the load is only on purchase part of application, why we duplicate all business logic/API.
Now to address most of the above concerns, let’s look at Microservices.
Microservices is driven by Domain Driven Design. Application will be broken into smaller chunks based on domain and sometimes even to subdomain levels.
Look at the same application in terms of Microservices implementation.
Lets revisit the above raised concerns again:
1. Now the change done is limited to Order service's API, it won’t affect other parts. Change can be deployed without effecting other parts of the application.
2. Now we can use all the best suitable data repositories based on kind of data each domain deals with.
3. Any new functionality results in new service creation, thus increasing the modularity and maintainability.
4. Due to increased modularity, switching the technology of one service will not affect others. So, Upgradability increases.
5. As we have various data repositories, its easy to archive existing or adding new repositories.
"Using
Same DB is a big anti-pattern in Microservices, so be mindful of that."
6. Finally in case of load on a holiday season as we discussed. Due to high modularity and independent scalability of services we can scale just the Order service without costing lot of resources. Look at below image.
7. Due to modularity of each service a small team can support, thus make development/testing and deployment more agile and fast.
8. Performance tuning is easy as you can fine tune each service independently.
I am not saying Microservices is a solution for every problem. It has its own issues.
For example:
1. The above design shows a microservices application in a very basic state. As the complexity increases there will be 20 other components like message brokers, gateway APIs, Identity Management Services, Distributed Logging, Circuit breaks, Distributed health Monitors, Error aggregators, Firewalls, Service Registries and so on. There will be too many moving parts once a microservices application reaches its full complexity.
2. With all the above components it has, integration testing will be tedious.
3. As it will be a mix of various technologies, there won’t be a single point of support. Support team need to be trained continuously.
4. Distributed transactions are not permitted in Microservices, so managing the data changes across multiple data stores is a complex task. Typically, Data change will be driven by Data Change Capture pattern.
5. More the no of components that were included in a system, Operation complexity will increase.
6. Monitoring the Logs, health checks and errors across multiple systems need to be aggregated, which requires special tools like Splunk.
7. Test environments also should be as complex as production in order to carry on the integration testing spanning all the components in the system.
8. You need to count all the risks due to network latency, network failures and component response delays due to highly distributed topology.
With above issues, i am just reminding that designing an application using Microservices takes a great deal of expertise and planning if you are going for enterprise solutions.
In the next post we will see types of communications between different services and how a transaction will happen considering multiple data stores.
Monolith Application
This is the regular way of application development we followed earlier. Typical 3 tier application with Presentation Layer, Business Layer, Data Access Layer. Below image explains what we call a Monolith application.
Let us assume the above application is a e-shop application. Its quite easy to develop, deploy and maintain. That’s one of the strengths of Monolith.
Now its holiday season, there will be lot of load on purchases department. So, we better be prepared for the expected additional load. What do we do, we deploy Business layer API component to multiple servers and load balance them? Exactly like shown below.
1. What if there is a change in purchase process. We end up deploying whole API and test it on a whole again.
2. In Monolith we use one kind of database. What if users can be better managed with LDAP, and Product details can use structured SQL data and Purchases and invoices can be saved on to a No-SQL Document management system?
3. As the code grows, the manageability decreases. New developers need to understand whole API to do any changes in one section of business logic.
4. Once design is done, a monolith application sticks to a stack of technology. Due to its non-modularity updating it to a new framework or a whole new technology is quite tedious task.
5. Due to all kinds of data end up in one single DB, it will grow to terabytes in no time.
6. Finally the load is only on purchase part of application, why we duplicate all business logic/API.
Now to address most of the above concerns, let’s look at Microservices.
“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.”
--James Lewis and Martin Fowler,
Thoughtworks
Microservices is driven by Domain Driven Design. Application will be broken into smaller chunks based on domain and sometimes even to subdomain levels.
Look at the same application in terms of Microservices implementation.
Lets revisit the above raised concerns again:
1. Now the change done is limited to Order service's API, it won’t affect other parts. Change can be deployed without effecting other parts of the application.
2. Now we can use all the best suitable data repositories based on kind of data each domain deals with.
3. Any new functionality results in new service creation, thus increasing the modularity and maintainability.
4. Due to increased modularity, switching the technology of one service will not affect others. So, Upgradability increases.
5. As we have various data repositories, its easy to archive existing or adding new repositories.
"Using
Same DB is a big anti-pattern in Microservices, so be mindful of that."
6. Finally in case of load on a holiday season as we discussed. Due to high modularity and independent scalability of services we can scale just the Order service without costing lot of resources. Look at below image.
7. Due to modularity of each service a small team can support, thus make development/testing and deployment more agile and fast.
8. Performance tuning is easy as you can fine tune each service independently.
I am not saying Microservices is a solution for every problem. It has its own issues.
For example:
CONS:
1. The above design shows a microservices application in a very basic state. As the complexity increases there will be 20 other components like message brokers, gateway APIs, Identity Management Services, Distributed Logging, Circuit breaks, Distributed health Monitors, Error aggregators, Firewalls, Service Registries and so on. There will be too many moving parts once a microservices application reaches its full complexity.
2. With all the above components it has, integration testing will be tedious.
3. As it will be a mix of various technologies, there won’t be a single point of support. Support team need to be trained continuously.
4. Distributed transactions are not permitted in Microservices, so managing the data changes across multiple data stores is a complex task. Typically, Data change will be driven by Data Change Capture pattern.
5. More the no of components that were included in a system, Operation complexity will increase.
6. Monitoring the Logs, health checks and errors across multiple systems need to be aggregated, which requires special tools like Splunk.
7. Test environments also should be as complex as production in order to carry on the integration testing spanning all the components in the system.
8. You need to count all the risks due to network latency, network failures and component response delays due to highly distributed topology.
With above issues, i am just reminding that designing an application using Microservices takes a great deal of expertise and planning if you are going for enterprise solutions.
In the next post we will see types of communications between different services and how a transaction will happen considering multiple data stores.
Happy Coding!
No comments:
Post a Comment