What is the Tao of HashiCorp?

Transcript

Armon: A document that we published five or six years ago on our website is the Tao of HashiCorp. And what it really covers is, "What are those core design ethos that we apply to all of the products in our portfolio?"

What's important for us is that, as people engage with HashiCorp and use everything from Vagrant, Terraform, Vault, Consul, is that they feel like there's some consistency here. There's a consistency of thought, a consistency of approach, a consistency of design.

And so what we wanted to do was really peel back and document, what are those ethos? What are those principles that we want to have shared across our whole portfolio? And what we find is, in some sense they are not just design principles in consistency of the UI—it's partially a way to think about infrastructure management as a whole. What is the goal? As we were talking about managing infrastructure, and what are the broad-stroke techniques that make us more effective, reduce risk, reduce complexity?

And saying that was the goal, is we wanted to have a really clear assertion to our users, to our customers, that this is what you should expect from our tools. And this is why we published it.

Mitchell, do you want to talk about a few of the important ones?

Mitchell: Cool, so I think the three most important elements of our Tao are:

• Infrastructure is code—or versioning is code
• Workflow is not technologies
• Pragmatism

There's a number of elements, but those three really define our view both internally when we design products, and how we want our customers to think about the products we're delivering.

Workflow is not technology is probably the most important. It's really core to HashiCorp.

The idea that we don't build tools that work just really well with one specific technology, we're trying to build really great workflows to solve a problem. Maybe it's deployment, maybe it's security, building infrastructure, so on. We're trying to build that workflow and be pretty agnostic to what technologies are underneath.

And so when we were first building the company, the major two technologies in play were cloud virtual machines, like things in the cloud. And on-prem data centers that are bare metal machines. And so we worked really hard to make those two technologies work. Throughout the life cycle of the company we saw the rise of containers coming. And also schedulers. And so those are two more platforms that we've also had to support.

And the fact that I think we've been able to support those so seamlessly in our tools is a good testament to this Tao element. And the benefit of that for our customers is that they adopted, let's say a security tool five years ago, and after they adopted that security tool, all these new technologies come out, there are corporate strategy shifts and infrastructure. But even though it's shifting, they get to keep the same security tool, it remains best-in-class, the workflow remains the same, and they get all the same benefits. I think that's just really the most important thing that we do.

The other element that's very important is infrastructure as code or codification in general. And this is the idea that anything that is built or configured should be represented as code—as a text document.

And by representing it as code, you're able to get all of the benefits of having it in this basic format. Which is stuff like history, versioning, reviewing any changes and so on. All the tools that we make have an element where you can do everything as code.

And then the last element I think is really important is pragmatism. It's sort of like an escape hatch, but it's a really important idea, that we had these elements of the Tao, we're very, very passionate about them. But we don't blindly follow them if there are good reasons not to.

And so whenever we're building a new product or building features or anything like that, of course we would try to build it to the Tao, but we always have to ask ourselves, "Is this not a good idea for some reason? Is there a better way?"

Have years passed—have circumstances changed so that we should reevaluate how we think about things? And making sure that we're always open-minded to new ideas and change is really important. Because as a company, we like to think that we're leading the charge in a lot of ways and I think we are, but the world continues to evolve around us at the same time. And we need to adapt to that.

Armon: Yeah, and I think maybe just adding on to that, I think a really good example of where pragmatism comes to shine for us, is one of our other Tao principles is the notion of immutability: We don't modify infrastructure after it's been created.

We create a server, we configure it as version 5 of our web server, and if we want to upgrade to version 6 we create a new, pristine version 6, and then destroy version 5. We don't try to do an upgrade in place from 5 to 6, which opens us up to the possibility that, maybe that upgrade fails half-way and now we're in version 5.5 that we don't really understand. We've fallen to the sort of middle-ground.

So our view has always been, as much as possible, apply the notions of immutability to every layer of our stack. Build immutable images, focus on immutable infrastructure, and you see all of our tools nudge users down that way. We don't try and make it difficult to go a different way, but imply that the right way to do it is an immutable approach.

But I think, that said, we're pragmatic in recognizing that many of our customers have either large investments in configuration management systems, or they have certain applications and services that don't easily fit into the mold of immutability. And so I think a very pragmatic approach to that is we say, "Great, you can do both." We're not saying you have to go all-in immutable or don't use the HashiCorp tools. It's, where possible, where you're going to get that value and it's easiest to apply, our tools make it easy to do immutable.

Where you have existing investments in configuration management, or want to do things more manually, great, that plays nice with the tools as well. We don't force you into one camp. So I think part of that ethos is: Accept that infrastructure already exists, it's large, it's complex, and we can't just force everyone to do it the way we think it should be done. We have to be pragmatic and practical and say, "Okay, great, how do we help you get some of the benefits without forcing you to boil the ocean and do everything the way we think it should be done?"

Mitchell: Yeah, I think there's a human element to that too, which is a lot of new technologies tend to think, philosophically, that that's the best way to do it and so you should do it that way. And it's not that these companies we're going into don't want to do it that way, that might truly be the best choice. There's a lot of very practical reasons. Historical, types of technologies, mission-critical aspects of it, regulation. There's just a lot of reasons out there that they just can't yet.

We didn't want to be a technical vendor that walked into a room and showed this bright, beautiful future but didn't give them any way to get there. It seemed a little mean just to be like, "This is what you could be, but you're not." Instead, we like to go in and say, "This is what we hope and plan for you to become, and here's how we could get you there over the next two, three, four years." Or something. And while you're getting there, you're still using best-in-class tools with your existing opinions and practices.