Keynote: The Role of HashiCorp as a Partner and Enabler on the Cloud Journey

HashiCorp's CEO Dave McJannet understands the amazing responsibility that comes with being one of the top enablers in the cloud transformation solutions arena.

Innovation in today's economy often comes from software, and that software often needs solid infrastructure foundations. In this closing keynote segment, McJannet discusses how the HashiCorp suite often fits into a Global 2000 company's IT infrastructure and shows the level of trust many of the world's most popular software services place in HashiCorp infrastructure products.

Transcript

Thank you. Obviously, we've made a bunch of pretty significant announcements today around Terraform and Consul, and I want to just step back a minute and provide a bit of context to what it is we're trying to do as an organization.

As Armon highlighted, whether by accident or by design, we live in a multi-infrastructure world, and our mission is to enable consistency around how you interact with those core principles of that modern infrastructure stack.

If you think about what we've done, collectively over the world of infrastructure or provisioning over the last couple years, it's astounding to see the progress that Terraform has made.

We do some of it, but many of you in the room do much the rest of it. Today, not only is Terraform a standard way for interfacing to how you provision infrastructure on Amazon or Azure or Google or even Alibaba or vSphere, but the inventory of providers outside of those cloud providers is amazing.

There are 250-plus distinct providers in the Terraform ecosystem, and all you need to do is spend a couple of seconds on the GitHub repo to see the velocity of how those are evolving. In some of our customer meetings, I open up a browser and say, "Listen, I think if you want to see what a vibrant community looks like, just spend 30 seconds refreshing your browser in the GitHub repo for the Terraform providers."

Literally every 10 seconds something new is being updated, and it’s being done by you. What that allows is for you not just to configure the infrastructure on Amazon or on Azure in a consistent way, but you can now configure the dependencies associated with the infrastructure stack, because Terraform's templating mechanism allows you that single language for everything that you need to provision.

That's super-cool for us to see, and we're super-grateful for the work that the community does.

The second principle, as Armon talked about, is in the world of identity-based security. The notion of identity as the basis for who can access what and what machines can access what inside the datacenter is a pretty clear thing. This general harmonization around the identity-based model for machines has taken hold, and many of the most sophisticated applications on the planet use Vault to underpin this process.

The model's super-cool for us because, given the modular nature of it, whether it's LDAP or Active Directory or Azure Active Directory, it can be loaded as a backend, and then you can connect any system that you like.

If you watch the repo of system backends on GitHub for Vault, you'll see that any system you want to apply this principle to is available to you. That only happens by virtue of having an enormous community of people collaborating in the open source to make this happen.

If you've been focusing on what we've been announcing, this notion of networking is a difficult thing in the cloud model. Those of us that have been looking at this for a while, you stare at it and go, "Hold on a second. In the cloud model, the application elements are coming to us in much smaller pieces, largely in the form of containers."

Number 2, they're ephemeral by design, which means they're going to scale up and scale down. That means they have different IP addresses every time they come and go. It's implausible for a human to reason over the firewall rules associated with those applications.

That's why for most of our customers, networking is the biggest challenge for applications seeing traffic after they're deployed, just because of the firewall realities of that. It stands to reason the same way we went to identity as the basis for security in the machine sense, you have to inevitably go to service name as the basis for routing in the networking sense.

The service mesh use case is a derivative of that, but Step 1, and the reason that Consul is by far the most widely deployed product is you need to create this common registry that tells you where everything is.

When I deploy a new application into that world, it updates the registry, and then I can do derivative things from that: route from Service A to Service B. The more extreme service mesh use case is about encryption when those things actually speak.

But the higher-level concept of service networking to us just feels inevitable, and that's why we spent so much time and energy on this, and it's why Consul is an enormous investment for us, and it's super-fun for us to see it get used.

What we all in this room recognize is that the shift to cloud is not just a shift in dropping an artifact somewhere new. It's a completely different way of building and delivering applications.

Because what you're doing is you're dropping that application artifact into a low-trust network that has no clear network perimeter, that is ephemeral by design, and that causes all the participants in the IT chain to have to rethink how they do their job. That’s why Armon described it in the layer view.

We have the benefit of speaking with literally hundreds of companies around the world on a weekly basis, and the pattern that we see most often played back to us is not something we prescribed initially, but is what we observed maybe a year and a half ago: People are standing up Terraform as a central shared service for their organizations.

They're telling their application teams, "If you want to go to cloud, I'm giving you one aperture. Nobody else gets the credentials to Amazon or Azure. I'm going to control it through a single set of templates that are pre-approved. If you use Terraform and the central shared service to Terraform, as the basis for those applications getting deployed, you can deploy 100 times a day. Knock yourself out."

At the security layer, we see people building the central shared service around Vault to use this identity-based notion, first of all, to enforce access to system secrets, but ultimately to enable encryption and advanced data protection use cases around those applications in the cloud model.

And they say, "If you reach back to Vault for your credentials, you can deploy your app 100 times a day. I'm getting out of your way. I'm giving you my implicit sign-off for you to deliver that application to that cloud world."

At the networking layer, if they say, "If you want that application artifact to see traffic when it gets there, we need to have a sign-off previously that says, 'You're going to include Consul client in that application element when it goes.' I will run a central shared service for Consul server, so that when that element lands in the cloud model, whether it's on-prem, or whether it's Azure, I will route traffic to it straight away, because I'll discover it. And now I'll optionally encrypt it, and with the service on Azure, it gets even easier, because now that can be set up for you." That model just makes a ton of sense.

So whether it's a Java app, a .NET app, a Cloud Foundry app, a Kubernetes app, or a Nomad scheduled app, it doesn't really matter. When we talk about the cloud model, this is what we refer to, because the consistency that we get to see as a vendor is on how all of our customers end up deploying our products, and this is what it looks like.

The users are at the heart of it all

The other really cool thing for us is that you all are at the center of this. You're the ones that are sharing with your organizations the realities of what it means to deliver applications in the cloud world. You're the ones who are providing this critical enabling role.

Our role, and our commitment to you, is to continue to deliver these tools using the open-source model. We think this is the way we can aggregate enormous communities together to make this all work for all of us.

Number 2, our commitment is to build commercial versions of these projects, because we recognize that an individual's technical need to provision 100,000 machines on Azure is different from the challenge of a team or an organization that has to work with that tech. It's like going from Git to GitHub, in a sense.

The team problem is one of collaboration. The organization problem is one of governance and policy associated with that provisioning process. That is something that our customers have brought to us as a requirement, and that is where we build our commercial products.

The third element that we're committed to is to continue to invest in the organization to deliver on the trust that you implicitly place in us when we play that role.

When you commercially partner with us, it allows us to invest back in the ecosystem, build better documentation, build our products, partner with bigger organizations to allow you to do what it is you do, and that is build mission-critical applications every day.

Obviously, we couldn't do this by ourselves. We have an enormous ecosystem of partners that we work with. I think it's particularly cool that we have Amazon, Google, Azure, and VMware as platinum sponsors at this event, which I think is indicative of the role that our products enable for those companies. They reduce the friction to the consumption of those platform technologies for all of us.

Beyond that, there's an enormous ecosystem of people that I would highly encourage you to take a look at downstairs in the partner pavilion. If you're running cloud infrastructure, I'm almost certain that these companies are of interest to you, and obviously we have an enormous ecosystem behind this.

In closing, I want to step back even further. Our central view is that the infrastructure that we provide enables some of the most sophisticated applications on the planet to be built. That is a super-fun role for us to play. We take it incredibly seriously. But you're the ones driving the change. We're here to help you, and I just want to take a moment to say thank you for all the support that you give us.

This is a really fun thing for us to do. When we talked to customers yesterday, just as an example, you get to see how significant these products are in the runtime of some of the most important applications on the planet.

So, thanks for all the support. We're honored and excited to have you here. Have a great conference.