Skip to main content

Bidirectional Infrastructure as Code

· 3 min read

What is Bidirectional Infrastructure as Code?

Deploying resources from code​

Direction one is the common workflow for deploying infrastructure. Infrastructure is defined in code and deployed via pipeline.

Add/update configuration in code --> Pull Request --> Pipeline --> Add/update Infrastructure

This works great, has a lot of advantages and everyone is doing it.

Capture existing resources to code​

Direction two is the reverse. Existing Infrastructure is captured back to code via pipeline.

Add/update infrastructure --> Pipeline --> Pull Request --> Add/update configuration in code

This workflow is required when we want to bring existing resources into code or when changes have been made manually and need to be retrofitted to code.

This is a common requirement but often done via ad-hoc means.

Bidirectional Infrastructure as code​

And this brings us to the concept of Bidirectional Infrastructure as Code which combines "Deploying resources from code" and "Capture existing resources to code".

bi directional IaC pipeline

Definition:

Bidirectional Infrastructure as Code builds on Infrastructure as Code to not only deploy infrastructure from code but to also be able to capture the infrastructure to code.

A bidirectional pipeline needs to have at least two modes: One to deploy and one to capture, and a consistent method to reliably create the code.

Advantages​

There are some major advantages to implementing Bidirectional Infrastructure as code.

Getting started is quick and easy​

You need only run the capture pipeline and all the existing resources will be captured to code and can be managed from there going forward.

Initial Capture to Code IaC pipeline

Retrofitting manual changes is simplified​

Any ongoing changes made manually in the portal are easily retrofitted to the code by re-running the capture pipeline.

Change capture to Code IaC pipeline

Increased development velocity​

Doing manual configuration is often much quicker than using tradition IaC.

With bidirectional IaC you can now chose the method that works best for you at the time.

It is just as valid to make ad-hoc manual changes to your infrastructure and capture them back to code as to do them in code.

Interesting new workflows are also made possible.

A good example is to allow manual configuration in DEV (or Sandbox) to speed up development, but capture DEV back to code and use this code to deploy TST and PRD.

New workflow

Summary​

Bidirectional IaC has some major advantages particularly around increased velocity and flexibility.

Maybe a few years from now a business will be able to point the capture pipeline at their cloud provider and have all resources captured to code in one run.

Realistically in the short term bidirectional pipelines would be best for simple, high volume resources or configurations, and particularly those that can be deployed from one pipeline for the entire environment.

The Osservante RBAC extension is a good example of a bidirectional pipeline. Click on the links to see what bidirectional IaC looks like in practice.