Ask HN: How is software development structured in large and mid-size companies?

I think your question is likely best answered by the Google SRE book: https://sre.google/sre-book/table-of-contents/

I think if you read that book you can then ask more narrow directed questions or for additional books or resources.

To attempt to directly answer:

Almost all isolation I've seen is logical and in some way defined in a database table. Just about the only place I've seen physical isolation is protecting the whole of the frontend system from the failure of one kind of backend by isolating particular routes from others.

Managing multiple versions is unpleasant. I can't imagine many situations where I would be allowing more than 3-5 concurrent versions of software (staging, canary, live and maybe some special cases) per "service cluster" defined as a load balancing group. There is probably better terminology.

Your question is vague, and I'm not sure what large and mid-size means, what internal or external use means, or the context of "version alignment across tenants."

I think all the team organization I've seen is relatively organic. Network teams are an infrastructure team. Teams always seem organized around various abstractions/abstraction layers.

I think the most important thing to considering structure is "First in Management chain that can resolve disagreements." A team manager can resolve disagreements for any dispute between two team members and generally has authority on their particular abstraction. A head of infra can resolve disputes between how two infra abstractions work together. A CTO might be the lowest level person in a management chain that can resolve disputes between product teams and infra teams. That's probably not a great structure.

I get that you're doing research, but these questions are somewhat book sized questions so it's hard to get a foothold on your question.

  GSLB -> SSL Termination -> SLB -> Monolith -> DataStore

Is a gross simplification of what a lot of valley infrastructure looks like and trying to answer your question in the context of that structure is a bit hard, because I don't think you understand what you are asking or I don't understand what you are asking.

Are you interested in identify current trends in software development or more like what the “most common way” of building software is (ie what the most common type of software being built are?)