Hey HN community!<p>I'm conducting research on software development practices and I'm seeking insights from professionals like you. If you have experience working in various companies, both large and mid-size, I'm particularly interested in understanding how software development is structured within organizations.<p>One aspect I'm exploring is how companies handle the development and deployment of multiple applications. Specifically, I'm curious about the following:<p>* How do companies manage software instances for internal or external use? Are they typically separate instances per customer, shared instances, or a combination of both?<p>* What approaches to versioning are commonly used in companies? Do they align versions across tenants or allow different versions for each tenant?<p>Additionally, I'm interested in learning about team organization and collaboration between developers, infrastructure teams and network teams, as well as the communication and coordination practices employed.<p>I'm excited to learn from your valuable experiences and insights!<p>Many thanks<p>Gert
I think your question is likely best answered by the Google SRE book: <a href="https://sre.google/sre-book/table-of-contents/" rel="nofollow">https://sre.google/sre-book/table-of-contents/</a><p>I think if you read that book you can then ask more narrow directed questions or for additional books or resources.<p>To attempt to directly answer:<p>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.<p>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.<p>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."<p>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.<p>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.<p>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.<p><pre><code> GSLB -> SSL Termination -> SLB -> Monolith -> DataStore
</code></pre>
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?)