Unlocking the Cloud Operating Model: Provisioning - Self-Service Infrastructure

Transcript

My name is Meghan Liese, and I'm with HashiCorp and I work on the Terraform product marketing team.

The thing I want to talk about today is, How do we enable self-service workflows with an infrastructure as code approach to provisioning infrastructure? How do I enable the rest of my organization to get on board with using Terraform infrastructure as code to provision infrastructure?

The 3 core tenets of understanding this are around:

• How do I standardize the adoption of this new tool?

• How do I manage the shadow IT to prevent the security risks that come with that?

• How do I enable my developers to be more agile and more productive with Terraform infrastructure as code?

Adoption

As you bring new tools into the organization, it's hard to get the rest of the organization to adopt them. How can you, knowing how good the infrastructure-as-code approach is to provisioning cloud infrastructure, get the rest of the organization on board?

The way that we like to think about this is: Don't get the organization to come to you; bring Terraform to them.

We do this by enabling developers and other types of end users to use the workflows that they're already using, with CLI workflows or using VCS tools. These are DevOps workflows and using CI/CD tools, or through ITSM types of workflows that are based on GUIs and UI workflows.

Shadow IT

The next part is around shadow IT. The self-service workflow that cloud provides means everything is a service and it can be provisioned as needed. This, however, creates a lot of shadow IT and a lot of risks to the operation's organization.

What do we need to do? We need to go in there and figure out what is the single way we want everyone to provision and then enable them to do that with policy enforcement, auditing, and tracking.

Enabling developers

And the final part is enabling developers. This is through integrated workflows that provide support and the agility that they need.

With self-service workflows, you want to provide them the ownership and access controls to provision infrastructure that they want. However, you also want to have the centralization where you can govern this infrastructure, that you can check it for security, compliance, and operational best practices.

The final part is having integrations that support the end-user workflows. Again, this goes back to enabling CLI and VCS workflows. This goes back to DevOps and CI/CD pipeline workflows and, finally, the GUI-based workflows that are with ITSM and cloud platform management workflows.

Putting IaC into modules

So from Terraform's approach, how do we think about this? Everything starts with infrastructure as code.

However, not everybody does infrastructure as code. So instead, what we like to do is package up infrastructure as code into modules that can be reused through publishing workflows in a registry.

So as a developer, I can go in, figure out what infrastructure I want, find the module that represents that infrastructure, import that into my environment, assign my variables that I want, and send that to Terraform to go out and provision my infrastructure.

I've used infrastructure as code to provision my infrastructure in a fully automated fashion. But I haven't had to go and write any infrastructure as code.

The other way that we like to enable organizations to provision infrastructure is through ITSM workflows such as ServiceNow. In this type of environment, you can use a GUI-based workflow to select the modules you want and add your variables. You can send that to Terraform to get provisioned, all the while doing everything through your ITSM-based workflows.

To learn more about Terraform, visit learn.hashicorp.com/terraform.