> “From my point of view, the main benefit of microservices is risk reduction. Microservices allow you to iterate rapidly and roll out new features without pote

> “From my point of view, the main benefit of microservices is risk reduction. Microservices allow you to iterate rapidly and roll out new features without potentially affecting your application as a whole.” I think this is the same reason why “do one thing and do it well” is useful in software components or shell utilities too. Basically, what you said about microservices is just a restatement of Single Responsibility Principle / decoupling, in general, and it’s not unique to microservices. In this sense, I’d say microservices are not a design pattern. Rather, it is an organizational strategy for minimizing the risks of coupling in other design patterns, which is also why microservices are explicitly a good idea in cases when a service might only have a few independent endpoints. I don’t buy the argument that it adds overhead. In fact I’d say it explicitly reduces overhead, because the boilerplate of wrapping it in a web service is just too tiny to care about compared with the overhead required to manage the complexity when a system tries to be responsible for too many things. In other words, I think good hygiene would say defaulting to microservices is the right idea, and consolidating should require evidence that it provides the expected benefits. Personally I am reminded of the funny Andrew Gelman quote, “Just because something is counter-intuitive doesn’t make it true.” I think it’s fashionable to criticize microservice designs and people jump on the bandwagon of pretending like criticizing microservice designs is somehow more well-rounded or more nuanced, but really it’s not. It’s just an attempt to make something fashionable via contrarianism. > “I think engineers should aim to be problem solvers” I agree with this very much and it is why I think cross-silo / cross-functional engineering is junk. The best way to organize a team of problem solvers is to clearly delineate the boundaries between what the problem solving responsibilities are. If people use the term “problem solver” to just be an ambiguous bucket of unlimited complexity by virtue of expecting people to “just solve the problem” no matter what the impedance mismatch between their skill area and the problem area, then it renders the term “problem solver” meaningless, and will just lead to a big mess of dysfunction. As an engineering manager, one of my most important jobs is to empower engineers to say “no.” To reject inappropriately allocated work or inappropriate cross-functional pivoting driven by ineffective short term business thinking. The engineers have to be empowered to say, “Hey, that work should not be assigned to us” because it signals whether the business overall has structured itself and staffed itself appropriately to actually respond to the business problems sent by Mother Nature at us. If we are structured wrongly, yet try to paper over it by pressuring engineers to be HR-approved “problem solvers” in the sense of more just doing what they are told instead of doing what would actually work, it will be medium-term detrimental and counter-productive. In this sense, I think “silo” is a good word, and indicates a good engineering culture where different silos have the power to say “no” and where specializations are respected and planned for by the management. Yes, of course that can be subverted into an anti-pattern in poorly run businesses, but that’s a property of bad management, not of “silos” in and of themselves.