Weighing between a hardware- or a software-oriented approach

Let's go through pros and cons for a traditional vs "modern" approach to environments.

🖥️ The benefits of hardware-segregated environments

  • Very easy to understand conceptually
  • Should result in very good separation of environments

🖥️ The drawbacks of hardware-segregated environments

  • You start expecting environmental parity between any other systems
  • You start expecting that all systems are in similar, co-deployed stages
  • The implicit reasoning starts becoming that you "should" or "can" only have a low degree of variability in configuration
  • As a consequence, such "pre-baked" configuration tests may start becoming large-scale blocking, manual tests
  • There may be significant cost overhead with a higher count of static environments
  • There is most likely a significant complexity overhead with a higher count of static environments

🧑‍💻 The benefits of a software-defined, dynamic environment

  • Less architectural complexity
  • Cheaper with fewer environments
  • No need to keep environments in sync
  • Realistically promotes modern practices: "testing in production", trunk-based development etc.
  • Scales to more intricate and realistic scenarios (such as testing system X in mode A with customer type B in configuration D etc.)

🧑‍💻 The drawbacks of a software-defined, dynamic environment

  • Can add solution complexity
  • Will become harder to work with in the local scope (i.e. the actual code), and more so if there are many branches
  • Requires some degree of cleanliness and pruning (governance even) to control, so things don't grow out of hand

🎨 Yes, you can mix these patterns with a hardware-separated environment!

You can certainly use the patterns seen in this project in a more "traditional" hardware-separated environment. However, the benefits become more pronounced as you also shed some of the overhead and weight of classical environments.