Hello, everyone. Before we start, I just wanted to promote a few upcoming pivotal things through June, July, and August. We had the Cloud Native Roadshow coming to all sorts of cities. This is a free day-long event we do with Google that goes over what exactly Cloud Native is and how our customers are using pivotal and Google technologies and approaches. The cities, and this is a long list, so get ready. The cities are Stuttgart, Dallas, Denver, LA, Seattle, San Francisco, Amsterdam, Seoul, Hong Kong, Sydney, and Singapore. There's a big list of dates that you can look at. You can check out the show notes for a link to it, or if you just want to go and Google for Pivotal Cloud Native Roadshow, you'll find it pretty easily. We also have Spring Days Atlanta coming up July 18th and 19th. It's chock full of sessions for developers who want to learn more about the Spring Framework, Cloud Native style development, and of course, to be fully buzzword compliant, microservices. If you go to springdays.io, you can get more info, and that's the last Spring Days we're having so far that we have scheduled this year, so get that one in if you're over in grits and pork land. It'll be good stuff. Finally, while it's way in the future, we also have Spring One platform coming up December 4th and 5th. Now, registration just opened recently for this. I think you might have missed the early bird thing for it, but that's fine. There's also still the CFP open. It closes on September 1st. Now, what goes on at this conference? Well, it's full of what I would call the suit track and the technology track. In the suit track, you've got case studies and managers and developers as well, but organizations talking about how they've transformed their company and what they're doing with Cloud Native and their organizations, how they're getting good results by switching over to doing things in more of a pivotal way. But then there's also plenty of events for those of you out there who enjoy more nerding out and doing technical things to check out. I'm one of the chairs of the DevOps pipeline and monitoring track that we informally call it. We've already got lots of excellent talks queued up from the likes of Home Depot, Express Scripts, Allstate Northern Trust, and of course, plenty of pivotal people. I'll be speaking in that track if that's anything. So come on there. Again, it's in San Francisco, December 4th and 5th. And if you just go to springplatform.io, you can check it all out. And with that, enjoy the episode this week.
2:04Well, you know, I like to start with a little weather reporting every now and then. Richard, it's hot down here. We had July 4th, which I have discovered is our international, not international. It's the opposite. It's our national holiday of eating too much. So I think that's the taste of freedom. It's hot dogs, pork chops, steaks. But man, down here in Austin, it's like, I think we're finally near the, feels like 100 or so degrees every day. It's crazy. And if you have to be on a big slope that goes down to a lake, I mean, it had some nice St. Augustine grass, which I always wonder how that's related to, you know, one of the founding people of Catholicism, but that's a whole other podcast, I guess. But it had that grass and like, you got to go up and down there with the floats and, uh, and, and coolers. You ever had to like lift a cooler all the way up and down a hill while everyone is just like, why are we not drinking beer yet? And you're like, cause I got this gigantic cooler. I have to lift. That's right. Yeah. No, it's a, it's only 80 up here. So it's not nearly as bad as your, your Texas weather. Those coolers though, pretty awkward to carry, especially when they're, they're full of sloshing things. Yeah. Yeah. Luckily, luckily I like the kind of things that are heavy initially. And then as you have more fun throughout the day, you, you, the liquid disappears. And so it becomes lighter. I think, I think that that's paces well with, with the, the strenuous effort you want to put on things. That's right. Especially when your strength is faded at the end of a day of drinking and eating meat. Faded strength. That's right. Well, we have a guest on this episode. Speaking of the opposite of faded strength, I guess you want to, you want to introduce yourself, uh, briefly. Yeah, sure. So I'm on this, Duncan Wynn. I run the platform architecture team for the Pacific West and I've been in pivotal since, uh, pivotal kicked off. Uh, I used to run the field engineering team in EMEA and I've also done a stint in PCFS working for Dino. Now, now one of my favorite questions to ask field people is, is what exactly their region means. So what is Pacific West? So I cover everything up to Richard's area in Seattle, right down to San Diego. And then I cover
4:09over to Denver and Phoenix. So any customer in that geography. So, so it's like all of the West coast. Not all of the West, the West is broken into like the Midwest and Tola and Oh, I just, I just mean West coast. If it's all, if I mean, it's all, it's all of the West coast. Yeah. I mean, there's this American thing of West means more than just the West coast. I cover all of the West coast. Right, right. See, this is why I like asking it because I find the names fascinating in that they're a little, little quandary inducing, right? Pacific West coast, which implies the Pacific nature, but then if you have all of the Pacific side, it's just West coast. But then, like you said, it's not all of West. So I see how you would derive that it's Pacific is not so much a location as an adjective for which West. Basically. Yeah. You got it. Makes sense. Okay. I like that. I like coming up with reverse engineering, the schemes people came up with for naming schemes. It's a, well, I feel like I've earned my intellectual, uh, giblets for today, if you will. So, uh, speaking of giblets, right. No, no, no. All the holidays are running together. I think, I think the next one is, uh, we got labor day. Is that right? I think, right. I think we were now in the American drought of holidays. Like we had a bunch of them. Then labor day comes up and then, and then Thanksgiving. Am I forgetting something? Like a Halloween coming up then. And then Thanksgiving, but yeah, we're halfway through the year. Don't, don't start talking about it. Yeah. You guys are getting ahead of yourself. We still have to slog through the rest of the summer holidays. Seriously. Oh yeah. Yeah. There is, there is, you know, I, when I worked at Red Monk, uh, they were half European or, or maybe a third, depending on how you count, uh, James governor's dual nationality. And, uh, the babies, basically there was this policy of like, you should take August off, which seemed like a, uh, a good way to live. That, that was fun. Cause, and, and the reasoning professionally was sound. It was like, yeah, nothing really happens in August, at least for an industry analyst perspective. But you know, we'll see, we'll keep that in mind. So, uh, so back to
6:10the giblets. So you did, you did a fine job. You know, I, I, I've got another, I've got my software defined talk recording coming up this afternoon. And I was thinking like, man, not, not much has been happening, but you did an excellent job of rounding up some news, Richard. So, so what, what do you have for us? Giblet wise this week? Yeah, no, I keep an eye on it. So yeah, the first thing I listed was, uh, Google cloud expanded to Australia. They just added their Sydney region and Amazon keeps scaling. Microsoft keeps doing their crazy scaling. I think it's this, again, for me, reminder that it is nonstop that everyone is going to, this cloud providers are just relentlessly moving around the globe, adding new locations. You start to look at these maps and say, where don't I have coverage? Like, where do I have any incentive to use co-location or some of those other providers? Cause that used to be a regional play. Like, Oh, I'll use colo because they actually have a site here. It doesn't really apply as much anymore. So very interesting stuff. Good for Google. You know, they're playing catch up, but I like what they're doing there. That was the first one. I don't know if you see that Coté as well at Duncan. It just, it's, there's no end to insight. I mean, Amazon announces things the year ahead of time of where they're coming into the next country and region. It just seems like you're really chipping away at any benefits some of those regional providers had. Yeah. It's like you're saying that used to be a, uh, a theoretic point of differentiation for, uh, companies that wanted to compete against them. But nowadays it's just like, Oh, you just go open a data center. No problem. Which I shouldn't say no problem, but it is a, a standard operating procedure that you open all these regional data centers, which I suppose makes sense. Yeah. The, uh, second one I called out was Microsoft or it was leaked. And then I guess confirmed that Microsoft's doing a big reorg revamping some of their sales force. And there's probably, I mean, there's going to be some layoffs involved. It looked like they haven't confirmed the whole thing, but really a lot of this is they're rearranging around artificial intelligence around cloud. And I don't know. I think it's a reminder to the traditional sales. When you look at some of the traditional software vendors who would sell three years out of three-year enterprise agreements and
8:13some of these big deals, the world's changed to a subscription model where I'm, you know, I'm buying Azure credits and I'm buying and I'm bursting and I'm shrinking. And it's just a different way you sell. It's a different approach. So traditional sales forces, it's just a different game now. And Duncan, I don't know your experience. When we think about platform architecture and supporting sales, but I don't think it's the same anymore of necessarily, let's go play golf and sign big, large contracts. And we'll check back in a few years and see how you're doing. It seems like there's much more of a constant trusted advisor sales process. It's not just show up every now and then. And I get Microsoft just reflecting the reality. So A, I don't play golf. I'm horrendous at golf. I just don't have the patience to whack the ball back and forth over the whole 10 times. But yeah, I definitely see there's far more technical focus in the sale. Customers want to go right into the specifics very, very early on. They want to understand the value proposition. They want to delve in very deep. They're getting more technically savvy. There's obviously a lot of open source, so they can do a lot of groundwork upfront, reading around it. And yeah, it's just far more technical and more relational sale. Yeah. I would just see often see in my own time doing sales and otherwise, as you would just notice that there was, as you say, more, more technical skill. You would often walk into a customer who knew more about your product than you did just because it was so easy to research and use these things ahead of time. There weren't the software gatekeepers anymore. So anyway, good for Microsoft. You're probably important to shrink in that area and focus a little tighter. You sort of answered the question I was going to ask. I read some of those stories and like all sort of leak confirmed leak stuff. It's not like they got the 50-page planning document that was used by the Microsoft SVP of sales and just put it up there on SlideShare, right? So you get not all the details are in there. Is that an EVP or an SVP thing at Microsoft or a corporate vice president? They got all those types of vice presidents running around. But or at least back when I would go to their conferences, they would. And yeah, I mean, it is like when I see something like that, like I always
10:13wonder like exactly what the reorganization is and as not what it looks like, but like why you would need to reorganize. And I guess if the theory is you two are going over is that you have a lot more technical sales, then there's two points after that. One, I guess you need people who are more technical. So make sure you have that. And then I guess also the other thing is like that maybe there's a shift in the way that things like Office and Office 365 are sold, right? If they're, I don't know if this is true or not, but you know, if they're all more of a SaaS subscription, it's not like every individual goes there with a credit card to sign up. You still have your large accounts where you go negotiate some big deal with it. But, but maybe you have a different types of salesperson and the way it's, it's organized there. And then I guess, I mean, there's always things like, like comp plans and the way that you cover your region, speaking of Pacific West and all of that stuff. But it's, it's, it's interesting to see how people organize their sales force because that's, that's always highly indicative of the type of technology they're selling. And, you know, certainly having, having looked at the way that, that, that we do our sales force and technical field stuff, it, we, we morph around pretty quickly to match the way that the customers want to consume things, or I should say prospects want to think about what they're doing and then customers want to on go consume their stuff. And it seems like I'm repeating a bit of what y'all were saying, but it seems like, um, if you have a, a bunch of stuff that's sold as a SaaS, then more or less, there's like not really that much relationship to have there. It's like the SaaS either does what you want or not. And then you got to integrate it with some other stuff. And then you're going to negotiate some prices on either side, but it's not like, uh, there's a lot of work there. Like hopefully it's more of a no ops, so to speak situation. And then this leaves this bulk of stuff that you're going to manage and run on prem on your own. And then that's more of like, as y'all are saying, the more technical ongoing relationship of things, which
12:14I guess would necessitate changing around how you, uh, do your sales. If, if you are more application heavy than, uh, sort of like, I don't know, Heathkit toolbox heavy on what you were selling. Yeah. I mean, cloud disrupts everything, right? I mean, at this point, even Salesforce is how you do project planning, how you host software. And so why, why should sales be immune from it? So again, I think just a recognition of reality, which is sometimes good to see. Yeah. One of the other things I threw out here was a SpringOne platform coming up in December. That's the pivotal giant conference that we do all kinds of stuff. It's focused a lot on spring, but we also dip into the cloud foundry world and gem fire and all kinds of fun stuff. And I listed because we have a couple of great keynoters now. So Eric Brewer from Google who, you know, cap theorem fellow came up with all that great engineer, great mind. So really excited to have him speaking. And then also we got last week, uh, Eric gamma from Microsoft, a technical fellow there who was one of the founders of eclipse project. Also part of that gang of four design patterns book now works on the visual studio code and other teams at Microsoft. So just really cool to have some practitioners and some smart folks kind of bookending the conference and sessions are starting to come online soon. So just exciting to see a lot of people already signing up. And if you haven't already, and you're listening to this podcast, then, uh, get on that. I'm really looking forward to SpringOne platform and SpringOne has always been a very technical conference, great content, tons of fun. It was fantastic last year to have, um, the cloud foundry element to it as well with SpringOne. So yeah, I'm super excited. So it's very good stuff. So I think, you know, while, while I'm like, uh, helping chair one track now per my usual style, that doesn't mean I'm paying that much attention to anything, but, uh, like, like what's the schedule for like announcing talks and things like that? Or, or is there one like what, what can people look forward to there? Question. Yeah, we're still in the call public call for papers. We did a private one for some internal folks and customers first is to start filling out the schedule, but the public one I think closes in September. So keep getting your talks in specifically, if you've got some good
14:17stuff on security, uh, implementation patterns, things like that. But then we're going to be trickling out as, as teams like yourselves, Coté kind of approve talks. We're going to get, be getting those on the website. So all throughout the summer and then kind of a big push in August, September, you'll see a lot of talks, almost the final schedule go online. So constantly coming, you'll have a good sense of kind of the talks we're having, the tracks we're having, things like that, but it's going to be absolutely chock full. There's, there's just a ton of content. We've gotten a ton of submissions, which is great. So yeah, at the Duncan's point, it's a fun conference. It's a great group of people. And, uh, I learned a ton last year. I'm going to go as an attendee as much as an organizer this year. And if I remember the prerecorded ad thing that just played at the beginning of this episode, that the listeners were here, I think there's a, there's a discount in there and a little preview, at least of the talks that I know of, of, of what they are. So just rewind and then listen to all of our delightful talk about weather, uh, afterwards. Right. And then, and then you win, I guess enough people sign up a code. Hey, I think you win something, a trophy, a badge, something like that. I don't think with any of my signup codes for conferences, they've ever been used. So they're more, it's more, I look at it as just brand advertising, right? There's no, there's no whatever. I think someone told me that, uh, DevOps stays Minneapolis people. They use that code, which I don't, I don't know what happened. Some, some strange anomaly. Well, finally, I think, uh, the last thing you had is that, uh, over there, over there in Kafka land, they finally, uh, they found, uh, you know, the wooden cup or the Holy grail or whatever. So, so what's, what's up with this exactly once, uh, reliability they have or delivery. Yeah. Good, good stuff. So, I mean, the team who helped build Kafka and obviously there's the open source piece and the commercial piece they support, they made a big splash over supporting exactly once delivery in the new Kafka engine coming out. And so on one hand, it gets positioned in the story I linked here as like, ah, they achieved it. My gosh, kudos to everyone. This has never been done before because in some cases people say exactly once is impossible that you can't guarantee in a distributed system that the writer will only write the message one time.
16:18And then that consumer will only read it once because, Hey, the network could glitch or I could fail to process it when I started processing it. And then I get in a weird limbo state or all kinds of things can happen in a distributed system, but they put together a really good thing. We linked to a couple of the papers here, some really well-written explained pieces that there's some asterisks here. Like you've got to be using what they've built to kind of have the right publisher and how it's read. And if you fan out beyond what's kind of working in confluent land, you can't guarantee everybody else will only get it exactly once. So there's some caveats and other systems like Azure's event hubs have done some pieces like this for a while. Other systems have solved pieces of this, but exactly once is really tough and distributed systems. What I enjoyed the most was the spirited debates back and forth from folks. Cause you end up learning a lot of people who have some really cool experience in this space. So read up on some of those links. It's a, it's well worth your time. Now, now between the two of you, I'm interested in y'all's response to this. It seems like, uh, uh, you know, I remember there was this explosion of like no SQL stuff, which never minding all the semantics of that. There was this explosion of post-relational databases for everything, uh, going on. And like, I seem to most, I don't know if this is some bias on my part of whatever, but I seem to mostly only hear about Kafka and sometimes Cassandra nowadays. Like, are those like, is that kind of all that's going on around there or is there other things and, and like, like why what's, what's, what's been the story with all that, that y'all two encounter? I mean, tons of stuff in no SQL land besides Cassandra, you've got, obviously Mongo is still super popular. You've got all the kind of cloud specific things, whether that's to some extent, you know, DIMO DB in, in Amazon or Azure equivalents, Google equivalents for kind of unstructured sort of data. But then, you know, for messaging, that's where Kafka is gone crazy. And RabbitMQ continues to be arguably the most popular messaging engine in the world. So you're seeing more open source flavor for those things, no doubt about it versus, but then you look at the cloud things and Dynamos proprietary, you know, spanners, relatively proprietary in
18:19Google land, even though it's kind of SQL-y. So it's an interesting space. You don't have a lot of commercial software being shipped for around databases. That's new. A lot of the innovations happening in open source, but a lot of cool as a service offerings are fairly proprietary in both the messaging and the storage space. But Duncan, what do you see there? Yeah, we used to be really prescriptive in the field and say, don't use your messaging engine for a cache and don't use your cache as a message bus. But we are seeing a bleeding there. You look at things like Redis, they now have a messaging component in Redis where historically it was a fantastic caching technology. We still have our own as well with things like Gemfire and Geode and the ability to cache and then have the distribution over a wide area network is really fantastic. So it's a very hot space. Products morphing, product changing, you've got these religious camps focusing on one or the other. Yeah, wild stuff. So anyway, it's a good thing to read up on. Lots of great stories. Last week, some good hacker news conversations. And maybe that leads into your last piece, because I love reading the comments when it comes to hacker news. I also adore reading the comments on any Coté register post. Yeah, yeah, it's where I go when I want to take myself down a few pegs. That's good stuff. Yeah, well, you know, I write a more or less monthly piece, except since it's a European publication to do a callback in August, because apparently no one reads anything in August over there. And then December, for obvious reasons, because he got Boxing Day, I don't really know what that is. And, and so the one the one I did this month was on, I don't know how to filter and select DevOps consultants, which really, as one of the astute commenters wrote, applies to any type of consultant, but but that's fine. But yeah, I think I think I talked with Matt Walburn, who used to work here for a short stint. He's now over at Amazon. But notably for this, he worked at the on one of the DevOps, I don't know, teams or groups over at Target for a while. And he gave some advice about finding them. And then also our very own Bridget, who, you know, she she surveys lots of people doing DevOps stuff at conferences. So she
20:25kind of spoke on that topic. And, you know, the advice in there is what you would expect. Like, unless the vendor has a vendor has sort of like, aggregated people who actually have firsthand experience, it's good to find people who have firsthand experience, not just pure theoreticians and everything like that. But yeah, you can go check that out. And as as my, my boss, Andrew Schaefer, wrote to me, you know, apparently the the volume is working for as one of the commenters wrote about. So I think there's there's some good descriptions of, of my theoretic toolkit for writing these pieces to your comment point. But yeah, good stuff. So we'll be honest, I, yeah, I sent a link to your post to someone on my team and said, you know, you should read the comments, because this is arguably our audience. Sometimes we do have some, you know, the register seems to have the grouchy sysadmin audience, which, you know what, that's still a voice. And those are people who still have legitimate complaints mixed in with the snark. So I actually like reading them, because specifically, that is the people we fight against sometimes in accounts who look at us as just kind of a unicorn promise to come in and save things. So we should know what those folks are thinking. Yeah, I, you know, I think I think that's a good, that's, that's a good turning a frown upside down content wise there that you just pulled off. But I think, I think that if you were to mind the comments, they, you know, the number one thing they're, they're sick of over there in register comment land is like, what the hell is DevOps? Like, and why it sounds like the same thing it always is, which is like, and I poke fun at people in those columns every now and then, I often do some parenthetical little wave to like, you've been doing this since the days of abacuses or whatever. But they, and it is kind of true, like, it's hard to find a satisfying definition of DevOps. Like I was just reading through, I was starting to read through speaking of a 50 page document, the 58 page PDF of the 2017 DevOps report. And there's, there's, there's some pretty good sort of like thrusts at defining DevOps. There's one chart in particular, they do the, there's some name for this, but
22:27they do these good, um, uh, they're not causal. They're very careful. Never say that, but sort of like predictive charts of like, if you follow these things that causes you to do these things, which causes success. And that's kind of a good summary of DevOps stuff. But, uh, if you're kind of cynical, it's easy to look at all of the stuff around what cloud native and DevOps is. If you don't get very technical and say like, so basically this is computers except working very well, right? Like, and automating a lot of stuff. And it's, it's sort of like finally doing all this stuff that the, uh, the computer should do well, which I think, um, to, to that point, right? Like the, the, the, the, I think, especially with us and other people who want to help explain why you would do things in this new way. And maybe this is a good segue to the book is like, we were talking about this with, uh, with Tony and, uh, and, and, uh, and John in the last episode, I think about like, so what exactly is cloud native ops? Right. And, and, you know, we got to a pretty good definition of a list of like, here's some exact specific things you do that are different in the technologies that are different that make it a cloud native thing or a DevOps sort of thing. So, uh, as you say, it's a good reminder to look in those comments about how you, you always need to be pretty specific with SysApi people about what exactly is different and why it changes things. And then, as I would say, why that allows your, uh, your, your meatware behavior to change and be better. Yeah. Good stuff. I'm doing an intro to DevOps for the agile Alliance conference in Orlando, uh, next month. So I'm both terrified and excited because I don't know how I want to cover that. I need to, uh, I need, I need to go check out your, uh, it's not paralysis. What's the learning service that you have a, a thing in? Plural site. Yeah. Yeah. I still need to go check out your plural site thing. That's an overview of DevOps. If only to, uh, if only to steal some of the content for, for such things. Yeah. That's how we work. Well, good. Yeah. So Duncan, so let's talk about it. So you have a new book. Congratulations. Writing books is hard. Yeah. I have a new book. Yeah. So tell us about that. Why, I mean, why do this? There's lots of books out there. There's,
24:30I think a few on cloud foundry. So did you see some sort of like, Hey, we're not talking about this enough. I should write a book that explains the guts of cloud foundry. Can you kind of tell us where the book came from? Yeah, sure. So, um, that's interesting. So I'm not actually aware of another deep dive book on cloud foundry, but the other part of writing a book is it's hard. It takes time. So I actually started this back in 2014, if you believe, and I was working on cloud foundry, PCF version one. So one point, one point zero, one point one, um, implementing it for a customer. And we came across loads of operational, um, infrastructure type issues that no one had described. There's no documentation at that level. And at that time, which went into the depths of how you manage your routing tier, your GTMs, your LTMs and all that stuff, and how you structure for high availability and what your backup and restore process should be like. Over the years, we've now baked this into the product. But back then we just had to learn on the job. I had a hundred page document in word with all my notes. And I was speaking to Andrew Clay Schaefer, and we thought this would actually be a good idea for a book. So we reached out to O'Reilly and generally started to, or gradually started to convert all that material into a book. As it was a three year project, you can imagine the project is the product. So cloud foundry has changed a huge amount of that time. Right. Yeah. That's crazy. How'd you keep up with that? I mean, every time that you finished in that last period on a chapter, did you get new release notes and start cursing at the sun? Yeah. So some of it being very specific and detailed, you had to refactor. So the stuff on DEAs, a whole chapter on DEAs just got ripped out and replaced by Diego. Bosch has changed a huge amount. So refactor the Bosch chapter. But the thing with refactoring, every time you go through that process, you realize there are systematic patterns which you can draw from. So you start to abstract up. Instead of talking about a specific implementation like Conshure, you talk about distributed locks and internal service discovery. So by abstracting up, the general concepts stay the same and it doesn't really matter too much how they're implemented. So what I've tried to do with the book is talk around the key considerations of cloud foundry. Obviously, it goes into some depth
26:34around the components and the value of each component, what they do, how they interrelate. But it also starts to talk about the patterns, like what specific parts you need to back up and how you restore and how you structure for HA and DR and how you operate the platform, that sort of stuff. And that should hopefully be longer lived. I didn't realize I had this question until we were talking about like, who's the audience for it? Is it people operating it or people who want to know what cloud foundry is or who developed for it? But who's your... I probably, as always do, I always do with the Riley books, I probably shouldn't have skipped that section entitled, who this book is for, when I was reading through it. Everyone skips it every time. Yeah, yeah. It's really for the cloud operator. So thinking about working on Dino's team in PCFS, and we go and do dojos, six weeks on the ground, helping customers get stood up with cloud foundry, often bleeding into data operations. It's for that sort of audience. The cloud foundry operator who needs to stand up a resilient version of cloud foundry, they need to link it into their user management, they need to have a good backup and DR strategy, they need to onboard new users, new projects, they need to augment cloud foundry with additional services, they need to set the routing policies and everything else. It's that sort of operator that's really the target audience. No, that makes sense. Yeah. And just to confirm a little bit of what you're saying, I mean, definitely, I think, to use another book series, there certainly has been a missing manual around cloud foundry ops out there. So that's good that that's filling that in. Yeah, Richard, first about the space. So this is actually my second book, but really, it's the first book. And as part of this book, I wrote a couple of chapters up front positioning the value of cloud foundry. And my editor said that the technical folks, the operators aren't going to care care about the value and the positioning and the theory around DevOps and cloud native apps and microservices and all that good stuff, all the stuff, that space that cloud foundry plays, and so suggested taking that content out and turning it into something more digestible for the C suite, the CTO, CIO. And so I had a six month segue, where I took those two chapters and turned that into this mini book. And that was the book that was released about a year and a half ago now.
28:43Yeah, I think I think that's a that's a very popular book for our downloads right next to another another odyssey of a book, the cloud native Java book. That's right, your own book, okay, with the cloud native arc journey you've got going on there. So yeah, little books are good. Yeah, we need big books. I mean, that's, you know, this one, Duncan, you weren't probably going to write a mini book on some of these topics, we get four chapters just for Bosch. Yeah, so I mean, that's pretty unique stuff, right? I mean, there's the Bosch.io site, there's some other conference presentations, but there's not a whole lot of centralized information on using Bosch. Do you feel like we've tried to spend the last year, bringing Bosch down to earth for people, so they don't feel like they just have to become YAML architects to use Bosch. But, you know, was that part of your intent that you spent a good portion of the book on Bosch? Obviously, that was intentional. Yeah, so I was trying to have mercy on my audience. There was one chapter on Bosch, it was something like 60 pages long, it was just too much to digest. And so I broke it into discrete chapters. So it starts with an overview on the value of Bosch and what Bosch is, and then it goes into Bosch releases and Bosch deployments, and then Bosch constructs. So it breaks the concepts of Bosch down so that people can dip into the relevant section. But again, this has been a work in progress, right? So back in 2014, 2015, Bosch was very different. Bosch.io wasn't a thing. And the documentation around Bosch was very different. So I spent a long time with Dimitri walking through the documentation, walking through what we've learned in the field and trying to reconcile the two. And Dimitri and the Bosch team have done a fantastic job with Bosch 2.0, with Bosch.io and the Bosch documentation. So Bosch, in terms of both how it's presented and also the usability of Bosch, you know, dramatically changed over the last year or so. Yeah, that's great. One thing, yeah, please. So I was, you know, I've written a couple of books myself, and I realized that there's often things you appreciate more, sometimes less, I guess, when you're done about the technology you're writing about at the end. So when you finished this, after especially the odyssey you've been on with when you started it, was there something about CF where you went, gosh, we don't talk about this enough, or this is kind of plumbing, but really helpful stuff that maybe people don't appreciate the log regator, or they don't appreciate things like that?
30:55Was there anything, when you finished the book, you said, I hope people pay more attention to this component, that this actually helps them more than they realize? Yeah, there's a few. I mean, we were just talking Bosch is really underrated. A couple of people reached out to me on Twitter and said, you know, Bosch isn't actually part of the Cloud Foundry Foundation, you know, back in the day, and therefore I shouldn't put it in the book. And I think it's such an intrinsic part of Cloud Foundry. It makes Cloud Foundry on the operational side just second to none. And for me, it's really front and center. So I felt it vital to talk about Bosch. Other things, people just, there's tons of confusion around containers and Docker and build packs. And so spending some time with Ben Hale on build packs and Jules on Docker and Glenn Normington and all those folks, just exploring the trade-offs between Docker and containers and build packs, and when you should use an image versus just pushing a raw artifact, that was actually very impactful for me to get that talk track down and then explain it to other people. Other things like routing, what Cloud Foundry does at the routing layer, I think is really cool looking at all the routing services that have come into play and just understanding more about the routing mechanisms is very impactful. I started to go into a lot of depth on the UAA. So again, the UAA becomes really important as well, especially for people who want to integrate with their existing user stores. Yeah, I mean, you just teased it, right? But do you have, for our listeners, kind of that take on build pack versus that more container image centric way of pushing applications? Do people should have rules of thumb? Is there all or nothing or scenarios where you should favor one or the other? Yeah, there's definitely times when one works better than another. So the key thing to note is that Cloud Foundry supports both. Like in the general marketplace, a lot of people, I still think, see Cloud Foundry as not or anti-Docker and not supporting Docker, whereas actually we supported Docker images for some time with Diego. I've worked with a customer recently where just building their complicated application on the fly. So it was a PHP app with a Perl module and something else in there. Just trying to compile that on the fly was really difficult. So Dockerizing that application made it far quicker just to get on to Cloud Foundry to then refactor.
32:59But by and large, if you can have a smaller footprint you actually deploy, if you just take your application artifact, push it to Cloud Foundry and let Cloud Foundry containerize that for you, there's really less surface area to deal with, there's less concern for the developer, there's less security scanning that needs to go on. So it's a more streamlined process overall if you can get away just pushing the application artifact. So speaking of, there's a weird connection to like paying attention to the grumpy people and the register comments. But, and at the danger of, I mean, hopefully this won't turn into too much of the usual like, you know, pivotal hyping stuff, despite this being our podcast. But like, I often think that, um, so, so there's a lot of discussion in the cloud native area and it feels like a lot of it is sort of like talking about what's under the hood of various container orchestration things out there. And oddly, the, the sort of like simplicity that Cloud Foundry tries to bring, um, to running your own applications. Like in the first part of your book, you know, you spend a lot of time basically saying like, we try to make it so you never have to open the hood essentially, or, or, you know, you don't have to change the oil every time you go out to drive to use that metaphor. Um, and there's a weird, like kind of to Ian's point, like, it feels like there's a weird marketing disadvantage where there's just sort of like, you don't need to worry about those things. So stop worrying about them. Um, and then everyone in the register comments is like, but I like worrying about those things and yeah, that's, that is the thing, right? So a lot of, uh, you know, it operators and engineers enjoy playing around with the nuts and bolts and we make it really easy to do the right thing. So by using a platform, the developers can just come along and push. They don't have to worry about all this operational overhead. So my experience is often the developers are crying out for something like Cloud Foundry or if not pivotal Cloud Foundry, but it's the operators who want to push back and say, look, we actually want to build the stuff ourselves because it gives us job security and it's more fun.
35:02Yeah. And, and, and, and it seems like a lot of what's going on in your book is, is almost like filling in all that stuff. Like, like, like, and, and it'd be interesting to hear like, like, like ongoing, like, uh, how, how you approach this as well. But there's almost like, uh, to use Google SRE terms, there's a, there's this black box, right? Like the way, the way you could think about something like Cloud Foundry is like, it's this black box that I don't really need to worry about its internals and how it operates. I just should use it. And it's almost like a little bit like, uh, I haven't finished reading your book self admittedly, but, but there, there's to some extent what, what your book's doing and having so many chapters on Bosch is like, well, let's make it kind of like a translucent box. Like if you're really interested in all the internals and how you can muck about in there, you can go free, you can feel free to go do that, or you can just keep treating it like a black box, which I think is why it feels like it's starting to fill in that middle part of like, I don't know if you're, if you're obsessed with like how all these little wing dings and everything works, like you can get in there and wing ding yourself as much as you want. Yeah. And I thought that was one of the interesting things, Duncan and Coté about the book was on one hand, I mean, go back to the SRE book, arguably Cloud Foundry tries to eliminate toil, right? I'm trying to get rid of the dumb undifferentiated work that SLOG wears me down and Cloud Foundry takes care of a lot of that. But what you pointed out, Duncan, in the book was things like HA, which, you know what, robots don't set that up for me. I have to think about an HA strategy and maybe robots do some failover, but I have to think about architecture. I have to think about how I deploy this and that's good. And that's good sysadmin, you know, infrastructure ops mindset. And then the machine just runs in a lot of cases, but there's, I think you did a good job of pointing out where do you need to come in and fiddle? Is that a good thing? Where do operators have some benefit? That's the whole thing with Cloud Foundry. It doesn't eliminate the operator need and it doesn't actually remove that fun. It just raises the value a lot. So you're not tinkering around with things like container orchestration. You let the platform do what it does best. You're not dealing with endless log aggregation. You're just piping it out into, you know, a centralized repository for all your logs and you can focus on that more high value thing.
37:06So how do you truly get active active and how you synchronize the data and how you set up your users for that and how you expose all this back end services and how you migrate some of those legacy apps. Off really expensive, unsupported middleware onto a unified platform, which is fully open source and fully supported. And so it just raises the bar. It means the operators still do tons of cool stuff. They just focus on something that's high value. Yeah, a lot more fun. I mean, and you'll have the same thing. I know some people can say, well, you know, these sort of run yourself software platforms are going to give way at some point to just a pure play public cloud. Like, why would you build and run your own platform, even if it's Cloud Foundry, when I can just use fill in the blank from a public cloud provider? But I think, again, to your point, many of those things you just listed out, setting up HA strategies, doing data replication, figuring out how you do app migration. That is identical, regardless of where you're doing it, and Cloud Foundry does give you some flexibility of where you're running that and a consistent experience everywhere. So these are universal problems, but luckily we're trying to all raise our gaze to things that matter a lot more than, you know, tweaking registry settings on a Windows box. And Coté, to your point, having some visibility into how things like Diego works and how containers work is important because if things go wrong, you need to be able to debug. You need to understand the flows of communication. You need to know what to look at, how the networks are configured, what components calling out to what component. And by having an appreciation of that, it really helps with the troubleshooting. So my aim about exposing some of those internals around Diego, and there's a big 50-page chapter on how Diego works, is to really help the operator go in very deep, very quickly if they need to then do some troubleshooting. Yeah, no, I mean, that's good. And it comes through in even the scant sections I read is, I think to phrase what you're saying another way. And weaving in my experience with talking with resistive ops people is they need some way to build up trust in, as we would say, the platform or trust in the new technology. And they need to do that even before they get to the point where they're learning the new things, or at least translating their old way of thinking, their current way of thinking about how they manage IT to a new way.
39:14And as an example, I thought the, you know, you have, you kind of have this brief discussion of how, what application instances are, AIs are, and how they're a different way of thinking about things than a server, you know, on a server-based thing or whatever, and, or a socket or even a VM, and why we would think about things in that way. And this comes up a lot going back to sales organization and pricing, because we price things based on AIs, which befuddles people a lot initially. But it does seem like they're at the ops level, like once you build up trust in the system, because it's not a black box, then you can kind of understand how the components move. And then that gets to, you know, to kind of switch a little bit. I mean, something that, that, that I'm kind of realizing as we're talking about it is, is a lot of above the value line ops wise is more managing the distributed applications, your, your, your organization's running than really managing the infrastructure it all runs on. And it seems like, I don't know, I mean, if that framing is good, that seems like a framing that, that to push people towards more is like, as you all are both saying, like, you're still doing a lot of operation stuff. You're just not managing infrastructure, you still have to come up with the way that you're going to have high availability and the way you're going to recover from failure and the policies that you need to have, like, you know, resilience and all of that stuff. You're just not really worrying about like, storage so much. I mean, there is kind of worrying of that, but you're more worrying about all the services that you're pulling together. And kind of from a developer perspective, you're, the operations people are sort of like taking some of those responsibilities that developers maybe used to worry about because they were way up in developer land. And instead doing that work probably better than most run-of-the-mill developers could do if they're actually planning out and managing services for them. Yeah, and Tony Hansman's got this line, get your business back. And that's absolutely pertinent for the developers and the lines of business. If they can just focus on their business instead of curating Docker images and understanding how container orchestration works and dealing with all the low-level concerns, they just focus on their business logic.
41:19The lines of business, the business owner really can move with high velocity. And then it should be more fun for the developer as well because they're developing meaningful business code at that point and making a direct, tangible difference to the business rather than just dealing with middleware and container orchestration concerns and the like. Yeah, now you mentioned, you know, if someone could read that book and go through and go, gosh, this all seems big and complicated. Like, there's just a lot of moving pieces. This thing's a beast. And on one hand, you could say, well, sure, it's a platform. I mean, you don't necessarily learn how Amazon works just by point and clicking on your first try. Like, there's a bunch of subsystems you have to think about, monitoring, whatever. So, sure, Cloud Foundry is a lot of things going on. How do developers then not look at this as, I have to learn a whole lot of stuff to use this? I mean, kind of that dev experience. How do you encourage people to start using the platform and not, you know, as you say, you can treat this like a black box if you want to or you can pull back the curtains. As a developer, though, how does this not feel intimidating? That's a really good question. I've tried to address that up front. So, the book is very explicitly not for developers, and I'll talk about this in a preface. It's really for the Cloud Foundry operator, the person who stands up Cloud Foundry and is responsible for all those data operations. And that means, as a developer, you're really free to understand the interaction with the platform. So, things like CF push. How do I push my application? How are environment variables exposed? How do I get access to my logs? How do I bind to services? And the footprint and the area to understand there is really very small. And so, my view is the developer experience when using Cloud Foundry is very, very quick. And we expedite that with a couple of things. We obviously have Pivotal Web Services where they can sign up and get some familiarity using Cloud Foundry. There's also Bosch Lite where they can stand up like a local version of Cloud Foundry if they want to, or they have PCF Dev where they can just download a vagrant image of Pivotal Cloud Foundry and get going. So, from the dev experience, hopefully, we've done a great job making that very, very easy. For the operator, to your point that Cloud Foundry comes across big, scary, complicated, we can't hide the fact that it is a complicated distributed system.
43:21But when I look at how we've broken Cloud Foundry into a set of subsystems and CF deployment, which is the new way Cloud Foundry is all packaged up, has done a great job breaking everything into isolated components rather than this big monolithic release. So, now you have a separate UAA, you have a separate Diego release, and, you know, everything's componentized. We've done a great job defining very clear boundaries, very clear flows of interaction between these subsystems. And so, for someone like an operator coming in cold, you can start at a high level understanding each discrete subsystem at a high level and how they interact. Then you have the freedom to dig into logging in isolation or Diego into isolation or UAA or routing. And you can pick and choose the areas of Cloud Foundry which you want to focus on. Awesome. So, one of the other things that you mentioned in there, and we talk a lot about in Cloud Foundry land, but it's, you know, I don't think we use the word contracts as much anymore between the layers because sometimes it has a legalistic sense. But that there's kind of expectations between different layers of the components that we do have an opinion that does get put on how you should build apps and things like that. So, you know, as you talked about in the book and as you think about Cloud Foundry in general, are opinions a bad thing? When are they a good thing? You know, how is that in favor of a developer or an operator when they're thinking of building and running systems like this? I think opinions is a really good thing. Cloud Foundry is definitely a structured, opinionated platform, and we have strong opinions on how you should do software delivery. I mean, Pivotal as a whole is transforming the way the world builds software, and you cannot do that without strong opinions. But the beauty of Cloud Foundry is that it's not just opinionated, it's also open. And so it leaves choice at the right areas. So we talked earlier, you have the choice to use Docker where you can push your application artifact. You have choice on service brokers. You have choice on which cloud provider you deploy to. You have choice on how you structure HA. So there are a number of critical decisions which we still have strong opinions on. Both the platform and platform architecture teams have strong opinions on these.
45:24But we also leave flexibility where it matters to the customer. Well, I think as a last question, so what's your favorite part of the book? Is there some part that you're like, oh, this part's great? Like, you know me. Maybe you don't, but I'm always trying to put stupid jokes in and allusions to things that I'm pretty sure only I do. But you got any, like, fun Easter eggs or just some favorite part where you're like, man, I really nailed how that creepy clam works. Like, what are you most proud of in there? Some of the stuff, like the really deep guts I had to remove because the book was just getting ridiculous in length. In terms of what's still in the book, in my favorite part, I like the ending, the what's next, the roadmap. I spent some time with Yui and a number of other people in engineering talking about some of the possibilities of Cloud Foundry. And when you look at the progression of Cloud Foundry from 2014 to now, you can see how far it's come. But you can also see what's on the horizon and some of the things which may be coming down the pipeline. Isolation zones are something that's come recently. But there's a load of other stuff that Cloud Foundry could start to stray into. And that's really exciting for me. All right. Well, thanks for being on. What's the best way to, like, for people to get a copy of the book? I mean, just, like, all the usual things? Or is there something that's better than that? Do you get some, like, bonus material if you go somewhere else? There's no bonus material. So O'Reilly are actually sunsetting their direct distribution. So I think if you want a copy of the book, there's some on Pivotal Store. So if you're on Pivotal, you can get some from there or Amazon.com. Yeah. Yeah. I started reading it. I don't know if we still do this, but I, for some reason, have some Safari subscription through Pivotal. So I was just reading it through there. Yeah, you can get on Safari. So O'Reilly is a safari where you can get it from. Yeah. Yeah. Yeah. All right. Well, thanks for being on. That was good stuff. We'll put a link to the book, Cloud Foundry, colon, the definitive guide. Right. And, you know, you can look it up. But it is, I think, you know, you got the little Cloud Foundry book that we talked about earlier. We always give that one out at conferences a lot. And that's the one I always recommend to people if they don't really know what all is going on in the Pivotal Cloud native area.
47:30As you were saying, it's a good overview of, like, why you would care about all of this stuff in a digestible form. So, also, if people want to follow, you know, not only the book, but if they want to putter around with you on the internet, you got a Twitter account or anything like that? Yeah. Where can they find you? So, yeah, just go to Don't Win and see me on Twitter. All right. That's two N's, right? I got that right? Yeah. W-R-N-N. There you go. All right. Well, as always, thanks for listening to Pivotal Conversations. We'll be back next week with something. If you want to find the most recent episodes, the RSS feed to listen to, and I guess the most unrecent episodes, all the old ones, the best place to go is soundcloud.com slash Pivotal Conversations with no space or underbar. We've got all sorts of fun stuff there. You know, we've alluded to a couple episodes, like the one about cloud native ops last week. There's some from actual customers like Allstate and others talking about their experience using all of this stuff and just changing how their organization does in general. You can also find how to subscribe to it if you go into iTunes or Overcast or whatever Stitcher is, all these places. That's always the best thing to do is subscribe. And if you have the time, it's always good to go write a little review in iTunes or, even better, just refer to your friends or other people who you think might be interested in it. You can email us at podcast at pivotal.io. And if someone wanted to see you on Twitter, Richard, where would they go? You can always find me at rseroter on the Twitters. That's right. And it's a very good real-time feed of all the interesting news that I haven't found yet and we'll find about next week when I hurriedly do some prep and read through the show notes. So I'm in Twitter as Coté, just C-O-T-E. And we'll see everyone next time. Bye-bye.