You can try to build a monolith that is modular enough to break up later. But I ...

errantmind · on Nov 14, 2022

Yes, and I've gone the other way too, i.e. taking a bunch of microservices and rewriting them as a monolith, saving the company over a million dollars a year in the process.

It isn't one or the other, the 'skill' is knowing which to apply when.

To make most of these types of projects work, the sponsor needs to demand an incremental approach that delivers real value, piece by piece, all the way up to retiring the original system(s). Tie-out is also necessary for many projects, and all the associated testing. It is a big grind, which is probably why so many of these projects fail.

nixlim · on Nov 14, 2022

I think that this is a very solid point, but perhaps the reasoning underlying this type of issue is somewhat more complex. For example, we run a what is now a v5 of our API as a bunch of microservices and have been running it as microservices since v4, about 4 years now. These are "children" of v3 - our monolith. The monolith is still alive and kicking in a much reduced state but the reason we cannot decom it has nothing to do with design or time or priorities - the monolith is sitting in a data centre and is the only regulatory permitted way (in our case) to access the mainframe. So, it sits there as a gatekeeper and will do so for the foreseeable future...

groestl · on Nov 13, 2022

Not only broken up, but merged again after a while as well.

hfjcic7 · on Nov 13, 2022

Why does the "old monolith" need to be broken up?

I'm all for ending old software when the time comes but not everything needs a rewrite to microservices.

Supporting two development paradigms isn't really a thing any reasonably sized organisation should be concerned about.

Especially when you're talking about adding one more build process to hundreds across all your services.

hbrn · on Nov 14, 2022

> you end up with both the old monolith and new microservices, the monolith never gets fully broken up, and now you need to support two development paradigms forever.

It's not a bad thing, it's actually a quite pragmatic approach. Some folks call it The Citadel:

https://m.signalvnoise.com/the-majestic-monolith-can-become-...

Building monolith is the best way to learn about domain and domain boundaries. Monolith is way more forgiving for your mistakes.

Going all in on microservices is like believing you learned everything there is. Some folks believe that, most of the time they are wrong.