Inside VMware’s Kubernetes playbook

When Joe Beda was working on early versions of Kubernetes at Google, little did he and his team expect that the software would become the de facto open source technology that enterprises would use to run and manage containerised applications.

Today, Kubernetes can be found in nearly every enterprise, in private cloud datacentres and on public clouds, wherever microservices-based applications are deployed. Cloud and application platform suppliers alike are jostling for a slice of the market that is slated to grow to nearly $5bn in 2023, according to some estimates.

Beda, who co-created Google Compute Engine and filed the first-ever Kubernetes project commit, now works for VMware as its principal engineer. He arrived at VMware via the acquisition of Heptio, a startup he co-founded to help enterprises manage Kubernetes clusters.

In an exclusive interview with Computer Weekly, Beda talks up the founding principles of Kubernetes, where he sees the market going, and why VMware is not about to force everyone to standardise on its technology.

As a co-creator of Kubernetes, did you think the platform would be what it is today?

Beda: It’s been a surprise to all of us who were involved early on to see where things have gone. I think we had a sense that if things lined up and we hit a nerve, it could be big. But the past six years have really been quite a whirlwind.

I’ve been doing platform-level stuff for much of my career. I started out at Microsoft, working on things like Internet Explorer and Windows. Then I switched to the server side and did cloud stuff with Google Compute Engine and Kubernetes. And through that time, I got a sense of what makes a good platform, which should enable people to do things they had never planned on and get value out of it that goes beyond what you had imagined.

The flexibility of Kubernetes and all the niches that it has been able to adapt to has been amazing. I don’t think we were thinking about edge computing when we were creating Kubernetes, but that’s now a big part of the story in terms of having a uniform platform across different environments.

And then finally, the way it has gone beyond containers towards being a more general sort of extensible control plane has been a huge surprise. It’s also great to see the influence that the Kubernetes community is having in many places.

“Our goal – and we’ve been saying this for a while – is that we want Kubernetes to be boring”

VMware is one of the top contributors in the Kubernetes community. What is the general approach towards contributing code to improve the platform?

Beda: We want to be good citizens when it comes to the open source community. We believe that open source can be a positive-sum game for everyone involved. Part of that is finding the right balance, both for us and the community, about stuff that is part of Kubernetes and the opportunities for companies to add value.

One of the things for successful interaction with open source communities is being honest about what your goals are, what you’re getting out of it and what you’re putting into it. But overall, when we look at our investments, we want to make sure that we put in as much as we get out. We don’t want to be just extracting value from the community and from Kubernetes. We want to advance it and make sure that it’s healthy over the long term.

What are your thoughts on some Kubernetes platform suppliers that have been accused of locking customers into their platforms?

Beda: Lock-in is an interesting concept and when I talk with customers, I try to view it through the point of view of the risks that they’re facing and what they are doing to mitigate those risks.

Our goal with Tanzu and the Kubernetes community is to bring value by providing a way to get involved without having to take on all that complexity. We want to be a bridge into the Kubernetes world, and not create silos.

We don’t want to separate people from the larger Kubernetes ecosystem because one of the things that gets customers excited about Kubernetes is having access to a rich set of innovative open source projects and solving problems that are unique to them.

With respect to compatibility and portability, there are a couple of ways to view that. One is, if you have perfect portability, you end up with a certain lowest common denominator. Customers generally want to take advantage of the unique features or qualities of the platform they’re using.

Beyond that, when we look to add value on top of Kubernetes, we make sure we’re very clear about things that are part of Tanzu and not part of open source, so customers can make an informed choice about software dependencies that stray outside of the pure open source point of view. You’re not going to get perfect portability, but the goal of Kubernetes and Tanzu is also to reduce that switching cost as much as possible.

There is also portability from a skillset perspective. If you have engineers who know how to work with Kubernetes and they’ve built your internal automation infrastructure and platforms on top of it, how can you make sure their skills and tools are as portable as possible across environments? It doesn’t have to be exact, but if you can reduce the switching costs and spin-up time for engineers, that’s real savings that matter to customers.

One of the value propositions of Tanzu is to address the application development needs of VMware customers. Do you see non-VMware customers coming on board as well?

Beda: That’s a good point. Our goal is to bring value to VMware customers, but we’re ambitious. We also want to be relevant and provide value to those who may not be VMware customers yet.

VMware has relationships with almost every large company, but those relationships could be with certain parts of a company. A big part of what we’re doing with Tanzu and related things like Kubernetes and the new APIs [application programming interfaces] in vSphere is we’re creating new products that address a larger segment of our customers, such as application teams. We do this by connecting the dots between vSphere and application teams or providing value to application teams even if vSphere may not be in the picture.

Kubernetes is a work in progress and there are a lot of enhancements being developed by the open source and supplier community. What are some of the immediate requirements that the platform needs to address?

Beda: Our goal – and we’ve been saying this for a while – is that we want Kubernetes to be boring. I’m speaking with a community hat on and that goal hasn’t changed. Good infrastructure disappears and we really want Kubernetes, regardless of who’s delivering it, to be able to get to that point where it feels like a utility.

To that end, I think the areas where the community is putting effort in are often around extensibility. From early on, we recognised that people would want more features that we could put into the core, so we started shifting our focus towards enabling people to extend Kubernetes without having to be involved in the core project.

“Beyond Kubernetes, there are more opportunities for vendors to coordinate and drive more ancillary open source projects”

That has been wildly successful and has spawned whole ecosystems. The great thing about that is there are no gatekeepers, whereas oftentimes in open source, there’s a group of people who wield a lot of power and say, “no you can’t do this”. With the extensibility we have with Kubernetes, there are people doing things that I may not think is a great idea, but they can still go ahead and do it.

One area in upstream Kubernetes where we’re putting a lot of effort – and built on top of extension mechanisms – is around cluster lifecycle, specifically our cluster API. Our Tanzu products in terms of managing Kubernetes are built on top of this, and we think this is a win-win across the industry.

To be brutally honest, the more people run Kubernetes, the more opportunity there is for us to create those relationships and build on top of it. It’s in our interest to make sure as many people as possible can get a cluster and find usage there. It’s hard, but we want to make it easier and we’re putting a lot of work into that.

With multiple Kubernetes distributions in the market, how do you think things will play out? Do you see this as a kind of platform war? You mentioned that you worked on Internet Explorer – is the competition akin to the browser wars in the 1990s?

Beda: There’s a lot of competition here and I think that’s going to be ultimately good for users to have a lot of people working to make things better. One of the other things that we see, and I think this has been a fascinating evolution, is that our users know what they want in terms of interoperability.

It may not be perfect portability, but there’s still some portability and that is something that customers value and have asked for. The closer it is to the application and its dependencies, the more likely they’d prefer these systems to be open – and, ideally, community-driven.

Beyond Kubernetes, there are more opportunities for vendors to coordinate and drive more ancillary open source projects. It has been interesting to see that there have been echoes of Kubernetes across a bunch of different environments. One example is a CNCF [Cloud Native Computing Foundation] project called Envoy, a load balancer which brings a lot of value. We are also a big driver behind another CNCF project called Contour, an ingress controller that uses Envoy under the covers. It’s great to see those independent ecosystems get launched and mature.

You speak to customers from all around the world. Are you able to share some interesting things that companies are doing with Tanzu since its launch not too long ago?

Beda: The diversity of use cases has been fascinating. One of the things we’ve seen – and this where we start to bring in some of the higher-level services in Tanzu – is the number of clusters that customers see themselves running and managing over time, especially large global enterprises with an explosion of infrastructure that needs to be managed.

A lot of the value and conversations with these folks is not about what happens on an individual cluster, it’s about how to manage, monitor and secure over 10,000 clusters for their enterprise. I think that’s where things start to get interesting and exciting.

I’ve met some of these larger companies as well, and some are running different application platforms and Kubernetes distributions for different classes of applications. There’s bound to be some complexity and interoperability issues that they must deal with. What advice would you offer to those companies?

Beda: Concretely, we’re working through open interfaces and open protocols to enable interoperability between multiple clusters and systems, even if they’re coming from different suppliers and different frameworks.

One of the open source projects that I started before Heptio was Spiffe, which is essentially an identity standard for how you encode identity into certificates and then make those available to workloads. We have a team working on that now in VMware, and it’s something that I’m excited about. It’s an open specification and an open reference implementation. Those are the types of things through which we can help to create a level of interoperability between different solutions.

The next thing is our management offering, Tanzu Mission Control. It works with any Kubernetes cluster that is Kubernetes compliant. Even if you’re not running Tanzu Kubernetes Grid for your clusters, we want to be able to provide a level of policy oversight and a single touchpoint for IT folks as they look across their entire estate.

I think it’s a pipedream for any complex enterprise to have a consistent infrastructure across its entire footprint. There’s always going to be some need to diverge. You’re going to make an acquisition, go through a merger, and you’re going to have a hybrid mixing of technologies. This isn’t a point-in-time thing; this is just the reality that folks deal with on a day-to-day basis. And so, a big part of what we’re trying to do with Tanzu is to work with that reality versus trying to fight it and force everybody to standardise on VMware up and down the stack.