[potrei]

Apart from the specific technology used, it's important to change the way applications are designed and implemented. I saw many projects in trouble because they merely split a monolithic application into small pieces, without applying a new model of design and thinking. If you approach micro-services development without changing your mind first, you will fail.

[rasteau]

Amen!

My last three companies were moving from a monolith to microservices. In every case, the rationale for the move was little more than "monolith development is slow, therefore microservices".

Unfortunately for all of them, the true reasons for the slow development was poor separation of concerns, insufficient and brittle tests, and years of accumulated hacky shortcuts to ship new features "faster".

The folks pushing the microservice panacea were "proven right" in that development was much faster... initially. Without years of cruft in their way, devs were able to churn out new stuff (after a significant time spent ramping up on infrastructure code).

Eventually, and in every case, the fundamental flaws resurfaced, this time increasing in severity now that changing the system often required multiple service changes. As well, a host of new kinds of problems emerged: distributed transactions, network failures, client/server versioning, debugging across services, etc.

I'm now a microservice skeptic. Whatever your solution, it should be at the same "level" as the problem. A massive change in technical architecture will not solve the accumulated cost of your poor engineering quality choices.

[potrei]

Yes, I agree. That's why I said that it's necessary to change the way application are designed. And, of course, there's no silver bullet. Sometimes micro-services architecture is not the way to go.