Keynote: Terraform Cloud & Cost Estimation

HashiCorp has been planning to bring Terraform to users as a managed cloud service for quite a while, and today it's finally here with three tiers: Free, Team, and Team & Governance

For no cost, Terraform Cloud is available to 5 users and gives them numerous features that open source users would have had to build or set up themselves. These include:

• VCS / Remote State
• Workspace Management
• Secure Variable Storage
• Remote Runs & Applies
• Full API Coverage
• Private Module Registry

The Team tier adds unlimited users for $20 per user per month. It also adds role-based access control (RBAC).

Finally the Team & Governance tier adds Sentinel policy as code and a new cost estimation feature.

Transcript

When we talk about Terraform, everything started with the practitioner, with the open-source tool. It was, How do we solve that problem of doing multi-cloud provisioning in an infrastructure-as-code way, that's going to be simple, and expand to multiple clouds and providers?

From there we heard from a lot of our users and customers that they wanted to use Terraform in an enterprise setting, but they had a whole different set of challenges. How do they connect it back to audit logging and single sign-on and policy-based management and role-based access controls? There's a ton of scaffolding needed around the open-source tool to make that work in an enterprise setting.

For folks in the middle, this left a major gap. How do you collaborate with your peers if you're not in a regulated corporate setting? Maybe you don't need Terraform Enterprise; it's too big.

New features for Terraform Cloud and the Free Tier

What we announced last year was Terraform Cloud along with the Free Tier to start to solve this problem. Much like GitHub provides a shared notion of a master branch for a development team, what Terraform Cloud does is provide a shared set of state so that you have a master notion of what your infrastructure looks like. It becomes a point of collaboration, just like GitHub does for development.

Last year we announced Terraform Cloud along with its Free Tier, which provided just that sort of centralized state storage. For folks who have used Terraform, I know in the past you might have used remote state storage on Consul and S3 buckets and things like that. But we wanted a more first-class experience.

What I'm super-excited to announce today is a major expansion to the feature sets and capabilities of the Free Tier. There are a few things that I want to touch on here. One is the state storage, which we talked about last year. It's still a part of it, but now we're bringing in remote abilities to do plans and applies, the full Terraform workflow within Terraform Cloud.

Now when you run terraform plan or terraform apply locally, it'll be executing it server-side in a centralized way. What this allows you to do is connect the experience of the command line, where it's unchanged, to a web interface, where you and your peers can see what's actually happening, what's the history of those changes, to an API, which will allow you to do all those same things.

You get the full workflow, but now you can access it in multiple different ways, and collaborate with a team, as opposed to just on your machine.

The other big problem is, How do we start to share and have these repeatable patterns in terms of working together? (We'll talk about the private module registry in a second here.)

What does this look like? If we look at the command line for Terraform, if we're running a local plan, it looks exactly the same as before, and this is by design; nothing changes. Your local workflow is unaltered.

When you're using Terraform Cloud, Terraform works just as you would expect. In some sense nothing changes. The command line acts as a terminal to the API behind the scenes, and it's invoking the right APIs for you transparently, but the user experience is unmodified.

But now you can see that exact same run happening in real time in the dashboard. You and your peers can see it, you can comment on it, you can collaborate on it. There's a history of it that operates like the Git commit history.

You can log in and do the "Git blame": How did this change get made? When did it happen? Who made the change? Why did they do it? What's the Git command that it ties back into?

It gives you this way of understanding how these changes happen in a central view.

Whittling Terraform config monoliths into smaller chunks

This is a view if you zoom out to looking at multiple workspaces. What ends up happening often with Terraform is people start with a relatively small configuration, and it grows with complexity, organically over time, until it becomes these giant configurations.

These become difficult to manage. They become higher-risk when you're making a change. It takes longer for applies to take place, because there are so many resources under management.

One of the things we want to encourage is a more granular decomposition. You don't want one monolithic application; you want many smaller services.

Same with Terraform. You don't want one massive configuration; you want many smaller workspaces that you compose together, and each of these then become safer to work with, with a smaller blast radius, easier to reason about, but you can compose them into a large infrastructure.

Terraform Cloud gives you this ability to think in terms of these smaller chunks, and compose them together easily.

As we think about shifting into this mode, we don't want to break the local workflow, but how do we get out of the business of distributing, let's say, AWS credentials to all of our developers? Instead, we can define those centrally, put them in as a variable to our execution, and those will get filled into Terraform just in time for the execution.

But we can mark them as sensitive, we don't have to distribute them to the whole team. If we need to rotate or revoke them. We can do that in a central way. It puts a central place where we can manage these things rather than having to worry about distributing credentials and settings to everyone on our team.

Introducing the Terraform private module registry

The final component of this is the private module registry. We've had the Terraform public module registry for a few years, and it has thousands of modules that have the best-practice ways of getting started with defining networks and middleware, and common application architectures.

This is great if you're willing to build a pattern and share it for the whole community, but what if you want to take one of those and modify it in a way that makes sense for your business, your context? It might not be appropriate to share that with the whole world.

This is where the private module registry helps. You can build your own modules that are designed for internal distribution. It might be tweaks that only make sense within your environment. You can capture all those, put them, and share them internally. It operates just like the public module registry, just with a different set of visibility and controls.

I'm super excited that all of this is available today. If you have an account already, you can log in. It's all there. If you don't yet, visit terraform.io. You can follow the link and register, and get started with the Free Tier.

Terraform Cloud for Teams

One of the challenges when we talk about the free team collaboration is that, over time, you're going to add more users. You're going to get to a bigger state, where your problem changes a little.

When it's a few users you're not as worried about things like security or policy or consistency. It's only a handful of people. But as you get bigger, you do worry about, "Should everybody have the ability to modify my core network systems? Should everybody be able to change the core shared databases? Or do we want to have more fine-grained access?"

Maybe app teams can modify their infrastructure, but core networking is handled by someone else, shared databases are handled by someone else. And we want to be able to share that, but without giving away the keys to the kingdom.

Similarly, we might want a consistent enforcement of policy. What instance sizes are we allowed to use? What regions are we allowed to deploy? What times of day can changes be made?

This is a different set of challenges that we look at solving with a different tier of Terraform Cloud. So I'm excited to talk about Terraform Cloud for Teams.

Terraform Cloud for Teams adds on top of the Free Tier, and looks at a slightly different set of challenges: How do we define a set of teams and provide different sets of permissions to them in terms of who is allowed to make what types of changes in a fine-grained way, and allows us to collaborate with an unlimited number of people?

It also changes the module registry to bring in role-based access control. You might want some people who are allowed to publish the modules, and people who are only allowed to consume.

Sentinel and policy as code

Lastly, it also exposes the Sentinel, our policy-as-code engine, for doing that fine-grained policy.

What this looks like is what you would expect, very similar to something like GitHub. You can define a set of teams, and then govern what they're allowed to do.

You might say, "My core network team, they're allowed to define and modify the network, while everybody else, they can read it. They need to know what's my VPC ID, and the subnet IDs, and things like that, but they shouldn't be able to modify any of that."

With the Sentinel engine as well you can define very fine-grained policy, things like allowable regions, allowable instance sizes, times of day that you can deploy, etc., and you can install these in different modes. Whether they're hard mandatory and there's no way to escape them—it might be a security thing like, "Don't open the firewall to the whole internet"—or if they're simply advisory like, "Hey, this instance type is deprecated; you should probably stop using it. We're not going to stop you, but here's a heads up."

This is all part of our Sentinel engine, and this gets exposed as well. With this, we round out thinking about these different layers. Terraform starts with the individual practitioner, and that's where it grows from. You start there, and it goes into smaller teams, and from there, if we succeed, you end up using it at hundreds of thousands of users at the enterprise tier.

Now there are multiple ways to get started.

With Terraform Cloud Free Tier, we want it to be super-easy to get started. It's free, you register today,

At some point you might transition to a larger team, where you start with Terraform Cloud for Teams, which is $20 a user a month.

From there, if you get really large, we're happy to chat with you about Terraform Enterprise if you need things like single sign-on, single tenancy, hosting it behind your firewall, and things like that.

Part of our goal was thinking about, How do we have a consistent Terraform user experience? Some of you who have been using it for a few years might have seen that Terraform's user experience changed at every scale, whether when you start at Day 1, to you had a team and you had to cobble together something in a CI/CD pipeline, to you try to figure out how to wrap policy around it at scale.

The challenges force you to break your workflow. This was really a key thing for us, going back to the Tao of HashiCorp, the notion that workflow is our most important thing. We were thinking about, How do we make that consistent? How do we not break it even as you go from 1 user to 1,000 users?

This is part of that standardization, of making that a clean and simple journey. We're excited for you to try it, and excited to have your feedback.

Terraform and provisioning as a lifecycle

When we talk about Terraform, we're often talking about provisioning as a lifecycle. What I mean by that is it starts with Day 1. Day 1 is what most people mean when they talk about provisioning. It's going from nothing to something. I want to go from I have nothing running to my initial network and VMs and things like that.

In many ways, this is the simplest problem; there's nothing to mess up. There are no users, there's no data, there's nothing running, so the worst you can do is fail to set it up. This is the luxury, easy problem.

As you get to Day 2, this is when life gets more challenging. You have an existing infrastructure, and now you want to evolve it. You're going to scale up, scale down, change a config, etc., but now there are users, there's data, there's live production traffic.

This is a much more challenging problem, because now there's risk, but it's the problem you have every day outside of Day 1. This is where we spend a lot of time and attention on things like terraform plan to make sure that you have the confidence to understand what's going to happen before it happens, to give you fine-grained ways of making changes, and give operator confidence.

And then there's ultimately Day N. You have that existing set of infrastructure, but you don't need it anymore. Maybe it's a testing environment, maybe it's a service that you're turning down, but you want to go from something back to nothing. In this sense, you complete the lifecycle. You went from nothing back to nothing, sort of cradle to grave.

When you think about Terraform in that lens, as a lifecycle, it becomes clear that it's an ongoing activity. It's not something you do one time Day 1 and then you forget about it. You're managing it much like code. It becomes a living, breathing thing.

If you think about it through that lens, provisioning doesn't happen in a vacuum. it's connected to other things in our infrastructure. It's connected to the day-to-day of how we work together. One of the goals is, How do we enable Terraform not just to be a Day 1 provisioning tool, but a platform that's part of your infrastructure, and part of your lifecycle?

So we look at the ecosystem around Terraform. There's the southbound side; that’s probably what most people are familiar with. This is where I'd put the Terraform providers, whether you have the major cloud providers, whether you have big on-premises vendors like VMware and Nutanix and F5 and Cisco, whether you have PaaS like Kubernetes or SaaS like Datadog and New Relic and GitHub.

The providers are what allow Terraform to integrate with this whole universe and manage 250 different types of providers today. There's always been a concerted effort on, How do we grow that ecosystem and support everything that you might want to manage as code?

But then if we talk about the northbound side, it's not about technology and infrastructure; it's about workflow. It's, How do I go about making these changes? What's the environment in which I'm working?

There the focus is on things like version control systems, GitHub, and GitLab, and Bitbucket. Where am I starting my infrastructure-as-code journey? Oftentimes, in version control. But then you might have a set of CI/CD practices that you build around it.

So, How do we integrate with Circle and Jenkins and Travis and all the major CI platforms that you might want to use? Similarly, how do I collaborate? Is that in Slack? Is it in other mediums? Do I have to use things like ServiceNow to do approvals for changes? What are the workflow pieces that I need to really integrate this into how I get things done?

Our goal is to start focusing on not just the southbound side, but the northbound side, and create a rich ecosystem around Terraform.

When we think about Terraform there are multiple inputs. There are things that might want to trigger it. There are things upstream that Terraform might want to notify, and systems that might want to interact with it on the southbound.

When we think about triggering, one major thing is version control systems. I make a change, and I want to automatically trigger a terraform plan or a terraform apply from that. Today we have tight integrations with GitHub and GitLab and Bitbucket, and more coming.

Terraform’s integration with ServiceNow

But what about organizations who maybe aren't ready to go full infrastructure as code? These are organizations who are maybe used to a more ticket-driven approach; they're using an IT service management system. How do we meet those people halfway? How do we give them some of the benefits of infrastructure as code without expecting them to fully abandon the way they work today?

One of the major integrations in the last year that we're super-excited about is ServiceNow. Users of ServiceNow might be more comfortable going through a UI, and using a point-and-click, ticket-driven interface. Now what Terraform Cloud enables you to do is automate the fulfillment of it.

You can expose a service catalog of different services, maybe a Java MySQL app, for example, and the user can come in and request this. But although it looks like requesting a ticket, the backend of the fulfillment is automated. This kicks the job out, and uses the Terraform templates to do the execution and the provisioning.

The benefit for organizations is they eliminate that multi-week wait for infrastructure, but without totally disrupting their workflow.

What about the things that Terraform needs to talk to? Provisioning doesn't just end when the infrastructure comes up; there's a bunch of upstream services that we might want to connect with.

One of the things that we've heard loud and clear is that you want Terraform where you actually collaborate, so there's now native Slack integration so you can get notifications anytime a plan gets scheduled, or an apply completes, or an approval is needed. So you can collaborate where you're already working.

There's a whole host of upstream services that you might want to talk to. This is where having a rich set of webhooks comes in: You can use this to integrate with either other ISV technology partners, custom software you build in-house, simply gluing together different pipelines with CI/CD solutions. But it lets you bake Terraform into a broader ecosystem of automation.

This is how we think in terms of, How do you enable this to be a piece of larger puzzle?

Before we move on from Terraform, there's one more thing in this ecosystem that I want to talk about. When we talk about the initial goal of Terraform being, "How do I enable the provisioning to take place?" the focus was the Terraform open-source tool. It's infrastructure as code as a philosophy, and it's a pluggable, extensible set of providers.

From there, it opens up a new set of problems, like, "How do I manage the risk of this? Now I have people who are provisioning in the cloud; they're doing whatever they want. How do I make sure whatever they want isn't going against what I want? I don't want open firewall rules, and I don't want people deleting my core networks."

This becomes a multi-faceted approached. It's things like role-based access controls, granular workspaces to reduce risk, Sentinel and policy as code to define a sandbox. It's, How do we lower the risk the things that we don't want to have happen happen?

Introducing Terraform cost estimation

This opens up the next challenge, which is, "We've defined a sandbox in which we can do things, we've enabled people to provision, but, oops, we provisioned a whole lot of things that we're not using, and we left them running." Or, "Did we really need the quadruple extra large TPUs for our dev box?"

There's a bunch of costs that start to accumulate that can become shadow. So I'm super-excited today to announce cost estimation in Terraform Cloud and Terraform Enterprise. As a quick sneak peek of what this looks like, cost estimation runs as a workflow step in between the plan and apply phase.

So you write your infrastructure as code, you run your terraform plan and terraform apply just like normal, and in between those 2 phases, Terraform will analyze what your configuration is and make a best guess of what this is going to cost.

It's going to look at the resource definitions, and understand, "What will this cost on an hourly or monthly basis? What's the point estimate of this apply, and what's the delta from your existing infrastructure?"

It starts to give you visibility into, "Did I really intend to introduce that much cost?" But it also lets us annotate these workspaces with those estimates and give you some idea: "If I have hundreds of workspaces, where does my cost sit? How did I get to this one sum picture that I get at the end of the month in a bill, and where is that cost originating?"

Unfortunately I don't have time to go deeper into this today. I would encourage you all, if you're interested, to check out the keynote by director of Terraform engineering Paul Hinze and Terraform product director Robbie Th'ng later this afternoon. They're going to go much deeper into all the announcements and all the latest and greatest with Terraform.

But again, all of this stuff is available today, everything I talked about—the Free Tier stuff, all the new teams, cost estimation—it's all available. Go to terraform.io, sign up, and register today.