Problems Solved by Microservices
Now we know the basics of the Microservices architecture and its good time to revisit the problems we discussed earlier with other types of architectures to see how much Microservices deal with them.
We discussed problems caused by Monoliths and SOA. Microservices solve these problems.
Lets see how exactly are they doing it?
Single Technology Platform
We discussed that with Monolith’s all the components must be developed using the same development platform. Since monolith is by definition is a single process, there is no room to develop various components of it in different platform. That is not always good.
We want to be able to use multiple platforms in a single application and to take advantage of the capabilities of these different platforms. In monolith we are tight to our initial choice and we can not change.
In addition, we said that future upgrade to the technology is a problem. We have to upgrade entire application and it will be a big effort.
How does Microservices architecture solves this? With Microservices, the decentralized governance attribute solves it.
This will allow each team to decide and develop using most suitable platform for that service.
Inflexible Deployments
With monolith, new deployment is always for the whole app. There is no way to deploy only part of the app. Even when updating only one component, the whole codebase is deployed. The problem with that it foces rigorous testing for every deployment on the whole application. That forces long development cycles.
How Microservices solves it? The componentization via services attribute solves it.
When moduling our system with services, its much easier to deploy just part of the system when software components are each in different process/services. The loose coupling between the processes allows for separate deployments and each new deployment has almost no effect at all.
Also important to mention, the decentralized data management attribute. This attribute also contributes to the flexible deployment of Microservices. In this case deploying update system with updated database is easier. If there was a single unified database, then all changes in the database had effects on the other services.
Inefficient Compute Resources
With monolith, compute resources (CPU and RAM) are devided across all the components. We have a single process, the monolith that consumes these resources are uses them for all its internal components. If a specific component needs more resources, there is no way to allocate that. We will have to allocate more compute resources to the whole monolith, which will give them to all the components. This is very inefficient.
How Microservices sovles it?
The componentization via services attribute solves it. Since the various parts of the software or the components run as a service and not in process using libraries, we can allocate each one of them the correct compute power it needs.
Its not possible to allocate resources to different code segments inside the process, but it is definitely possible to do that to the process itself. In Microservices, each service as we have already discussed, run in the process of its own.
Large and Complex
As you know, with monolith, the codebase is naturally large and complex. Since all the software components are part of a single process, naturally we have a very large base containing a lot of dependencies and coupling. In other words, every little change can affect other parts. So technically every little change requires extensive testing and effort and rolling out updates are costly. In addition this will make developers reluctant to do updates and system will become obsolete quickly.
Here also the attribute comes to our help is the componentization via services.
By modularizing code as independent services, will give us well-defined pieces of code.
Also by using separate database of each service, will eliminate data mixing too. The both code and the database are small and simple and much easier to maintain.
Another attribute that is relevant here is the organized around the business capabilities. Most of the time same team will maintain and develop all the components.
Lack of Tooling
For Service Oriented Architecture to be effective, short development cycles were needed. Also one of the problems with monoliths was long development cycles. In order to achieve short development cycles, we needed tools to support that.
With microservices, the Infrastructure automation attribute solves it. Its goal is to automate testing and deployment (with CI/CD). We can provide short deployment cycles by using all automation tools. This will make the architecture more efficient and effective.
☕ Like this content? Support me on Buy Me a Coffee!
