Celebrations: Happy Thanksgiving to all our American readers!
Microservice merits

Microservices – Why would I even care?

Eberhard Wolff
Network image via Shutterstock

Taking the microservices approach can mean adding a serious workload. So what’s the incentive? Architecture consultant Eberhard Wolff lists all the reasons why a microservices approach is worth the extra effort.

Microservices are a software architecture style that composes systems out of small independent deployment units. Usually each microservice is deployed in its own virtual machine or Docker container. Each service might use a different technology. Of course a standardized technology stack makes life much easier in some regards.

Microservices come with a lot of additional effort – a lot more units need to be deployed, tested and monitored. The deployment and testing processes must therefore be automized. But most organizations have a hard time establishing automated procedures at all. So why would they do microservices and invest so much effort in it?

If each team is responsible for a set of microservices it can work quite independently from other teams: There is no need need to coordinate deployments. Each microservice can be deployed independently. Also each microservice can have its own technology stack – so there is no need to even standardize the platform. That saves even more communication. If each team has a set of microservices for a certain functionality – e.g. the registration process – then the team can work on stories for this functionality on its own. The microservices architectures allows teams to work independently – and therefore to scale agile processes.

Reasons to use microservices

But there are completely different reasons to use microservices. For example they naturally add bulkheads to the application: If one microservice crashes the process or the whole virtual machine other microservices are not impacted. With a deployment monolith the complete system crashes. Of course other microservice will not be able to communicate with the failed service – so multiple instances of each microservice should run for fail over. Also microservices should be able to deal with a non available microservices, for example by using cashed response or a fall back strategy. Interestingly enough, colleauges of mine have introduced microservices in one project to increase the robustness of an application. So robustness might be reason enough to try microservices.

Software Architecture SummitMicroservices sessions at the Software Architecture Summit
The Software Architecture Summit hosts two tracks in English and German, 12 half-day workshops, three keynotes and an exciting speaker panel. Topics include microservices, continuous design, architectural design, cloud-native architectures, enterprise integration patterns, event-driven architecture and much more! Find out more here.

And then there is Continuous Delivery: It aims to continuously bring new software into production, ideally multiple times a day. With a deployment monolith, this is rather hard: Testing the monoliths takes its time because there are so many features in the monoliths. And the deployment is risky because a failure might bring the business to a halt. The deployment of a microservice is less risky because of its size. There are fewer features so, it’s easier to test. Therefore Continuous Delivery is much easier with microservices. A lot of projects migrate away from monoliths because they want to do Continuous Delivery and see no other option to achieve that goal.

If you think about it, you wonder why there are so many projects with large deployment units. Everyone has seen systems that are much too big and complex. But you never see too small a system. So there seems to be a tendency to build deployment units that are too large – and current technology allows us to deal with many more, and therefore smaller, units.

But than again: There is no silver bullet – and if all you have is a hammer everything looks like a nail. However, you should at least understand microservices and the technological implications – because they are quite useful in a lot of situations and should be part of the tool belt of every serious architect these days.

Author
Eberhard Wolff
Eberhard Wolff has 15+ years of experience as an architect and consultant - often on the intersection of business and technology. He is a Fellow at innoQ in Germany. As a speaker, he has given talks at international conferences and as an author, he has written more than 100 articles and books. His technological focus is on modern architectures – often involving Cloud, Continuous Delivery, DevOps, Microservices or NoSQL.

Comments
comments powered by Disqus