Infrastructure as Code
Infrastructure as Code is a concept that was created to solve the problems that are faced managing infrastructure in the “Cloud Age” by applying principles more often used in software development. Modern, cloud-like infrastructure is dynamic in nature and can lead to server sprawl, configuration drift and “snowflakes”. How do you ensure the servers deployed into different environments are going to be functionally the same when a new version of an application is released? Over time configuration changes to environments are not consistently applied and each environment becomes a unique “snowflake” – with its own unique peculiarities. This can lead to deployment problems with these environments becoming inconsistent, unreliable and fragile.
Infrastructure as Code solves this by capturing all the components and configuration of your infrastructure (e.g. virtual machines, containers, networks, load balancers and topology) in a code format that describes the desired end state. This code format can then be interpreted by a provider to provision, configure and manage the infrastructure in repeatable, reliable and on-demand fashion. The code description can then be source controlled and managed as a developer would an application’s source code.
Changes to the configuration of an environment are made in the source code (not the target environment) which is then interpreted and fulfilled by the provider. The change is self-documented because the code is a well-known format that describes the end state. The change can be staged across multiple environments to ensure consistency. Environments can also be rolled back to previous states should a change be detrimental to the environment simply by utilising source control versioning.
Infrastructure as Code is typically declarative – it describes the desired state of the infrastructure, but it doesn’t necessarily describe how to achieve that desired state, this is left up to the Infrastructure as Code provider. Declarative code differs from an imperative approach, which describes a series of steps or commands that are executed to achieve the desired state. Imperative code typically does not have the same scalability, reusability or resilience as the declarative approach.
Deployed environments should be configured in the same way regardless of the starting state of the environment, a property known as idempotency. This can be achieved by modifying the existing environment to the desired state (mutable infrastructure – it can be “mutated” or changed), or by destroying the current state and deploying the desired one (immutable infrastructure – it cannot be “mutated” or changed).
Some Infrastructure as Code providers are platform-specific, such as AWS CloudFormation or Azure Resource manager, whereas others are more modular and can deploy to multiple platforms, for example Hashicorp Terraform or Pulumi.
vRealize Automation as an Infrastructure as Code provider
vRealize Automation can deploy to a growing range of cloud endpoints (AWS, Azure, GCP, vSphere and VMware Cloud on AWS), and blueprints created in vRealize Automation are written declaratively in YAML. Blueprints describe a desired end-state of virtual machines, networking, load balancers and other infrastructure components that are satisfied by the various Cloud Accounts and Integrations. With GitLab and GitHub integration the YAML blueprints can be subject to source control management, with versioning synchronised between blueprints and the source control system. In these ways vRealize Automation can be described as a typical Infrastructure as Code provider.
Deployment change management in vRealize Automation is provided in a slightly different way than you’d expect from a typical Infrastructure as Code provider – deployments are not directly linked to a blueprint in that if the blueprint code were to change, the deployment will not be updated automatically. The day-2 “update” action allows us to update the input values of a deployment, which may mean blueprint components are deployed, re-deployed or removed from a deployment. It also allows us to bring the deployment up-to-date with newer versions of the blueprint – the plan stage of the action shows what’s going to happen when the update is applied – an example of which is shown below:
Conclusion
All the content in vRealize Automation – from blueprints and actions in Cloud Assembly, to forms in Service Broker, pipelines in CodeStream and workflows in Orchestrator – is available as source code that can be version controlled, with integrations available for popular source control endpoints. Cloud agnostic components allow blueprints to describe infrastructure in a declarative way, delivering the same functionality regardless of the cloud environment it’s deployed to. And for use cases that require an imperative approach, vRealize Orchestrator, Action Based Extensions and CodeStream Pipelines can be used to build the desired state.
If you’re interested in an introduction to the vRealize Automation Terraform Provider, which allows you to further extend the Infrastructure as Code capabilities of vRealize Automation, take a look at my next blog post Getting Started with the vRealize Automation Terraform Provider
