This is a continuation of a series of articles on the shortcomings and resolutions of Infrastructure-as-code (IaC). One of the commonly encountered situations is when IaC must be defined differently for non-production and production environments. There is a separation that must be maintained between actions taken on non-production and production environments because they require different maintenance. The diligence and rigor for production environments is usually high.

Although software product code and infrastructure-as-code can both be written with reusable modules and a centralized repository and pipeline, Infrastructure can vary between business objectives, and between environments. This results in distinct sets of resources and as such have their own lifecycle and maintenance requirements. Therefore, while the emphasis with software development has been one of system architecture and microservices framework, that for infrastructure is about variations and independent management. This calls for separation not only in declaration and definition but also in pipelines and resource deployments.

It is important to call out that this requirement to keep different sets of infrastructure resources available for different purposes also manifests in IaC as separate folders for various business objectives. Each folder will have its own set of templates, variables, parameters and so on and constitute a logical holistic declaration of all the resources used towards that objective. This might result in an explosion of folders and organizational units within them which makes it difficult to enforce consistency and best practices. The increase in folders must also be matched with investments that enforce consistency possibly as pipeline automation if they fall outside what the compiler can support. Investments in pipeline automations and tests or validations are just as important as they are with the code for software products.

Some of the hierarchy is determined by the IaC compiler and all most favor locality with all the resources and associated definitions to be available within the same folder for generating a plan. The restriction comes from the compiler requiring a root folder for the project to build. In some cases, there are features that allow import by virtue of referencing external modules. A common theme in organizing IaC is the use of common modules that act like a wrapper over primitives so that all the consumers from various projects have dependencies on single point of definitions. This is great for consistency enforcement as well as introduction of optional attributes to resources. Large IaC assets also manifest maturity in their naming conventions, terse definitions and avoidance of unnecessary declarations and dependencies. This suits IaC because the unit of declarations is usually on a resource-by-resource basis.

Another frequently borrowed functionality from automations is scriptability. While IaC manifests the resource declarations, scriptability is sometimes unavoidable when working with various resources, not all of which have feature parity with IaC syntax. This calls for scripts to be made part of IaC  and the use of pseudo-resources for this purpose is even facilitated by the compiler. However, it is important to remember that the idempotent and deterministic nature of IaC wins over the changes that scripts go through.