Pivotal Container Service (PKS), with Cornelia Davis and such (Ep. 81)

Episode 66 · 48:47 · SRT · archive.org · all Tanzu Talk

Well, I think it was maybe a couple months ago, maybe a month. I've lost track of time. But we had an announcement here around Pivotal that we were adding in the Pivotal Container Service, or PKS, as is cleverly named. Adding in, essentially, into the Pivotal Cloud Foundry stack or portfolio, or as I like to call it, burger diagram, a Kubernetes distro that we've been working with Google on. And so, finally, after a flurry of important conversations, getting work done announcements, we have Cornelia on to talk about that. You want to introduce yourself briefly, Cornelia? Sure. Thanks, Coté. My name is Cornelia Davis. I have been with Pivotal since the Pivotal spinoff. And just by brief, you know, kind of background, I came to Pivotal from EMC, where I worked in the corporate CTO office, working on kind of architecture and emerging tech. And the emerging tech space that I was working on five years ago, a little more than five years ago, was Platform as a Service. And, of course, being EMC and Cloud Foundry was getting incubated at VMware, I was really digging into Cloud Foundry. So, when the Pivotal spinoff happened, I joined the Cloud Foundry team proper in a role which is very similar to what I do now. Well, it's essentially exactly the same role that I do now, but I have always been in the product organization, but in a kind of market outreach position. So, I work with customers and partners in an emerging technology space, helping them grok it, helping them help us grok it, how it might be helpful, and essentially kind of inventing with them. And that's what we were doing with Cloud Foundry about four years ago, when we brought this brand new emerging technology to market, kind of defining the market and figuring out what's the right way of it being used and bringing value to customers.

And that's exactly the role that I'm playing now with PKS. So, I'm kind of leading that charge of getting into the hands of our customers and really kind of sussing out what is it that they need? What's the value that we can bring them with this new product? Yeah, that's right. So, it's sort of like the role that a CTO does internally, but kind of itinerant amongst the customer and just general enterprise base, trying to map that stuff. And then occasionally, it's good to do something. So, you come back and do more of the product direction and things like that. At least that's what I've noticed over the years. And am I remembering wrong or did you used to work on also like a secure document space back – weren't you part of that startup that Documentum got with that or something? Or is my memory a little messed up? Oh, yeah. That is so funny. That's way back when. So, yeah. I actually – my journey to Pivotal is kind of fun because I started literally 18 years ago at a company called Eroom, which was the market leader in online web-based collaboration. So, you have to remember 18 years ago, the web was still pretty new and we were still figuring out where the value was going to come from. So, that was web-based collaboration, document sharing, but more than that. And then it was acquired by Documentum in 2002. And then almost exactly a year later, Documentum, which of course is content management, was acquired by EMC. So, that's how it came to EMC. And so, for the last 18 years, I've worked for four different companies, but it's all been through acquisitions and spinoffs. That's right. I think I remember – well, I know why I remember that because when I worked at M&A at Dell, on M&A at Dell, we would use that occasionally amongst many other things. I remember some people elected not to use too secure of a space, but we would frequently use a very secure space to share all of the – I forget the word they use for it, but all the materials and the clean room or whatever metaphor they would use.

But, yeah, that was always fun. That was good stuff. Anyhow, enough of the memories. Lots of the good stuff. That's right. That's right. Awesome. Yeah, so I thought we would kind of talk a little bit more about your journey. One thing I was – you and I have gotten to work together a little bit on the PKS work. Well, I believe when you took this on that this was – Kubernetes was kind of new to you, that you weren't a kubehead leading up to this. So, assuming my memory is correct there, are there things you've learned about, especially coming from the Elastic Runtime Cloud Foundry environment, that were just interesting or novel to you or something that you kind of had to switch a gear to say, okay, this is how this works now. I have to kind of remap that part of my brain of how to deploy apps or to run things. Anything kind of interesting on Kubernetes that's really stuck with you? Oh, most definitely. And so let me share this kind of anecdotally with you. So I think, Richard, you know that I'm writing a book. And I had written some chapters, and it's mostly an architecture book, but I used some code samples in there to demonstrate some of the architecture stuff. And so the book is called Cloud Native, and I'm writing it with Manning. And I had written some stuff earlier in the year before I was working on Kubernetes. And there was an example where I deployed it to Cloud Foundry. And what I was demonstrating was statelessness. And so it really doesn't matter what the specifics of the example were, but I needed multiple instances. And so I transitioned from running that code locally to running it on a platform that has automatic load balancing, for example. And so I had pushed it into Cloud Foundry. And it was, as we know, super simple. I had compiled my Java code into a jar file, and then I did a CF push and pointed to my jar file. And that's all I had to do. And so just recently, in fact, last weekend, so a little more than a week ago, I was like, you know what?

I want to do this on Kubernetes because I'm now working on PKS. And so I want to go through that same exercise. And naive little me that's been working on Cloud Foundry for the last, you know, four years, four or five years, when I said, okay, and I made some change. And I made a couple of code changes, not because I was pushing the Kubernetes, because I was just changing the sample a little bit. And I was like, okay, great. Now I'm ready to push this Kubernetes. And I was like, oh, wait, I need a Docker build file. Because I can't just push a jar file. I actually have to push a container image. So I have to create that container image. Right. Okay, good. So create the Docker file. And I'm like, okay, I deploy it to Kubernetes. And now what's my endpoint? Oh, right. I need to actually expose it specifically as an endpoint. And depending on the Kubernetes deployment that I'm running on, I happen to be running on Minikube. I need to figure out, well, where's that load balancer going to come from? Because it's actually not part of Kubernetes at all. So Minikube brings its own load balancer. So when you expose something as a service, so it's a Kubernetes call to say expose this as a service. But then it leverages something on the outside of Kubernetes to actually give you that endpoint and that load balancing. And none of it was particularly difficult to do because the tools like Minikube make it easy. But it was definitely, I love your question, because it was definitely like, oh, yeah, that's that yak shaving thing that I haven't had to deal with for the last four or five years on Foundry. I now have to do a little of my own yak shaving. That's funny. Yeah, I mean, it's kind of built on that. So now you could listen to that answer and go, oh, good Lord. Like, why would anyone want to do that then? But there is a reason people not only choose to do that because they like to screw around with low-level stuff, but because the app demands it or the workload.

So, I mean, when you've, you know, you've been amazing talking to so many different customers. This is not just an ivory tower product we're building with PKS. It's legitimately based on tons of feedback and market understanding. But what problems are you hearing the most this is meant to solve? Not only Kubernetes as a whole, although I'd love your answer on that, but then also kind of where is PKS filling a gap in what those customers have been trying to do themselves so far? Yeah, it's interesting, and it really depends on the customer. And even, so I'll tell you, we have one customer who, existing Pivotal customer, existing Cloud Foundry, Elastic Runtime customer, who's been arguably very, very successful with the Elastic Runtime. Literally thousands of application instances out running in production, mission-critical production workloads. And even there, and the people, but it's a large organization that has literally thousands of developers in it. And those developers who have embraced Cloud Foundry are delighted with it. But with thousands of developers, they don't have 100% penetration on that new way of building software and of not having to do the yak shaving. And so there are some organizations, even within that company, that have created their own yak shaving foundries, if you will. And so they are doing things like creating pipelines and using standardized images and standardized Docker files and those types of things to do kind of some of those, the same things that Cloud Foundry does really well. And so we do have some of those, and so we do have some of those, and so I want to acknowledge that there are some of the people that we've spoken to that are looking to try to build up their own kind of some of the capabilities that are in the ERT around this container orchestration. That does exist. But that said, a far larger, I think, opportunity for our customers that I'm seeing actually out talking to customers is, again, even those customers that have been really, really successful with the Cloud Foundry Elastic runtime to date.

They've been successful with that, and they have good workloads running on it, but those workloads in some cases are only about 10% of the overall workloads that they need to run as a whole. So I sometimes talk to enterprise customers, and of course, we know that Netflix is one of the poster child, you know, poster children of modern cloud native architectures, microservices based, and things like that. And when I talk to them about what Netflix has done in terms of even, you know, the OSS stuff that they have created, I often have enterprise customers say, I wish I was Netflix. I wish I had one app that I needed to run. But I have 500 apps that I need to keep running, and many of those apps were built 20 years ago, and I'm not going to rewrite those in microservices because there just isn't business value for me on that. And so they've got 10% of their portfolio where they've got this really modern process and all of that stuff and using the modern platform. But then they have a huge percentage of their workload that, quite frankly, they're still using old ways of managing that, of deploying it into prod and those types of things. And so that category right there of existing workloads, kind of traditional workloads that don't have the microservices architecture, but they want some operational benefits. And it's probably workloads that they don't even, they aren't really doing a lot of development on anymore. It's, they're kind of in maintenance mode. They don't have an active DevOps team on it. They, it's mostly just being run in operations, and occasionally there's a few bug fixes, but they're relatively stable from a software development lifecycle perspective. They don't get released every week. They get released every six months or nine months, but they want to do something better than just provision it on raw compute storage and network.

Yeah, that makes sense. So somewhat related to that, and this is a bit like up in the clouds, as it were, you know, especially building on your work around the, the, the who does what in the organization. It seems like one of the, one of the theories I've been messing around with my head is that the way you scale up a lot of this stuff is to, I mean, it's extremely biased to pivotal, but what are you going to do? And then kind of thinking about your story of, I wanted to deploy some stuff to redeploy some things to Kubernetes. It seems like part of what having a Kubernetes distro that's kind of built into the overall ecosystem or the stack that you have, it allows you to, in those large organizations of, I don't know, I always use JPMC's 19,000 developers, that it provides a standard way of doing this, this one thing of deploying on top of, of a cluster rather than. You could say allowing or giving the freedom to various teams to kind of figure out how they would do this configuration and stuff on their own. And so that seems like one of the goals we would have with having both, I always forget what we're calling it now, the, the traditional pivotal cloud foundry. And then also here is a standard way to, as, as you're saying, whether you want to, what would be the word, almost lift and shift over your existing low maintenance applications to a better way of running things. Or if you want to sort of use that as a staging ground to migrate, re-platforming or rewriting them, in addition to the new applications and more cloud native-y things you do. But it's sort of widening the net of being able to standardize and centralize the way you're running things instead of having a, let's say, heterogeneous way of doing it across the, the organizations. Hence, allowing you to scale up a whole bunch of these benefits that I think, I think maybe back to your Netflix point, if you had, I mean, I always figured Netflix probably has maybe 15, 20 applications or something.

Cause they got all their back office stuff, but basically having one application, um, one core application, um, you know, maybe you don't really need to have such standardization of how you package things and how you manage things and stuff, or as much as maybe draconian. But it seems like that's, uh, I don't know, there's no question there, but, uh, I mean, is that kind of the, the trend that you've been seeing in large organizations over the years that there's much value and maybe not having as much freedom as you might see over in like Spotify and other places. And in fact, it allows them to, uh, scale up more efficiently. Yeah. And you know, I actually think it's a bit of a myth that places like Netflix and Spotify that the developers run, rule the roost and have all this choice and can do whatever they want. I mean, what Netflix has done and they've open source now is a framework that standardizes the way that things work. Exactly. Um, so, so it, they, they definitely have adopted those standards, but I love your point around the standards and it's really interesting. This is where PKS brings in a different angle. So on the ERT, and that's what I'm calling it at the moment. So what we've called cloud foundry or PCF in the past, I, I'm very careful to call that the elastic runtime. So that's the place where you do the CF push and the things we know and love there. Um, it is an opinionated platform and it's designed so that our, the organizations that we work with can work with their chief security office or their compliance office to make sure that that standardized platform that's available, that opinionated platform reflects the policies of the organization. And so it is, we sometimes, uh, sometimes people will use the word constrained, but I prefer the word opinionated because it's actually not trying to make your life more difficult. It's actually trying to make your life easier. Um, now, when we move over to PKS, PKS definitely brings in an element of standardization.

It says, okay, instead of you coming up with a new snowflakey way of doing your operations one way for one app and another way for another app, what we're trying to do is introduce some standardization there. So having at least a single container platform where we can deploy the Kubernetes subsystem, we, you can deploy your apps against it. And then now we know how to upgrade that Kubernetes cluster and all of those types of things introduces a level of standardization, but here's the important part. We are not asking you and saying the only way that you can take advantage of this new platform is by retooling and changing the architectures or even changing your operational practices around your existing code base. So, we give you the ability to say, you know what, leave some of that alone, we're going to make it easy for you to take what you've got, lift it and shift it, but bring some benefits. And so some of those benefits are things like, um, multi-cloud. So, because PKS runs on top of Bosch, the same layer that the Elastic Runtime runs on top of, we automatically get multi-cloud. And what do we get? Well, we get things like Bosch is watching the nodes that make up the Kubernetes cluster so that if they go down, Bosch will recognize that and bring it back up. Well, some people would say, well, VMware does that. Well, yeah, VMware does it, but what about Amazon or what about GCP or what about OpenStack? And so Bosch does that across all of these different clouds. So, that's an advantage. Another advantage that you get by adding this abstraction is that we own the kernel.

So, even though you can bring some of your own operating system, root file system with you, we are at least bringing the kernel. And so, if there are kernel vulnerabilities that come in, we can take care of that for you. So, we are asking, we are with PKS adding another level of abstraction above the infrastructure, be it virtualized or, you know, be it VMware or AWS or GCP or any of those. So, we're asking you to bring another level of abstraction, but you would only do that if you got some benefits. And that's the cool thing is you get some benefits from that. And that's what we're focusing on with PKS is those benefits. Yeah, that's awesome. I mean, the other, remind me, Cornelia, I think that the other benefit of Bosch handling some of that recovery versus just straight up vSphere or even AWS is Bosch is aware of the role that that node played. So, it also knows how to properly recover it. It's not just spin the VM back up, but it might have to rejoin something. It might have to reattach a disk. Things like that. Am I right there? That's exactly right. And so, Bosch, because what you're doing with Bosch is you're not scripting things. Bosch, for those of you, you know, the listeners that don't know it, but Bosch, what you do is you describe a cluster. And you describe that topology and you describe the characteristics of that cluster. And that can include things like, well, these types of nodes depend on these other types of nodes. And so, you can characterize some order dependencies in there and those types of things. And that's something that doesn't necessarily exist and certainly doesn't exist in any kind of a standardized form across these different other infrastructure providers. So, absolutely, Bosch is a cloud-native way of managing clusters because it's declarative, it's eventually consistent, it's always watching the actual state versus the desired state, bringing them back into alignment.

The same things that we know and love in the ERT, Bosch does the infrastructure layer. Yeah, that's great. One of the, so speaking of VMware, you know, one of the key parts of PKS, and I'm sure some of your own work, has been kind of looking at how does PKS, which includes at least some add-ons or capabilities with these VMware components, can you kind of talk about what is that piece? You know, what does VMware bring to the table technology-wise with PKS? And I guess, alternatively, if you weren't using those pieces, what would you do? Yeah. Oh, I'm so excited to talk about this. So, VMware is bringing a number of things. So, Kubernetes brings some really great capabilities. So, when you deploy workloads into a Kubernetes cluster, Kubernetes will watch those workloads. Exactly that eventually consistent model that I just talked about, actual state versus desired state. If you lose one of those workloads, so if you lose a pod, it will recognize that it'll bring the pod back up, it'll reconnect things the way that it needs to, and all that, for the workloads that are running in the Kubernetes cluster. What PKS, of course, does is it's watching the Kubernetes cluster itself. So, Kubernetes is watching the workloads, we're watching Kubernetes, so we need to make sure that Kubernetes is staying up and running. But then there's a lot, again, that doesn't come with Kubernetes, so you can, for example, request the logs be brought together from a bunch of different nodes, you know, the same workload, different instances of the workload. But you don't, you can't do that, but you can't do that, but you can't do that in any kind of a streaming way. So, you have to do that yourself. So, if you wanted to do an aggregated log where you did searching across that and you wanted to have that constantly streaming, you have to bring that log yourself, that logging capability yourself.

One of the other things that's keenly important to our enterprise customers who are doing container images is that we have, as an industry, we've learned that this idealistic viewpoint that we had two or three years ago of, hey, Docker images are great because the developer can just create the image and hand it over to prod and it'll run exactly the same way. Everybody's come to this realization that, oh, yeah, well, I can't just take anything that a developer creates and run it on my production systems. It needs to be, I need to make sure that it doesn't have any vulnerabilities in it because they now have a lot of control. Like I said, they even bring their own root file system. And so, making sure that, for example, the images that we're running on our environment have been checked, that they're okay to run on prod, so that they've been scanned, for example. And there's technology out there that scans Docker images to look for known vulnerabilities. So, there's a lot of things that you need to add on to Kubernetes. And VMware brings a whole host of those. They have, for example, logging. So, they have vRealize operations. And there is a huge community of people that are power users of VR ops. And so, they know how to use that. And so, connecting Kubernetes, the workloads and the clusters into VRO ops or into Wavefront, which, again, we've got lots and lots of people who are power users of these monitoring products. So, VMware brings that, and PKS automatically connects into that. They are bringing something called Harbor, which is an image registry. But it's an image registry with vulnerability scanning built into it so that you can, as soon as something's dropped into the registry, it's scanned. And it's only once it's scanned and been okayed will you be allowed to deploy things into production.

So, they're bringing a whole host of, you know, like management and operational capabilities that they're so good at. But I've saved the best one for last. And I just happened to have spent the last week really studying this in more detail. And that's NSXT, software-defined networks. So, as we know, in the enterprise, a great deal of security is implemented into the network layer. And we hear these stories of thousands of firewall rules that expand into tens or hundreds of thousands of actual, you know, in-the-switch rules that are being implemented into the network. And so, they're using an awful lot of network segmentation to achieve policies and access control and various other security things. And we all know that management of those firewall rules and those subnets and things like that is a really difficult process. And that's where software-defined networking has really impacted the market a great deal lately. Now, put that together with deploying things into containers. Well, Kubernetes, for example, well, there's, so let's think about Kubernetes and think about breaking that up into tenants. So, I've got lots of workloads. That's the whole point of containerized stuff is that we've got lots of workloads that we're deploying into hosts. And the host becomes a shared resource. And we've got lots of containers that are running in there, but we need them to be segregated. And so, and the segregation, the point of segregation are tenants. Well, there's a couple of different ways that you could segregate that. Number one, Kubernetes has a notion of a namespace, which is their way of segregating, taking a single Kubernetes cluster and breaking it down into individual tenants.

Another thing that you can do that PKS is doing is that you can actually have independent clusters. You could say one cluster is for this tenant, another Kubernetes cluster is for this other tenant. So, PKS is going to support that. What we are doing with NSXT is that the easy button is when I create a tenant abstraction, we will automatically create the virtual switch. And I'm not a network expert, so I'm going to sound a little bit like I know. I know enough to be dangerous, but we create the networking abstractions to create that segregation, so that segmentation. So, we do micro segmentation automatically. So, when you create a tenant in this Kubernetes space, we automatically invoke the NSXT system to create the right abstractions and the right tenancy at the network level as well. And that's the NSXT product just totally rules. And the integration of these two systems, what we're going to be doing is bringing something into the market that just doesn't exist. Wow. That's pretty cool. You sold it. So, whether you feel like an expert or not, I totally buy what you're laying down there. I have to admit that I did spend many, many hours last week studying. I felt like I was back in school. I have to study this networking thing. So, we talked about, like, some, like, you know, existing applications and a few other things. But, like, what are the other types, the profile of application or workload that you would imagine people, either they should put in PKS or they want to put in PKS? Like, what, how should people think about what they put where, essentially? So, I think that's a great question. And we, as you have both pointed out, I've been spending a lot of time talking to customers and been hearing about these workloads. And just recently, in fact, a couple of weeks ago at CF Summit, did a talk on workloads.

And it was in preparing for that talk that I took all of these anecdotes that I was getting from literally dozens of customers and dozens of conversations and trying to organize that in some way. And what I ended up doing was I ended up finding, and we talk a lot about workloads. And when we say, what are the right workloads, kind of our knee-jerk reaction is to say, well, what is the architecture of the application? That was kind of our going in knee-jerk response, which is to say, okay, well, if it's not cloud native. So, for example, I've got workloads that need a little more persistent state, so they're not stateless. Or I have workloads that have fixed identity, so I can't, so, for example, if you deploy something in the ERT, and either because of some catastrophic event or some kind of a crash, or just simply an upgrade, we're upgrading all the nodes, and we recreate some app instances, they get different identities. They get a different IP address. They might be exposed on a different port. Those types of things. And those are the characteristics of really cloud native applications. So, when we think about, okay, well, what are the workloads that I'm running on IaaS today that I want to be able to up-level into this? Like I said, one of the axes that we kind of naturally gravitate to is, what are the architectural considerations of the application? But it actually turns out, and that's absolutely important, and we look at that. But there's another one as well, which is your software delivery lifecycle. So, is this something that you are cycling very, very frequently? Or is this something that, as we talked about earlier, some of these traditional workloads, where I'm not cycling it as often? And so, if we take those two axes, and we actually draw them in kind of the Cartesian plane, you know, those of us who know Pivotal know that we like two-by-twos.

So, if I put one of those, like workload on one axis, and I put software delivery lifecycle on the other axis, we've now got four quadrants. And one of those, in two of those quadrants are cloud-native applications. So, cloud-native applications that are either getting released all the time, and I have an active DevOps team or dev team that is constantly releasing new versions of this. That's where the ERT, the existing Cloud Foundry product, really shines. And that product is all about developer productivity as well as operational efficiency. But developer productivity is certainly one of the killer features that we get out of that, killer outcomes. If you've got a cloud-native workload, and maybe you're not releasing it every week, it's pretty stable, you're releasing it every month or two months or quarterly or whatever the case may be, there's still a lot of value in using the ERT because you get those operational efficiencies. You've got the watchdogs, you've got the monitoring that's built in, LoggerGator, you know, all of those types of things. So, there's no reason that you shouldn't do that. It's when we get to the non-cloud and cloud-native workloads that we now look again at the, is this something that's cycling all the time, or is this something that's relatively stable? If we look at the relatively stable, what's interesting there is that today, the way that organizations bring those relatively stable, infrequently changing code bases, they sometimes call it promote them into upper environments, it's a rather lengthy process. It can take weeks or sometimes a couple of months to go through all of the approvals to promote something into those upper environments. So, that kind of cadence allows you to say, well, okay, what I'm now doing is I'm creating images for that. Instead of that whole process, that six- or eight-week process happening directly against infrastructure, let me do that against building my container image.

Now, I've got an image that's been approved, and I can just stamp those out, and I get some operational benefits on that. So, that's a cool thing. And then, the last quadrant is kind of theoretical. It says, okay, well, I'm trying to release things frequently, but it's a traditional workload, so maybe I've got a little bit more of a bespoke environment. That one's tricky in that, again, going back to the theme of Kubernetes doesn't bring all of that opinionation with you. That means you have to bring that opinionation to yourself. You've got to create your standardized base images. You've got to create your pipelines. Gee, that starts sounding a lot like a stem cell in a build pack, but you've got to bring that all yourself. So, to kind of sum it up, to circle back on the question that you were asking, which is we look at workloads, but then we also look at the software delivery lifecycle. And both of those things are really interesting attributes for us to look at as we're deciding where things should land in the whole platform, the choice of platforms and the choice of different dial tones that you have. Yeah. That's a great answer. That makes sense. Yeah. So, one of the last questions I have for you, Cornelius, one of the talking points we had at VMworld, and Sam Ramji mentioned others, I think it was constant compatibility, this idea of keeping PKS kind of in sync, if you will, with the Kubernetes version in GKE. Can you kind of explain that concept and at least some of our thinking around that, why that's differentiating? Yeah. So, constant compatibility means that, so let me back up. Let me start with this. First of all, PKS is built on top of an open source project that we've been calling Kubo. And just a couple of weeks ago at the CF Summit in Europe, the Cloud Foundry Foundation said, okay, we've got a new name.

And I'm kind of sad because Kubo is seriously the best project name that I have worked on in my 30-year career. I know. It just rolls off the tongue. It's just so cool. Uh-huh. So, I'm a little sad. I still call it Kubo. But they're now calling it Cloud Foundry Container Platform? Container Runtime, I think? Container Runtime. There you go. See, it doesn't roll off the tongue as well. But it's an open source project. And what it does is it creates the Bosch artifact. It takes open source Kubernetes and it bundles it in such a way that Bosch can do its deployment and management of that Kubernetes cluster. So, it's creating a Bosch packaging, if you will, of that. And then PKS is built on top of that. It's a commercialized version of that. But it's fundamentally built on this open core, which is exactly what we did with Cloud Foundry with the Elastic Runtime. And it's not a fork of it. It is built on top of that. And it gives you kind of that. It gives you turning the crank. It gives you the provisioning engine. And it gives you all sorts of additional kind of operational capabilities on top of the open core. And so, the way that that's structured, what that means is that the open source project, what we used to call Kubo, and I'll keep calling Kubo because I'll botch the name again otherwise, is that when a new version of Kubernetes comes out, we have the engineering muscle and all of the pipelines and all of the test cases to be able to turn the crank. And the reason that we call out constant compatibility with GKE is that we realized that Kubernetes is an open source.

It's an open source project, but it's a open source project, but it's heavily dominated by Google. It has a great deal of involvement from Google. And GKE, of course, is the commercialized version of Kubernetes running on GCP. And so, given that both of those sides are Google, when Kubernetes is coming out with a new version, GKE is already at the ready. So, they can very quickly turn their crank and say, oh, a new version of Kubernetes? Within a couple of days, here it is available on GKE. Because we're partnering so closely with Google on PKS, we are in the know as well. So, it's both being in the know, but it's also having the architectural structure and the engineering machinery in place to be able to turn the crank so that as soon as there's a new version of Kubernetes, it's essentially available to you. So, you can upgrade your PKS, you can upgrade your PKS, and have that new version available immediately. And by the way, of course, we know from Bosch that it's rolling upgrade, zero downtime, all of that great stuff. So, on the one hand, you can think of constant compatibility as saying, hey, well, if I can run a workload in GKE, then I should be able to bring it over to PKS and run it there, and vice versa. But it's as much saying, well, you know what, GKE sets a pretty high bar, and we're going to be able to meet that bar. We're going to be at that bar with them. And so, we're constantly compatible with GKE. Some of the other, you know, 100 different Kubernetes, you know, packagings of Kubernetes that are out there on the market today, we've heard from some of our customers that are trying some of those out that it takes three months from the time that a new Kubernetes version comes out before it's available in a new release of that commercialized offering.

So, that's a bar that we're setting for ourselves and for our customers. It's kind of an SLA that we're giving to our customers saying, we will turn the crank quickly, and you will always be able to get the latest version. So, before we wrap up on a related to you, but somewhat different topic. So, tell us about the book you're working on. If I remember, there's like a preview version that's printed out and everything. Like, what's the topic of it? How is it? Yeah. So, the topic is on cloud native. So, as I mentioned in my intro, I've been working on Cloud Foundry for five years and working on cloud native applications and been so lucky to be part of kind of this movement of really figuring out even what cloud native means. And I spend a lot of time out talking to customers about this, and so I am delighted to have this opportunity to kind of scale that, to be able to share what I know and love about cloud native with a broader audience. And so, I am working with Manning on producing this book. And it's interesting, I'm a first-time book author, and so I'll tell you that the book that I started working on about a year ago is different than the book that I'm writing now. It has evolved. I've learned how to be an author, and I've changed the table of contents several times. The content, by and large, is the same. It's just, as I've started writing, I've organized it in different ways. And it's fundamentally, I guess you could think of it, it's not a programming book, although there's programming examples throughout it. It's more of an architecture book. But what it does is, first, let me define what I mean by cloud native. So, there's a difference between cloud and cloud native. Cloud, arguably, is the internet. And so, you could say, I'm going to the cloud, and you could say, I'm taking my workloads that are running inside of my own data center, and I'm now going to go get the same abstractions I've been working with there, which is hosts and storage networks and all of that stuff.

And I'm just going to use Amazon's versions of those. So, I'm going to go to EC2, and I'm going to go to S3, and I'm going to go to block storage, and I'm going to leverage all of those things. That's cloud. Cloud native, to me, fundamentally gets down to two things. Cloud native workloads are more distributed than they ever have been. Distributed systems have been around for decades. But the distributed systems that we used to work on were relatively easy to kind of get into our heads. We deployed maybe three hosts. And yes, we had to deal with distribution across those hosts, but it was really kind of carefully orchestrated. Now, we are talking about hundreds or thousands of app instances. We are talking about deploying things into these areas where, am I deploying into Oregon or am I deploying into Virginia? Sometimes I don't even know. I don't even care. So, it's more distributed than ever before, and that distribution becomes more invisible to us. So, I like to say cloud native workloads are highly, highly distributed. The other thing is that they're constantly changing. And that change ranges everywhere from the infrastructure changing because something goes down or I'm upgrading, I'm patching a vulnerability. It's constantly changing. So, cloud native workloads are workloads that run well in this environment of highly distributed and constantly changing. So, you have to do things in your software and in your architectures to make sure that I can be tolerant to those changes. And it's some of the things that we've even touched upon throughout this conversation of, like, it's best if you don't have to depend on the same identity every time you bring up a node. Because you know what? That IP address, we get a great gain if I can just serve up IP addresses and then give up those IP addresses and let somebody else use them.

IP addresses are limited. There's still limited in the number of IP addresses that you can have, so you want to be able to reuse them. And so, there's certain patterns. And so, the first three chapters of the book, and that's what's available as an e-book that's sponsored by Pivotal and also available as a mini book, a physical mini book, kind of gives you the rationale of let's understand what cloud native means and why we care about these architectural patterns. And then the rest of the book, which is about another 10 chapters, covers things like, okay, well, how does application configuration change in this cloud native setting? How does, how do we deal with state? Because our big A applications, our digital products still have state. And you're telling me my apps have to be stateless, so how do I deal with that? So, it talks about those types of architectures. It talks about event-driven versus request response. There's a whole chapter on that that's actually available in early access at the moment. So, it's teaching you kind of those architectural tenets. Anyway, so, do you know when that's going to come out so you can reveal the other 10 chapters? Yep, so, like I said, the first three chapters are available. You can go to the Pivotal website and get those in electronic form or if you see us at some kind of a show, we have physical copies that you can get. The five chapters are already available at Manning.com or is it Manning Books? I should know that. So, at the Manning Books website. The first five chapters are already available. So, you know, book publishing is just like a software in that release early and often. And so, we already have released five chapters and we will be releasing another chapter about every, honestly, every six weeks or so. And I'm hoping to have the whole, the complete volume done and have my weekends back by next summer, honestly.

But we're releasing the chapters as we go along. So, then finally, as I recall, you get to have some influence over the delightful woodcut on the cover. So, what's the explanation of that person that you selected for it? Yeah, so, it's interesting. So, being a woman in technology, the first thing was it was a no-brainer to say I'm putting a woman on the cover. Because we are technologists and we belong in this industry. So, that part was easy. And then the way the process went was that Manning sent me, you know, you know that Manning, their thing for their covers is they have kind of period figures and historical figures. And they're not famous figures. They're just figures that come from various regions on the globe at various time periods. And I didn't do anything, I wasn't targeting a specific time period or a specific region. I was really just going on kind of what kind of feeling did I get from the candidates that they put before me. So, they sent me three and I didn't care for them. They sent me another dozen or so. And the funny thing is that the woman who's on the cover, she's a little bit more senior than some of the other individuals that they sent to me. In other words, she's a little older like I am. And it wasn't so much that I wanted to have a figure that kind of had gray hair like I have. And you can't see her hair anyway. It's wrapped up. What I start, what really gravitated, why I really gravitated to her was that she has a certain piece about her. Like she's seen some stuff and she is leveraging kind of that experience but is still very curious and engaged and open to change. And that's what I felt from her. And that's why I chose her was that here was somebody who's seen some stuff and who is delighted and engaged for the future.

And that's what I felt from her and that's why I chose her for the cover. Yeah, I knew there would be a little back story there. That's very well thought out. Well, great. Well, thanks for being on. This is helpful, interesting stuff. It's been really a delight. Thank you so much. Sure thing. So as always, this has been Pivotal Conversations. If you want to get the most recent episodes, you just go to soundcloud.com slash Pivotal Conversations. So there's no underscore or, you know, percent 20 or whatever in there. You can also, about every Thursday, we post the extensive show notes and I'll try to put as many links to stuff we've talked about in there over at pivotal.io slash podcast. And also, come the first week of December, if you're interested in this and many other topics, including I've been looking at the sessions, plenty of topics of people who actually use this who aren't us pivotal people, customers, if you will, you should come check out SpringOne Platform, which is going to be in San Francisco. It's going to be a really good show. And as I recall, you can go to springoneplatform.io and if you check in the show notes, you can get a $200 off discount code, if you're into that kind of thing. But with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.