It's not that simple, and that's the problem with microservices. You'll learn that "break it up" means a huge investment in devops, logging, stats dashboards to understand what the problems are, etc. It's like transitioning dimensions from 2D to 3D, and that's the trap that most people fall into.
You cannot survive microservices without real-time dashboards and proper logging to understand the health of your environment, whereas with a monolith, it was fairly obvious because there's the server and usually a database, and that's it.
All true about monitoring and logging. Is is a huge cost and overhead.
Consider it the other way around: micro-service to monolith. It seems to me it is as difficult, if not more difficult. Potentially different language or different build system are used. Different framework might be in place. Sometimes a merge is completely infeasible without a total rewrite.
So going from micro-service to monolith is like going from 3D to VR.
Splitting seems in a way way easier than merging back.
Totally agree it's not simple. But monolith in early stages enables a must faster change cycle from early adopter feedback since there's less wiring up to consider as features change.
Totally agree with this. No idea why anyone would do things different. Other paradigms are cool and fun, but if you need to get your prototype out there now, this is absolutely the way to do it.
I do the same thing with the components of the monolith. I'll use Pyramid + SQLAlchemy + WTForms all day long with a reasonable separation of concerns. When I hit a real problem where the ORM is causing a bottleneck, hey, that's a good time to drop the ORM and use stored procs.
Same thing with almost any element of the web app. When it's a clear bottleneck, drop one layer of abstraction and move on.
This will get you excellent performance without the overhead of an SPA for 99% of your use cases.
Design your way around page refreshes, and judiciously apply ajax calls, and you're done.
If you aren't one of the big 5, this is good enough, even with a slow language like Python.
You cannot survive microservices without real-time dashboards and proper logging to understand the health of your environment, whereas with a monolith, it was fairly obvious because there's the server and usually a database, and that's it.