> Microservices was always a solution to the organisational problem of getting more developers working on a system at once. I’m not sure that that’s entirely t

> Microservices was always a solution to the organisational problem of getting more developers working on a system at once. I’m not sure that that’s entirely true. To be sure that’s an aspect, but it’s also conceptually quite reasonable to desire the best tool for a particular job rather than employ a kitchen sink for everything. Separation of concerns is a commonly admired quality in code, and it makes sense sometimes to have this separation be at the repo level. I don’t jive with the “only organizational not technical” characterizations this thread is rife with. It’s now hipster to say the cool shiny thing is lame, and it blinds some utility. > It is easier to start with a monolith, find the right design and then split on the boundaries than it is to make the correct microservices to begin with. This I definitely agree with in many, perhaps most, cases. But of course inertia, especially in organizations, could have future you lamenting such a decision you now have no easy way out of.