During the Covid-19 pandemic and lockdown there has been a lot of spare time for reading and thinking. One of the things I came across was a tweet from Gergely Orosz, an engineer from Uber stating that they are refactoring their systems, making bigger microservices...
From what I am reading this has started a whole loooong discusson/slur on twitter around how useful, doable and sensible it is to design systems based on microservice design patterns. The critics has been ranging from microservices being a "bright" idea of rockstar "celebrity" software craftspeople still trying to be relevant to "I wasn't able to do it so it must be a failure" kind of responses. It's very polarized. You are either in or out with the microservice crowd :) The weird thing is that I get a sense that people are a lot more open to Domain Driven Design principles ...
In all, Uber and Netflix are the two unicorns of microservice design, hailed by all authors and their books, atleast the ones I've read on the topic. It looks like a lot of people it seems, take this tweet as a "sign" that micrservices aren't working and a sign of yet another failed attempt to re-shape the way we create software (looking at you SOA).
I disagree with the sentiment that this refactoring and/or consolidation of services is a proof that microservices is a failed principle. I say it is a living proof of it working. Uber, redefining the concept of what their bounded context is, is systematic evolution! It is good systems design, it is natural and it is healthy in a "living", evolving system.
Yes, microservice design and implementation is hard, it takes discipline and it can be hugely overwhelming when you have not done it before. But don't "blame the system" when the real reason might be a gap in both skill and experience. The number one question that arises from all devs I talk to about microservices is "How big is a microservice", closely followed by "How many microservices do I create" - short answer - I have no idea until I've seen that you are trying to build, or - Let's figure it out based on what you need to do :)
So, here is my 2 cents about what microservices is, and is not.
It IS as large or big as your team needs it to be - to successfully develop, test, deploy and change it according to your needs without it taking down the system as a whole. A system withing the system. self contained and autonomous owner of it's own storage and the data it produces.
It IS NOT a fixed number of code lines, classes or functions.
One of my favorite books on this subject is Sam Neuman' "Building Microservices book since it doesn't deal with implementations, it deals with the idea and principles. Understanding how you can discover for yourself how big or how many services your system need.
finally, I think SOA was a great idea, it was sadly "destroyed" by large enterprises selling SOA server magic pills. You could not do SOA without a really expensive server from your favorite server vendor....
One last point.. microservice design isn't meant for all kinds of systems. It is meant for systems that has a certain size, and update frequency that makes it sensible to be able to autonomously update and scale parts of the system independently of the system as a whole. It is important to keep this in mind.
Top comments (1)
Read the book "Righting Software" by Juval Löwy for all the answers to questions about micro-services. Or writing software in general actually.
The author knows more about micro-services than anyone else. He was working on the Windows Communication Foundation (WCF) in 2007. At a time when nobody even thought about micro-services. This platform enables developers the implementation of micro-services in the way they are supposed to be build. Already in 2007!!
He explains in the book why software fails, how to avoid the common pitfalls and how proper system development can not go without a proper project approach (vs Agile). Even if you will not agree with him, it is still a profound read.