[zinekeller]

> If we analyze most of the successful migrations into microservices, they were driven almost exclusively from necessity rather than preference.

This is basically how everything should work. There's no need to rush things if you don't need it now, especially that some that do convert are disappointed at the results (it's not the microservices themselves, it's the specific migration planning, design, and maintenance.)

> So maybe there’s no point in keep discussing microservices vs monoliths.

Wikimedia has monoliths for text-based systems and microservices for (some) media-based systems, and it make sense: transcoding is unpredictable workload (for them, I imagine this is more common for YouTube) while database operations (at Wikipedia's scale) is very predictable and doesn't warrant the additional complexity. Even in their planning for multi-datacenter operations (https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Ac...), they are more concerned with disaster recovery and slowness to logged-in users, not quick scalability.

[mmazing]

> This is basically how everything should work. There's no need to rush things if you don't need it [right] now.

I'm really not sure why this is so difficult to grasp for so many people in IT.

I think it stems from a desire to not have to think too hard about how to solve a problem since "someone else has already solved this."

... or maybe an inability to do so.

[xnx]

Many IT people are tech-fetishists and only solve genuine problems incidentally.