pankaj021

This blog is not on why you should choose microservices, it's just about microservices communication, but let me start with saying I don't agree. I know a couple of friends from startups and they all build software using microservices. I have personally worked in large monoliths for close to 12 years (and last 4/5 years microservices). IMO, the biggest benefit of microservices is agility, you can build and deploy features incrementally and fast. Nowadays with slick frameworks like Spring boot, Nest.js and all the tooling around (like Kubernetes) building microservices is much easier than building monolith. In the monolith world, we had developed a sophisticated, in-house framework for concurrent and distributed task management and I don' see the need for that kind of framework in microservices. In the last 3 years, I had never come across a single developer working on a "cloud-native" microservices project who can confidently answer a single thread question - but developing an auto-scaling application based on the Kubernetes is a piece of cake. How do you expect them to write a well-behaved monolith? It's much easier to quote Sam Newman and Martin fowler, but sorry, I don't find all advice from pundits very practical. From Sam Newman's book "One of the things I see people having the hardest time with is the idea that microservices should avoid the use of shared databases. If a microservice wants to access data held by another microservice, it should go and ask that second microservice for the data. This gives the microservices the ability to decide what is shared and what is hidden, which allows us to clearly separate functionality that can change freely (our internal implementation) from the functionality that we want to change infrequently (the external contract that the consumers use)." How is this practical for each microservices to have its own database? Is it even possible in the cloud world where we consume databases as a service? The bottom line is - nowadays developing microservices is much easier than a monolith. You get lots of tooling - such as observability stack, resiliency out of the box. This just needs to be well supported by organization culture and practices (DevOps, SRE, incident management).