Pivotal Container Orchestration - CTO Advisor 095

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

Hey everybody, welcome to the CTO Advisor. I'm here with a good friend of mine, James Waters. James, introduce yourself. Hey, I'm James Waters, SVP of Strategy at Pivotal and a friend of CTO Advisor. So what do you do at Pivotal? What does SVP of Strategy actually do? I tend to do two things. I work on a lot of things with our clients. So I spend a lot of time traveling with our clients, making sure we're doing the right thing, that they're being successful with what we do.

And then I try to help the company think about big new bets we can make. I worked a lot on our recent container strategy and so here at VMworld there's a lot of talk about containers. So it's kind of fun for me to watch these things go from early ideas to more mass market. So you mentioned containers and this is where VMworld, there's been a lot of talk about containers all over the place. So if I look at what I'll call container adoption, we had Docker a couple of years ago and all the stuff that led up to it.

But now it seems to all be about container orchestration and Kubernetes. So where do your customers, when you're talking to your customers, how do they feel about Kubernetes? Are they doing it? Do they want to do it? Are they having trouble doing it? I think a great question about the history there is in the peak Docker hype, there was a moment where it was sort of casting itself as just Docker solved everything, right? And I used to take uncomfortable opinions with some people, I was like, hey, it's kind of a laptop technology, right?

It really was developers on their laptop, they love that Docker image, they could put together their Python app with their Redis and their Postgres and their Elasticsearch all in one little Docker configuration, their laptop, they're like, this is the greatest thing ever. But that really didn't solve for what you might call enterprise data center orchestration. And so I think Kubernetes has now become the place that all those things from laptops migrate to in the data center. But in the same way, Kubernetes itself needs a lot of help to become a platform.

So it needs a lot of networking help. I think that's why VMware is so big on this with NSX, you can see them talking about that. It needs security help, so you still need to wrap virtual machines around it. That's kind of one of the big things and why I think VMware is a nice bet here and it needs a day two, right? It's not like you put it down once and forever and ever it's gone. So it's just interesting to watch what was a laptop phenomenon now getting closer and closer to enterprise reality, if that makes any sense.

So it sounds like Kubernetes isn't easy. So there's lots of challenges, right? Yeah, I think I like how honest Kelsey is about this and Joe Beda and the folks that really originated the Kubernetes code base, they're like, hey, this is a kernel of a platform. And I think what happens is the word gets so popular, people start to assume it's just sort of a proven fact. But it's a lot of fun to help people have a good time on the ride, I guess, as I was saying before the podcast.

So you're here, you're talking to a lot of customers, right? Yeah, a lot. Are they all wanting to talk about your Kubernetes offering or are they talking about other things with you? I'll give you an example from this morning where one thing that's really exciting about Kubernetes and what customers are talking about is ISVs that have been shipping on-prem are now starting to ship container native. And so one conversation this morning was a bank who said, hey, we're conservative, but we have to have this for our quant ISV that wants to come on-prem with us.

So when I think of things like that, I see a lot of people going to SaaS offerings instead of those COTS apps and those ISVs. But I've never thought about where it would go if you still need it on-prem, if your requirement is still on-prem. Yeah. Is that a big use case? An easy use case probably. I think there's a huge amount of on-prem software left and on-prem ISVs I actually think is a really interesting frontier because the mega horizontal things like Google Docs and Office 365 and Salesforce, we've figured out how to SaaS that.

But there's a really big long tail of applications that enterprises use and a lot of times we help them with their original platform so much with their traditional apps that they built. But their pain was they're packaged on-prem apps. So I'm super excited to see people saying, our app artifact is going to come with programmatic infrastructure built into it. It's all going to be packaged for Kubernetes. So I see a lot of it. So have you talked to any customers who have tried to deploy Kubernetes and failed or were successful?

What happens most of the time? I think there's been a learning curve where one other conversation I just had today, just keeping it real like what would I really hear today, was there was one vendor that their philosophy around open source was, let's support the old version and we'll kind of fork and support the old version. Right. That's always something people want to do. It doesn't work out usually. It doesn't really work in the Kubernetes world because the cloud providers and the Kubernetes community keep rolling forward on it.

And so it turned out that their on-prem app didn't work on the forked version. So that reminds me a lot about OpenStack. Yeah. Right. You know, OpenStack, they're constantly changing, constantly tweaking. Yeah. So many versions. And it's so difficult. Right. I had a team, a customer, and they literally tried to deploy OpenStack. Yeah. They worked really hard. And these were really smart people. Yeah. And they failed. And when I saw these really smart people fail and being able to deploy something, that was a real challenge.

You know, I work for a company that's owned partially by Dell Technologies, so I'm a little biased. Right. But my honest advice to anybody is I would say that fewer vendors in your private cloud stack today, like sticking all this stuff together is hard enough. Right. And it's all starting to move faster. And that's really where fewer vendors make sense because if you had two years to do a project to glue it all together, maybe you had a shot. But when these open source communities continue to move forward rapidly, DIY gets really hard.

Yeah. So I'm excited when we can kind of come in and be like, we'll give you a Kubernetes dial tone with the full infrastructure stack. Yeah. Because it's a lot of work otherwise. Right. I don't know. I think I'm just agreeing with you there. No, but that's good because that echoes what I've seen in the industry. And I would say, just straight talk a little bit, you know, like OpenStack in general, I don't think is seeing the growth curve of adoption.

I mean, what are you seeing? Like, I'm seeing less OpenStack. No, I agree. I think OpenStack, you know, certain use cases, you know, large service providers where they're really building and have the talent to build all that. But I think in the enterprise, I don't think I've seen much OpenStack adoption. A few banks, you know, they've really heavily invested in it. Yeah. And that's kind of, I think, what you have to do. So I think a lot of people I've heard compare Kubernetes to OpenStack in complexity.

Not so much in success or failure, but in complexity. Yeah. And that's where I think because Kubernetes is like half a developer API, like here's my app artifact, here's my rolling update, and half an infrastructure API. Here are my networks, here are my, you know, virtual machines, or at least nodes. I'm hopeful that it can have a bigger ecosystem because of all the developer impact, these package things, and what's happening there than maybe some of the lower level stuff where OpenStack was.

And to be fair, my friend Josh McKenzie helped create OpenStack. He always wanted to get it to be like a developer experience eventually. So interestingly enough, one of the things that when we started talking about Kubernetes and Docker is it changes things for developers, but it also changes things for infrastructure. So when you go out to customers, you know, I don't like to say it like this, but it's the best way I can think of to say it, who usually ends up owning the platform that Kubernetes becomes?

It's something that the developers usually own, the infrastructure, and how does that work? I see that being a huge challenge for, you know, politics of a real enterprise, right? It's there, it exists, and we have to deal with that. As you said, it's a human challenge. And you can't fix that? I haven't fixed all human challenges yet. Give me a couple lifetimes. The thing that I would say, though, is that I think it makes sense to have an infrastructure platform team run it.

I don't think developer teams running it makes a lot of sense. Just because, like, you know, I was talking to one bank that was building a new digital initiative, and I was like, look, honestly, the cognitive load I like to put on myself when I'm trying to do something else at the app level is as minimal as possible. So if I can just have something that abstracts that for me, and I can focus on how hard my microservices are to stitch together, I guess plenty.

So if I'm thinking about deploying Kubernetes in an infrastructure environment, I'm an infrastructure admin, what are some of the challenges that I should be looking out for, some of the questions that I should be asking myself to think about before I just jump right in and try to do it the hard way? I mean, I've got three that are pretty universal to any Kubernetes deployment on-prem, especially or hybrid. I like to just qualify everybody who's souped up on it, like, yeah, we're Kubernetes, they're chanting.

It's like, okay, can I ask you a couple of questions? When I was telling you about these, the first one is, you know, how many times does it come out a year? Because I meet teams that their enterprise process to get something to production takes them sometimes a year or a year and a half. And so they end up about to take to prod a year and a half old version of Kubernetes. Now there's also some vendors that try to support the old version and they almost amplify that.

But go over to Stack Overflow and Google, like, your old version of Kubernetes now and you see the ecosystem has moved on. The other thing that Kubernetes formally only supports N-2, which means after nine months, you're basically out of date. And that's hard in the enterprise, right? I'll echo my pivotal experiences, updates come out always. I mean, they've probably been one in the time we've had this conversation, I think. Probably. I imagine Kubernetes would be... Well, that's why it's a sweet spot for us, not to like, you know, pitch our own book too hard.

But we were already managing like, you know, half a million containers in production and enterprise and constantly updating the platform underneath them. So when we saw the ecosystem expansion potential, the Kubernetes, you know, community and the fact that it needed our constant delivery capability, we're like, we can really help. And so that's the first question. And oftentimes, people don't even know it comes out four times a year. And that's just like the first brace where they're like, oh, yeah, we better have a plan for that.

And I know that these things matter to enterprises because like, you'll see them go from no notebook to like, they pull the notebook out and they start scribbling these down. Start actually paying attention and realize what they actually have to do. I think they realize it's going to affect them. Yeah. Right. This isn't some pie in the sky vendor feature. Like, this is core fundamental 101. Yep. All right. So that's question number one. Yeah. The second question is a little more nuanced, which is like, how many clusters are you going to need?

And you know, the example like Kelsey or some of the other folks talk about too, is sometimes there's like a helm chart that wants access to the full root privileges. So if you only have one giant cluster for your organization, how do you do that? Like, do you want to give everyone root on the whole cluster, on every node? Well, so that's a challenge that I've seen with Cloud Foundry is your minimum spend. I mean, it's cloud scale where it's like a minimum cluster.

I would say four. Yeah. But I think it's actually technically three. That's a big footprint. Yeah. Right? If I presume that most of those are on vSphere or that's the lead, that's a lot. And fully resilient Cloud Foundry has a fair number of VMs. Yeah. Right. Yeah. And Kubernetes, I think what you want to be able to do is have essentially one Bosch in our world where you can stand up multiple clusters of Kubernetes inside of it versus one big Kubernetes cluster and everyone has to swim in the same permissions.

So we're talking a Kubernetes cluster. How would that translate to a vSphere cluster? You could have n number of those on a vSphere cluster. And that's what we're trying to drive with VMware and our partnership, is you should be able to programmatically deploy as many Kubernetes clusters on a vSphere cluster as you want, expand, shrink, and update them. And if we make that dial tone boring and simple, then people can get to adding value as opposed to getting to bogged down.

Yep. All right. I really like the way you're thinking about that. So third question. Yeah. The third question is, is your network ready for this and how mature is your SDN? And as you know with Kubernetes, I want a provisioned ingress controller. Oftentimes at enterprise, that means I just had to go talk to the F5 team. Yeah. And I have to explain that I want to add this thing to a cluster somewhere in Kubernetes. And that's a whole back and forth.

Right. Whereas with some of the stuff VMware is doing with NSX-T, as a Kubernetes cluster is deployed, up pops an ingress controller programmatically. So that's the difference between three weeks with a ticket or programmatic. Choose programmatic. Same thing in terms of wiring networks into the clusters and between clusters. Again, I don't think you want to do that in a traditional I'll go file a ticket with a network team while I'm dynamically managing all these containers. Yeah. Well, so that brings me to the point.

Yeah. How many of your customers already have an SDN solution that's mature? I know we talk a lot about NSX. Yeah. And it sounds like a great product, but how many people actually do it? I would say that one of the number one use cases for NSX-T is containers in general. Right. People doing kind of continuous delivery, constant updates of environments is really driving NSX-T for containers. Yeah. That's what I hear. So NSX-T at least is co-evolving with this container ecosystem, which I think is promising, but it is new for people.

Yeah. Like there's definitely, it's a new journey. Yep. Well, okay. So those are, I think this started out as what will we give to our infrastructure people? Yeah. What will we say to developers who are looking at going down that journey? I think developers are a little more in tune to that because really we're trying to give them values so that they can help drive business value. Yeah. But as they start looking at their container and that ecosystem, what would you tell them to think about?

Yeah. I think in an enterprise context, the first thing I'd say is that sort of the developer experience in Kubernetes, there's not one opinionated one. Yeah. Like there's not one God API on top of Kubernetes that all developer workflows result to. Yeah. I think all the core Kubernetes contributors would say similar things. Yep. We partnered with Google on a new one called Knative, which is optimized for functions and apps that essentially are wired to respond to events and scale up and scale down based on events.

I think that's an exciting use case, but at the same time, I think what you want to do for developers is keep it as a more open ecosystem because there's a lot of innovation coming out right now. Yeah. I think if you're going to give your developers one kind of forked version that has one opinionated way of doing a developer workflow, I think you want to take advantage of the community. And there's a lot of different CD tools. There's Spinnaker that now plugs into Kubernetes.

We're working with Weaveworks. Alexis Richardson's company has a GitOps flow into Kubernetes. So I think it's a time of incredible innovation on the developer front within the Kubernetes community. So Keith and I were talking to, I think it was Nick Rockwell. He's the CTO of the New York Times, about the people challenges in adopting any new technology. And specifically from his perspective, I think they almost skipped the container journey. They went right from VMs, they toyed with containers, and there's a podcast that we'll link to.

Cool. And then they just went serverless instead. Yeah. And they were doing some work with Kafka too, if I remember the New York Times. So I've always thought of containers just the next logical journey to serverless, and then serverless the next logical journey to I don't know what. How do you feel about that? I think one of the beautiful things that this philosopher Wittgenstein said, he said, language is constantly evolving in the direction that when we do new activities, we get new language.

It's not like when we create a new word, we throw another one out. It's not like, oh, hey, we're saying this now, let's throw that out. And I think if you keep waiting for developer interfaces in computing to get smaller and fewer, you're ignoring all the new utility that's happening. Genuinely, to use a New York Times example, running Kafka on Kubernetes is a perfectly legitimate and important use case. Confluent is now coming out with a Kafka operator. It's totally optimized for the Kubernetes APIs as it exists, and it doesn't need any fancy workflow on top of it.

You can't run Kafka on Lambda. In a sense, that doesn't make sense. So I don't see the whole world going serverless, quote unquote, because you still need to run your data cluster somewhere. At the same time, if all of your data looks like a bunch of events on Kafka, maybe you go with a serverless framework like Knative, and you just respond to them as they come through, you process them, and you turn off that node. So I try not to reduce things down.

I look at as new utility happens, we're learning new words, but it very rarely is all boiled down to five things. Does that make any sense? Yeah, it does. Too wonky? No, no. I like that. So I really like where we've gone with this. So I wanted to kind of fork a little bit to talk about James. What has your career been like? You're SVP at Pivotal, I know you've worked at Oracle before. Sun Microsystems.

Sun Microsystems. Until the day Oracle bought them, and then I... Sun Microsystems. Yeah, yeah. So where did you start, and how did you end up here? Do you have a Pivotal moment in your career where it really pivoted differently than you were expecting? Sure. If you'll indulge my nostalgia, the first thing I'd say is I was incredibly privileged to work at Sun for eight years, because it was kind of like a research organization. And so it had the feel of an academic world, where we spent a lot of time thinking with smart people, we thought a lot about what IT is a service, what cloud, what open source would mean.

Yeah. Sun as a company didn't end up monetizing all of that. Right. That would have been a while ago. Yeah, this is 2004, I was working on cloud and IT as a service thinking at Sun. Yeah. So I've been fortunate to have that long runway, but we kind of hit a point where we realized there wasn't a lot of value in the hardware itself anymore. So the Pivotal moment for me was when I left Sun, I was like, I got to find the software that makes all this distributed hardware valuable.

And I was lucky enough to kind of start on what you now call the cloud native software journey there. Awesome. So I think just look at where value is headed in your industry. And if you can be a couple years ahead of that and learning, you'll be more ready for the challenges when they come. Great. Maybe that's my only few cents. All right. Well, James, thanks for your time. Again, I'm Mark May with the CTO Advisor. Yeah.

And we'll catch everybody later. Awesome. Great to be here.