And with a single monolith you can comfortably handle several thousand concurrent users, not just several hundred.
From my humble experience I've found that it is also relatively easier to migrate an established monolith to a semi-distributed system, than it is to build and scale a distributed system from the ground up whilst at the same time trying to figure out all its kinks before it too becomes an established system.
The trick is to find "fault lines" throughout your monolith - places where it's easy to create separation of concerns and narrow interfaces. Maintain and document these like they are external APIs. Only pass simple data through it (serialized or anything easy to serialize).
When the time comes, cleave these chunks off and wrap them in RPC/REST/graphql.
It's good form even for monoliths since it makes for an easy interface to test.
+1 to you sir. I was just having a discussion this past weekend with some technical friends and noted that a well-architected monolith often lends itself to easy deconstruction such that you get the best of both worlds when they're necessary in your product lifecycle.
Ah, i kinda agree. My former employer developed and sold an editorial suite architected in about 1999-2000 around the SOA model (along with corba) and later evolved through the years.
So basically some monoliths playing together.
I've always been admiring that design and how much it could do and handle with so little resources.
Most times for a whole editorial newsroom a single 48c/128gb machine can be more than enough.
They were particularly smart on avoiding relational databases and sticking to an object database (Versant oodbms, another mostly unknown marvel of software engineering).
That software, even with its shortcomings, was really a great piece of software engineering.
People today don't realize how cheap you can get a really upscaled machine. In Azure, a 48 core, 192GB machine is 2000 USD a month. This is nothing compared to upscaling your app on 10 servers and 20 services, with a lot of overhead, maintenance and dev time.
If you can get away with a monolith, it's the way to go, as long as you leave room to quickly grow horizontally as well, if needed.
This is really important wisdom being shared.
And with a single monolith you can comfortably handle several thousand concurrent users, not just several hundred.
From my humble experience I've found that it is also relatively easier to migrate an established monolith to a semi-distributed system, than it is to build and scale a distributed system from the ground up whilst at the same time trying to figure out all its kinks before it too becomes an established system.