Curious about the future of data-driven systems? Join our Data Engineering roundtable and learn how to build scalable data platforms.
Data Engineering: The industry has come a long way from organizing unstructured data to adopting today's modern data pipelines. See how.
Stats
| Reputation: | 130 |
| Pageviews: | 268.3K |
| Articles: | 1 |
| Comments: | 2 |
Comments
May 25, 2020 · Duncan Brown
What a great discussion! I agree with most of your points. I do think that enforcing certain constraints to avoid human errors is OK. It's like static code analysis or code style tools that throw errors if something is off. These constraints can remove part of the human factor and improve overall design.
But I see your point of view. You could say that the communication channels of microservices are just "implementation details" of the overall architecture. It doesn't matter if it's HTTP, MSMQ or in process RPC.
Since I wrote the article, I've learned more about microservices and Martin Fowler and James Lewis have a great article on it: https://www.martinfowler.com/articles/microservices.html
In it, they stress some extra factors that make microservices like decentralized governance, automated deployment and design for failure. Unfortunately, I didn't mention these things in my article, which is a shortcoming on my behalf.
Without these, microservices are indeed not much better than a well-factored monolith. But if you add these, I believe the game changes. I'm actually making a LinkedIn Learning course on architecture patterns and I will talk about these point (microservices is listed as an architecture pattern, sorry!) But then microservices also steps a bit out of the traditional boundaries of architecture and enters the world of company culture, process, etc.
It's a tricky one, to say the least.
May 25, 2020 · Duncan Brown
Hi Sergiy, thank you for your comments.
I did mention that in the disadvantages of microservices. Though there have been opinions that disagree recently: https://youtu.be/_XcVRbqWiG8?t=2193 (the whole video is interesting as well). I must say that I'm leaning towards the same opinion now, because of the human factor.
While it is possible to write a well-factored monolith, we're all just human and we make mistakes, cut corners, give in to external pressure, etc. Which means that the monolith will not be as easily split into microservices as we would like to. Starting with microservices enforces clear boundaries between them.
I think that microservices are a little more than just packaging and so they deserve their own mention. But you are right that it shifts a lot of the internal complexity in a monolith towards the infrastructure.