When we need Microservices Architecture ?
Microservice Architecture is more complex than Service Oriented Architecture. Before adapting the Microservices Architecture we need to answer to that three main questions :
Easier onboarding for rich business area: Does your services represents rich and different business cases/domains ?
Independent Management to Faster Deployment: Does the services needs to be deployed and managed independently and faster ?
Smarter scaling: Does different parts of the application has different scaling/Technology needs ?
Easier onboarding for rich business area
Your product is widely used in production and obviously it needs support and new features, so you decide to hire new developers. For newcomers it can be really difficult to approach a monolithic codebase and to become productive in a few weeks. It is very reasonable if you reflect on it: your new developers have to understand not only the new business features that need to be added, but also the overall business domain and the way it was coded down by other people who left the project! A monolithic architecture is the main reason that made me hear during the last years things like:
To be productive on this codebase you need N months
or
A couple of years ago we decided that...
If you hired new developers and you want them to be productive as soon as possible, you may consider switching to a microservices architecture. With such approach new team members can develop all the new features you need in a faster way without the burden of a limited knowledge of what lies in the monolith. Newcomers should practice work on these new features while pair programming with somebody with more experience on the project so that they can be thought about the business domain and team/project history.
Independent Management to Faster Deployment
In monolithic architectures, most of the times the process of deploying working features in productions becomes difficult and time consuming. Let we understand why a microservices architecture can ease these kinds of organizational issues.
When the products we are working on becomes somehow stable and are actively used by customers, the daily work of the team splits in three different activities:
- new features implementation
- bug fixing
- changes of the existing features (small ones, most of the time)
If your code is organized in a monolithic structure chances are very high that your Continuous Integration/Delivery/Deployment pipeline will reflect the same structure which means that it has a unique flow. Therefore each and every change to the codebase will need to pass through tests or build steps that are totally unrelated to the change itself; this obviously means that you need more time to deploy your new code in production with all the costs that this implies. this speech of a manager seems familiar to us:
We spent X Millions for acceptance tests last year. We must reduce this expense...
When we need to push to production an urgent fix, but our continuous delivery pipeline remains blocked by non related broken user acceptance tests for hours (they can even be tests on features that are seldom used), the team can undergo frustration and irritability. The same frustration arises when Product-Owner asks to deploy a given feature to production without deploying other features that are still not ready and the team just can't satisfy the request because the deploy follows the motto "get everything or nothing".
Microservices architecture obviously can help in tackling these kind of issues. If we separate our big project in smaller services built around features, we can obviously decouple the related code, with the great benefit that our deployment strategy will follow. This means that we can decide to create a different pipeline for each microservice application and therefore we will be able to deploy each component independently decreasing drastically the time our bug/feature/change takes to be released and used in production.
Smarter scaling
Suppose our application just became mainstream and day by day is used by more users: with a monolith, if we want to scale, we are forced to deploy everything to several "replica machines", without taking into consideration whether we need to scale all the features the application provides or just a small subset of them. This kind of approach introduces different business related issues in our organisation, not only technical ones: for example we will have to use several new machines that must provide the computational power needed by the entire application and obviously this will cost us more.
When talking about scalability, microservices architecture seems to outperform many other architectural choices out there. Whenever we feel the urge to scale some part of the system, we can decide to spin new small machines that will host only the service that provides the needed feature and nothing more.
With a microservices architecture approach we will get another great benefit: we will be able to kill some of the instances with no mercy because we are confident that just by stopping one or more services we are not shutting down the entire system but only a part of it.