Walking into a muti-release program, l’m always expecting to see a familiar sight; environments that are different and re-designed for the purpose they fit. For example, Development environments are not designed in-line with System Testing environments, which are not inline with User Acceptance or Performance and Volume testing environments. To be fair, they are similar, but often differ in some key areas like database server, application server and web server nodes. Overall, the environment designs are inline with the Infrastructure Architecture, however, due to cost, skill or motivation factors, often most environments end up being designed in different shapes and sizes. Now, some of these decisions to create different configurations for Development environments can be influenced by cost, however, these differences need to be clearly documented to reduce configuration risk that can often cripple the SDLC.
Modern vitualisation approaches have changed the landscape in environment management in the area of hardware consolidation, configuration management centralisation, infrastructure architectural flexibility and general management of operating systems. As result of the benefits of virtualisation, we have seen an increase in the number of environments in the SDLC, which (as you would expect) has also increased the configuration management overheads. Deployments are one of the critical functions executed by the environment management team, and due the increasing number of environment and complexity in modern infrastructure architectures, configuration management is getting more complicated and time consuming. Our novel approaches of the past are not scaling to meet our insatiable appetite for the benefits of virtualisation. As a consequence, our costs in environment management are increasing and the benefits of this additional cost are not being realised.
So, where to from here? Well, l believe the solution lies in Environment Models and a smart configuration management strategy that is deployment focused.
When we design internet facing business systems, we get our customers to specify their requirements and we then architect, build and test them. Why, as infrastructure architects and environment managers don’t we go through the same specification process? We should be specifying our environments in a way that will optimise our ability to deploy to them and manage their configurations. Seem’s simple really, yet we don’t seem to want to apply the same diligence to our internal processes as we do to our customers requirements.
This is where Environment Models come into the picture. My definition of an Environment Model is an environment that is built for the purposes of being used in the SDLC, where the entire collection of environment components are version controlled, labeled and unique. This way, we can construct an Environment Model once (this is what l call the Genesis Environment Model), and use it as a basis to build other environments. Figure 1 represents an Environment Model.
Figure 1. Environment Model
One of the biggest advantages of Environment Models is the consistency they present in terms of architecture, design and configuration. This makes deploying to them more consistent and predictable. If you have not already been able to see it, there are some greater benefits to Environment Models that we can exploit – deployment standardisation. Building our deployment and configuration tools right into our Environment Models can significantly improve our ability to deploy to these environments.
Till now, l have proposed the benefits of Environment Models and how they can standardise the definitions of environments, standardise the deployment & configuration methods and improve the overall configuration quality and traceability of our environments in the SDLC. By following the approaches discussed here and applying them to a virtualisation platform (VMWare, AWS), will certainly take you many steps closer to copy-and-pasting of environments. Now, wouldn’t that be a great alternative to what we have today?
Till next time.
Categorised in: Uncategorized
This post was written by Oscar Huseyin