FAQ

How can organizations adopt the cloud operating model?

Learn how HashiCorp Terraform helps organizations adopt a cloud operating model that works easily with multiple vendors, and fosters DevOps collaboration.

For our updated view on the cloud operating model, read our latest white paper: Unlocking the Cloud Operating Model

HashiCorp's director of product marketing, Meghan Liese, has talked to some of the world's largest, most complex organizations about their infrastructure orchestration and scaling challenges. The conversations often center around a key topic: The cloud operating model.

With multiple cloud providers being used by organizations' operations teams, how can they provision and tear down large amounts of cloud infrastructure from several differen providers—each of which have unique APIs and interaction patterns? Instead of needing experts in every cloud provider's API, operators can try Terraform—one tool that lets you automate infrastructure modifications for any major cloud service.

Hear about the four phases of Terraform adoption and how they reflect the maturity of your cloud operating model.

Speakers

  • Meghan Liese
    Meghan LieseDirector of Product Marketing, HashiCorp

Transcript

My name's Meghan Liese. I work at HashiCorp. And over the last few years I've had the chance to talk with some of the world's largest and most complex organizations. And as they're navigating their way through this multi-cloud, hybrid cloud world where there are tons of external services that they need to incorporate into their environments, there is a common theme that comes up: 1. What is this "operating model"—this cloud operating model that I need to put into place to really enable my organization to embrace all the offerings out there? 2. The natural next question is, What are the phases to actually implement this cloud operating model? 3. And then the final one is, Okay, where am I today? Each organization has to ask that question themselves, And, "How do I take steps to get going down this path?"

So before we get too far into what the journey is, we have to establish what's changed for our model, and there are really two key things: What we did before is we had a private data center and it was relatively static and homogenous. Now we're moving to a model where you have multiple clouds and you might still have your private data center, or maybe it's a private cloud, and you're embracing it in AWS and Azure and maybe GCP and the Alibaba Cloud and whatever those other services or cloud providers might be. That now means that we have a multi-cloud model across multiple data centers. It's heterogeneous, it's dynamic and it's distributed across multiple environments. So that's the infrastructure layer.

Then you fast forward and you kind of have another thing taking place, and that's really around this DevOps influence, where it's now, "How do I take this infrastructure that's distributed, heterogeneous, and dynamic and how do I create a pool of that that is available to multiple teams within my organization?"

Those are really the two distinct challenges that every organization out there has as they try and figure out what that cloud operating model is, and how they can put something in place to achieve it.

There are really two things that are changing that we're trying to address. One is around the heterogeneity of the infrastructure providers. We have the private cloud, AWS, Azure, GCP, and all of these different cloud providers, and they each have their own individual API that we have to interface with. Then there's the piece around the request coming in through the developers. One request might be, "Hey, can you spin up a thousand instances on AWS every Monday morning to run our applications?" And another one might be, "Could you spin out 300 instances with the various networking services on Azure three times per day?" So how does the operations team keep up with the pace of all of these requirements?

There are really three things we're solving for:

  • Scale: "How do I keep up with it?"

  • Heterogeneity of the various infrastructure providers

  • Making the infrastructure self-service to our developers

What is the cloud operating model?

Let's bring it back to what we said in the beginning. What is the cloud operating model?

If you don't do anything and you just go with the status quo, your cloud operating model will look like this: 1. I use some type of VMware management for my private data center where I run my VMware. 2. And then I adopted AWS so maybe I use their portal or their CloudFormation to provide some sense of automation to address that scale element. 3. Then I adopt Azure and I start using ARM templates, and then I adopt maybe GCP or Alibaba or any other type of infrastructure provider. And I have to adopt then what their individual automation or management portal is.

With each of these—because remember we're dealing with individual APIs for each of the providers—I generally need a team then that has the expertise to actually use that infrastructure. From an operator standpoint, I now have individual operations teams for each of those cloud providers, with a long on-ramp of 6-18 months, something like that. At the end result, none of these teams can actually leverage the work of each other, or have a cohesive sense for the infrastructure that's being provisioned.

So what I end up with is very siloed work across multiple different infrastructure providers, that then ultimately just requires another layer of abstraction, so I can provide it then to the developers. This is an incredibly complex model, and as we talk to hundreds of these large, complex and global enterprises, they've come to the same conclusion.

There has to be a better operating model for adopting a new infrastructure provider. That it can't take 18 to 24 months to onboard a new cloud or a new service provider, because that's not going to meet our business needs.

At HashiCorp, we believe the same thing. We believe adopting any cloud infrastructure or service should be safe, efficient, and as simple as a few lines of code. To simplify that operating model, we have created HashiCorp Terraform, and it aligns with the three core principles of HashiCorp products in general:

  • Automation through codification, so you codify your infrastructure.
  • Workflows not technology: We provide one provisioning workflow with Terraform so it works with all of your infrastructure. Using AWS, Azure, GCP or any variety of any external services and you can use that Terraform workload to both provision and manage that infrastructure.
  • And then the third part is about open and extensibility: And that's the ability to be able to incorporate any type of infrastructure into your environment at any time.

So we have over 125 different providers that cover a broad set of common infrastructure that people are using. These are the things that all of these organizations we've been talking to use.

But then there's also the ability to extend to new providers at any time. If you want to create a custom provider you can do that, or if new technology comes about in say a year or two years, you can create a provider so that you can interact with that technology as well. All providers work on an API basis, so Terraform's talking directly to the API, and preserving the uniqueness of all of the different infrastructure types.

Implementing the cloud operating model with Terraform

Organizations that want to get started with Terraform often ask, "How do I get started and what is the right journey to take to go from new-with-Terraform to running it as a shared service across my organization?"

Those are two ends of that journey. There are four phases that we see organizations in.

Phase 1

The first phase is how you get started, and that's downloading open source and using Terraform to codify configurations in a single cloud. This might be for one or two applications.

Phase 2

After organizations mastered that phase, you move on to phase two, which is, "How do I take that workload that I applied to my first cloud, which is maybe AWS, and extend that to Azure, and then maybe also your VMware environment?"

So in phase two you've gone to a single cloud where you codified the environment to run some applications, to now be able to codify your configurations across maybe three different environments that are distributed with one single workflow and leveraging the work of just one team.

Now as organizations go from, "Hey, I've got an operations team and they've effectively created some configurations that span three different cloud providers, or three different environments," [to] "How do I go where I can scale that team of operators?" Because, "Hey this is working. It's a simple workflow. I'm able to onboard other infrastructure. So now how do I enter phase three where I start incorporating more teams into the work I'm doing?"

Phase 3

In phase three, it becomes a different set of challenges. Remember phase two was all about democratizing multiple clouds across the organization? What that did is it enabled all the operators and a lot of developers to leverage Terraform open-source to codify their infrastructure and be able to provision.

Now as you enter into phase three, it's like, "How do I make sure that the organization as a whole is able to collaborate and leverage each other's work, so that they can all safely and efficiently provision the infrastructure they need?"

Phase 4

Now we move into phase four. In phase three we were enabling collaboration for our teams to work together in a way that they can leverage the work of each other. In phase four it's really about monopolizing on that automation, but also putting the right guard rails in place so that we can safely and efficiently provision across any different cloud at that scale.

What that means now is we're going to embed the policy as code into our provisioning workflow. We do that with Sentinel policy as code management that is part of the Terraform Enterprise product. And that, therefore, gives it the automation to both enforce governance and policy every step of the way.

A recap on cloud operating model adoption

So let's recap background on the three questions:

  1. The first one is the cloud operating model. That is building a consistent model around our challenges of scale, heterogeneity, and enabling our developers.
  2. The second one is, "What is that journey for me to put my cloud operating model into play?" How do I go from phase one where it's one cloud, to phase two where it's multi-cloud. Then phase three where my organization starts to be able to provision that scale, and collaborate and leverage the work of each other. And in that final phase four where you start putting the guard rails in place with governance and your policies.
  3. That final third question then is, "How do I get started today?" No matter which organization you are, that's really about identifying which phase you are at in the journey, and then what you need to do to get to that next stage. It's always moving you forward.

We've been talking to a lot of organizations over the years. And the reality is every organization is completely different, and they're different in their journey. To get started, you can reach out to us and we'd be happy to help you figure out where you are in the journey, and what the next best steps are for you.

If you'd just like to learn more, check out our online resources at hashicorp.com.

More resources like this one

  • 3/15/2023
  • Presentation

Advanced Terraform techniques

  • 2/3/2023
  • Case Study

Automating Multi-Cloud, Multi-Region Vault for Teams and Landing Zones

  • 2/1/2023
  • Case Study

Should My Team Really Need to Know Terraform?

  • 1/20/2023
  • Case Study

Packaging security in Terraform modules