 Hi, this is Matt Trafiro, CMO of Edge Infrastructure Company, VapeRio, and co-chair of the Linux Foundation's State of the Edge project. I'm the host of Over the Edge, a weekly, hour-long, interview-style podcast on edge computing and the future of the internet. You can find it at overthedgepodcast.com and on all the major podcasting platforms and tuning iTunes and Spotify. Today, we're coming to you live from the Kubernetes on Edge virtual conference, and I'm thrilled to be joined by Craig McClucky, currently VP of product at the Modern Application Platform and Business Unit at VMware, but also one of the co-founders of the Kubernetes project, the driving force behind the formation of the CNCF and the former CEO and co-founder of Heptio, along with Joe Beta. We're going to talk to Craig about his career and technology, including the origins of Kubernetes. We're also going to cover the past, present, and future of all things Kubernetes and Edge. Hey, Craig, how are you doing today? I'm doing really well, Matt. Thanks for having me on. Oh, yeah, this is terrific. I've been wanting to do this for a long time. You and I have been friends for a while, never been in an environment like this, so this is really fun to do this. So how did you even get started in technology? It's funny. I was thinking about that. And I think the answer was the Commodore 64, as with so many kids of my generation. As a nerdy teenager, I discovered that programming was a great creative outlet for me. And so I spent most of the years from between 10 and 17, I guess, coding. And then it took a little break from it, believe it or not, during college. I actually decided to pursue a different direction, electrical engineering, which in South Africa meant like real electricity. I don't think, I'm not sure that Microsoft already understood that when they interviewed me, but I can actually do a lot of formal CS coursework, but it was close enough that enabled me to get a job at Microsoft, and the rest has been a great journey. Yeah, that's great. And so when did you leave Microsoft and go to Google? So I left Microsoft, it was back in about roughly 2009, 2010, somewhere around there. And my first project at Google was, I kind of lucked out. There was this thing called, it became Google Compute Engine. It was called Big Cluster at the time, but that's where I met Joe Beta. And sort of starting point was really just working on bringing traditional enterprise VMs into the Google data center. And it was a really fun project. I learned a lot about Google's infrastructure, a lot about some of the challenges of actually bringing those enterprise grade workloads into that sort of cloud environment. And it really set me up on the journey that I've been on ever since. Well, and how did you go from Compute Engine to Kubernetes? You know, it's an interesting story. Jonah poured our hearts and souls into building Compute Engine. And we felt like it was great technology, had a really clean, elegant API, had a lot of very favorable performance attributes, some really interesting networking capabilities, et cetera, et cetera. But it was also kind of interesting because in some ways it was almost too little too late. When we started the project, Amazon had already opened a huge lead in the ecosystem. And we were starting to see a really strong convergence of ISVs and a lot of other organizations around the Amazon ecosystem. So we stepped back a little bit and we're really thinking about, well, what can we do to kind of change the game somehow? Can we be a little disruptive? We knew that was gonna take a while for Google to build out the strength in the go-to-market side of the house, get that enterprise readiness that it needed to really compete, which I think they've done a fabulous job under Thomas Curian, by the way. But it was also clear that if we didn't do something quite disruptive, we would have a really hard time competing over time. And that really motivated me to think outside the box a little bit and look at other options. Yeah, well, you know, when we met, I was the CMO of Mesosphere. And what I think is really interesting about the CNCF and Kubernetes origin story is that you actually embraced these alternative technologies. Can you tell me a little bit about what drove that thinking and how that became part of the foundational ethos of the CNCF? You know, it's really interesting because it's funny, you know, I remember this one moment where, you know, Joe and I were kind of working on Compute Engine. And it was really kind of sad because I think the world had had an opportunity to normalize on something like the virtual machine image definition as something that could be relatively ubiquitous. But that just never happened. And I remember turning to Joe while we were kind of working on the project, I just had this sort of like moment where I was like, you know, whoever solves the problem associated with packaging and deploying software atomically, kind of like the way we do it in Borg, is ultimately gonna just have this amazing sort of, you know, run of it. They're gonna be able to be quite disruptive to the industry. But we were busy on Compute Engine. So eventually, once we got to a point where Compute Engine was largely kind of ideated and was on rails, we started playing with some ideas. And one of the things that immediately caught our attention was Docker. It was funny because I remember, you know, someone mentioning this to me like way, way, way back when, way before Docker was even popular. Like, hey, you should really be paying attention to this. It's kind of a neat model. And when we started really getting stuck into it, it was like one of those moments where like, you know, wow, we should really have thought of this, right? Like it's, it was such an elegant way to, you know, express a unit of, you know, deployment. But the thing that was most elegant about it wasn't necessarily the technology, which was, you know, by Google's we're thinking somewhat mundane. It was really the experience that had been created around that recognition that that Linux Cisco there was, was such a powerful abstraction. And that really got the wheels turning. You know, we started thinking about like, well, what would this look like done upright? And there were certainly some projects in the ecosystem that were interesting. But more importantly, the way that, you know, my other friend, Brennan Burns, who we were working with at the time, described it as like, we kind of had the puzzle box when everyone was trying to figure out, you know, how to fit the pieces together. We'd seen how this would work at scale. And that really motivated us to do something new. And it became obvious that we had to do this through the lens of the community. You know, once we just saw the disproportional level of attention and traction and engagement Docker was receiving, you know, versus the relative maturity of the technology, it was clear that if we could create something righteous, meaning that had a lot of the sensibilities that we'd come to take for granted at a place like Google, but we could do it in a way that brought the community with us, we could create something quite special. And I don't know which of the two it was that, you know, kind of originally, you know, came up with a crazy idea to, you know, to make a run at an open source project, which became Kubernetes. It was either Brennan or Joe, I just don't remember. But they're like, hey, what would it look like to do this? And, you know, I thought about it a bit and we're like, yeah, like, let's give it a go and see what happens. And, you know, it definitely worked out okay in the end. I think it did. I think, you know, one of the things I've really always enjoyed about you is how methodical you are in your strategic planning. You know, there's always some game theory equation going on in your head. And I think that is why CNCF ended up being the way it is. I think a large part of it had to do with just your conviction that this was the proper way to change an industry. And it certainly has. And I think we say Kubernetes has changed the industry and is continuing to change the industry. So somewhere along the line, you left Google and you co-founded a little company called Heptio. Tell us a little bit about that. You know, it's really interesting. You know, while I was at Google, I was working on, you know, so Kubernetes was on rails and I started to kind of play with some other ideas in the space, you know, what would the next abstraction up look like? You know, how would we think about creating a services ecosystem on top of it? And I was working on a couple of things there, one of which was the Apogee acquisition. And I kind of got friendly with Chet Kapoor who was the kind of founding CEO of Apogee. And he said something to me, which kind of just stuck in my head, you know, he was like, you know, to succeed in a startup, you really need to look for a moment of disruption where, you know, the set of incumbents are not able to move as quickly as they might like, where there's a high sort of total addressable market and you're sort of in a situation where that's what you can create a successful business on. And that like, it kind of clicked for me. And I was like, wow, we're never gonna see, I'm never gonna see these circumstances again. But it was also for me an opportunity to really kind of step back a little bit and walk the journey with customers. You know, I'd looked at the sort of circumstance where I was thinking about like, well, do I wanna do another Kubernetes? I was sure that there was another Kubernetes in that next era. So I thought there would be another Kubernetes in there somewhere, right? Like, you know, some of the ideas around, you know, that eventually evolved into things like service mesh and some of those technologies. But the really interesting opportunity for me personally was the opportunity to engage with customers where they were, to be an effective ambassador for this very rich open source community and bridge the gap between enterprise organizations that were looking to get more intrinsically aligned with upstream technology and the communities that were supporting them. And so that's really what caused me to go out and do to Heptio. And, you know, my friend Joe was, he had decided to retire, which was kind of hilarious, because he loves working. I remember that. I didn't believe him when he tried. But I don't know, like, and eventually he was like, hey, when we're doing a startup, when we're doing a startup. And I just wanna work with Joe again too, I'll be honest. Like that was, I've always enjoyed his perspective on things. And so that really motivated us. And, you know, that one worked out okay too. So we were very pleased with the traction we made in a relatively small amount of time in terms of just helping some larger enterprise organizations start to make this journey towards cloud-native technologies. What was the most surprising thing that you learned on your journey at Heptio? I don't know if this is surprising, but it's something that I would, I certainly took to heart as a leader. When I look back on, you know, what we created and the impact that the team we brought together is having within my business unit and within VMware is, you know, there's no substitute for culture. I think if you can establish a very kind of effect of cultural bar, if you can design your culture to the problem at hand. And if you hold yourselves to a very high standard, you will, it becomes self-perpetuating. The quality of individuals we brought in have just done tremendous work, you know, within the parameters of the community, within the parameters of VMware. And I couldn't be more proud of just the people. Like it's, and I think that really just started with being very, very deliberate about the culture we're creating. What were the pillars of the culture? It's funny you asked that. There were kind of three sort of pillars of the culture that we established. The first was, what I used to say was honest technology. You know, we are a organization that is in service of the community and in service of our customers and what we build is honest technology. So, you know, we stand behind the way that we build. We stand behind what we build. We take a great degree of pride and delight in creating honest technology. The second kind of, you know, cultural element that, you know, I used to push a lot was carry the fire, like a real passion for disruption and authentic desire to create something that was bigger than anyone had seen. And this willingness to do the hard thing, to walk the hard road when you have to. And then the third element that we put a lot of emphasis on was we before me. The idea that, you know, it's about the quality of the team, it's about the quality of the community. It's about doing that little bit of extra work so that someone else doesn't have to do it tomorrow. And obviously there's an ocean of nuance associated with each of those three elements. But just having that anchor of culture that was really understandable and manifest every day, it informed the decisions that we made, informed who we hired, informed how we interviewed. And I think that really set us up for success. Yeah, and for those who don't know, and probably two people in the audience, Heptio was acquired by VMware. And, you know, back when you and I were working closely together, we used to get the question, right? VMs are containers, like which is gonna win? And I think we knew that the answer was yes. And now I think definitively it's yes, but can you tell me a little bit how Heptio, and I guess more importantly to the Kubernetes community, Kubernetes has been integrated into VMware and what is the VMware Tanzu grid, I believe, is the product meet? It's kind of navigating us. Yeah, it's interesting because I see containers and VMs as being, they're fundamentally different technologies. One solves a packaging and distribution problem, the other solves a hardware isolation and abstraction problem. And we're certainly seeing often as not a kind of yes and series of outcomes. I think almost every vendor now has some form of hypervisor isolated Kubernetes or container abstraction and we're certainly no exception to that. You know, for me, when Pat approached us, we certainly weren't looking to sell. I thought, you know, like we were doing great, we're having a lot of fun, but it was also clear that to have the impact that I wanted to have on the industry, we did need a bigger boat. It's like that scene from Jaws where you see the size of the opportunity, see the size of the impact you can have and you need that bigger boat, right? And what I was, you know, so excited about was the opportunity to use the strengths that VMware was bringing to the table, you know, that incredibly trusted brand in enterprise computing and awareness of how to actually operationalize its scale and understanding that, you know, the first 80% of the work is, you know, getting to that 80% point is only 20% of the effort, right? Like that last 20% of enterprise technology is really hard. There's just an inordinate amount of effort associated with dealing with the edge cases and getting everything set up. And, you know, to me, I saw this impeccable opportunity to, you know, be a part of VMware becoming something more than just a virtualization company. Obviously VMware already was well down the franchise road. I had a lot of different kind of, you know, businesses, but being in a position where we could build out what I thought of as being a legitimate meta cloud, you know, something that would make on-premises public cloud and increasingly the network edge look consistent was just, you know, incredibly exciting to me. And so as I've been on this journey, you know, I always think of, you know, the kind of, in my head I'm pretty simplistic, you know, one, I want to deliver a ubiquitous Kubernetes substrate that's consistent everywhere. Two, that's not really interesting unless you have an effective control plane to manage it. And then three, I want to render up the software supply chain that enables developers to produce business outcomes in that destination. And, you know, through the initial, you know, integration into VMware, we just massively extended our reach to all of those existing facilities and became a really strong anchor for VMware's own navigation and migration to support public cloud computing. And then, you know, from a futures perspective, you know, it's all about the edge. Like this is where I see the most excitement, you know, for me personally, I think it's going to be a huge growth area and a highly disruptive area of innovation, you know, the coming years. And I just couldn't be happier to be a part of that journey at a company like VMware. Well, I'm glad you brought up Edge because I was about to transition to that since this is the edge day. So when you say the opportunity at Edge, and I won't make you define Edge, but I want to see what are the opportunities that you see for Kubernetes? Well, I mean, the whole point of Kubernetes was that it would be that Goldilocks abstraction that enables you to treat, you know, most infrastructure consistently. And the opportunity here is no different. You know, I think, you know, obviously there's a very broad, you know, array of definitions for, you know, what edge computing is from, you know, thick edge to thin edge, near edge, far edge. However, you want to kind of taxonomize it. And so the starting point, I think, is just having that normalized substrate, like that compute substrate that you can then tie back to a control plane. So you can start to reason about your Edge, whether it's, you know, geographically distributed, whether it's running in a variety of different, you know, polities, whatever the case may be, as being a common destination. And making that destination accessible to developers that are building physical outcomes is really interesting. We've seen so much excitement and engagement around things like reactive computing patterns. We've seen the emergence of, you know, CDN-based capabilities. That's really addressing the kind of outward flow of developer assets, you know, to the Edge device. The really exciting thing is what about the reverse? Like how do we start to kind of synthesize and process information that's being generated at the Edge? How do we do that in a topology-aware way that's making appropriate use of what computational resources hold their, you know, balancing computational consumption with network backbone consumption? And that to me is just, I could not be more excited about the opportunity to look to participate in that part of the journey. Something impact that a little bit. So if you think about, you know, Kubernetes as being a oversimplistically, but I think usefully a platform that will take a container and based on a declaration run it somewhere. And in a single data center, there's a set of, you know, common declarations that we might make that the scheduler can interpret to figure out where those workloads run within that cluster in that data center. Do you see that metaphor translating, you know, that the 10,000 servers are my single data center, that different from the 10,000 servers in the, you know, 500 data centers that I might be using at the Edge? Is those metaphors translate, do you think? I think they do to a certain extent, but you have to recognize that it sort of added complexity to the problem, right? So the interesting challenge with Edge is, you know, one is you're just dealing with the scale of operations. Within the logical construct of the data center, you can afford to have an operating model that scales, you know, somewhat linearly with the number of, you know, potential clusters or your pick your poison. As you start looking at Edge, it changes the dynamics. You have to have something that scales, you know, pretty much, you know, like just the cost of operations just doesn't scale with the deployment apology. Otherwise, things are gonna get bad. You can't send an IT operator to every edge location to deal with something that you have to update, whereas you could do that in the old days. And Kubernetes is just an incredibly important technology from that perspective. It introduces a determinism in terms of how you can reason about deploying something. So you can take that package software and run it very much like you couldn't a data center. But the thing that's really elegant about Kubernetes isn't just about like, oh, I can make placement decisions about virtual machine instances. Kubernetes has created a controller pattern. Like, you know, Brennan Burns, one of the founders of the project is creative genius as far as I'm concerned. He was also a robotics professor before this. And so he was all geeking out about, you know, kind of control theory. And that certainly is a key element of what Kubernetes is. It's not just about containers and deployment. It's about creating an appropriate set of control loops so that what's within the boundaries of that controller can be managed automatically by that controller. So it's not just about getting your application out there. It's about the care and feeding if something goes wrong. The restart dynamics, the ability to deterministically update it, making informed decisions about, you know, scalability in those locations without access to a centralized control plate, perhaps. In some situations, they certainly work with a lot of organizations where, you know, some of those environments are periscoping in their behavior. They might be LTE connected and there might be a network outage or they might be on a cruise ship that sells out to sea every, you know, X months and it's just not connected at all. And Kubernetes lends itself so well to that because it's not just about, you know, delivering static technology. It's about delivering well thought through controllers that can deal with a lot of those parameters. If you can, you know, if you can think about it, you can program it and you can, you know, push into Kubernetes and not just at the infrastructure level, but increasing at the application level as well. So I think that's going to be incredibly powerful. So when you think about the edge, you know, there are some pretty fundamental changes that happen at the access network, that last mile, so to speak. Yeah. You know, a lot of times the ownership of the server transfers from a cloud company to an enterprise, you know. How do you see, how do you view that transition, the edge of the last mile market network? Do you see that getting blurrier? Do you imagine, you know, cloud workloads being spawned on private equipment? I mean, how do you view that? I think it's a fascinating topic of discussion. And like if I, I think anyone who tells you they know exactly how it's going to go is probably selling something. I think there's still a lot of figuring out to do, but I'd say there are a couple of trends. We will see the cloud providers come with deeply vertically integrated capabilities that are being rendered out into those environments. And they have some very strong assets at their disposal. I think we will certainly see some amazing opportunities for organizations to create kind of multi-tenant based outcomes in those types of destinations. So independently of who owns a physical piece of serving gear, there's no reason why you couldn't create an API economy or an edge function economy that can leverage out, you know, whoever, you know, put that piece of infrastructure up there, as long as you can normalize that infrastructure, as long as you can set up the tendency model and the isolation boundaries sufficiently, you're in a situation where there's like whole new economies will likely emerge around this. And I think that landscape will be quite fluid for some time. But yeah, it's certainly, it's a fascinating dynamic. Exactly as you said, as you, you know, there's these sort of classic boundaries of ownership and that's very much in flux at the moment. Yeah, I mean, it's, you know, you can run Kubernetes on a Raspberry Pi on a device that's actually in the field. And I think it's very different than running Kubernetes on a, you know, on a server that happens to be at the base of a cell tower or in a carrier hotel or in a regional data center. But I think both are reasonable and applicable. Yeah, I do think so. And it's interesting because there's a, there's a decent analog here to Linux. If you think about the form factors that Linux is deployed into, Linux is deployed into everything from cell phone size devices to mainframes and everything in between. And if you think about what Kubernetes is emerging is it's effectively a, it's a way to program distributed systems patterns. It's a way to kind of deliver a distributed systems patterns. And I think the analog is pretty clear. I don't, you know, I think Kubernetes complements Linux. I'm not sufficiently arrogant to like assume that it will have the duty cycle that Linux has had. I hope it does. I think it likely will. But we still have work to do as a community to make that true. But the potential of the sort of the versatility of that model I think is quite strong. And we're certainly heading in a positive direction with the technology. If you could provide the audience of developers some direction on where you would like to see the community invest in Kubernetes to exploit some of the new opportunities at Edge. What would you advise them to do? You know, it's interesting. I was thinking a little bit about this before we came on. I think there's obviously, you know, normalizing a variety of different form factors, making sure that we have effective conformance standards around a variety of different form factors. Effectively, making sure that we get those profiles in place so that, you know, if you're building an application for a certain class of deployment, there's a well qualified, you know, profile because, you know, when you're running something on Raspberry Pi, it's not going to feel like running something in your mainstream data center. So I think that's certainly an area that, you know, behooves us to emphasize and focus on. You know, interestingly, I've been thinking a fair bit recently about the intersection of WebAssembly and some of these technologies. You know, there's an interesting little project from Microsoft called Crustlet. But when we start looking at the class and shape and nature of things like Edge functions, the ability to write a relatively small slew of code that can run in a massively multi-tenant context, have very high levels of security isolation. It really starts to feel a lot like WebAssembly. And so I'd love to see things like the WebAssembly systems interfaces protocols solidify. I think that could become quite interesting in this world. And it's obviously very early days, but that's something I'd love to see us think about. And, you know, and then like really tooling up the developer experience around some of those pieces would be quite interesting. Just enabling folks to start thinking about building, you know, building applications for these types of deployments where various pieces are honed in a variety of different destinations depending on the cost economics of where something is run is going to be quite interesting. And again, it's all going to come back to the control plane. You're not going to be a cool vendor if you don't have a control plane that enables you to deliver outcomes into these types of destinations. At the end of the day, relatively few organizations are going to have the capabilities to, you know, operate effectively a full on SaaS service to, you know, think through the mechanics of how these types of applications are built and delivered and managed and updated and observed. And that's going to be interesting. And then the final piece, I think that's going to be quite interesting. And this is something I don't think the community is focused quite enough on yet, but it's certainly an area that we're focused on in VMware, which is observability becomes really interesting when you're dealing with something. Really important too. And really important. Like, you know, what does it look like? You know, what does APM look like for an edge based solution where you have, you know, a pretty, you know, a pretty fragmented or pretty hierarchical topology. How do you reason about, you know, the metric system that's thinking about it? How do you make that sufficiently hierarchical so that you don't overwhelm the network links with metrics, but you're able to retain what you need to retain from a local deployment perspective? So that's going to be an area of, you know, certainly significant emphasis for us. And I think an area that the community would do well to pay attention to. Yeah, I think that the whole telemetry, the importance of telemetry to edge computing has been underappreciated. And it's not just telemetry coming off and coming off the applications. It's telemetry coming off the network. It's kind of coming off of the operational technology. I mean, if one of your microdata centers out at the edge goes on to battery power, you probably want to make some intelligent decisions about starting up, you know, backup workloads somewhere and starting to low balance traffic around. And right now, getting that information is very hard because it's not something that, you know, it's probably buried behind some CAN bus interface that you don't have access to as a software developer. And even you did, you might not know what to do with it. So it's the telemetry piece, I think you're right. That's really, really underappreciated. From a use case perspective, and you know, the autonomous car example is the one used to be everybody's favorite, although I think people that really think about it don't expect the infrastructure to be the driving factor for autonomous vehicles, maybe for coordinating them, but not that thing. But if you look like over the next, let's say 18 months, what are the use cases that you think are realistically going to emerge that excite you in engineering? The two areas where I see the most kind of energy around are in the retail and manufacturing segments. Look, pretty much every segment you can think of is chewing on the edge problem. Retail in particular is an area where I'm seeing things moving very, very quickly. Obviously the global pandemic has forced a lot of retailers to take a long, hard look at how they do business, how they operate. And the old narrative around necessity and invention, it's, we're seeing so much traction there. So getting to a point where we have far more computational resource in a form factor that is appropriate for the destination, that is sufficiently operable, that you can roll it out to a pretty broad array of sites to unlock everything from relatively simple experiences in small branch locations or small retail locations to running really high-end inferencing workloads and creating these next generation shopping experiences is interesting. That segment in particular is moving very quickly. Manufacturing I think over a slightly longer horizon is becoming very, very focused on getting better computational resource and a better control of the computational resource. But the problem with a lot of manufacturing is that that's generally tied to a pretty high capex moment and it's a sort of much more kind of complex roll-up. But certainly from what I see- Well, you mentioned COVID-19 and my experience is that every manufacturer had a 10-year automation plan that's now a four-year automation plan because of COVID, because nobody wants to stuck in that position again where they're shutting down the lines because they can't get people close enough. Yeah, really, really interesting times. So, Craig, what do you think the biggest challenges are to adoption of edge devices and edge technology? It always comes back to the people, skills. The technology I think is emerging. Being able to identify, just given the noise, being able to still signal from the noise and make smart bets, getting the skill set in place that's necessary to start running a series of experiments, navigating so that you're not making these kind of huge capex heavy investments that you can actually start to build into what you're doing and build your organizational skills at the same rate as you're starting to engage and deploy these technologies is key. The control plan, you have to have a sort of a hierarchical, highly available control plan to support this. That's necessary because it's not just about, I think a lot of folks overemphasize, well, what does it take to deploy a Kubernetes to this destination? Well, that's one thing, updating it, that's another. But then, how do I deploy an application into 10,000 retail locations? How do I run an experiment in two of those and get the results of that experiment? How do I make informed decision when I'm ready to deploy that update to the other 9,998 locations if you're running a sufficiently large operation? And without that control plan, technology getting really buttoned down and being able to reason about the control plan is something that spans both the infrastructure but also the supply chain that renders those application capabilities, components, experiences is gonna be key. And I'd say the second area, and this is, as we start looking at the energy and impetus to start to have more multi-tenant edge-based facilities is gonna be a challenge. The Kubernetes itself was certainly never built as a kind of natively multi-tenant environment. So being able to have better lines of isolation, security, a tenancy model that's smart for much lighter weight kind of function like use cases. It's gonna be a big challenge for this industry. Sounds like a lot of exciting work to get done. Craig, thank you. Thank you for joining us today. How can people find you online and learn more about your work? Well, you can always at me, that's CMCLUCK on Twitter. And then I occasionally post blogs on Medium if you look at my name, Craig and Clucky. But yeah, love to hear from folks and thank you so much for having me on. It's been a lot of fun chatting to you, Matt. Yeah, thanks a lot, Craig, really appreciate it.