Monoliths vs Microservices

As a general rule of thumb, fully explore and exhaust your "monolith" options before you switch to Microservices. They quite often create more problems than they solve.

"I see you have a poorly structured monolith. Would you like me to convert it into a poorly structured set of microservices?"

Fact is Monoliths are more flexible than Badly Split Microservices.

A few years ago, after having worked on a microservice-oriented project for some time, I joined a team which developed a monolith. To be honest, it felt like a breath of fresh air. What previously took coordination across multiple teams and repositories, tens of API schemas, complex multi-stage releases (your average feature usually touches lots of microservices), complicated synchronization of data stored in tens of DB, with a whole theory on microservice communication and a whole DevOps team w

Microservces enforce some separation of concerns, but Monoliths can use the same approach without nearly as much complexity. Overall, I find microservices to add a huge range of new failure modes for little net gain. The sweet spot seems to be services where large chunks of the application operate independently. 10 services are manageable, 100 are not.

Am I the only one who uses microservices to deploy small monolithic projects?

Start with a monolith, not microservices.

microservices are not a substitute for discipline. You can have a modular monolith.

I've never understood all this drama. In my experience, monoliths are universally bad in every imaginable way. A huge part of my career has been splitting monoliths into cohesive smaller codebases which could be called microservices.How to split them has never really been a problem, you tend to develop an intuition and the monolith kind of splits itself.Eg, currently we have user profiles (user id > the users names, email etc) in one microservice, relationships between users (user

Don’t end with microservices either. Monoliths are your friend.