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.

Last updated