HashiCorp Cloud Platform (HCP): A Whiteboard Video with Armon Dadgar

Our vision for HCP has three key components:

• Push-button deployment of any HashiCorp product to help teams move applications to the cloud faster.
• Fully managed infrastructure to enable a team to focus on building applications instead of managing clusters.
• One workflow across all cloud providers to give teams the flexibility to run applications wherever they need to.

HCP provides a suite of managed services for HashiCorp products with built-in workflows to deploy production-ready infrastructure pre-configured according to the latest best practices. Pay-as-you-go pricing lowers the barrier to entry so that smaller teams and organizations can get critical workloads into production quickly.

Upgrades, backups, monitoring, and scaling are handled automatically by the engineering teams that build the core products. Operational issues are resolved quickly since debug and performance related information is readily available to operators and support engineers.

Watch HashiCorp co-founder and CTO explain the HashiCorp Cloud Platform, its goals, and its components.

Transcript

I want to spend a little bit of time talking about the HashiCorp Cloud Platform (HCP) today. We're going to talk about...

• What it is

• Why we created it

• The vision for where we're taking the project

We announced the HashiCorp Cloud Platform in June of 2020 at our summer conference, so for those of you who aren't yet familiar, it's us starting to look at what would it mean for HashiCorp to transition to delivering cloud services.

If you've used HashiCorp tools for a while, you know we've always distributed our tools as open source as well as enterprise binaries. Whether it's an open source binary or it's an enterprise binary, the way we've historically delivered all of our products is—you can download it, you are free to run it, you can operate it on-premise. You can operate it in the cloud, can run it on your local machine for development, etc.

This is great. You get a ton of portability. You have a lot of flexibility in terms of how you operate it, how you deploy it. We have no intention of changing that. We always will distribute our tools as binaries that you can continue to download and use wherever you want. So when we talk about the open source or the binary, to get started with it, there's really a few key phases.

Managing HashiCorp Products Yourself

Obviously, you have to download it, but beyond that, you have to first start by deploying it. Suppose this might be a Vault cluster. For example, you have to configure the infrastructure for it, deploy Vault onto a handful of VMs, make sure it's set up properly. And then from there we go into an operation phase. When we talk about "operate", this is really about managing the life cycle.

So great, you deployed it at day one, but you have to make sure that you're keeping it up to date as new versions come out. You're patching the system if there's underlying security vulnerabilities with the operating system or the environment that you're running into. And then you're keeping up to date in general with new versions, security, best practices, etc. So the way to think about 'operate' is, it's not a one-time step. It's really an ongoing activity. It doesn't stop after day one. Once we've deployed and we're starting to operate, we've operationalized all of our monitoring, alerts, etc. Then we're really ready to move on to the third phase, which is adoption.

When we talked about the adoption phase of the product, what we're really focused on is actually using the product. Using Vault, integrating with our app, doing secret management, etc. In this model of delivering an open source binary or an enterprise binary, the customer or the user is ultimately responsible for all of this. So while this is great for a lot of our users—they like that flexibility, they like the power—increasingly, what we've heard from our users and from our customers is we don't necessarily want to have to do all of this work just to get the capabilities of the tool.

HashiCorp-as-a-Service

How can we just focus on the adoption side of it and actually getting value rather than necessarily having to focus on deploy or operate? When we talk about a cloud service, the goal for us is to take the first part of it and make this HashiCorp's responsibility. When we talk about the deploy phase and the ongoing operations of patching monitoring, etc, this is a HashiCorp problem.

The customer is then able to focus on just this last piece—this becomes the end-users' focus. The goal, when we talk about moving to this cloud service model, is: how do we focus on the time to value or the time to adoption? You can skip this earlier phase and go right into getting the value from it. But you also have a lower operational overhead because that's a problem that we solve for you. So in some sense preaching to the choir when we talk about cloud services for a HashiCorp user, this is relatively new for HashiCorp.

The vehicle for us to deliver these cloud services is what we announced and is called the HashiCorp Cloud Platform. The idea behind it is HashiCorp Cloud Platform, for shorthand we call this HCP, is that it will be the common chassis for us to deliver all of our applications as a managed service.

So you'll log in, and you'll have an account with HCP. You'll have a billing relationship with HCP, but it will ultimately span all of the major clouds. This includes AWS, Azure, GCP, etc. The goal is that this platform is available anywhere that you want to run infrastructure: all of the major public cloud environments, and then above that is where we are able to then offer our services. The products that we know and love already: Vault, Consul, etc, as a service.

HCP Roadmap

What we've announced to date is that we will have the Vault service on AWS later in 2020, as well as the Consul service on AWS, going public GA [Correction: HCP Consul was released in public beta at HashiConf October 2020, not GA]. What you should expect to see from us is a gradual filling in of this. So over time, all of the HashiCorp products will be available, and we'll expand that to all of the major public cloud environments.

This is the high-level goal and vision of where it's going. If you want push-button managed services, you want it to span any cloud environment you want it to be in, how does this actually work?

How it Works

At the core, there is a shared responsibility model, similar to other cloud services. But one of the requirements we've heard loud and clear from our users is: "we want to be able to do private networking to these services." If I'm trusting my credentials to Vault or my core network service discovery to Consul, I want that single-tenant. I want that in a private network environment.

So the architecture of how this works fundamentally is: you have your core HCP account, and then what you do is define what we call an HVN, a HashiCorp Virtual Network. So an HVN is tied to a specific cloud region. I might have one HVN, and this might be for AWS East as an example. And then I might have a different HVN here. Let's just say this is for GCP West. And then I can deploy any of these services into one of those managed regions. So I can say, I want a Vault, for example, in each of these regions. So you'll get A HashiCorp managed Vault cluster running in these two different locations, one in AWS, East, one in GCP, West.

In the future, the goal would be to include the ability for you to specify that you want these replicated, and we'll manage that for you, cross-cloud, cross-region. But now if I'm running my application, my own infrastructure in these regions, this is where there's this dividing line. Everything below this line is owned and operated by HashiCorp. Above this line, as a customer, you can have your own Amazon VPC here. What we will support is a direct pairing relationship between our VPC—that's being managed on your behalf, single-tenant, only for you as a customer—and your VPC. This enables direct network access.

If I have a web application here or really any application, and I want to interact with this Vault cluster, I don't have to transit over the public internet. Instead, I have a direct private connection directly between my infrastructure and my Vault cluster running in a single-tenant way. Likewise, the same exact pattern would extend if I had, let's say, a virtual network over here. So here I have my GCP network, maybe I have an API service as an example, I would do the exact same thing, establish a pairing arrangement between my HashiCorp-managed HVN, and then my application can talk directly over this private network.

At a very high level, you start to see how the system works and what our goals are. We want to be able to deliver all of the HashiCorp products as a managed service. So you've got that push-button deployment where the onus of operation, patching, security, etc, is a HashiCorp problem, not an end-user problem. So really a focus on how quickly can we get the value of the product? How much of the operational burden can we get rid of? You also get it across all of the major public cloud environments. And then to enable that single tenancy in that private networking, we have this model where you can create these HVNs that are abstracted, and then you can pair with these directly, giving you that private network access.

As you can tell, we're super, super excited about HCP as a big vision, and there's a lot of work ahead of us to realize all of it, but we hope that you check it out, try it out today. The system is in GA, and we're starting with Consul on AWS and expect to see more services and more clouds shortly.