Your comment was in some ways better than the original article! Thanks. But, as you know, many of these problems are either solved or non-existent in Big-Monol

Your comment was in some ways better than the original article! Thanks. But, as you know, many of these problems are either solved or non-existent in Big-Monolithic-App-land. So -- take the things that worked there and use them. Like I said, a common set of shared source code that handles all persistence means all apps can talk to each other using the same code. Changes don't break the chain. Stuff can be fixed in one spot. And so on. The orchestration and testing pieces deserve special attention. I think you're going to end up with as many folks writing test/monitor/break code as you are microswervices. And that's probably a good thing. But you need to plan for that. As far as the hype cycle, I've seen this over and over again. As far as I can tell, the driver is over-specialization of developers. Some new buzzword comes out, people teach and train around that, and suddenly you've got somebody called a "DBA" that can't write a web service. So then you need a "Front-end" guy, and so on. This industry is constantly labeling things, over-developing them, creating work silos that lead to poor performance, then going back and relabeling things again. There's some magic number of developers where you need specialists, but it's not 10, or even 40. The longer you put off creating silos, the better the entire effort is. EDIT: In fact, I'll just say it: if you want to swim in the ocean of nirvana that is microservices, use pure FP and share all the source code that involves persistence.