I'm still convinced we could run our entire software platform off 5 EC2 instances and an S3 bucket. But the last 10 years of technical mismanagement turned this into a microservices shit show. Splunk gets more traffic than our clients do.
We ended up with 3 service. Exact same API is provided. It does not matter : nobody is using it anyway !
Have also seen this coupled with the microservices pattern of having all the microservices share a large common library, with all microservices built together and deployed together all the time. All the pain of shared code across teams plus the pain of shared DB plus the pain of debugging across completely arbitrary process boundaries.
The common denominator of those companies is they all had no significant traffic, had their initial codebase developed by (unmanaged) amateurs, and were later managed by people inexperienced in software.
Due to the heavy resistance in all cases, I eventually became tired of proposing simpler solutions and the endless discussions around it, and accepted premature microservice architectures to be part of my infinite source of income.
Basically, get boxes on the diagram for each aspect the exec might want to talk about or answer questions about. So that they'd have something to point to, and investors would have some level of understanding, as well as confidence that we thought of and were doing something about each thing. (This is a bit different than the diagrams we were using to discuss and build it internally.)
So I mention to a colleague that I "just know", if a room of tech investors see the Web facet of this (even though that's the easiest technical part of the system), and this one part is all going through only one server (which is all it would ever need), someone is gonna be concerned that we might not know what we're doing about scalability, and I bet the exec doesn't want to get derailed debating that with them.
Colleague advised we go full "System Design Interview!", so I spewed all the unnecessary vapid things we could do, that some semi-technical person might be tuned to look for. Trying to modify the spew to be sensible enough (if encumbering overkill) that, if investors happened to have a hardcore veteran techie vetting (like one of the people who built AWS or Google from nuts and bolts), that they wouldn't become enraged with disgust, and kill me where I stand. The investor meeting seemed to go well.
In a different (real, internal) diagram, for networking architecture, I also broke out out some logical functions into distinct physical servers (some fixed, some variable) in an information/control flow compartment. Then I added a comment on the diagram, something about that these might be combined into a single server for efficiency, for smaller deployments, like customer on-prem. And, I didn't add, if our own data center suddenly needed to host a hugely-popular service for others, and we suddenly had enough hardware for that, the software would be ready (but we'd still only need one server in that one spot that a System Design Interview book-prepped person would think needed a load balancer and workers).
of unzipped data
Do you really need those 5 nines?
If my bank can go down every week for patching, you probably can too.
What matters if they will pay someone else for that reliability they don't need.