Technology Heterogeneity
Due to the nature of microservices the system is composed out of collaborating services, for each of these services you can, but don't need to, use a different technology. This approach allows you to use the right tool for each job without having to make compromises like you would have to do in a standardised environment. Using the microservices approach, the adoption cycle of a new technology is much shorter. Of course using a lot of technologies comes with an overhead, but the fact you have this option can make you move a lot faster than traditionally approaches.
Resilience
Microservices allow you to build more resilient systems by implementing service boundaries. Using circuitbrakers, when a system fails, it doesn't cascade and you can isolate the problem more easily.
Scaling
One of the pitfalls of using large monolithic services is that you can't scale certain parts of this service. If one part in the overal system is constrained in performance, it generally locks up the whole service/application. When scaling a monolithic service you have to scale everything. With microservices you can scale the services that need to be scaled. This is more efficient and cost effective.
Ease Of Deployment
When you make a change to one particular service you can release much faster and more reliable. You can ship new features reliable and at lightning speed to your costumers. Another advantage of using this methodology is that in case of an issue after the deployment, you are able to isolate or rollback the change.
Organisational Alignment
If your codebase is divided in a couple of microservices, less people will be working on the same codebase. This will hit the sweet spot of team size and productivity. You can now decide to have dedicated ownership of services on certain parts of a team.
Composability
Reuse of functionality is a very big thing in microservices. You can move fast by reusing certain services in certain parts of your application.
Optimise For Replaceability
Way to often in previous roles I have come across big nasty legacy systems which nobody wants to touch. Its too big, its too risky, its too much work, but the fact is, it should have been replaced years ago. Don't treat your servers as pets but as cattle, meaning prepare to replace certain parts by using microservices. You keep way more agile and nobody will ever have an excuses not to touch the application.
At in4it, docker is used to support this methodology on the infrastructure side.
