1 00:00:00,000 --> 00:00:02,720 Well, I think it was maybe a couple months ago, maybe a month. 2 00:00:02,820 --> 00:00:03,800 I've lost track of time. 3 00:00:04,540 --> 00:00:12,580 But we had an announcement here around Pivotal that we were adding in the Pivotal Container Service, or PKS, as is cleverly named. 4 00:00:13,240 --> 00:00:24,240 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. 5 00:00:24,240 --> 00:00:34,080 And so, finally, after a flurry of important conversations, getting work done announcements, we have Cornelia on to talk about that. 6 00:00:34,240 --> 00:00:36,060 You want to introduce yourself briefly, Cornelia? 7 00:00:37,120 --> 00:00:37,640 Sure. 8 00:00:37,900 --> 00:00:38,480 Thanks, Coté. 9 00:00:39,160 --> 00:00:40,700 My name is Cornelia Davis. 10 00:00:40,840 --> 00:00:43,620 I have been with Pivotal since the Pivotal spinoff. 11 00:00:44,820 --> 00:00:55,180 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. 12 00:00:55,500 --> 00:01:02,100 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. 13 00:01:02,920 --> 00:01:10,960 And, of course, being EMC and Cloud Foundry was getting incubated at VMware, I was really digging into Cloud Foundry. 14 00:01:10,960 --> 00:01:20,760 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. 15 00:01:21,060 --> 00:01:30,120 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. 16 00:01:30,120 --> 00:01:44,220 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. 17 00:01:44,900 --> 00:02:00,300 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. 18 00:02:00,880 --> 00:02:03,500 And that's exactly the role that I'm playing now with PKS. 19 00:02:03,820 --> 00:02:11,200 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? 20 00:02:11,300 --> 00:02:14,140 What's the value that we can bring them with this new product? 21 00:02:14,600 --> 00:02:15,320 Yeah, that's right. 22 00:02:15,380 --> 00:02:27,100 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. 23 00:02:27,260 --> 00:02:29,460 And then occasionally, it's good to do something. 24 00:02:29,640 --> 00:02:33,440 So, you come back and do more of the product direction and things like that. 25 00:02:33,820 --> 00:02:35,520 At least that's what I've noticed over the years. 26 00:02:35,520 --> 00:02:44,340 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? 27 00:02:44,500 --> 00:02:46,100 Or is my memory a little messed up? 28 00:02:46,180 --> 00:02:46,540 Oh, yeah. 29 00:02:46,540 --> 00:02:47,540 That is so funny. 30 00:02:47,640 --> 00:02:48,600 That's way back when. 31 00:02:48,820 --> 00:02:49,340 So, yeah. 32 00:02:49,460 --> 00:03:03,240 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. 33 00:03:03,400 --> 00:03:10,780 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. 34 00:03:11,500 --> 00:03:16,980 So, that was web-based collaboration, document sharing, but more than that. 35 00:03:17,160 --> 00:03:21,200 And then it was acquired by Documentum in 2002. 36 00:03:21,700 --> 00:03:28,800 And then almost exactly a year later, Documentum, which of course is content management, was acquired by EMC. 37 00:03:29,240 --> 00:03:30,420 So, that's how it came to EMC. 38 00:03:31,080 --> 00:03:36,940 And so, for the last 18 years, I've worked for four different companies, but it's all been through acquisitions and spinoffs. 39 00:03:37,160 --> 00:03:37,300 That's right. 40 00:03:37,360 --> 00:03:46,920 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. 41 00:03:47,020 --> 00:04:01,580 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. 42 00:04:01,800 --> 00:04:03,240 But, yeah, that was always fun. 43 00:04:03,680 --> 00:04:04,320 That was good stuff. 44 00:04:04,400 --> 00:04:06,360 Anyhow, enough of the memories. 45 00:04:07,960 --> 00:04:09,700 Lots of the good stuff. 46 00:04:09,860 --> 00:04:10,300 That's right. 47 00:04:10,620 --> 00:04:11,040 That's right. 48 00:04:12,400 --> 00:04:12,760 Awesome. 49 00:04:13,180 --> 00:04:16,600 Yeah, so I thought we would kind of talk a little bit more about your journey. 50 00:04:16,700 --> 00:04:20,680 One thing I was – you and I have gotten to work together a little bit on the PKS work. 51 00:04:20,760 --> 00:04:28,340 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. 52 00:04:28,340 --> 00:04:42,920 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. 53 00:04:43,160 --> 00:04:48,060 I have to kind of remap that part of my brain of how to deploy apps or to run things. 54 00:04:48,260 --> 00:04:51,220 Anything kind of interesting on Kubernetes that's really stuck with you? 55 00:04:51,940 --> 00:04:53,400 Oh, most definitely. 56 00:04:53,840 --> 00:04:56,900 And so let me share this kind of anecdotally with you. 57 00:04:56,900 --> 00:05:00,480 So I think, Richard, you know that I'm writing a book. 58 00:05:00,880 --> 00:05:09,900 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. 59 00:05:10,500 --> 00:05:13,880 And so the book is called Cloud Native, and I'm writing it with Manning. 60 00:05:14,780 --> 00:05:21,980 And I had written some stuff earlier in the year before I was working on Kubernetes. 61 00:05:22,680 --> 00:05:26,540 And there was an example where I deployed it to Cloud Foundry. 62 00:05:27,360 --> 00:05:30,320 And what I was demonstrating was statelessness. 63 00:05:30,640 --> 00:05:36,180 And so it really doesn't matter what the specifics of the example were, but I needed multiple instances. 64 00:05:36,420 --> 00:05:44,840 And so I transitioned from running that code locally to running it on a platform that has automatic load balancing, for example. 65 00:05:45,480 --> 00:05:47,580 And so I had pushed it into Cloud Foundry. 66 00:05:47,820 --> 00:05:49,980 And it was, as we know, super simple. 67 00:05:50,280 --> 00:05:56,160 I had compiled my Java code into a jar file, and then I did a CF push and pointed to my jar file. 68 00:05:56,380 --> 00:05:58,180 And that's all I had to do. 69 00:05:58,700 --> 00:06:06,400 And so just recently, in fact, last weekend, so a little more than a week ago, I was like, you know what? 70 00:06:06,800 --> 00:06:09,600 I want to do this on Kubernetes because I'm now working on PKS. 71 00:06:10,080 --> 00:06:12,480 And so I want to go through that same exercise. 72 00:06:13,240 --> 00:06:22,740 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. 73 00:06:22,800 --> 00:06:28,280 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. 74 00:06:28,980 --> 00:06:30,620 And I was like, okay, great. 75 00:06:30,720 --> 00:06:32,160 Now I'm ready to push this Kubernetes. 76 00:06:32,360 --> 00:06:35,620 And I was like, oh, wait, I need a Docker build file. 77 00:06:36,340 --> 00:06:38,540 Because I can't just push a jar file. 78 00:06:38,980 --> 00:06:41,280 I actually have to push a container image. 79 00:06:41,280 --> 00:06:43,300 So I have to create that container image. 80 00:06:43,900 --> 00:06:44,300 Right. 81 00:06:44,680 --> 00:06:45,460 Okay, good. 82 00:06:46,080 --> 00:06:47,820 So create the Docker file. 83 00:06:47,920 --> 00:06:49,660 And I'm like, okay, I deploy it to Kubernetes. 84 00:06:50,520 --> 00:06:51,940 And now what's my endpoint? 85 00:06:52,860 --> 00:06:54,720 Oh, right. 86 00:06:55,160 --> 00:06:59,420 I need to actually expose it specifically as an endpoint. 87 00:06:59,860 --> 00:07:06,100 And depending on the Kubernetes deployment that I'm running on, I happen to be running on Minikube. 88 00:07:07,180 --> 00:07:11,040 I need to figure out, well, where's that load balancer going to come from? 89 00:07:11,120 --> 00:07:13,560 Because it's actually not part of Kubernetes at all. 90 00:07:14,340 --> 00:07:16,940 So Minikube brings its own load balancer. 91 00:07:17,120 --> 00:07:22,700 So when you expose something as a service, so it's a Kubernetes call to say expose this as a service. 92 00:07:22,840 --> 00:07:28,860 But then it leverages something on the outside of Kubernetes to actually give you that endpoint and that load balancing. 93 00:07:28,860 --> 00:07:35,120 And none of it was particularly difficult to do because the tools like Minikube make it easy. 94 00:07:35,660 --> 00:07:46,640 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. 95 00:07:46,740 --> 00:07:49,100 I now have to do a little of my own yak shaving. 96 00:07:49,900 --> 00:07:50,540 That's funny. 97 00:07:50,760 --> 00:07:53,620 Yeah, I mean, it's kind of built on that. 98 00:07:53,860 --> 00:07:56,760 So now you could listen to that answer and go, oh, good Lord. 99 00:07:56,900 --> 00:07:58,560 Like, why would anyone want to do that then? 100 00:07:58,600 --> 00:08:05,760 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. 101 00:08:06,120 --> 00:08:10,360 So, I mean, when you've, you know, you've been amazing talking to so many different customers. 102 00:08:10,520 --> 00:08:13,840 This is not just an ivory tower product we're building with PKS. 103 00:08:14,380 --> 00:08:18,040 It's legitimately based on tons of feedback and market understanding. 104 00:08:18,140 --> 00:08:21,260 But what problems are you hearing the most this is meant to solve? 105 00:08:21,300 --> 00:08:29,540 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? 106 00:08:30,540 --> 00:08:33,640 Yeah, it's interesting, and it really depends on the customer. 107 00:08:33,640 --> 00:08:46,640 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. 108 00:08:47,040 --> 00:08:53,460 Literally thousands of application instances out running in production, mission-critical production workloads. 109 00:08:54,580 --> 00:09:02,200 And even there, and the people, but it's a large organization that has literally thousands of developers in it. 110 00:09:02,520 --> 00:09:07,780 And those developers who have embraced Cloud Foundry are delighted with it. 111 00:09:07,840 --> 00:09:16,920 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. 112 00:09:16,920 --> 00:09:29,060 And so there are some organizations, even within that company, that have created their own yak shaving foundries, if you will. 113 00:09:29,560 --> 00:09:43,420 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. 114 00:09:43,920 --> 00:10:00,540 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. 115 00:10:00,680 --> 00:10:02,020 That does exist. 116 00:10:02,680 --> 00:10:23,140 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. 117 00:10:24,140 --> 00:10:36,400 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. 118 00:10:37,500 --> 00:10:49,880 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. 119 00:10:49,920 --> 00:11:00,020 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. 120 00:11:00,520 --> 00:11:04,040 I wish I had one app that I needed to run. 121 00:11:04,580 --> 00:11:19,500 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. 122 00:11:20,420 --> 00:11:28,940 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. 123 00:11:28,940 --> 00:11:39,980 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. 124 00:11:40,540 --> 00:11:50,800 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. 125 00:11:50,800 --> 00:11:57,760 And it's probably workloads that they don't even, they aren't really doing a lot of development on anymore. 126 00:11:58,500 --> 00:12:00,020 It's, they're kind of in maintenance mode. 127 00:12:00,120 --> 00:12:02,900 They don't have an active DevOps team on it. 128 00:12:03,260 --> 00:12:13,480 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. 129 00:12:13,480 --> 00:12:15,140 They don't get released every week. 130 00:12:15,140 --> 00:12:24,760 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. 131 00:12:25,960 --> 00:12:26,640 Yeah, that makes sense. 132 00:12:26,780 --> 00:12:38,140 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. 133 00:12:38,400 --> 00:12:51,400 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? 134 00:12:52,060 --> 00:13:03,620 And then kind of thinking about your story of, I wanted to deploy some stuff to redeploy some things to Kubernetes. 135 00:13:03,620 --> 00:13:27,140 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. 136 00:13:28,140 --> 00:13:37,180 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. 137 00:13:37,180 --> 00:13:47,420 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. 138 00:13:47,520 --> 00:14:00,380 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. 139 00:14:00,700 --> 00:14:09,160 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. 140 00:14:09,400 --> 00:14:20,660 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. 141 00:14:20,660 --> 00:14:31,640 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. 142 00:14:31,640 --> 00:14:47,340 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. 143 00:14:47,560 --> 00:15:01,820 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. 144 00:15:01,820 --> 00:15:04,720 And in fact, it allows them to, uh, scale up more efficiently. 145 00:15:05,920 --> 00:15:06,320 Yeah. 146 00:15:06,480 --> 00:15:17,460 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. 147 00:15:17,460 --> 00:15:23,680 I mean, what Netflix has done and they've open source now is a framework that standardizes the way that things work. 148 00:15:24,180 --> 00:15:24,620 Exactly. 149 00:15:24,920 --> 00:15:33,700 Um, so, so it, they, they definitely have adopted those standards, but I love your point around the standards and it's really interesting. 150 00:15:33,880 --> 00:15:37,560 This is where PKS brings in a different angle. 151 00:15:37,560 --> 00:15:41,940 So on the ERT, and that's what I'm calling it at the moment. 152 00:15:41,940 --> 00:15:47,800 So what we've called cloud foundry or PCF in the past, I, I'm very careful to call that the elastic runtime. 153 00:15:48,020 --> 00:15:51,720 So that's the place where you do the CF push and the things we know and love there. 154 00:15:51,720 --> 00:16:12,740 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. 155 00:16:12,740 --> 00:16:24,660 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. 156 00:16:24,760 --> 00:16:26,220 It's actually trying to make your life easier. 157 00:16:26,780 --> 00:16:33,780 Um, now, when we move over to PKS, PKS definitely brings in an element of standardization. 158 00:16:34,020 --> 00:16:48,860 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. 159 00:16:48,860 --> 00:16:59,340 So having at least a single container platform where we can deploy the Kubernetes subsystem, we, you can deploy your apps against it. 160 00:16:59,340 --> 00:17:09,960 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. 161 00:17:10,280 --> 00:17:28,760 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. 162 00:17:29,140 --> 00:17:40,920 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. 163 00:17:41,820 --> 00:17:46,460 And so some of those benefits are things like, um, multi-cloud. 164 00:17:46,920 --> 00:17:59,100 So, because PKS runs on top of Bosch, the same layer that the Elastic Runtime runs on top of, we automatically get multi-cloud. 165 00:17:59,540 --> 00:18:00,680 And what do we get? 166 00:18:00,880 --> 00:18:12,820 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. 167 00:18:12,820 --> 00:18:15,360 Well, some people would say, well, VMware does that. 168 00:18:15,900 --> 00:18:22,900 Well, yeah, VMware does it, but what about Amazon or what about GCP or what about OpenStack? 169 00:18:23,480 --> 00:18:27,200 And so Bosch does that across all of these different clouds. 170 00:18:27,620 --> 00:18:28,720 So, that's an advantage. 171 00:18:29,320 --> 00:18:35,480 Another advantage that you get by adding this abstraction is that we own the kernel. 172 00:18:35,960 --> 00:18:44,840 So, even though you can bring some of your own operating system, root file system with you, we are at least bringing the kernel. 173 00:18:45,260 --> 00:18:49,380 And so, if there are kernel vulnerabilities that come in, we can take care of that for you. 174 00:18:50,080 --> 00:19:04,180 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. 175 00:19:05,040 --> 00:19:10,620 So, we're asking you to bring another level of abstraction, but you would only do that if you got some benefits. 176 00:19:10,920 --> 00:19:13,240 And that's the cool thing is you get some benefits from that. 177 00:19:13,500 --> 00:19:16,320 And that's what we're focusing on with PKS is those benefits. 178 00:19:17,280 --> 00:19:18,160 Yeah, that's awesome. 179 00:19:18,560 --> 00:19:29,520 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. 180 00:19:29,700 --> 00:19:31,660 So, it also knows how to properly recover it. 181 00:19:31,720 --> 00:19:34,620 It's not just spin the VM back up, but it might have to rejoin something. 182 00:19:34,700 --> 00:19:36,020 It might have to reattach a disk. 183 00:19:36,400 --> 00:19:36,920 Things like that. 184 00:19:36,960 --> 00:19:37,400 Am I right there? 185 00:19:38,300 --> 00:19:39,620 That's exactly right. 186 00:19:39,620 --> 00:19:45,420 And so, Bosch, because what you're doing with Bosch is you're not scripting things. 187 00:19:46,100 --> 00:19:53,260 Bosch, for those of you, you know, the listeners that don't know it, but Bosch, what you do is you describe a cluster. 188 00:19:53,740 --> 00:19:59,220 And you describe that topology and you describe the characteristics of that cluster. 189 00:19:59,940 --> 00:20:06,180 And that can include things like, well, these types of nodes depend on these other types of nodes. 190 00:20:06,700 --> 00:20:12,640 And so, you can characterize some order dependencies in there and those types of things. 191 00:20:12,640 --> 00:20:23,160 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. 192 00:20:23,160 --> 00:20:40,780 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. 193 00:20:41,460 --> 00:20:45,440 The same things that we know and love in the ERT, Bosch does the infrastructure layer. 194 00:20:46,220 --> 00:20:46,860 Yeah, that's great. 195 00:20:47,380 --> 00:21:02,980 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? 196 00:21:02,980 --> 00:21:07,460 You know, what does VMware bring to the table technology-wise with PKS? 197 00:21:07,780 --> 00:21:10,760 And I guess, alternatively, if you weren't using those pieces, what would you do? 198 00:21:11,480 --> 00:21:11,780 Yeah. 199 00:21:12,720 --> 00:21:15,060 Oh, I'm so excited to talk about this. 200 00:21:15,580 --> 00:21:18,520 So, VMware is bringing a number of things. 201 00:21:18,520 --> 00:21:24,380 So, Kubernetes brings some really great capabilities. 202 00:21:24,940 --> 00:21:30,500 So, when you deploy workloads into a Kubernetes cluster, Kubernetes will watch those workloads. 203 00:21:30,680 --> 00:21:36,040 Exactly that eventually consistent model that I just talked about, actual state versus desired state. 204 00:21:36,280 --> 00:21:45,260 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, 205 00:21:45,260 --> 00:21:48,200 and all that, for the workloads that are running in the Kubernetes cluster. 206 00:21:48,200 --> 00:21:53,060 What PKS, of course, does is it's watching the Kubernetes cluster itself. 207 00:21:53,940 --> 00:22:02,240 So, Kubernetes is watching the workloads, we're watching Kubernetes, so we need to make sure that Kubernetes is staying up and running. 208 00:22:03,740 --> 00:22:24,600 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. 209 00:22:24,600 --> 00:22:28,060 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. 210 00:22:28,540 --> 00:22:29,880 So, you have to do that yourself. 211 00:22:29,880 --> 00:22:40,920 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. 212 00:22:41,480 --> 00:22:57,700 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, 213 00:22:57,700 --> 00:23:05,940 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. 214 00:23:06,520 --> 00:23:14,520 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. 215 00:23:14,880 --> 00:23:21,080 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. 216 00:23:21,220 --> 00:23:23,400 Like I said, they even bring their own root file system. 217 00:23:24,540 --> 00:23:37,660 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. 218 00:23:37,740 --> 00:23:42,160 And there's technology out there that scans Docker images to look for known vulnerabilities. 219 00:23:42,820 --> 00:23:45,940 So, there's a lot of things that you need to add on to Kubernetes. 220 00:23:46,940 --> 00:23:49,920 And VMware brings a whole host of those. 221 00:23:50,800 --> 00:23:53,160 They have, for example, logging. 222 00:23:53,400 --> 00:23:55,100 So, they have vRealize operations. 223 00:23:55,880 --> 00:24:02,620 And there is a huge community of people that are power users of VR ops. 224 00:24:03,320 --> 00:24:05,600 And so, they know how to use that. 225 00:24:05,720 --> 00:24:17,800 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. 226 00:24:17,800 --> 00:24:23,520 So, VMware brings that, and PKS automatically connects into that. 227 00:24:24,180 --> 00:24:30,140 They are bringing something called Harbor, which is an image registry. 228 00:24:30,360 --> 00:24:38,720 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. 229 00:24:38,880 --> 00:24:46,080 And it's only once it's scanned and been okayed will you be allowed to deploy things into production. 230 00:24:46,740 --> 00:24:52,000 So, they're bringing a whole host of, you know, like management and operational capabilities that they're so good at. 231 00:24:52,220 --> 00:24:54,340 But I've saved the best one for last. 232 00:24:55,020 --> 00:24:59,220 And I just happened to have spent the last week really studying this in more detail. 233 00:24:59,220 --> 00:25:03,820 And that's NSXT, software-defined networks. 234 00:25:04,880 --> 00:25:13,060 So, as we know, in the enterprise, a great deal of security is implemented into the network layer. 235 00:25:13,060 --> 00:25:27,620 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. 236 00:25:27,620 --> 00:25:38,540 And so, they're using an awful lot of network segmentation to achieve policies and access control and various other security things. 237 00:25:39,400 --> 00:25:46,580 And we all know that management of those firewall rules and those subnets and things like that is a really difficult process. 238 00:25:47,000 --> 00:25:53,220 And that's where software-defined networking has really impacted the market a great deal lately. 239 00:25:53,220 --> 00:25:59,500 Now, put that together with deploying things into containers. 240 00:26:00,460 --> 00:26:07,180 Well, Kubernetes, for example, well, there's, so let's think about Kubernetes and think about breaking that up into tenants. 241 00:26:08,280 --> 00:26:10,460 So, I've got lots of workloads. 242 00:26:10,640 --> 00:26:18,040 That's the whole point of containerized stuff is that we've got lots of workloads that we're deploying into hosts. 243 00:26:18,080 --> 00:26:20,640 And the host becomes a shared resource. 244 00:26:20,640 --> 00:26:25,160 And we've got lots of containers that are running in there, but we need them to be segregated. 245 00:26:26,700 --> 00:26:33,660 And so, and the segregation, the point of segregation are tenants. 246 00:26:34,040 --> 00:26:36,500 Well, there's a couple of different ways that you could segregate that. 247 00:26:36,800 --> 00:26:46,020 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. 248 00:26:46,580 --> 00:26:53,300 Another thing that you can do that PKS is doing is that you can actually have independent clusters. 249 00:26:53,740 --> 00:26:58,600 You could say one cluster is for this tenant, another Kubernetes cluster is for this other tenant. 250 00:26:59,080 --> 00:27:00,980 So, PKS is going to support that. 251 00:27:02,460 --> 00:27:16,580 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. 252 00:27:17,420 --> 00:27:21,500 And I'm not a network expert, so I'm going to sound a little bit like I know. 253 00:27:21,560 --> 00:27:30,700 I know enough to be dangerous, but we create the networking abstractions to create that segregation, so that segmentation. 254 00:27:31,000 --> 00:27:33,440 So, we do micro segmentation automatically. 255 00:27:34,000 --> 00:27:47,060 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. 256 00:27:47,440 --> 00:27:52,340 And that's the NSXT product just totally rules. 257 00:27:52,960 --> 00:27:57,880 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. 258 00:27:58,720 --> 00:27:58,840 Wow. 259 00:27:58,960 --> 00:27:59,520 That's pretty cool. 260 00:27:59,660 --> 00:28:00,400 You sold it. 261 00:28:00,560 --> 00:28:03,480 So, whether you feel like an expert or not, I totally buy what you're laying down there. 262 00:28:04,140 --> 00:28:07,480 I have to admit that I did spend many, many hours last week studying. 263 00:28:07,880 --> 00:28:09,260 I felt like I was back in school. 264 00:28:09,440 --> 00:28:11,180 I have to study this networking thing. 265 00:28:12,680 --> 00:28:17,280 So, we talked about, like, some, like, you know, existing applications and a few other things. 266 00:28:17,340 --> 00:28:29,220 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? 267 00:28:29,720 --> 00:28:33,320 Like, what, how should people think about what they put where, essentially? 268 00:28:34,640 --> 00:28:36,340 So, I think that's a great question. 269 00:28:36,520 --> 00:28:45,620 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. 270 00:28:45,620 --> 00:28:50,380 And just recently, in fact, a couple of weeks ago at CF Summit, did a talk on workloads. 271 00:28:50,820 --> 00:29:03,100 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. 272 00:29:04,060 --> 00:29:08,760 And what I ended up doing was I ended up finding, and we talk a lot about workloads. 273 00:29:08,880 --> 00:29:17,040 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? 274 00:29:17,720 --> 00:29:23,760 That was kind of our going in knee-jerk response, which is to say, okay, well, if it's not cloud native. 275 00:29:23,760 --> 00:29:31,220 So, for example, I've got workloads that need a little more persistent state, so they're not stateless. 276 00:29:31,500 --> 00:29:45,760 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, 277 00:29:45,760 --> 00:29:54,720 or just simply an upgrade, we're upgrading all the nodes, and we recreate some app instances, they get different identities. 278 00:29:55,280 --> 00:29:56,920 They get a different IP address. 279 00:29:57,080 --> 00:29:58,820 They might be exposed on a different port. 280 00:29:59,160 --> 00:30:00,240 Those types of things. 281 00:30:00,360 --> 00:30:04,300 And those are the characteristics of really cloud native applications. 282 00:30:05,560 --> 00:30:13,440 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? 283 00:30:13,880 --> 00:30:22,120 Like I said, one of the axes that we kind of naturally gravitate to is, what are the architectural considerations of the application? 284 00:30:22,780 --> 00:30:27,780 But it actually turns out, and that's absolutely important, and we look at that. 285 00:30:27,780 --> 00:30:33,760 But there's another one as well, which is your software delivery lifecycle. 286 00:30:34,880 --> 00:30:39,660 So, is this something that you are cycling very, very frequently? 287 00:30:40,420 --> 00:30:47,700 Or is this something that, as we talked about earlier, some of these traditional workloads, where I'm not cycling it as often? 288 00:30:48,720 --> 00:30:57,840 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. 289 00:30:58,380 --> 00:31:07,760 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. 290 00:31:08,760 --> 00:31:16,040 And one of those, in two of those quadrants are cloud-native applications. 291 00:31:16,040 --> 00:31:26,060 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. 292 00:31:26,460 --> 00:31:30,920 That's where the ERT, the existing Cloud Foundry product, really shines. 293 00:31:31,620 --> 00:31:37,020 And that product is all about developer productivity as well as operational efficiency. 294 00:31:37,300 --> 00:31:42,620 But developer productivity is certainly one of the killer features that we get out of that, killer outcomes. 295 00:31:43,280 --> 00:31:58,780 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. 296 00:31:59,040 --> 00:32:04,560 You've got the watchdogs, you've got the monitoring that's built in, LoggerGator, you know, all of those types of things. 297 00:32:04,620 --> 00:32:06,420 So, there's no reason that you shouldn't do that. 298 00:32:07,060 --> 00:32:16,980 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? 299 00:32:17,620 --> 00:32:34,640 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. 300 00:32:34,640 --> 00:32:41,760 It can take weeks or sometimes a couple of months to go through all of the approvals to promote something into those upper environments. 301 00:32:43,100 --> 00:32:52,620 So, that kind of cadence allows you to say, well, okay, what I'm now doing is I'm creating images for that. 302 00:32:52,700 --> 00:33:01,480 Instead of that whole process, that six- or eight-week process happening directly against infrastructure, let me do that against building my container image. 303 00:33:01,800 --> 00:33:08,560 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. 304 00:33:10,200 --> 00:33:12,160 So, that's a cool thing. 305 00:33:12,300 --> 00:33:15,360 And then, the last quadrant is kind of theoretical. 306 00:33:15,600 --> 00:33:25,540 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. 307 00:33:25,860 --> 00:33:32,440 That one's tricky in that, again, going back to the theme of Kubernetes doesn't bring all of that opinionation with you. 308 00:33:32,700 --> 00:33:34,840 That means you have to bring that opinionation to yourself. 309 00:33:35,200 --> 00:33:37,420 You've got to create your standardized base images. 310 00:33:37,900 --> 00:33:39,460 You've got to create your pipelines. 311 00:33:39,980 --> 00:33:46,460 Gee, that starts sounding a lot like a stem cell in a build pack, but you've got to bring that all yourself. 312 00:33:47,260 --> 00:33:57,780 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. 313 00:33:58,020 --> 00:34:09,320 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. 314 00:34:10,160 --> 00:34:10,600 Yeah. 315 00:34:10,600 --> 00:34:11,260 That's a great answer. 316 00:34:11,380 --> 00:34:11,920 That makes sense. 317 00:34:13,180 --> 00:34:13,380 Yeah. 318 00:34:13,700 --> 00:34:30,140 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. 319 00:34:30,280 --> 00:34:34,440 Can you kind of explain that concept and at least some of our thinking around that, why that's differentiating? 320 00:34:35,580 --> 00:34:35,960 Yeah. 321 00:34:37,140 --> 00:34:44,440 So, constant compatibility means that, so let me back up. 322 00:34:44,600 --> 00:34:45,600 Let me start with this. 323 00:34:45,940 --> 00:34:52,840 First of all, PKS is built on top of an open source project that we've been calling Kubo. 324 00:34:53,520 --> 00:35:01,300 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. 325 00:35:01,580 --> 00:35:07,900 And I'm kind of sad because Kubo is seriously the best project name that I have worked on in my 30-year career. 326 00:35:08,420 --> 00:35:08,740 I know. 327 00:35:08,760 --> 00:35:09,600 It just rolls off the tongue. 328 00:35:09,700 --> 00:35:10,460 It's just so cool. 329 00:35:10,960 --> 00:35:11,300 Uh-huh. 330 00:35:11,980 --> 00:35:13,160 So, I'm a little sad. 331 00:35:13,400 --> 00:35:14,680 I still call it Kubo. 332 00:35:14,980 --> 00:35:21,580 But they're now calling it Cloud Foundry Container Platform? 333 00:35:22,300 --> 00:35:24,600 Container Runtime, I think? 334 00:35:24,840 --> 00:35:25,740 Container Runtime. 335 00:35:25,820 --> 00:35:26,260 There you go. 336 00:35:26,360 --> 00:35:29,000 See, it doesn't roll off the tongue as well. 337 00:35:29,000 --> 00:35:32,480 But it's an open source project. 338 00:35:32,740 --> 00:35:36,920 And what it does is it creates the Bosch artifact. 339 00:35:37,380 --> 00:35:47,860 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. 340 00:35:47,860 --> 00:35:52,340 So, it's creating a Bosch packaging, if you will, of that. 341 00:35:53,980 --> 00:35:55,940 And then PKS is built on top of that. 342 00:35:56,020 --> 00:35:57,920 It's a commercialized version of that. 343 00:35:58,280 --> 00:36:05,340 But it's fundamentally built on this open core, which is exactly what we did with Cloud Foundry with the Elastic Runtime. 344 00:36:05,920 --> 00:36:08,540 And it's not a fork of it. 345 00:36:08,880 --> 00:36:10,960 It is built on top of that. 346 00:36:11,080 --> 00:36:12,300 And it gives you kind of that. 347 00:36:12,720 --> 00:36:14,220 It gives you turning the crank. 348 00:36:14,220 --> 00:36:16,680 It gives you the provisioning engine. 349 00:36:18,000 --> 00:36:23,000 And it gives you all sorts of additional kind of operational capabilities on top of the open core. 350 00:36:23,840 --> 00:36:45,420 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. 351 00:36:45,420 --> 00:37:15,400 And the reason that we call out constant compatibility with GKE is that we realized that Kubernetes is an open source. 352 00:37:15,400 --> 00:37:19,560 It's an open source project, but it's a open source project, but it's heavily dominated by Google. 353 00:37:20,020 --> 00:37:22,320 It has a great deal of involvement from Google. 354 00:37:23,520 --> 00:37:29,920 And GKE, of course, is the commercialized version of Kubernetes running on GCP. 355 00:37:31,540 --> 00:37:41,020 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. 356 00:37:41,740 --> 00:37:46,060 So, they can very quickly turn their crank and say, oh, a new version of Kubernetes? 357 00:37:46,500 --> 00:37:49,880 Within a couple of days, here it is available on GKE. 358 00:37:51,160 --> 00:37:58,080 Because we're partnering so closely with Google on PKS, we are in the know as well. 359 00:37:58,080 --> 00:38:14,380 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. 360 00:38:14,920 --> 00:38:24,700 So, you can upgrade your PKS, you can upgrade your PKS, and have that new version available immediately. 361 00:38:24,980 --> 00:38:30,160 And by the way, of course, we know from Bosch that it's rolling upgrade, zero downtime, all of that great stuff. 362 00:38:31,120 --> 00:38:43,080 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. 363 00:38:43,700 --> 00:38:52,060 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. 364 00:38:52,060 --> 00:38:54,400 We're going to be at that bar with them. 365 00:38:55,300 --> 00:38:58,220 And so, we're constantly compatible with GKE. 366 00:38:58,840 --> 00:39:19,080 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. 367 00:39:19,460 --> 00:39:23,000 So, that's a bar that we're setting for ourselves and for our customers. 368 00:39:23,000 --> 00:39:29,540 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. 369 00:39:31,160 --> 00:39:35,220 So, before we wrap up on a related to you, but somewhat different topic. 370 00:39:35,360 --> 00:39:37,180 So, tell us about the book you're working on. 371 00:39:37,440 --> 00:39:42,160 If I remember, there's like a preview version that's printed out and everything. 372 00:39:42,360 --> 00:39:44,180 Like, what's the topic of it? 373 00:39:44,480 --> 00:39:45,040 How is it? 374 00:39:45,240 --> 00:39:45,560 Yeah. 375 00:39:45,560 --> 00:39:48,020 So, the topic is on cloud native. 376 00:39:48,440 --> 00:40:02,240 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. 377 00:40:03,240 --> 00:40:17,140 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. 378 00:40:17,720 --> 00:40:21,000 And so, I am working with Manning on producing this book. 379 00:40:21,520 --> 00:40:32,260 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. 380 00:40:32,740 --> 00:40:33,980 It has evolved. 381 00:40:34,260 --> 00:40:38,640 I've learned how to be an author, and I've changed the table of contents several times. 382 00:40:39,240 --> 00:40:41,180 The content, by and large, is the same. 383 00:40:41,300 --> 00:40:45,040 It's just, as I've started writing, I've organized it in different ways. 384 00:40:45,940 --> 00:40:52,760 And it's fundamentally, I guess you could think of it, it's not a programming book, although there's programming examples throughout it. 385 00:40:53,060 --> 00:40:55,160 It's more of an architecture book. 386 00:40:56,580 --> 00:41:00,620 But what it does is, first, let me define what I mean by cloud native. 387 00:41:00,620 --> 00:41:04,460 So, there's a difference between cloud and cloud native. 388 00:41:05,200 --> 00:41:07,320 Cloud, arguably, is the internet. 389 00:41:07,740 --> 00:41:14,600 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, 390 00:41:14,820 --> 00:41:23,380 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. 391 00:41:24,120 --> 00:41:26,900 And I'm just going to use Amazon's versions of those. 392 00:41:26,960 --> 00:41:34,040 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. 393 00:41:34,040 --> 00:41:34,800 That's cloud. 394 00:41:35,580 --> 00:41:39,800 Cloud native, to me, fundamentally gets down to two things. 395 00:41:40,580 --> 00:41:45,060 Cloud native workloads are more distributed than they ever have been. 396 00:41:45,280 --> 00:41:47,320 Distributed systems have been around for decades. 397 00:41:48,100 --> 00:41:56,080 But the distributed systems that we used to work on were relatively easy to kind of get into our heads. 398 00:41:56,280 --> 00:41:59,800 We deployed maybe three hosts. 399 00:42:00,520 --> 00:42:06,380 And yes, we had to deal with distribution across those hosts, but it was really kind of carefully orchestrated. 400 00:42:06,380 --> 00:42:11,300 Now, we are talking about hundreds or thousands of app instances. 401 00:42:12,000 --> 00:42:20,320 We are talking about deploying things into these areas where, am I deploying into Oregon or am I deploying into Virginia? 402 00:42:20,680 --> 00:42:22,060 Sometimes I don't even know. 403 00:42:22,320 --> 00:42:23,400 I don't even care. 404 00:42:23,860 --> 00:42:30,120 So, it's more distributed than ever before, and that distribution becomes more invisible to us. 405 00:42:30,300 --> 00:42:33,980 So, I like to say cloud native workloads are highly, highly distributed. 406 00:42:33,980 --> 00:42:36,720 The other thing is that they're constantly changing. 407 00:42:37,700 --> 00:42:48,220 And that change ranges everywhere from the infrastructure changing because something goes down or I'm upgrading, I'm patching a vulnerability. 408 00:42:48,640 --> 00:42:49,960 It's constantly changing. 409 00:42:51,140 --> 00:42:59,100 So, cloud native workloads are workloads that run well in this environment of highly distributed and constantly changing. 410 00:42:59,540 --> 00:43:08,260 So, you have to do things in your software and in your architectures to make sure that I can be tolerant to those changes. 411 00:43:08,920 --> 00:43:19,480 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. 412 00:43:19,920 --> 00:43:20,880 Because you know what? 413 00:43:21,120 --> 00:43:31,820 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. 414 00:43:31,820 --> 00:43:33,960 IP addresses are limited. 415 00:43:34,400 --> 00:43:39,240 There's still limited in the number of IP addresses that you can have, so you want to be able to reuse them. 416 00:43:39,840 --> 00:43:41,040 And so, there's certain patterns. 417 00:43:41,260 --> 00:43:57,340 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. 418 00:43:57,560 --> 00:44:07,860 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? 419 00:44:08,560 --> 00:44:11,680 How does, how do we deal with state? 420 00:44:11,920 --> 00:44:15,860 Because our big A applications, our digital products still have state. 421 00:44:16,160 --> 00:44:19,980 And you're telling me my apps have to be stateless, so how do I deal with that? 422 00:44:20,380 --> 00:44:23,020 So, it talks about those types of architectures. 423 00:44:23,160 --> 00:44:26,740 It talks about event-driven versus request response. 424 00:44:27,040 --> 00:44:31,080 There's a whole chapter on that that's actually available in early access at the moment. 425 00:44:31,560 --> 00:44:34,600 So, it's teaching you kind of those architectural tenets. 426 00:44:35,560 --> 00:44:41,220 Anyway, so, do you know when that's going to come out so you can reveal the other 10 chapters? 427 00:44:41,220 --> 00:44:46,760 Yep, so, like I said, the first three chapters are available. 428 00:44:46,920 --> 00:44:54,100 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. 429 00:44:55,080 --> 00:45:01,460 The five chapters are already available at Manning.com or is it Manning Books? 430 00:45:01,540 --> 00:45:02,320 I should know that. 431 00:45:02,540 --> 00:45:05,140 So, at the Manning Books website. 432 00:45:05,700 --> 00:45:07,820 The first five chapters are already available. 433 00:45:07,820 --> 00:45:14,680 So, you know, book publishing is just like a software in that release early and often. 434 00:45:15,540 --> 00:45:24,700 And so, we already have released five chapters and we will be releasing another chapter about every, honestly, every six weeks or so. 435 00:45:25,600 --> 00:45:33,140 And I'm hoping to have the whole, the complete volume done and have my weekends back by next summer, honestly. 436 00:45:33,280 --> 00:45:36,920 But we're releasing the chapters as we go along. 437 00:45:37,120 --> 00:45:44,920 So, then finally, as I recall, you get to have some influence over the delightful woodcut on the cover. 438 00:45:45,400 --> 00:45:49,780 So, what's the explanation of that person that you selected for it? 439 00:45:50,100 --> 00:45:52,000 Yeah, so, it's interesting. 440 00:45:52,260 --> 00:45:58,740 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. 441 00:45:59,900 --> 00:46:04,980 Because we are technologists and we belong in this industry. 442 00:46:04,980 --> 00:46:06,340 So, that part was easy. 443 00:46:07,220 --> 00:46:18,640 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. 444 00:46:18,900 --> 00:46:20,360 And they're not famous figures. 445 00:46:20,360 --> 00:46:26,680 They're just figures that come from various regions on the globe at various time periods. 446 00:46:27,600 --> 00:46:32,960 And I didn't do anything, I wasn't targeting a specific time period or a specific region. 447 00:46:33,080 --> 00:46:40,700 I was really just going on kind of what kind of feeling did I get from the candidates that they put before me. 448 00:46:40,800 --> 00:46:42,960 So, they sent me three and I didn't care for them. 449 00:46:43,020 --> 00:46:44,320 They sent me another dozen or so. 450 00:46:44,980 --> 00:46:53,300 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. 451 00:46:53,620 --> 00:46:56,440 In other words, she's a little older like I am. 452 00:46:57,340 --> 00:47:02,440 And it wasn't so much that I wanted to have a figure that kind of had gray hair like I have. 453 00:47:02,540 --> 00:47:03,940 And you can't see her hair anyway. 454 00:47:04,120 --> 00:47:05,160 It's wrapped up. 455 00:47:05,900 --> 00:47:12,960 What I start, what really gravitated, why I really gravitated to her was that she has a certain piece about her. 456 00:47:12,960 --> 00:47:27,740 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. 457 00:47:28,520 --> 00:47:30,220 And that's what I felt from her. 458 00:47:30,380 --> 00:47:38,380 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. 459 00:47:39,380 --> 00:47:42,760 And that's what I felt from her and that's why I chose her for the cover. 460 00:47:42,960 --> 00:47:45,440 Yeah, I knew there would be a little back story there. 461 00:47:45,740 --> 00:47:46,800 That's very well thought out. 462 00:47:47,760 --> 00:47:48,340 Well, great. 463 00:47:48,420 --> 00:47:49,340 Well, thanks for being on. 464 00:47:49,520 --> 00:47:52,060 This is helpful, interesting stuff. 465 00:47:52,840 --> 00:47:54,120 It's been really a delight. 466 00:47:54,240 --> 00:47:55,080 Thank you so much. 467 00:47:55,180 --> 00:47:55,740 Sure thing. 468 00:47:55,940 --> 00:47:58,200 So as always, this has been Pivotal Conversations. 469 00:47:58,400 --> 00:48:03,280 If you want to get the most recent episodes, you just go to soundcloud.com slash Pivotal Conversations. 470 00:48:04,320 --> 00:48:07,600 So there's no underscore or, you know, percent 20 or whatever in there. 471 00:48:08,000 --> 00:48:16,960 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. 472 00:48:17,820 --> 00:48:33,620 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. 473 00:48:33,880 --> 00:48:35,680 It's going to be a really good show. 474 00:48:36,260 --> 00:48:44,220 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. 475 00:48:44,680 --> 00:48:46,720 But with that, we'll see everyone next time. 476 00:48:46,980 --> 00:48:47,440 Bye-bye.