Well put. Honestly, I like the monoliths I worked on and would again start (even on my own) with simple monolith which solves the aimed problems securely with a dose of scalability and with an ability to 'eject' or offload to microservice design if needed. And that would be through a bus or messaging system. I guess a typo in "If you are worked on an enterprise". Thanks for the writeup and attached images which help understand better what your telling.
About Microservice, Microservice is for the cloud; we could buy a small instance with its own web server and database, it is microservice, however and in general, it's not suitable for an enterprise environment.
About scalability, microservices are not scalable. You can't start a microservice architecture, and magically it is scalable. It is not how it works, and it is part of the myth of microservice.
We achieve scalability by using load balancing, clusters and so on, the same than with monolith. We use microservice because of decoupling and because it's easy to modify and to implement. However, we already are doing it with SOA (Service Oriented Architecture).
Let's say we decide to move from SOA to microservice. It means we need more server (microserver), each one using its own instance. This generates an over-head because we aren't increasing the number of machines but the number of instances using the same machines, then we need to orchestrate each microservice. Also, each micro-instance requires maintenance.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.