Well, I'm here in Paris for DevOx France, and the thing that I have noticed – now, I don't know why I ever doubt this, but pretty much everyone who's ever touched a computer knows who Josh Long is. I'm here helping to staff the booth, and people come up to me, and one of the first things they mention is like, oh, I'm here to see Josh Long. So that guy is – he's really doing his work around here. He's pulling his own weight. Yes. Very famous. Well, you know, we don't always have little ads here on the podcast, but there's a couple of things that I wanted to make sure we go over. One of them is that we – I wouldn't say we're in the thick of it, but we're in the thin edge of the beginning of the thickness of our cloud-native roadshows that we do here at Pivotal. I think there's been a couple of them already, but if you go to – well, we'll put a link to it in the show notes, but if you just look up Pivotal cloud-native roadshows, there's – I don't know, what would you say it is? There's so many cities that I can't really count them, but there's about 10 or 12 or so cities, many of them in North America, but there's also several in Germany and Europe and other locations. Throughout, let's say, into August, things going on where you can come and – I think it's basically like a two-thirds of a day event where you get some nice lunch and you get to hang out with some Pivotal people, some Google Cloud people, and they'll kind of in nice detail go over all sorts of things about what we mean by cloud-native and what we're doing here in the Pivotal and the Google space. But it's a good event to go look up, and it's in most major cities, but chances are, if you live in a larger city, definitely in the U.S., but also in some spots in Europe, you'll have a chance over the summer and early fall to go check out a cloud-native roadshow. Yeah, I think it's 25 total, 15 in the U.S., 5 Europe, 5 Asia. Oh, yes, I skipped over the coming soon in Amsterdam and Seoul and Tokyo, Hong Kong, Sydney, and Singapore. That's right. We're cloud-native wherever you are. That's right. That's a new motto. You must work in marketing. Well, so let's see. We also have – there's two other – there's spring days we have, right? When's that coming up? Yeah, spring days. So it's three cities, Chicago, New York, and Atlanta.
2:00So this is really – I mean, more of a user conference. This is people who are going to be talking about spring, get your spring fix in before SpringOne platform in December. So it starts in Chicago at the end of May. It'll be in New York in June, Atlanta in July. Should be fun. A couple days. Your aforementioned Josh Long will be there, which automatically means lots of screaming people and adoring fans. But we'd love to see, I think, more topics pitched. So you can do a submit for proposals or you can attend. Both are good ideas. Well, we have a returning guest on this episode. Do you want to introduce yourself briefly, returning guest? Yes, I am Jared Ruckel, returning guest to the Pivotal Conversations podcast. I work on the product team with Richard. And so we have you on nominally to talk about the new release that – was it just announced today, Richard? Yeah, it was announced a few hours ago. And so it's – we'll see how fresh I make this podcast once I post it. But sort of fresh off the release, we're going to go over what's in Pivotal Cloud Foundry 1.10, as I recall. But before we get to that, as usual, there's a few news items that you, the audience, may be interested in that we'll go over. And as always, feel free to, as the special guest, Jared, weigh in on what you think. But, you know, I like the first one you have because I hadn't found this reference for it yet. I've read the – I think the registers coverage and maybe the fabled Business Insider. But it looks like our buddies over at VMware have sold off their vCloud Air to OVH. Did I get that right? A big, coincidentally, French company. Yeah, I mean, I think it's switching to being more of a supplier of technology versus running it themselves. We saw that last year with some of the Amazon announcement and others. That seems like a decent trend. OVH apparently making a big push into the U.S. So, you know, it seems like a good match. And you just wonder as more and more there's just fewer people up for the capital expense of running a cloud. Yeah, and I think – I mean, there's a general consolidation of public clouds that we comment on here and there. But that seems to be, as they say, a thing that's going on.
4:02Yeah, I mean, we'll be probably talking a year from now and there will be four clouds, Google, Microsoft, Amazon, and Pivotal. Yeah, maybe one day we'll actually get to – was it Nicholas Carr or Benjamin Franklin who said, you know, soon there will only be one computer? I forget which one. But maybe there will just be the one URL in the cloud that we all go to, which will probably never actually happen. It reminds me of a – I think this was last week. There was also an interview with the CEO of Rackspace. And it was – as someone who, you know, has covered the public cloud space for quite some time, it was a notable thing along this trend where, you know, I think basically there's – I guess you could call it a downshifting of them, Rackspace, being a big public cloud competitor. Because they do also offer, like – they offer their – I don't know if it's patented so much as maybe trademarked fanatical support around helping you run Amazon. And there was an interesting part in the interview that's easy to look over where he goes over the idea that – I think the way Rackspace is thinking about OpenStack now is a lot more for private cloud running rather than being a public cloud sort of thing, at least for them. You know, maybe other people who run it would like to position in the public cloud. But it was a – I don't know how new. Maybe in the past year or so, it's a notable repositioning that Rackspace has in the cloud space. Yeah, they've been doing that for – I mean, they were the first one that I remember that kind of dropped straight up public cloud and saying, hey, we're going to focus a little more on managed services again. We're going to be focusing on multi-cloud things. And, you know, others have followed suit to some extent. But they were on the track with that. And obviously, even with this one, saying, look, the money is going to be in professional services whether you're even a Rackspace customer or not. That was – I thought interesting as part of that news that you don't have to be using Rackspace tech. You don't have to be an existing customer. We just want to help you adopt a cloud. Again, maybe a good strategy. It's definitely different. I think it just shows that most cloud providers have to diversify. So in other news, it looks like our friends at the Linux Foundation, they're almost like an all-consuming foundation nowadays.
6:07They keep taking on more and more things. It's a foundation of foundations. So, yeah, the Cloud Native Computing Foundation, which originally started with Kubernetes and then added Prometheus, I believe, for monitoring, kind of keeps adding more things under some stewardship. So, you know, there's GRPC, which I think Google had started with, some of this core DNS, others, just making it easier, I guess, to have some of these open-source projects with a little more coaching through their lifecycle, making sure there's a little bit more organization. Not a bad thing, as we all depend a heck of a lot more on open-source than ever before. So, Cloud Foundry Foundation, you know, Linux Foundation, Cloud Native Computing Foundation, we're all kind of under these banners of trying to make sure that open-source doesn't just flame out some of these interesting projects. Let's make sure that they get some good lift and, you know, we prioritize the right work. Yeah, and Bridget, she and I had a webinar where we kind of went over briefly the other thing that, sort of in Linux Foundation land, but the Cloud Foundry Foundation. They launched a developer certification program, and, you know, I was lucky enough to read some crib notes and everything, so I'm slightly informed of it. It's interesting to follow kind of an arc of a conversation that you can see at the CFF, the Cloud Foundry Foundation, they've been doing where, maybe you remember, but this is like three or four months ago, they had a survey about organizations doing cloud-native. And one of the major findings they had was that organizations were a little fearful of their ability to get the skills they need and staff that they have to do things in a cloud-native way. And so this is a – I'm remembering my days of strategy where you identify a problem that's preventing the world from being a way you like, and so you sort of work on a solution to get there, like having a certification program to train developers to have all those cloud-native skills that organizations feel are lacking. Yeah, you know, it's a pretty cheap exam to take. From the sounds of it, it takes four hours to do, which just means you're not as rigorous as a CPA or something, but at least you're a good cloud-native developer. And, you know, again, as you have a skills gap, as you're trying to figure out, how do you, first of all, vet existing people you're trying to hire?
8:08Like, are they paper experts? Do they actually do something? Do they know what they're doing? Hey, you might look for a certification. Or if you're just trying to up-level your own people, it'd be great to give them this to aspire to. It's not the end state. I think it seems like it's a nice proof point. I'm tempted to take this myself just to see if I actually know what I'm talking about, but I'm terrified of the result. On that note, so as I mentioned, we have a new Pivotal Cloud Foundry release out. And as is the way that we often do things, you actually could have gotten the bits, as they used to say in my day, I don't know how long ago, but we sort of quietly or soft released it. But today is the day that we had all of the fanfare and the ticketed parade. I think we're going to have to hire someone to go clean up the streets with all the ticker tape in our cyber streets, as it were. But Richard and I thought it would be great to – I think we did this last time also when 1.9 or 09 or whatever was out. But just to kind of get a brief overview of what's in this release and kind of the general themes of it and how things have been going in Pivotal Cloud Foundry land. Yeah, so I thought we'd chat with Jared about some of the major themes. We also somehow published about 19 blog posts and have a ton of content, a new product page. So we blitzed it. But I think it's good because this is – I mean, since I've been here, no doubt the biggest release we've done in the last year and probably for the last couple of years. So, yeah, I don't know if we start off with Jared. What are the headlines here for somebody looking at PCF 110? Well, that was one hell of a parade, by the way. So that was money well spent from the marketing budget. Elephant was excessive. It was. I think there's three themes that stand out. We've done a lot to improve this developer operator workflow, making it easier for those teams to work together and troubleshoot issues, get access to extensible data services, things of that nature. There's a second one there around security and compliance, which is always a really big area of focus for us in our product roadmap,
10:09given our focus on the Fortune 2000s. There's some things there to help customers with that. And then the last pillar is on Windows Server and .NET. A lot of people, of course, know Pivotal through our support of the Spring framework. So we have a lot of Java goodness going on. And we've been investing a lot the last year and a half or so to offer that same type of experience for the .NET and Windows Server crew. And there's some nice enhancements in this release for that crowd. So we look at kind of a stupid term, double click on some of those. So, I mean, we look at the first pillar or even let's look at the Microsoft one first. I know, Coté, you were interested in this as well. But as we think of what that means, and PCF supported Windows for a little while now. And both Jared and I worked at a company that first created some of the .NET extensions for Cloud Foundry years ago. But so we've supported it, but it's always been kind of a manual bolt-on. So why is this different now? Yeah, when operators are looking to really get that immutable infrastructure baseline for their modern applications, that's where some of the things with Bosch and Operations Manager come into play. There's always been some really strong tools there on the Linux side of the house. But on Windows, as you mentioned, Richard, there's a bit of a manual process that's there. And so now in this new release, there's an integrated, really nice user experience. There's a PCF for Windows tile that gets installed. And then from there, operators, system administrators can pave all these fleets of Windows servers in their data center and really manage it in a highly automated way in the same way that a lot of Linux administrators have been able to do for a while now. So there's a lot of goodness for the operators where they can start to get some of these cattle, not pets type of processes and methodologies for their applications running inside of Pivotal Cloud Foundry. I mean, it seems like a big deal because that has not been easy, from my experience, in the Microsoft space. And if you use Microsoft tools and System Center and others, you could manage and update and patch fleets of Windows servers.
12:12But these weren't application centric. This was like managing the VMs. And so I don't know of any platforms that treat Windows as just this sort of application set that I can patch and replace and update with zero downtime and containerizing support. This feels unique. I mean, I don't know if you see other things in market here, but it seems like we finally have a good home for .NET apps everywhere. Yeah. And certainly Microsoft, the Microsoft ecosystem has their own set of tools. But this is, I think, pretty unique in kind of how it's distinct from Microsoft and part of their, you know, overtures, the open source community. We've really, I think, embraced a lot of that and worked with Microsoft on a lot of these initiatives. And there's also a little bit of uniqueness, too, going back to the Java heritage that we have and our continued investments there with Spring, where when you can run Java and Windows on the same platform, the way that, you know, Pivotal Cloud Foundry really allows you to do in a really nice way. You get a lot of operational efficiencies without really compromising that developer experience. Developers can use the tool chains that allow them to build the best apps, use the right tool for the job. And because you're pushing to this platform, you get all these really great economies of scale and gets a really increased velocity on your applications, which is, you know, what we spend a lot of our time talking about. So now, you know, I'm a simple Java 1.4 caveman. I don't understand all these, like, vagaries of, like, new ways of doing stuff, let alone .NET things. But what I hear is, like, is this something beyond, like, .NET core stuff or whatever? Like, what does it mean to have, like, .NET support and Windows support? Is it just sort of, like, now you can do everything? Or is there some, like, new way of doing, like, .NET things? Like, what's the set of applications or stuff that it means you can now run in Pivotal Cloud Foundry? So we talked about some of the things where, as a, at Windows server, operators can run and automate all that kind of stuff. And so as a developer, you use the .NET framework, and it does get a little bit tricky to parse for us cave people.
14:15Microsoft has done a lot of open source, as we just mentioned. They have a way you can run some .NET applications on top of Linux VMs, and that's something called .NET Core. But there's a more sort of full-featured version that I think a lot of our customers have really been excited about and, you know, asked that the Pivotal product team kind of step up and invest in. And that's something called the hosted Web Core for .NET, which allows you to do the full, you know, the full complexity of .NET. And with that build pack, you can do that in Pivotal Cloud Foundry. So we have the .NET Core, the lightweight flavor for Linux VMs, and then the hosted Web Core .NET for the richer .NET experience on Windows VMs inside of Pivotal. So you get kind of both flavors depending on how much .NET you want to CF push. So if I remember a couple of things. One, Sir Richard was earlier sharing like a nice new, I don't know, tealy-colored diagram of what Pivotal Cloud Foundry looks like. And I think, so we, the two operating systems, you know, stripped down and pared down that you can now run in Pivotal Cloud Foundry. We have an Ubuntu variant, but now you can run that like stripped down Windows OS in there, which essentially enables all of the stuff you were just talking about. Yeah. Yeah, that's right. And when you go further deeper into the developer experience, there's another cool thing that we've done for .NET with our SteelToe open source project. It's now gone commercial where Pivotal customers are now entitled to use SteelToe. And they take a lot of these really popular microservices patterns from Spring Cloud services and extend them to the world of .NET. So it furthers some of that, you know, microservices tooling that have been popular on the Java side. And now you can do that same type of thing on the Microsoft side. Yeah, which is pretty nice. I mean, to your original question, Coté, I mean, if I'm using .NET Core is probably the future for Microsoft.
16:16They've invested a ton in that .NET framework on Windows. I don't believe has the same exciting future, but that's where all the apps are right now. So when you think about how do I move these apps that, sure, I should be able to run most traditional .NET apps now on PCF. But as I'm looking at how do I build more resilient cloud native ones, that's where SteelToe is kind of cool, where I can have a service registry. And look up services at runtime. Or I can have a get back config store to store all my sensitive values. I don't want to embed in my application code. Or I want connectors to things like RabbitMQ or Reddit. So it's a pretty cool library. These .NET devs are trying to get a little closer to the rest of this open source ecosystem and this sort of resilient pattern design. I think it's kind of neat that we're trying to create parity for all dev types and language becomes just a personal preference versus something that you're sacrificing dramatic functionality when you choose one language or the other. Yeah. Yeah. I mean, effectively, and we see this when we visit with large organizations and customers. I mean, there's, as you were kind of alluding to, there's just developers who want to develop software, right? They don't care what set of NASCAR logos are on the side. They just want to, like, deploy their software and have an enjoyable, productive time doing it. I think that's exciting stuff. I mean, you know, the other underrated piece with all these multi-polyglot stuff on PCF is that the experience is the same, as Jared pointed out. The CF pushes the same. They all get the same monitoring, the same auto-scaling, the same containerization logging. So nobody's a second-class citizen, which is unique because, again, sometimes you push to a certain platform and, well, these apps kind of get the special treatment. Here's some weird hooks to add so we can monitor your stuff or put this agent on your box. I haven't met a dev who wants to care about any of that. Like, just let me build good apps, and your machinery and your platform should take care of it for me. Absolutely. Well, that raises the other thing you mentioned, Jared, and something that I'm always – having worked at BMC Software doing systems management and monitoring, I'm always fascinated with the instrumentation of monitoring that people do. So why don't you give us a little overview of the sort of depth of monitoring-ness that we have in this release?
18:17Yeah, we have the PCF Metrics module that's part of the commercial subscription with Pivotal Cloud Foundry. I think this was introduced about a year ago, and there's been a really nice, steady drumbeat of enhancements to this module. A lot of our customers said, hey, Pivotal, this is where your applications – our applications run on your platform. This is really a problem that you guys need to go solve and give developers and operators a shared repository to draw information from – to troubleshoot and help figure out what's happening with the system. So we've added, you know, metrics and logs and events and had, you know, longer retention periods, really nice timeline views to understand how the element of time plays into this use case. I think the really cool thing in this new release is distributed tracing, which in some ways is maybe the secret sauce, if you will, for understanding microservices architectures, where you've got, you know, hundreds or thousands of services all interacting with each other. The complexity in the system is not in your source code. It's in how all those services are interacting with each other. That's well put. Yeah, and so with distributed tracing, you can see how a trace or actual almost like user flow or request goes through the system across all these different services, and you can understand where latency may have occurred, failures may have occurred, and it's a really interesting intuitive visual display so that, you know, any engineer at your company can probably do a pretty decent job of finding out what's going on in the system. And this, you know, makes every developer sort of a global troubleshooter, which is a nice thing to have. And also, a lot of these systems are so complex, there isn't really any one person that can understand end-to-end what's going on. So this is a really nice thing that is a little bit of the cherry on top for how you troubleshoot microservices. You talk to that team, they'll tell you there's much more left to be done still. But distributed tracing is a thing that this community has been, you know, looking at, you know, for a while,
20:20and there's various open source projects that people can use. And so now there's some of that, you know, commercial feeding and care that we're giving customers to make distributed tracing really straightforward. If y'all and the listeners will allow me a, I don't know, to perhaps dive too deeply into the monitoring cold pool, so to speak. Yeah, you know, I mean, there's three things that I was thinking about as I was looking over this. One is that, like, we can all agree that sort of, like, breadth and depth of monitoring, as you were talking about, is vital for, I don't know, the distributed applications that one does in a cloud-native environment, right? So inherently, all of the types of application development you do on top of Pivotal Cloud Foundry or any of these other cloud-native things are effectively distributed applications, which back when I was raised as a developer was sort of, like, I don't know, the ninth or tenth level of hell as far as, like, intellectual difficulty. But since then, we have filled in the pool of those levels, and now it's quite easy. But the ability to monitor those is always difficult, and so it's good to have the breadth and the depth of it. But I think I'll release this episode after this one, but Andrew Schaefer and I, we did another little book report episode about the Google SRE book. And there's a third thing that kind of, another one of these things that you intuitively know, but that especially at the scale of management and the speed at which people would be managing things running on Pivotal Cloud Foundry, that you kind of learn or intuit from that book, which is it's really handy to standardize on the way that you do your monitoring, which immediately comes out from how the Google SREs operate. And I think that's the part, I mean, honestly, I don't know how our customers and users are doing the following, but I think the intention is that, in addition to the partners that we have that will give you more in-depth look into doing your basic monitoring and systems management, but there is a standardized way of doing monitoring, and therefore figuring out how to troubleshoot and manage the applications that you have, which I think is pretty vital for the scale of distributed applications that our customers aspire to be using us for.
22:26Yeah, I mean, from what you even mentioned, Coté, from your old days of monitoring, it's just funny how the space has changed now. I mean, now I've got containers that live for a few hours. I've got no real versions anymore because I can never recreate the state of when things actually broke yesterday because all the components are different, and everything's asynchronous, multiple threads, multiple servers. So, like, the whole nature of what it even means to collect logs and recreate the situation is different. So, it's all got to be about how am I using, as you mentioned, either standardized tools or better visibility to quickly find out something bad happened, how do I fix it? And if you're slogging through logs on every individual machine and SSH-ing in and reading logs and, you know, trying to piece together how 14 microservices talk to each other, like, what a disaster that is. So, I think we've kind of seen someone here at Pivotal mentioned this to me. I don't know who to credit with it, but we've almost seen this interesting trajectory of, I want to build microservices. Great, there's Spring Boot. Okay, I'm trying to do things that are complicated. I don't know how to do that. Great, now there's Spring Cloud. Where the hell am I supposed to run this? Oh, great, there's Pivotal Cloud Foundry. Like, there's this natural progression that we're doing more complicated things to solve more interesting problems, but at some point, it's great to have a platform that's trying to simplify some aspects of it for you. Exactly. Yeah, and it must be, like, five or ten episodes back, but there's a, back at SpringOne Platform, there's a good episode I had with Marcin talking about Sleuth, and it's, you know, it's a part of this overall idea of how you do monitoring in Pivotal Cloud Foundry, but it's, that's a good overview of how, as an application developer, you can start to think about, as we would say in my day, instrumenting your applications or making it possible to easily manage and monitor your applications, which I think is, I, you know, that's another, is this true? Maybe not so widely talked about notion in the DevOps world of developers being very cognizant of how things are going to be monitored and managed in production, and from my old-timer perspective,
24:27you have the luxury of actually modifying your application to make it monitorable, which was not always the case. No, and correct me if I'm wrong, first of all, Jerry, I mean, I think, first of all, this is not Spring-specific, so if you want to do Node, you know, Java, Go, Python, those all work with tracing, but also I believe we kind of target the dev audience purposely with metrics. Like, we love the APM space, we love New Relic, Dynatrace, AppD, all these great partners who do some really rich app performance monitoring. I think the goal of metrics was also to help developers have a good tool, you know, I'm getting some nice insight into the platform, but it's almost a little more dev-centric, hasn't it been? Yeah, I think so, and you look at what the, what those, you know, SRE kind of roles are doing, you know, the lines are certainly, you know, blurred to a pretty strong degree, but, yeah, I think this is really for that, you know, developer kind of audience, and it's really geared towards, I think that the logs are the other thing that really stand out, where the system retains a lot of the logs that get thrown off the application. And so, again, for those, you know, brave souls that go on call, this makes their life just a little bit easier. So you made a, or Coté and I can tag team on this one, but as we look at the security stuff that we did, I guess I wanted to start with, you know, there's a few things there, but I wanted to start with some of the reference architecture work, because you actually co-authored some papers on this. Can you tell us a little bit about the genesis of why that relates to security and what these papers are? Yeah, there's the phrase, the frozen middle, that we like to throw around here a little bit. And the conversations with, you know, businesses and being able to do their software better, they've really shifted from why to how. And so there certainly aren't, you know, magic documents like PDFs or white papers that will, you know, solve that problem. But the reference architectures and the work that we've been doing to thaw that frozen middle should help a little bit with the how. So as we look at, you know, customers, once they've kind of, you know, bought into this whole cloud native idea, you know, it's sort of the now what, you know, kind of approach.
26:28So we talk about what's included in the platform, what you get with it, you know, why that stuff, you know, matters, how you deploy the platform on top of infrastructure, because, you know, VMware is different, Amazon, Microsoft, and Google are all different. And then taking a look at the actual applications themselves, how do you actually build a microservices app on top of this platform using, you know, Spring, Spring Cloud Services, things of that nature. So there's a look at all those different levels. And then we focused in on, again, security in some areas, namely in the on-premises data center with things like, you know, NSX and network virtualization that can really help kind of get buttoned up. So there's security compliance, you know, woven throughout those documents, especially since our big security, you know, motto is, you know, having it built in rather than bolted on later. So a couple of the tech features, I mean, you mentioned the VMware stuff and the NSX stuff, which is interesting. I guess, tell us a little bit about the kind of what that play is. Like, why does someone care that NSX and PCF are now BFFs, if I can add more acronyms? Yeah, this is a little bit of the confess your unpopular opinion kind of session where you talk about people that, you know, are building in on-prem data centers and private cloud. You know, you can make a really compelling economic argument for the on-premises data center when you've got, you know, a baseline virtualization layer, network virtualization, and then Pivotal Cloud Foundry on top of that. You've got some really good, you know, full stack automation there that you can rival a lot of the things that you do in the public cloud in terms of those advanced services. So when you have PCF and NSX and then the hypervisor layer with vSphere, things like that, you get a really compelling, you know, way to, again, breathe more life into your on-prem, you know, data centers for the next, you know, five, seven years or so. So I think that's really one of the big things in terms of the overall business case. And then when you get NSX and PCF together, life is just generally a lot easier because you get the same configuration. As you expand your PCF footprint, firewall rules get easier to manage.
28:31And then as organizations look to this zero-trust security model, it's easier to enforce those policies, you know, globally across the data center. In the past, there would be this notion of a trusted network and an untrusted network. In this day and age with complex architectures and microservices, you can't really have this trusted and not trusted type of approach. So if you assume that everything is not trusted, you're going to be a lot better off and a lot more, you know, have a better security posture. And so with software to find everything along the way, you really reduce your attack surface, if you will. Right. So one thing container networking folks can read up on, but the isolation segments always struck me as interesting. You want to kind of describe what that is, why that matters? Yeah. When customers want their applications, their data to be separated from other workloads inside of Pivotal Cloud Foundry, they'd have to spin up a whole other foundation, which is a little bit clunky for a lot of operators. It's a little bit harder to keep permissions in sync and just overall, it's a tax on the day-to-day running of the platform. Now, isolation segments, they can deploy an app to a specific set of VM hosts. So they can have a dedicated, you know, network to access those workloads. And then you get the logical isolation there for those apps, which is important for a lot of internal compliance standards and is oftentimes a key building block for PCI, for people that you keep track of credit cards and payment information. So it's a nice integrated tile, integrated into the command line interface and is integrated into the rest of the platform. So it gives you some of that isolation. And so now it just makes that element of running a platform day-to-day that much more straightforward. Now, if there's anything I'm dumber on than security, it's networking. So allow me to embarrass myself here. But so is that like isolation achieved through some sort of like router level, like, you know, strong arming to prevent like various services talking with each other?
30:34So you sort of set it up and there's basically like, as you say, you have one Pivotal Cloud Foundry foundation. So one cloud, if you will, but it's making sure that various types of services or network traffic doesn't really know about each other, even though it's running on the same hardware. Yeah, I mean, I think some of that's where, you know, network isolation comes into play. But the biggest feature is when I see a push, those workloads go to dedicated hardware. Right. So I can have these two servers that are PCI, these three that have some sort of GPU processing because I'm doing some weird batch jobs. And so I'm at least making sure that the host running the apps, that's not spanning the rest of the environment. You can also, again, do some routing isolation. But I believe it's really about giving some of that host level affinity. That's interesting because as you're alluding to, like, I often come across customers of ours who run multiple foundations. And I'm sure there's many logical reasons to do it. But it seems like the ultimate end goal and the happy future is that you would just have the one cloud that you're running everything in. And so getting closer to that always seems fantastic. You know, the other place I thought I'd quick zig and zag you for just a moment. One of the things that's maybe an underrated part of the release, but around persistent storage and volume services. So, you know, this idea of actually bringing stateful workloads to PCF. And, of course, all apps have state. You know, they're either in a database or a cache or object storage or whatever. But actually be able to have an NFS file mount available in my container to write logs to or migrate some existing app that expects a local file system, doesn't know what to do with object storage. That seems like a big deal. Does that, you know, as you were talking to even field people and getting people ready for this, did that click with folks? Are people excited about that? I think so. And it goes back to kind of what we talked about a little bit earlier with, you know, Java and .NET being able to run the same platform. A lot of the features that we add to the platform and a lot of what we hear from customers is help make Pivotal Cloud Foundry a big tent for all my applications. Even these ones that, you know, may not have, you know, the full 12-factor, you know, design principles or may not be API first or microservices first.
32:38And certainly this, these, you know, volume services, you know, fit that category of older things sitting in a data center, you know, most likely. And so, you know, a lot of customers say, I like how PCF treats these more modern applications. Is there a way you can help me with these other things that are maybe not so modern? And we always, I think, take this notion of lift and shift and say, you know, be careful with that type of approach. But now this is at least one more toolkit for the customer to pick and choose how they may want to decompose or break down some of these older things where there's now another option. And then once they embrace that option, they can have just that another class of application running on PCF and then take advantage of those developer and operator efficiencies from having a large platform that can run a wide range of applications, regardless of sort of, you know, what maturity model they're in, architecturally speaking. I mean, I know we think of that almost as cloud native storage if you do it right. So it's not just kind of putting workloads onto some sort of box that doesn't let you delete the containers because, hey, at least you'll be able to store the state. It's like, no, this should still kind of be a backing service, but let's make it one that's native to that sort of app. So, again, try not to compromise too much because we're trying to help people build more scalable apps. But bringing more of the natural constructs, I don't know, lowering the barrier to entry for some of those apps is one less thing you have to do when you refactor, if you want to refactor. That seems like that's handy. Yeah, especially when you have companies that are kind of now going all in on some of this, you know, platform ideas that we've been talking about. You know, we have, you know, done a nice job in helping companies get more modern, you know, middleware at the heart of their business systems. Certainly a lot of the greenfield new applications. You can't just take the fun stuff. There's some other things there, too, that you need to, you know, prioritize and build features for that are going to help the customer, you know, sort of along this, you know, longer digital transformation type of journey. I think that's a pretty good whirlwind tour of everything. Do you think, having toiled away, to use another SRE term, at documenting this, Jared, do you think there's anything that we're missing out on?
34:44Are there any favorite children that we're not addressing? I think that, you know, one of the hidden gems, you know, Richard mentioned this idea, is new APIs for our operations manager, you know, module. We talked about this a little bit earlier, getting a bit of a boost on the Windows side. There's a set of new APIs that are out there so that customers can essentially automate a lot more of what they're doing with the platform. They can automate the deployment of the platform itself. Customers want to do that. And we have a platform that can sort of be continuously deployed, you know, itself. So kind of a weird inception there thing to think about. But it's something that customers can do often. So these APIs will definitely help with that. And it also helps the customer redeploy, you know, tiles for, you know, add-on services or other components. And then, of course, their applications. So the APIs are kind of, you know, another one of those hidden gems I'd encourage people to take a look at. And for a lot of customers that have been, you know, long-time users of PCF, these will be, you know, welcome enhancements. Yeah, I know we're looking also for some feedback on people using container networking now, which is baked in. Like, we want feedback on that before it goes final, GA, beta, and this release. And then same with tasks. If you're doing one-off jobs in the platform, that's baked into Apps Manager. But we're looking for how customers want to use kind of one-off jobs. And we're introducing some cool new things in the next few weeks we'll talk about then. But as customers now are thinking of, you know, database migrations, alert notifications, you know, cash warm-ups. How do they want to use one-off jobs in the platform? You can do it now point and click. But, you know, as you as a customer listening or even you as a pivotal employee, use this stuff, give us feedback. It's going to help make it a better product. Well, so, Richard, you mentioned there's, what did you say, 15 to 30 blog posts on this topic? Yeah, not to mention all the documentation got repressed. There's some awesome new docs. There's a whole new pivotal.io slash platform page for PCF. So, yeah, there's, I think, six blog posts, plus one from VMware themselves on their blog. So, lots of great stuff.
36:44Yeah, no, that sounds good. Well, thanks for being on, Jared. I think it was a good overview of what we had. And, yeah, I mean, we'll put a link to the show notes to the, I don't know what you would call it, the main blog post, which references all the details on various things and a few other things we didn't detail out and has links to them. And there's, of course, the release notes, which I was reading through earlier today. I was thinking, like, I remember, again, being a Java 1.4 caveman, I used to get very excited when a new version of Eclipse would come out, and I would set aside some time to read through the release notes. It's a similar enjoyable experience if your life is as exciting as mine was back then. This is why lunch with you is always my favorite thing. That's right. That's right. What did we talk about? I'll release notes. That's right. And, Jose, it's the anchor blog post. We like to use nautical terms wherever we can. Ah, yes, the anchor blog post. Of course, because we're in the clouds. So the nautical terminology goes to space. That makes sense. Always be shipping, so the nautical metaphors abound. On that note, as always, this has been Pivotal Conversations. If you want to get the episodes as quickly as possible, the best thing to do is subscribe to the podcast feed, which you can find in iTunes or Overcast or wherever you might listen to these things. You can find that feed, if you don't deign to search in aforementioned podcast directories, by going to soundcloud.com slash pivotalconversations. And if you prefer to listen to things in web browsers, you can listen there, which is totally fine. Also, we post the show notes at pivotal.io slash podcast. And we'll have a link to the – I think the count's increased as we're talking. There's about 50 blog posts, right? There's an extensive write-up, all keying off the anchor, going over what's in this new feature. And with that, we'll see everyone next time. Now, just for a little Easter egg at the beginning, I want to throw – before we wrap up and I tell you where to get the podcast episode, I want to – since we're talking about space, so to bring it back here to DevOps, Paris, I've been hanging out with our friend Bob, who's on my team. And I was noting to him that it seems like in these space movies with long-term space travel,
38:46the people who work on the – you know, what do you call it? The stasis, like you get frozen in place for a 10-year journey? Anyways, sort of like in the same way that every character in a zombie movie has never actually seen a zombie movie, so they don't instantly realize that they're in a zombie movie and therefore should not approach the zombies. I feel like the chirostasis engineers haven't realized that every single time you freeze someone in space travel, at least one of the machines breaks, so they should pay more attention to it. So that's a message I want to get out to any future space travel people is spend a lot of time QAing your space stasis things because one of them is going to crack and all sorts of problems are going to happen. It makes sense. When they're studying our civilization 1,000 years from now, they will find this podcast. Exactly. They'll know that if there's a human stumbling around that's acting kind of odd, do not place your hand in its mouth. Pro tip. Or tap them on the shoulder and ask them if they're okay. Just keep your distance. And then make sure that the glass on your cryogenic space chamber doesn't crack. Just focus on that. Where do you live by?