HashiCorp CEO David McJannet | Powering the Multi-Cloud Paradigm
14 Jun 2022 · 44 min
HashiCorp CEO David McJannet explains the company's Unix-like philosophy: one tool per problem. Terraform handles infrastructure provisioning, Vault manages identity-based security, Consul handles service networking, and Nomad schedules distributed workloads. McJannet argues multi-cloud and edge deployments will persist as cloud services unbundle.
Chapters
Hi, everyone. Welcome to Grey Matter, the podcast from Greylock, where we share stories about company builders and business leaders. I'm Jerry Chen. General Perner Greylock, and today my guest is David McJanet, CEO of HashiCorp. HashiCorp is one of the defining companies in the cloud and we're super excited to have David today. Hashic was started in 2012 and went public last year and it's been one the kind of category defining cloud infrastructure, cloud open source companies, and, and I've had the privilege to work with David for many years. So Dave and I worked together first at VMware over 10 years ago, and then he was briefly eir at Greylock. So. Hey, David, thank you for coming on the podcast today.
Thanks for having me. Yeah, it has been 10 years, shockingly, in fact, probably slightly more.
It's been 10 years and obviously the news a couple weeks ago of VMware Broadcom acquisition. You know, I want to talk about all things cloud, but maybe just riff about our times there and you know, Cloud Foundry v fabric is how you and I first came working together where we try to build this first effort around cross cloud multi cloud software. What do you think we got right back then and what do you think we got wrong?
To me, there's such a consistent pattern to this stuff of existing spend categories transitioning from old world to new world. And essentially what Cloud Foundry was was a bet that the app, the app server market, basically how people were going to run and deploy applications was going from a world of like weblogic, websphere, maybe tomcat, to a world of this sort of highly curated runtime platform, which at that time we were just sort of messing around the wording with as a platform, as a service. And so that turns out the platform as a service notion is just a modern version of an app server. And I think we got that right. I think we also got got right the idea that developers just want to be able to do a CF push rather than, you know, declare all the infrastructure that underpins that application, just want to push that application element. I think that part got right. I think Cloud Foundry then became a thing. In fact, we were joking about how that got started. It's actually amazingly simple how these things you sort of get ideated become these things. I remember the picture on the whiteboard of what ultimately became Cloud Foundry sort of got propagated around the Internet. I think you got the design from 99designs or something similar. It was not very complicated how it all got started, but it turned out to be pretty right.
Best $99 you spent on my crypto dynamics back then. So maybe we'll segue that to kind of this journey to Hashicorp. I mean, you did a brief stand at a couple of the companies before landing at Greylock. As eir we're going to get in the weeds around cloud and open source and Hashicorp. But for those listening to podcasts that may be less familiar about deep, deep infrastructure technology, tell me a little bit about Hashicorp. What are the products you sell and how do they work together?
Sure. So our core thesis was that the infrastructure transition underway is from people running private data centers to people running cloud, which is just a different operating model with kind of very different paradigms for the core aspects of infrastructure. And so we provide a suite of products that address the challenges of running and securing apps in distributed systems that is outside of the data center. We took a very Unix like view of the world, which is let's create one product that does one thing and then another product that does another thing and you can use them together. Originally the team said, I think there are actually four problems we need to solve to run cloud infrastructure. So let's try and solve all four of them. One that's around infrastructure provisioning, well, that became Terraform. One's around the identity based security of things in cloud. Like, can this thing talk to this thing? I don't know, what's its identity? That's the core paradigm of security in the cloud is identity based, and that is vault. Then the question becomes, how do I network it all together? This thing wants to talk to this thing, is it allowed to? Well, vault tells me that, but the actual connecting of it is what Consul does. So it's a modern take on networking. And then the fourth problem to solve is how do I then run compute jobs across that distributed fleet? So those four problems, basically infrastructure, security, networking, and then the runtime are the four problems that have to get solved in cloud. And so ergo, the Hashi stack was born. So these are actually independent products that were created, but you generally use them together. So today we see companies that run like a 20,000 server estate, they run these products to underpin them all, and it basically acts as one throbbing, humming distributed compute fabric with nomad scheduling jobs across the top. So pretty complex distributed system stuff, but it decomposes into really four core products that underpin it.
Yeah, I mean, those four core things, identity, security, networking, infrastructure you and I have riffed on, have been the core paradigm from the first mainframe to the Minicomputer to the PC to the cloud, that you always need compute, you always need networking, you always need identity, you always need infrastructure. And what happens is every time there's this platform shift, these elements get rehydrated into different technologies. But to your point, I think the genius of HashiCorp was one you identify. These are the atomic elements or the stem cells of the cloud that can either work independently and some of your customers do, but also work together as a stack. Because the evolution to this cloud comes at different paces, different rates for different customers. And so your ability to have customers either start with Vault or start with Console or start with Terraform and then evolve over time, embracing all four parts is super interesting. I think that's one of the things you guys got right that we didn't get right at Cloud Foundry, for example.
Exactly. I think all platform tech, again, in hindsight, gets adopted the same way. It's about balancing insertion point versus big picture vision. So what I just described, imagine, and this is literally what we see in our customers. Like if you're playing a game or if you're sending a message to your friend, or if you're streaming a processing payment, it is going through our stuff. And what it's doing is a basically federated feet of thousands of servers that that customer is running and they put this stuff on top and it's basically like having a single computer look like across a thousand different machines and then finding that open slots to drop in things where there's processing space in a secure way and network, et cetera. So that's what it looks like at scale. That's pretty sophisticated stuff, but that's not where most people start. It's too big of a vision for them to get there, to have 20,000 servers wired together like this. So you have to determine an insertion point, which is why this sort of un philosophy worked really, really well. You know, how about you just start with the infrastructure provisioning problem? Let's just start with that one. And I can walk you over the course of years into that broader picture vision. Once you're ready for it, it's just too big of a vision to sell because it's such a different paradigm. Cloud Foundry, conversely, says here's your black box. And people go, well, that's an awfully big black box, like what's it doing? And you go, don't worry about it, it just works. So what happens when it doesn't? And so there's just a lot of reluctance and it's very hard to get a Bottoms up. Adoption motion when I'm just telling you one big thing now, people want to be able to adopt the elements and walk your way to it.
The insertion or I keep preaching like the sharpness of the wedge with matters, right? It's the pointy tip of the spear or the sharper wedge. And oftentimes with startups, you want to have a very narrow wedge to land insert with low friction. You always want low friction in, high friction out, right? As a platform company, infrastructure company, and many startups fail because they see the second or third act where they want to be. But they forget that you don't get to third act if you don't have a very good wedge to land on. I think the nice thing, what you guys built at Hashicorp was this portfolio of three or four different wedges. One is historically an open source, especially in the cloud, especially with developers. And the history of Hashicorp is obviously tied with open source. And I love to hear about how Hashicorp thinks about open source. Both invest in the ecosystem, then balancing that with a product you guys build and the business models around open source, be it an enterprise version you sell versus a cloud hosted version.
I'm kind of a disciple of the view that you can't build an infrastructure company today that isn't open source. That's just my particular view. I think VMware was the last one. It was built at a time where open source really wasn't a thing. I just think it's hard to build infrastructure companies that isn't open source because so many people rely on it and they actually, they need it to be open source in many respects. So our view is always the products were going to be open source and we authentically commit to that. And I think that the approach you take is you say, all right, what's the role of open source? There's a development role and there's a distribution role. On the development side, how can we construct a project where we. We can invite people to collaborate with us, to aggregate more people to build things that we wouldn't otherwise build while retaining control of the direction of the project? Like that. There's a science and an art to that short version is it kind of comes to the architecture of those projects. For example, you'll notice Terraform, there's Terraform Core, and then there's the provider ecosystem for what plugs into it. There are thousands of contributors to the providers. There are very few people that contribute to Core. And that's where the way the model works. Well, for Everybody. So number one, it's about getting development leverage and that's one path. The second part is how do you drive standardization? That's really what you're trying to achieve because you get distribution and practitioners through open source. There's no friction to the consumption of it. But you also get ecosystem standardization. So the real magic of something like Terraform today is that there are thousands of Terraform providers. So if you want to use Terraform to provision something, you know there's a Terraform provider for it, whether it's for provisioning stuff on Amazon or whether it's for configuring your GitHub account. Why? Because someone has built a provider for it. And actually it's the standardization that you're trying to accomplish with open source that is just like, why would someone build a plugin for Vsphere today or like a driver for vSphere? You wouldn't until all your customers required it. But in this way you can actually activate the ecosystem around it. So actually you have to kind of authentically commit to that saying, like I'm not trying to make money out of that. I'm genuinely just trying to, you know, drive standardization because I think it's good for everybody. I think that's, that's sort of point number two. Point number one is using it for development. Point number two is actually authentically committing to that idea that we're not trying to monetize that group, we're genuinely just, we think it's good for everybody. To standardization then number three is about what's your commercial model? And I actually loved the comment that Mitchell made years ago. He goes, we realized early on that, you know, if you build a really big open source ecosystem or community and then try to monetize that community, you have to reconcile that you've now aggregated a community of people with a predilection not to pay you anything. And I think there's a truth to that. So you don't try and monetize them. What you try and do is try to come up with a model that monetizes the usage of those products inside an enterprise, inside some other methods. But you're not trying to monetize the same people. What we did is we had the philosophy of, hey, let's say everything the practitioner needs is open source. We don't hold that back. But everything the organization needs, well, that will go sell that to the organization's that are using this tech. And you think about that paradigm, it's actually just a different set of problems. You Go from an individual to a team to an organization as you try to get further organizational complexity. Right. The team problem is one of collaboration. How do we collaborate around this thing? Okay, that's an opportunity. Number two is policy and governance for the organization who did do what, audit trails and all the rest. So that's how we think about it. So the commercial value is around that latter part. For most successful open source companies it's sort of, it's sort of monetizing the organizational complexity. I think that's pretty straightforward to the users. It's pretty honest and straightforward. Now do you do that in the form of a managed product or do you do that in the form of kind of an open core product? I think everybody's preference is to that in form of a managed product. Let me have my cloud service for Kafka, for Confluent or for you know, pick technology A, B or C. But I think you have to reconcile what your buyers want first. So it turns out people's appetite for consuming a managed database is actually pretty high because there's only one app using that database at the infrastructure layer. It's just sort of a different beast. You know, if vault goes down, the lights go off for all of your company, not just one application. So as a result the bar is just much, much higher to consume that as a service. Turns out the market will tell you whether it wants to consume your products as a service. In our case it didn't want to early on they wanted us to have a self managed version that they could manage themselves in enterprise form. I'll maybe stop there cause I could talk about this forever.
No, no, I mean I think you said two or three threads that are super fascinating and you know, it's probably, you know, Armand and Mitchell, the two co founders had that great insight of open sourcing all the service areas that practitioner wanted, cared about and really committing to that. And then I think you came in in 2016, was it 2016? Yes, 2016 as CEO and you had insight where like you know, Armand Mitchell had this great insight and understood the developer aesthetic. You had the great insight, understood the organizational requirements of the monetization that I think the three of you made such a great team because that separation of the Personas practitioner like the developer version of the organization and had different needs identifying the organization paid for it and what those features are and making sure you don't open source those features versus what the practitioner cared about. Open source, those things it's kind of church and state.
We actually refer to it as church and state and those, those things can't cross.
I'm afraid to ask what's religion and what's government, which is church? I think we both know, right. I think clearly the practitioner is the religion and the organization is the government regulating it. In this cloud world where increasingly Hashicorp has a fast growing cloud business. Confluent has a fast growing cloud business. Mongo Atlas is a fast growing cloud business. Snowflake is not open source at all. Hundred percent cloud business. I'm involved in companies like Docker, Rockset, Docker's open source, Rockset's a hundred percent cloud, Chronosphere is open source, but then all cloud. Do you need to be open source anymore to win in the cloud game at all or yes or no?
I think it's harder to drive market standardization. It depends what your aspirations are. So again, these companies, they get married together and they are in fact very different. And I would posit that there's a big difference between the application layers. So databases, message queuing and middleware or basically the runtime layer as opposed to core infrastructure, which is security, networking and the infrastructure itself. So let's talk about the top layer, which I'm referring to as the app infrastructure. You don't have to standardize that entire market to build a business. I mean, look at Snowflake, they're one of multiple data warehouses. Look at Confluent, they're one of multiple message queuing options. I have look at Kubernetes. It's one of many runtime platforms that are out there. And so I think in that instance you actually don't need to be open source. I don't believe at the core infrastructure layer, it turns out like there's only one way to do tcp, there's only one way to do firewalls, like there's only one way to do to do networking. It all works the same way, right? So, so I think there tends to be stat like to win at the infrastructure layer, you sort of need standardization because I'm going to have a variety of applications but I can't have different ways of doing networking. So I think those kind of need to be open source. The adoption path ends up being subtly different too. And I think there's a nuance that really matters here which is at the app infrastructure layers or databases, et cetera, middleware. It's very app driven. So I have an app that I want to be built in Kubernetes. I have an app that I want to do message queuing in this modern way, I have a set of apps that I want to do data warehousing with versus the infrastructure sells for all your apps. Right. So there's a very different motion. And I say the appetite for consuming a cloud service that serves as a single app is kind of okay because if that service goes down, like that sucks. But my lights still stay on versus at the infrastructure layer, there's just a different risk tolerance.
And so the framework then becomes, to your point, how many other things do you touch, right? Or integrate or depend upon it, like an app, a single CRM app. Notably there's been tries like open source CRM, like sugar CRM, et cetera, has never worked out the same as other layers. The lower level in the stack, clearly like a Kubernetes or a docker. The more open source you have to.
Be, the lower down you get, the more important it is.
The early days of Hashi. Tell us about the foundational early customers that really help Hashi get his footing, get started and help sharpen the sword, if you will, to polish what the price became. Be kind of curious, what was the inception customers and how has that changed over time?
Yeah, I go back to kind of the thesis for business building in my view is very consistent. It's about old world, new world, transitions architecturally that create the opportunity. So what was happening 10 years ago was the emergence of cloud as a target. And it was the realization, you know what, the paradigms are just different. Like I'll take security as an example. Old world, the idea of like four walls and a pipe in, a pipe out and a firewall around it was how we think about security. Cloud world, wait a second, there's no walls. It's like it's a setting on my S3 bucket. Is it inside or is it outside? This changes my world a little bit. And so the definitive conviction around, hey, the right way to do security in cloud is based on brokering identity was the insight that Armand and Mitchell had early on. And they were just convicted around that. They said, hey, this IP based, where security makes no sense, let's build a product that does identity based. And then the people that were starting to use cloud were like, yeah, these guys are right. That's right. And they started using it. So the people that were adopting that cloud paradigm first came to the realization that this was the right way to do it. And those were the cloud native companies. It's the twitches of the world, it's the githubs of the world. It's sort of the early cloud native folks that you would expect who were building companies at that time. And that is where the initial traction came from, unquestionably because we'd been very opinionated about the idea of infrastructure as code is how you do provisioning, identity is how you do security, service name is the way you do networking. Those three principles are the most profound. They're just totally different principles. Once that sort of got some adoption, you sort of work the edges off inside these big web cloud native companies. And some of them are just absolutely enormous, as you can imagine. Like the scale of usage sort of started to shock us. All of a sudden you're connecting 100,000 machines and you're like, wait, I never expected that to happen. So that by the time some of the leaning, the leaning enterprises who we wanted to monetize ultimately started consuming this stuff as well, because they were like, hey, we're building a massive web app that needs to be built on cloud infrastructure. The very, very earliest of Amazon's customers, they adopted it. And I think that's actually quite repeatable. But it was related to this paradigm shift. You got kind of got to look for those who are the people that are looking at that new paradigm first. And it's select financial institutions, we like to say.
Some of those companies, as you mentioned, the early adopters have seen the future, right? So you look at some of the things we back at Greylock like Rockset team came out, Facebook, Chronosphere team came out of Uber. A lot of those teams on Facebook, Uber we've said seen the future, right? Or Salma at Docker seeing the future in terms of how people build apps. And they've solved this problem that other folks haven't yet but will soon. They're just, you know, one step around the corner and pretty soon the bangs, maybe some of the telcos you mentioned or other companies soon adopt this pretty quickly. From containers and microservices to whatever those are the same customers that started early in cloud. Amazon, the early days were a bunch of startups and then now they're standardizing on gov clouds or financial services clouds with likes of Goldman Sachs. This Castles in the Cloud project that you've helped me on and I have riffed on these ideas in the past. We've been tracking the big three, Amazon, Azure, Google and how they evolved over time and how oftentimes they copy each other. But increasingly now in 2022, especially the past two years of the COVID seeing multi cloud really be a best practice paradigm. And multi cloud will also include maybe private Cloud as well. Hashicorp has been, like I said earlier, this defining company in this multi cloud conversation. So it'd be kind of curious. You talked to a lot of customers right now. What are you seeing about multi cloud or cloud trends writ large? And is it going to be a multi cloud world? Is all going to be Amazon?
I think we all 2012, 2013, everyone thought, oh yeah, Amazon, I got it. Seen this pattern before. Old world, new world, old world, Private Data Center, VMware, New World, Amazon. Okay, got it. And obviously our bet was that the steady state was multi at the time. And actually I've been really bullish on Azure all along because I think that's a very. They're a very like dogged culture that's going to pursue the tail lights of Amazon and probably pass them at some point just out of sheer determination. And so I think we made the view that multi was going to be the thing and that was probably. It wouldn't be 10, it would be a few. And that's kind of how it's worked out. When you, when you travel around, it's like every single big company is trying to standardize on a couple but not succeeding. I had a conversation with the CIO a couple of weeks ago. It made me laugh. He goes, hey, I just finished a project of data center consolidation. We went from 18 data centers down to six, like it took us two years to do. And I just sort of smiled. I said, can I guess which ones those are? He goes, sure. I go, Amazon, Azure, Google, Alibaba, private data centers times two. He goes, how do you know that? Because you look like everybody else. You have operations in China. So that's going to be on Alibaba whether you like it or not, and whether by accident or by design, you're going to use the other ones. He goes, yeah, we just come to grips with that. So that's what the world looks like. It just does. People are doing strategic deals with maybe two to try and get vendor power, but like, they're not really succeeding because you have a dev team that wants to do something over here for very good reason, then you end up there. I actually think if anything, that trend is sort of accelerating. And I've been traveling around for the last quarter. Armand was in Europe, Asia and North America a couple of times this quarter. And what you see is actually, yeah, no, you know what, some of the stuff needs to run more in private data center because this one's really sensitive. That stuff is okay to run on Amazon on. And actually this One maybe needs to manage it run on an edge pop because it's serving an edge network and you're like hold on a second, I thought there were going to be three. Now I'm seeing the big three, plus Alibaba, plus even Oracle in some instances, plus some pop. And it just speaks to like that's the messy reality that we all live in. And I think multi cloud just becomes the thing now as it relates to investment opportunities, startup opportunities. That's awesome, right? Think about the problem that your customer has of like trying to. How do I think about zero trust across those five estates? Good grief. Okay, well it turns out that's what we all help them with. So I think it actually creates massive opportunity. What initially looked like a winner take all game for Amazon and then okay maybe just for a few of them actually now looks like there will be a software stack that runs across all of them to solve sort of some of these problems with consistency and we're certainly seeing that sort of massively.
This multi cloud architecture, David, is fear versus greed. What I mean by fear is the fear of lock in the early days or Oracle and how much is greed saying, hey, I want to take advantage of XYZ service on Google, ABC service and Azure. Is it just like, hey, fool me once, shame on you, fool me twice, shame on me. I don't want to be locked into the next gen Oracle.
I think it's a bit of both. I was talking to a customer in Australia that's got a big bank that's got the majority of their apps on cloud already. They basically said, hey, we're going to pick Amazon and Azure and you know, some will run on either place. We're just trying to get them to cloud because long term we think it's cheaper there than we can run it ourselves. And they're okay with the lock in. But then there's a certain class of applications within their estate. They're like, this one actually needs to be built more like Zoom. Like the way Zoom is built if you followed it, it's sort of cloud agnostic. It doesn't use any cloud native services from what I recall. And as a result it can be moved around to wherever their compute fabric is. And I think people are coming to the grips like number one, I'm okay getting locked in because I get a lot of benefit from that and by the way I can drive down costs that'll get cheaper over time than I could ever run it, so I'm okay with it. But there are certain things which are More, less sanguine about. I think that is a newer trend where people are like, you know what, this payment app, that actually is the basis of my whole thing. Maybe that one. No. And so that's new. That's new. I think also just that underscores my previous point around increasing heterogeneity, not less.
Yeah. I used to say in the early days when I talked to developers and startups like this is not how people use cloud, not how customers use cloud. In terms of an elastic workload that sprints between clouds. It was to your point, different workloads on different clouds that had different privacy security use cases. And you're okay going all in on one cloud in one region. So for scale and cost, you're never bursting between clouds. But there are some categories of applications for security or privacy purposes need to be in a private cloud or for some companies like ISVs, like Zoom needs to be truly multi cloud with the same app. But more or less most customers aren't with that Zoom architecture, don't have one giant app that is moving around the globe. It's really different apps on different clouds for different purposes.
One insight that did surprise me on my last current trip was for these companies that are pretty far down the path of cloud, they're actually starting to see cost savings year over year as they move more of their estate into cloud. Their bill's actually going down. You're like, that's weird. Well, it's actually not because there's actually truth to the thesis that the cost of storage computer networking on cloud is going to be cheaper than you could do it on your private data center. So they may be charging you a margin on it. But, but if you can get good at optimizing, hey, don't over provision stuff, don't leave stuff running. This shouldn't be running just operationally. You can massively ratchet down your cloud spend. And I think that's the phase to come of cloud for these mature people. And if you make the bet that it's cheaper for them to run than it is for you, like it's sort of one directional.
Yeah, we're, we're seeing a category companies I've invested a couple around, not necessarily finops, but reducing cloud costs and cloud spending. Right. And I think in this economic environment right now, you will see more people focus on reducing cloud costs. Begs the question for me around cloud, like how does Hashic compete or work with the big cloud providers? Right? Because on the outside people say, oh, Amazon or Google or Azure would hate hashicorp. But you guys do a decent job also working with them. So be kind of curious, how do you guys thread that needle, if you will.
So we actually won Partner of the year from Azure like three the last four years and partner of the Year from Google last year. And Amazon's a bigger partner than any of them. They just don't have that same partner award structure. So the Net is our mission in life is actually to drive more workloads to cloud. And I think that comes down to that's a very, actually very unique position in the market. That's very unlike a snowflake or even a confluent where hey Amazon trying to sell you a service first for the warehousing or a pub sub service. So like there's a one to one thing they're going to sell. They don't try and sell you your provisioning products, they don't try and sell your identity brokering products. Those are just the fundamental primitives of their platforms. That's the difference. So there is absolutely zero conflict between us. We are like the railroad tracks to cloud for them by allowing people to have a consistent way to provision allows them to reduce the time to get apps running on Amazon. So we're like the railroad tracks to them. So yeah, we really like it's a very unusual position, but it's a very deliberate position. And I think it took us a while to figure out that that was the right model and now we are where we are. So we definitely don't compete with them. We're like their biggest enablers. And I think it comes down to like the very practical view that your system of engagement might be running on a Kubernetes platform running on Amazon, but the database is connected to is probably running in your private data center. So you have a bridging problem for that real app to be built. And so we, and we solve that bridging problem. Amazon cares about Amazon, VMware cares about VMware. We pay the bridge between them.
I think the bridging thing is interesting, right? Because you know, I've talked in the past, one of my favorite quotes is that old Jim Barstow quote, the only two ways to make money in technology is bundling and unbundling. And they go through this phase of bundling everything together as a PC to unbundling between the OS and the apps, bundling everything together in client server unbundling again. And you can argue that from 2008 to 2018 it was a bundling of compute, network and storage databases et CETERA into the cloud and Amazon in the past four years we're seeing unbundling these services and companies like Snowflake, Confluent, Mongo, Datadog, Chronosphere, Rockset, Docker, Hashicorp, all either attacking one service like a database or data warehouse or observability or networking identity, for example. And so now we're seeing, I think, in my opinion, an unbundling phase where you see Amazon, Azure, Google getting unbundled into independent services and obviously something like Hashi that bridges between services between data centers makes sense when you have an unbundled world, I'd be curious, are you seeing the same thing? And if you do believe in the unbundling, where are you seeing this happening?
I think 100% that's what's happening. I think it comes back to the heterogeneity reality. If you're a big company and you're having to build things on that are going to go in multiple different places, like you can't use the pub sub mechanism on Amazon to build one app and the pub sub mechanism on Azure to build another one, like it's just way too operationally complex. So I think as reality is set in that actually I'm not going to put all my workload on Amazon, I'm going to have to deal with multiple things and my private data center. Then people start sort of stepping back and say like what are actually the software layers that I need in the software stack? And I've always contended that there are seven, there are seven core ones. There's infrastructure, security, networking, that's the bottom three. Then there's the runtime layer, the message queuing layer and then the database. Those are the core six. And then on the right hand side of that is how you monitor all and that's your apm. And I think there are others as well, but I think those are the ones that have been very clearly re established. Hey, how do we do provisioning? Well, that's Terraform, whether it's on Amazon or Azure, how do I broker identity for that security contract? Well, that's fault. How do I do monitoring? Well, that's a datadog. Right. And so I think that heterogeneity has driven the unbundling reality because the end users just can't deal with that much heterogeneity. Not technically, I just mean operationally. Right. If your job is to establish a zero trust approach to your new fleet of applications and some running on Amazon and someone running on Azure, like good grief, good luck trying to Build them in different ways. You can't. You have to step back, say what's my common foundation? And then all apps are going to use that common foundation. And that is essentially a software stack that I run either on Amazon or on Azure. And it's the same stack.
Yeah, I love that. Seven elements. And clearly that informs a lot of how we organize Castle the clouds and how we've been investing from observability like Chronosphere, databases like Rockset, elements like Docker and Compute Stage. And the one networking and security is one that has to be cross cloud. So we're involved in a company called Cato Networks that's basically both wide area networking across clouds and data centers, as well as security like firewall and Caspi across workloads. Because as you unbundle between the cloud, you need a. Some things have to be a common independent substrate like security. And so that's obviously one we're super bullish on as we see this unbundling of the world happen before our eyes.
I think what we're, we're also seeing is we're seeing that on the front end stack as well. So I think like as the, as the cloud world has gone, you know, as well as gone cloud, the infrastructure stuff has gotten recast. But I also think that same thing is happening at the, on the, like the front end stack, which used to be a very consistent stack, now you've got like a lot more decomposition of those elements. It's kind of going through that same experience. So that's one area that's super interesting. I think the other one that gets super neat that we see way more than I would expect is edge. And I think Edge to some degree actually think the way I think about it and where our customers think about it is there's like your private data center world and then there's the outside of your private data center world and that outside of the private data center world. One A is Cloud, one B is Edge. Because it turns out the software stack you need to like imagine a car that needs to connect to a data center. Well, it's the same software stack as you're running on cloud. But I got to believe there's a lot of other specific things that Edge environment I'm not close enough to know that are also unbundled because there's heterogeneity of edge targets as well. There's probably lots of interesting things there.
Yeah, Edge is one we see obviously with, with Cato Networks. They built their own network of pops around the globe Kind of like a cloudflare, et cetera, just to be close to the customer. But this edge of pushing things out leads to another theme that you and I have talked about. This kind of either federation of cloud, federation workloads across multiple clouds, multi geos. And how much of that you think is driven by a compliance of data across GEOs and how much do you think is just more multi cloud unbundling?
I just think that the practicality of deploying things where they make sense to be deployed is what's driving it. It's like yeah, I think the Alibaba is the best example of it where if you're going to run something in China you kind of got one choice and people are generally okay with that. So a lot of multinationals run stuff on Alibaba. It's probably not the first choice, but it's kind of their only one and they're okay with that because their consumers are in China and that's the way to have it work. So I just think it's more just practicality that begs lots of questions around controls and how you have consistency across this totally different environments, disparate environments, but it kind of goes back to the point of this common software stacked. It's funny, I actually find myself, obviously I totally geek out on this stuff. I just think it's super intellectually interesting to watch these markets evolve. So you got to stop me but like whenever I like whenever I see an app like Zoom or Slack or Stripe, like I can kind of imagine how they're built. It's not that complicated. Or when I see my Uber driver, you know, filling with their app to like get to next ride, you know exactly how those are built. It's something like Vault authenticating the identity of that endpoint, something like console creating that encrypted connection across the Internet. And it's something like Terraform that's automating the provisioning of the compute farm to allow it and then it's some custom app running on top. You're like okay, cool. Like that's just how these things are all built. And that level of consistency I think is what we're all looking at is like how, like what are, what is that pattern? Because I think regardless of what the underpinning Compute is for that like that software stack sort of is finding its way to standardization and that's what's cool for startups is, is like what does that market? Like what are those pieces that are required and, and just know that the cloud vendors are not going to Fight you for it. They're like they want the compute.
Well, okay, so that begs me to the next question. I want to be doing my job. I wasn't picking your brain around that startup ecosystem out there either. Startups out there that you think interesting or just spaces or themes in general that you're tracking that you think are either white spaces for yourself, white spaces for startups that as we think about castle in the clouds, where are the holes in the castle walls or the paths or the moat, if you will, that you would suggest to our listeners out there they should think about if they're a founder.
I would think about how profoundly different the paradigm of cloud is relative to the old world. And then start looking at the existing markets in the old world and see how they're going to get reconstituted in cloud. I think that's actually the right word. These markets go from old world to new world and they don't look the same, they're just reconstituted in a slightly different form. For example, like you use firewalls for security in the old world, use identity based control software in the new world, you're going to spend the same amount of money on each, just a different way. The one that we've been talking about sort of goes down. That thought process is privileged access management and obviously this we have a product in like in the open source community around this. But I'll use it as an example because it just underscores how we think about it, which is the idea of privilege. Access management is actually a pretty well established market. It's the idea of how does an administrator log into a privileged machine and they do like you know, session recording what they've done. And there's compliance reasons why you do that. There are vendors in the market that do that very well today in the private data center and that is it is a billion dollar spend category or probably well as the world goes cloud like it's just a totally different paradigm now. You've got to give temporary access to a machine that may only be alive for a minute. Right so, but the problem still exists. So the old world new world transition is right there for the taking. It's like okay, well architecturally that old way which assumes a static IP address target just doesn't translate to the new world. But the spend category has to translate to the new world. So I'd look for those for us boundary is that product because it's very specifically just like an old world neural transition. And everybody in our, in the platform teams that we Service that you describe it to goes please tomorrow. Like, yes, that's exactly my problem because you understand how different the paradigm is. So I think that's an example boundary.
For the listeners is this kind of simple secure remote access for your end users.
Yeah, yeah, it's like how do I SSH into that machine over there for one second when that machine only exists for, you know, 30 seconds? So this idea of old world is how to look at it. I think there are lots of those markets, things like the tokenization markets in the private data, things like even the HSM market, some of these really nerdy hardcore markets that are relatively sleepy vendors in those markets because they haven't changed a lot. Well, their world's totally changed on the cloud world. So I would do that academic exercise and I think you've done that exercise as well. And you can see that Amazon services, which basically have copied that path, we've.
Done that multiple times trying to find founder startups. Oftentimes I probably get them more wrong than right, Dave. But it doesn't stop me from trying to. But no, no, it's, you know, I would say like when you have a new platform shift like the cloud, first thing happens is people try to use the old tools in the new paradigm. Right? And the first question is in the new paradigm, what breaks? Right? And so the first thing is you fix the things that break from old tools and new tools and then, okay, now you're in the new paradigm, what new things can you do?
Right?
So it's a two step thing. So there's still a category of things are broken. And then once you're in the cloud you can, there's a new category of things you can do differently that you couldn't do before, which is I think super fascinating. We're just beginning to see that. I think because the first generation cloud was totally agree. Let's move what we had before into the cloud. We broke a bunch of stuff, let's fix it. Now we're seeing, oh, now we're in the cloud, we can build things differently. And so I think stuff you guys build like boundary or wave point, et cetera, and you're changing now I can build apps differently than I did eight years ago.
Yeah, but I think, but I think this is the progression. You're exactly right. I think console for me is a perfect example of this. So you look old world, new world. Like if I were to look at all the IDC categories of spend in the current data center, like, okay, well, which those need to move to the cloud model, because that's where all the future apps are going to be. You can see a one for one mapping, and that's how you get started. And then once you've built that, then you go, actually, you know what, from where I'm sitting here, you can do something totally different. A perfect example is what happened with console. So console was built around this idea of, hey, the way you do networking in the old world is I've configured Cisco networking gear in the new world. I just create a rule that says this thing talks to this thing, so whenever it appears, connect the two and that becomes your DNS. So basically it just speaks DNS whenever something wants to find another thing. You know, console is your DNS. The not just that's a. Literally a one for one replacement. The evolution became, what if I wanted to run that across a wide area network and I wanted to have mutual tls between all those services? Well, that became the service mesh market, which people go, well, that service mesh thing's pretty obvious. Well, it wasn't obvious. It was an evolution of console. In fact, even Istio is, you know, essentially a replica of that exact console idea that came out a long time after console. But that's an example of how you navigate. You cross over one to one and then you go, hold on a second, I can see something different. And boom, an entirely new market. Categories created.
Take it full circle, right? Twitter. Recently, Massimo, one of our former VMware colleagues, reminded me of conversation I had with him saying, hey, the market is trying to figure out, is VMware the last of the last generation companies, the first of the next generation of companies. And I think that was the minimal state between old world and cloud data centers. VMware and virtualization was the enabler of cloud. And I think 13, 14 years later, we're now the next generation where this kind of state between how Cloud 1.0 or the first active cloud is to the second active cloud, which could be edge, could be decentralized, could be multiple clouds, that we have a generation of developers and customers and users and students don't know anything but cloud. You and I rack servers for the first part of our careers and plugged in networking cards, et cetera. And now because we have a generation born in the cloud natively, what they imagine and what they expect is very different. So I'm an investor who's pretty excited. This next turn of the wheel, if you will, will be very different than previous turn and I think comes like Hashira things that we're investing in are going to be there for the next generation of multibillion dollar companies.
Yeah, I totally agree. The generation of folks, it's just like they just think differently. In fact I remember going to my first hashicump I had no idea what they about were talking talking about. I was like, I was genuinely confused because it's just like a different language and I was like I understand this stuff pretty well, but not this stuff, the other, the other. So, so I echo your point. The other point I just make, I think it's getting easier for startups because I think there's a logical buying center for this stuff. And I'll give you, I'll draw the analog to the VMware world because it's been on my mind a lot. The thing that happens in these infrastructure transitions is actually requires a slight org check structure change every time it happens. And I think about what happened pre VMware. If you wanted more compute, you called up your person at HP and you waited three weeks for another machine, whatever. And it came. Then came the creation of the VI admin as a role. No, no, no, no. You just open a ticket. The VI admin will provision you a virtual machine and close the ticket because I have a pool here waiting for you. And that became the buyer for so much of amware stuff. In the end, that singular role right like that, that is, that is sort of that entry point. And I think there's a parallel here in cloud is the creation of these platform teams or these cloud program offices, that is a central team that goes, hold on a second, you all are willy nilly adopting cloud. Stop. I'm going to step back, create a common set of apertures for provisioning, monitoring, whatever it is. And you're all going to have to use those regardless of whether you're running on Amazon or on Azure or private data center. Because that's the only way we can achieve consistency. And that is what has happened in every cloud company. That's what happened at Hashicorp. We have a cloud, we have a cloud team or basically a platform team and then four product teams. Every company we engage with has a platform team and the, and the, and the app teams that they support. And that is your buyer. They're the people that are deeply steeped in this domain of, of understanding the paradigm that's different and that's who you seek out if you're a startup. You go and find that group of people who are in the cloud program office or whatever it might be and they are the ones defining the next 30 years of infrastructure.
I think that's a great place to leave it and end the conversation. This new Persona, this cloud buyer, this architect has evolved and become a reality the past four or five years. And that's Persona you and I'd be working with in the next five, 10 years of our career. So David, any last advice to founders executives out there that starting things in the cloud and either advice on starting companies, running companies, or how to work.
With you in Hashicorp business building is by definition super fun. These are intellectually fascinating, pretty pursuits that are super interesting to pursue, particularly if you really geek out at the role that you play for these biggest companies in the world as they're doing their thing. So I would embrace the journey. There's lots of opportunity. Last I checked, $180 billion will be spent on the big four cloud providers this year and that number is growing 30 plus percent per year. So there's so much committed budgets out there for you to go and engage with that. It is a great time to be engaging with it. And despite the macro realities and what you hear broadly, you know the secular tailwind is strong.
Well, thank you for your time and we'll do another podcast on that topic, running and building companies and the leadership aspects that the journey you had in your career. I'm Jerry Chen with Greylock Partners. Thanks for listening to Gray Matter.
More from Jerry
"Ship Pricing as Fast as Product" - CEO Alvaro Morales on Orb's Mission to Revolutionize Billing Infrastructure