Hello. Welcome to Transient Infrastructure. In this lesson, we are going to talk a little bit about transient infrastructure and its role in DevOps.

In a typical hardware-based IT environment, the deployment of an infrastructure is highly manual and takes time to complete. Such an infrastructure typically remains in place for as long as the project that requires it remains active. Taking it a step further, in many cases, when a production infrastructure is deployed, a matching dev environment and maybe even a matching test environment are also deployed. This is obviously highly manual, time-consuming, and sometimes error prone. In such a scenario, every environment uses essentially the same resources.

By leveraging cloud computing resources, organizations can quickly deploy identically configured infrastructures and they can quickly tear them down when they are no longer needed. Such infrastructures are known as transient infrastructures. They are transient because they are built up and torn down in bursts, meaning they often have short lifecycles.

Now, while a production infrastructure isn’t really considered transient in most cases, the deployment of containers and the use of autoscaling, which spins up resources when they are needed and spins down resources when they are no longer needed, kind of makes the production infrastructure almost semi-transient.

So where does this fit in?

Well, when an organization is following the agile methodology, it should be leveraging automation that allows it to deploy the infrastructure that is needed at the time, to run any tests that are necessary, and then to automatically decommission the infrastructure when it’s no longer needed. This automation is where transient infrastructures really shine.

To achieve a truly transient environment, the environment build should be completely scripted. This can be achieved in Azure through ARM templates. By incorporating versioning and self-service, transient environments can be spun up by virtually any team member. These types of transient environments should have automatic termination procedures built into the provisioning sequence. This ensures that such environments do not linger after they are no longer needed.

Leveraging transient environments or transient infrastructures ensures that such environments or infrastructures adhere to enforced standards. This reduces the chances of creating a bunch of snowflake infrastructures due to configuration drift. Transient infrastructures also result in more efficient use of resources and capacity, since these infrastructures only exist when they are needed and only include the resources that are needed. This obviously also results in cost savings.

There are two parts to a deployment of a transient environment. The first part is the policy that defines the configuration and lifecycle of the environment to be spun up. Project requirements will often dictate these aspects, which are included in the script that will deploy the environment. 

The second part of the deployment of a transient environment is the technical implementation, which includes the creation of the script and the deployment of the environment from that script.

So, at the end of the day, the deployment of transient infrastructures is not only useful in speeding projects up, but it is also useful when trying to save on costs. In addition to speeding up projects and saving on costs, transient infrastructures also help ensure adherence to established standards.

Lectures

• Introduction
• Hosting Infrastructure
• An Intro to Infrastructure as Code
• Infrastructure as Code (IaC) Technologies
• Technical Debt & Templates
• Mitigating Infrastructure State Drift
• Conclusion