PCI, BOSH, CI/CD, and microservices - white papers galore, with Jared Ruckle

Episode 61 · 53:51 · SRT · archive.org · all Tanzu Talk

Well, I went camping this weekend, so I wanted to ask you to, well, first, assuming you go camping, if you don't, you can just skip. But, like, what's your sort of camping routine? What do you do up there? What do the campers do? Because down here, let me ask a question and then make a statement. Down here in Texas, you try not to melt. So that is number one. You go out there and you don't want to die. So you find a swimming hole or whatever, or you just suffer. But those are your options. And then you might go on a little bit of a hike, look around at things. You can fish, stuff like that. But what goes on up there in the Pacific Northwest? Yeah, I think Jared's a camper, so he can answer. I'm not a huge camper. My brother, who's nothing like me, lives in Arizona and camps, like, every weekend. But that is not my bag. Jared, I think you camp, don't you? I do camp. And it's remarkably similar to what happens in Texas. Usually, when we go camping, it's further inland. So kind of in the Mount Rainier area where we happen to live by, you want lots of shade. You want a swimming hole. The swimming holes tend to be really chilly. There's one place that we always go to that has just freshly melted glacial water. So it's a very brisk swim. And you cool off very quickly when you go through that. But yeah, shade, swimming hole, same deal. That's camping. Well, my revelation about this camping trip, other than we were talking before we were recording about me eating fried chicken and what an adventure that was. I used to eat that as a kid all the time. And I have to say, man, it's probably been, I don't want to say 15, but maybe 10 years since I've had fried chicken. It just doesn't come up in my current life. But we were there in the hole, right? Spring fed, not glacier fed. And, you know, just swimming around, having fun. And first, there were some, what I could only describe as post-teens. I wouldn't call them 20-year-olds, but they were some sort of teens.

And they were, I don't know what was in these cups, but they were running around with like a, all four of them had like those big 32-ounce fits-in-your-cup holder styrofoam cup from some gas station. They looked like they were having fun. That's the way to kind of slum camp. But then there was this whole big family that came to the, it takes about 20 minutes to walk to the hole in the ground that you swim in. And they had like camping chairs and a rolling cooler and all this stuff. And they're hanging out. And I was like, you see, when you plan for this kind of thing, what you got to do is assume that when you get there, you're going to have fun and ask yourself, what would I want when I'm having fun? And I think, I think, you know, if you're obsessed about not melting, you're just thinking about risk avoidance and you're not focusing on when you actually show up there that you're going to want a cooler full of delicious beverages and chairs. So I'm going to, I'm going to start on that outlook on life and see what happens. That's good advice. Yeah. Yeah. I'm trying, I'm flying with my family today to start vacation right after this podcast. And the thought of initially flying with five people, including three kids, made me want to, you know, leave in the middle of the night and not come home. But I think to your, your point, some of it, I'm also now woke up this morning and think I'm going to have fun with this, even if it's crazy. It's a good way to think versus planning for the negative. That's right. That's right. You don't, you don't want to, you don't want to be like, my plan is I'm going to get on the plane without a parachute, open up the door and leave this vacation. I'll try to avoid it. Yeah. Yeah. Yeah. You know, I always find, I always find since I, you know, just, just like, just like yourself, I'm sure I travel a lot for work and it's a whole new experience in a good way. Traveling with family. It's just sort of like, it's cause you know, you're like, you have the whole travel airport thing figured out and then you can just be like, now we're just chilling. Right. I can't expense this absurdly priced airport meal, but like at the very least I can have fun and I can, I can do what all those other people with their funny rolling backpacks, all the families are doing. See what that life is like. That's good stuff. That's right. You wear, you wear those team Coté t-shirts, your whole family.

And you talk about your group, your group as your family, as a team. Man, I'm going to, let me, let me open up OmniFocus and write that one down. It's a contextual reminder. Print up some t-shirts. I always see like one of those families on every vacation through the airport and I don't think I want to be them, but I really admire them. Yeah, it's like the McCone Spivak family reunion and like a bright pink shirt that has some saying like, you know, like, you know, make sure Uncle Jerry changes his pants every day. Just, oh, Uncle Jerry. Anyways, that's, I never went to family reunions much, but, you know, I think reInvent is this week, isn't it? Not reInvent. They are doing one of their, I think, Amazon kind of events, like roadshow sort of events, and they are announcing some new products today. So, yeah, the fall pickup is getting going on new products. When is reInvent then? And I'll forget it next time. I believe it's November. November. That's not this month at all. That's close. Yeah. So they do little regional shows now. That's right. I remember there was one in London a little while back, right? That was interesting. Yeah. And, well, first of all, why don't you introduce yourself, guest, just briefly? I am Jared Ruckel. I'm on the product team here at Pivotal, working a lot with Pivotal Cloud Foundry. That's right. Finds lots of holes to swim in, more or less. Well, also, last week, there was the announcement that AWS, I guess, I don't know if finally is the right word, but they finally answered the question, are you going to care about Kubernetes officially? And they joined the Cloud Native Computing Foundation, which, as I recall, I don't think they put a hyphen in Cloud Native, but we'll have to go check on that. But I thought, you know, I read through a little bit. We talked a little bit about it on my other podcast, Software Defined Talk, last week. But there wasn't a definitive statement about them being, like, all in on Kubernetes stuff. But it was about as definitive – it was definitive minus one.

They had Adrian over there in his Medium blog being, like, we do all the open source stuff. Tons of people run Kubernetes. We're going to work on all these projects. So that's exciting to see them join that – the old Kubernetes boat. Yeah, I mean, foundations are foundations. I mean, I think there's, you know, there's value in doing them. I think sometimes it's a rite of passage. In this case, I think it shows that Amazon's going to spend some time thinking about that. But at the same time, I'm sure they still keep a skeptical eye knowing that this does make workloads easier to go to Google. But at the same time, there's probably no cloud company, of course, minus Pivotal, that is more attuned to what their customers are asking for than Amazon. So they're doing it because their customers are asking for it, not just because they feel like it. Yeah, you know, it's also good, like, reading all the press around them joining the CNCF. You get a good whirlwind tour of all the projects they have there. There's actually a tremendous amount of a big stack that they have. So also, I was thinking, you know, I have a little – we did several episodes on my cloud-native enterprise architect odyssey. And I'm just going to give a little update. I forced myself to have a deadline. I have a little five-minute talk I'm giving here in Austin tomorrow, which I think will be a good – basically, I can introduce myself, and then I'll have 30 seconds to say that I'm working on this. And then later on this week, at, of all places, an OpenStack meetup, I'm giving a longer talk, so I'll be able to dump everything that I have there. And eventually, I'll probably write something up. But, you know, I referred to a document I had earlier. I think I'm going to go delete all of that, and then I'll start over again with the actual useful content that I've come up with. But there's been a lot of people who've talked with me about it, and it's been nice and helpful. So, as always, if you still want to talk about what enterprise architects do in a cloud-native world, that would be fun. But I think I'll have some actual helpful things to publish. Awesome. So then I have to admit, I haven't read this low-code article you have. What's going on there?

You know, why do I share links with you if we're not going to read them? It's just our whole relationship. I like to have a little previewing. It's kind of like a sommelier of links. Yeah. You can describe the woody taste. There was a couple of articles last week around the same survey, and it was just talking about low-code. And kind of the one take was like, hey, it's doing some good stuff. The other take from the new stack was like, hey, through a safe survey, it shows like a lot of people have checked out low-code platforms and then moved on. So is that kind of just peaked, stagnant, what have you? And, you know, there was some Twitter engagement after I had shared that, and it was good stuff. And I just think it's an interesting conversation because Pivotal's partners with Mendix and Pega and some other platforms, the whole point of them is how do I have developers writing less code and building these apps quicker? Because many times these are just very data-driven apps. You know, think force.com. Think these interfaces where I have kind of a data schema, and I build out some interfaces to collect that data or process that data. So they're not as crazy as a custom streaming app I'm going to build in Spring Boot, but they also solve a lot of problems. So, you know, they've been around for a while. I personally haven't seen them kind of get over that hump of being totally mainstream and, you know, regular professional developers breaking them out. But they seem to have also found a successful niche. So I didn't know, Coté, in your world, if you come across this sort of space much and if they've just kind of occupied the spot they're in, and that's where they're going to stay versus kind of taking off or exploding. So now low-code is, that's like the notion, as you were just, that's the phrase for it, right? Like you're doing a low-code style approach. Right. Yeah, yeah. I mean, I always think of these as, I mean, especially in y'all's neck of the wood. You used to have a RAD development, which is, it's so sad. We don't use that acronym anymore, but you're. I know, it's a shame. You're rapid application development. And, you know, at one point when my wife was working for the ACLU of Texas, they had, I used FileMaker, which is fun.

And I don't know if that counts as low-code or RAD, but it sure felt like it. Yeah, yeah, yeah. That was the first thing I learned, Don, back in the 90s. Yeah, yeah. It was, it was, it was a good lesson in something they should teach in Computer Science 101, which is never volunteer to write code for anyone. That's, that's going to go poorly for you. But, you know, they, they had this thing where you could, there's complaints in prisons and you could submit. There was a, there was a form and they would get, there was this web application to get dumped to a MySQL database. And then you get the CSV file and load it up into FileMaker. And then all the lawyers there can process it. And it was, I think if I actually knew how to, ironically, very ironically, right? Like if I knew how to use FileMaker, it would have been really easy to do because the main sticking point being, and, and, you know, I'll get to more of the modern day, but the main sticking point being that like FileMaker has this, I mean, it's a database, but I was like a highfalutin Java developer at the time. And like, it's not an SQL database. So I like, I just couldn't wrap my head around it. It was one of those, like, it's the same way that if you spend too much time in Excel and you used to be a program, you're like, how does Excel think? Like, how does it arrange data? And, and like, I could never figure out in FileMaker how to really do that. But anyways, yeah, it was really useful. Like, I think, and to your point, like Mendix is a good example of this. And I think like the, probably most of the first generation of, of platform as a service, like you're saying, like Salesforce and like Intuit with QuickBase and other things had this. It was basically like a low codish, maybe medium code way of extending out the platform. And it does, I mean, this kind of, and I think Gartner sometimes is, it's related to citizen developers and stuff like that. And it is, it is a curious phenomena that aside from Excel and maybe whatever people do in Tableau and Quick nowadays and kind of BI stuff, like it's interesting that it hasn't spread more. I don't know, like it feels like, it feels like conceptually and not by volume, but maybe the apex was like HyperCard and, and, and Fox Pro and all that stuff.

The nineties was the apex of it. And I don't know, I don't know if it's sort of like scaling and manageability problems or whatever, but it's, it is weird that it hasn't caught on more. Yeah. And I don't know if there's some of the, you know, I didn't build it and there's just too much scaffolding and too much opinion. And so, I mean, some of these platforms have extended to allow for you to, you know, write some custom code in there as well. But yeah, I don't know if it's just sort of the, you know, that's not good enough for me. I like just jumping down and building compilers or, you know, more importantly, I just like building my custom apps. And I don't like your constraints. So yeah, I mean, they're really, some of them are very compelling platforms are very useful. And I don't know, I don't love debugging code and doing really boiling, boring boilerplate stuff. But yeah, I just, I've just never seen it go beyond the, you know, business analyst set or citizen developer set into mainstream. I mean, I guess there are, like, I often think that a lot of, not to affect our monthly compensation with an idea like this or anything, but I have to think a lot of the custom application development tasks that companies have could be taken care of with a pretty good Google form. Right. But on the other hand, there is, you know, with those, those talk about that sort of like, you know, bottom of the barrel code. But what that tends to lack is kind of like workflow stuff. Like you often need like so much of what you do in organizations with something like this is I want to collect some data, as they say, enrich it. I want to monkey around with it. And then I need some manager to approve it and then it goes to someone else and they do something. And, you know, that you could, I mean, I think I remember when I was talking with the Mindix people, they get involved in things like that. But like there's, you can do a lot with just that simple little loop. And no, and that's a sweet spot for a lot of those systems is that sort of workflow stuff that's hard to necessarily chain together in just your random .NET app. Like you can do it, but there's a lot of stuff you have to do.

So there's a lot of value in the workflow stuff or the hyper data driven stuff. And absolutely right. There's some cases where it's unnecessary to go build your custom app. Like you really could use platforms like this. That's why Access had such a long life because anybody could quick sling together something that would capture data and run some quick reports on it, you know, solving problems. Yeah. Yeah. You know, the closing it out. It was interesting when I did that FileMaker thing to find out they were owned by Apple. It's a very, very, I guess it makes sense. But in that I bet FileMaker is relatively small and drives a lot of Apple customers. But it's a strange little thing to learn about. So now back to the high code and the highest of the high code. There were also, I think, you know, you pulled together two of them. But I remember looking this up for another one of my podcasts where we go on about white papers, ironically, for the topic of this show. But I think there were like four hype cycles that came out last week that were related to like application development, right? Or at least three or something. But there was the application infrastructure and integration. There's a good name there. And then you got your normal application development one. I think there was a PaaS one too, right? Or did they shift it in one of these two? PaaS was mixed into some of these. There might have been another one. There was just a flurry of them. And these two stood out to me. Yeah. Always pretty useful. Yeah. No, these are good. But it's always good to get fresh analyst meat for the presentations, for your King Ranch casseroles or your just pot roast, whatever you're working on. But, yeah, like hype cycles are fun because they're really – you can read them really quickly or you can read them really slowly. They're usually like, what, 40, 50 pages, if I remember? Because I got to go over all this stuff. Yeah, look at this bad boy. One of them is 67. The other one is 59. So, I mean, they're big. But like you said, there's the quick kind of at a glance. Okay, what is at the peak of inflated expectations, which is like the title of my autobiography. Yeah. And then you have the trough of disillusionment for like, oh, gosh, this thing was so overhyped. I didn't want to use it. And then you hit that graceful slope of enlightenment where eventually you get value.

And so it's good to read through those. And then I actually like in those hype cycles, they have a comparison table that says, here's the sort of thing I'm looking for. And here's the years to the mainstream adoption. So it's not even just that this thing's crazy hyped. It's, hey, you're probably five to 10 years away from bots in this example, or event-driven programming models, or crowd testing, or things like that. But, hey, less than two years away is things like citizen developers, per our previous conversation, or responsive design or functional programming. So I like being able to also map it that way. That's helpful if you're a CIO thinking about where do I put my chips maybe right now for R&D stuff for what things are coming. Now, in y'all's experience, how accurate – I mean, accuracy is the wrong word. I mean, you kind of went over useful, but like what y'all's experience was sort of like using it in that way that you were just talking about, Richard, where you're trying to time things out. Like, do you have any examples you remember where it worked out well or didn't work out well? Yeah, I mean, we go back to our nine-episode series on enterprise architecture. I think back in those days, things like this would be handy when it would be, okay, what kind of projects do we want to put something in the budget next year to just do some POC stuff? Or call in some vendors to mess around with service-oriented architecture in that time? Or we were doing some mashup technology, and I would go off and explore mashups for a month and write up a summary. So this kind of helps you at least think about what are those trends that maybe I'm not seeing. Or even conversely, if something has just hype peak expectations, maybe do we talk ourselves off the ledge from doing like all in on this thing right now because maybe we're just overhyping it. So I had some experience in the architecture team using this to grade out the future a little bit. How about yourself, Jared? You had any good relationships with the hype cycle in the past? It's a good question. I think that they're a really good snapshot point in time, your sense of guidance. I'm not sure if anybody's actually done the cartoon flip book kind of comparison to see how they change and evolve over time and how historically accurate they are.

But I think really what the market wants and what it needs is kind of this temperature check about where all these different things are. And so it's a really useful tool for that current state. I don't know if you're going to gain any super awesome competitive advantage as an IT firm by using it as gospel. But like Richard mentioned, it's probably a pretty good tool to help allocate your spend where you want to hedge your bets and mess around with things, look more closely at things too. Yeah, yeah. Well, so just looking at the application development one, I see that so far my favorite phrase on it is post-scrum methodologies. I saw that one. I like that. That sounds like something a therapist might be advising you about. But, you know, it looks like in general, PaaS frameworks, they're climbing out of the trough of disillusionment. So that's a good sign. But then I guess AD PaaS, I forget my 30 categories of PaaS, but I think that might be application development PaaS. You're right. You're right. I had to look that one up too. So that's just about to strike bottom and bounce off towards the top there. So that's good. That's good. Things are going well. But yeah, I mean, it is like, and then I still don't really know what reactive programming is, despite making many people explain it to me. But it looks like, let's see if I can pull this joke off. The back pressure is driving it down the curve. Is that right? Did I get that one? Well played. Okay. Thank you. Thank you. And yeah, but this one's pretty good. It's also, to add to it, I mean, y'all both said this, but it is a good overview of all the hipster stuff out there. I think, you know, I haven't seen a Forrester Wave in a long time, unfortunately, but like the ThoughtWorks also puts out an annual, like, I think it's a spiral of all things. They're going all, how do you say that guy's name? Boheme? They're going all spiral on it. But that one's also a good sort of lay of the land, if you will, that they do. But when y'all look across these hype cycles, what's getting your gizzard all jiggly?

Well, I mean, it's nice to see, trying to get that visual out of my head. The microservices at the top of the peak inflated expectations, which is not a surprise. I have no idea what project management bots are. So these things are always humbling because I don't even know what some of these things are. So that's always good. I think they're probably like, you're in Slack, and they're like, hello, have you filled out your TPS report? What is your status? I don't know if that's worthy of being on the hype cycle, but that's fine. But then also function paths, right? Function as a service, serverless, also at the peak. So that's the Gartner phrase for serverless, then, function paths, right? F paths. Container management, those sort of things. So not surprising at all that those are at the peak. I think it's actually good to see that because it can remind you again that our kind of echo chamber bubble of tech sometimes, we get hyped up about tech that's still multiple years away from mainstream. And then, as you said, the things that maybe you see as a little boring, like in-memory data grids or traditional database platforms or application platform as a service are now in this sort of, hey, we know what we're doing with these now and are actually productive part of the slope. Yeah, the other thing I recall reading, I need to go back and reread these more formally, is that private paths is in there as kind of an official thing, which that probably has happened sometime over the past year. But that's nice that that's in there. That hasn't been in Gartner land for a long time. Yeah, it's kind of curious looking to see that iPaaS, integration paths, is about to hit the bottom here because it seems like that's been around for a long time. So it's all upside for Boomi from now on. That's it. Well, there's just been so many vendors now. I think there's like 80 or 90 that Gartner's tracking. So I think there's just been that explosion of them, which is why you had that inflated expectations. Now you'll see some consolidation. Now you'll see some more tight use cases get defined. Yeah. How about yourself, Jared? What do you like here? You know, what's really fascinating about this, I wonder if there's some sort of master reconciliation of these cycles within,

within Gartner, because you've got microservices infrastructure at this really innovation area, but then microservices are kind of at the peak and just sort of how all these different things, you know, interrelate to each other. I'm sort of, you know, amazed at these things that sound kind of similar or at least adjacent categories can be so all over the place. And I guess that's a little bit of what, you know, Gartner's role to play is in all of this as a intermediary between, you know, buyers and vendors to help this, you know, sort of matchmaking dance make a little bit more sense. Yeah. No, I think that interrelation stuff's interesting because as you say, many of these things are not an island. Actually, arguably none of them are. So just because this thing is peaking, does that mean something else is less relevant or that sort of thing? So yeah, it's fascinating to see the interplay. Yeah, it's a very detailed breakout of everything. Well, speaking of detailed breakouts, so we're having you on, Jared, because you, well, there's two parts of this. One is you helped Shepard co-author, like I think this was last week, we released four new white papers. Is that right? Four or is it three? It's four. So that's the definitive answer to what I did on my summer vacation. That's right. Exactly. Exactly. And then I was rereading the blog post and you were like, these are our first four, which implies there are other bundles out there, which will be amazing. That'll be great. And so, you know, I thought it'd be good to have you come on and just kind of go over what these four are and just highlight them a little bit. Obviously, we don't have time to detail that or everything, but it is. I mean, I think it's exciting. I was excited when I saw that because I remember when I was first at Pivotal almost three years ago now, we were talking with some government agency and I got this this odd request where someone at the end of the meeting was like, oh, can you just send me all the all the white papers you have? And I was I was I was said, like, well, you know, on what topic? And they're like, no, no, just send me all your white papers. And like it was kind of an interesting request.

But I thought about it and like, you know, I like collecting white papers. Like I was saying, I have a whole podcast where we just talk about white papers. But it is I think it's nice to have white papers. And I've read through these. These are these are a lot more Redbook white paper than even number of printable glossy sheet white paper, which is great. So they're actually they're good ones. But how many how many you have planned out? What's in the pipe? You know, we're very XP ish around here. So I don't want you to make any promises of dates other than the future. You see what evolves. But like what else do you have in the works before we get to the ones you have? Yeah, there's I think there's probably about five or six more in the offing that will get out there. So we're not not quite at the at the halfway point here. So what are what are the four you have? Give us an overview and then we'll go through them. Sure. So we've got I think really this to maybe kind of start off with. It's a little bit like the government agency interaction that you were describing there, their Coté, where we've got this constellation of content that we do, you know, at Pivotal. And there's a lot of curation, a lot of generation that we do with that content. And there's always learning that goes on. And we identify a handful of gaps that are really there in terms of how we work with customers and and position your Pivotal Cloud Foundry. So there were a handful of topics that were identified. And so we started with, you know, four of them to start off with. And so we've got one on PCI compliance. So for all the folks out there that handle payment processing, credit card data and they want to improve how they do software, the PCI one will be interesting for them. We've also got one on Bosch, really kind of a 101 on that open source distributed tool chain. And then we've got one on how to run microservices on Pivotal Cloud Foundry. There's a lot of stuff that we've written in the past about microservices architectures in general. So let's get a little bit more specific about PCF as a target platform for those.

And then lastly, we've got kind of an introduction to continuous integration, continuous delivery metrics, what to look for, how to get started, practical advice around that. So that one in particular is pretty product neutral. It's really more about the category of process and tooling that exists out there. Yeah, that one, as I was looking through it as fun, you had some metrics to track. I think metrics in like all newfangled cloud native stuff is always interesting because they're always everyone, you know, always about whatever you want to call cycle lead, whatever, however technical you want to get time, time to actually do something. Think about it and do it and deliver it is interesting. But you had some other, some novel new ones in there that were pretty good. Like I think if I'm remembering right, the one that I thought was good was the not only time to do a build, but maybe time to like run all the tests and validate, time to validate the build, as I recall, which is, that's a fun sort of internal metric to track. Because I would assume you'd like to get that down as much as possible to be shorter. Yeah, and really it's a practical exercise. You know, I think that a lot of us that you spend time on, on Twitter, we all kind of see the cloud or Roddy talking about, you know, things with CICD and moving quickly and all this stuff. But you got to help, you know, a lot of enterprises still connect the dots with how they go from kind of work backwards from being awesome at software to where they're at today. And so a lot of customers would, would tell us, okay, how do I measure this? What do I do? How do I know if I'm getting better? So there's kind of a practical, you know, strain of, of detail throughout all these. And I think that's a good example that you hit on. Yeah. Yeah. I mean, specifically, you know, you, uh, Coté mentioned, these aren't like two page glossies, but they're also not, you know, 120 page book page manifestos. Like they're in that, I guess that sweet spot. Uh, so, I mean, who wrote these conceptually, like who was the audience and what was the point of, of cranking these out?

Yeah, the, it was really, you know, I think we have a unique sales process here, you know, at pivotal and we've got the audacious goal of transforming how the world, you know, build software. And you don't do that by having the customer swipe a credit card and, you know, accept a click through agreement, you know, so a lot of times the sales process or almost every time with the sales process is, you know, our team of account executives, platform architects, um, getting embedded with the customer for, you know, three, six, nine months. A lot of the time, really understanding what's going on in that customer's environment, understanding, you know, what their landscape looks like, what their culture's like, what the application architecture's like, what business goals they have. And so as a result of that, you know, deep collaboration, you kind of identify some key things that the customer wants to, wants to know in order to get better at, at doing software. So this was an effort by a lot of the platform architects who, you know, most of whom have, you know, a couple of decades experience in, you know, IT and business and helping the customers, you know, achieve their, their business goals. They wanted to sit down and address, you know, some of these, um, really burning technical topics that didn't quite fit in, uh, neatly with the existing content that we have at, at pivotal. So it came from, from that group, um, and it was really meant to address, you know, the, the technical, you know, buying cycle of, of enterprises. So you've got your, you know, application developers, you've got, you know, operators, um, you've got enterprise architects, which, uh, we were just talking about a little bit earlier. And then you've got, you know, the security and compliance teams as well. And, you know, very little happens in enterprise IT, uh, as a system of record without security and compliance teams getting on board. So, um, a whole range of buyers, uh, should hopefully find some useful information in the series. Yeah. I know one thing I noticed when, uh, I mean, I guess documentation always seems to trail, obviously, product maturity. I mean, on one hand, when we were asked about this, it was like, gosh, how do we not already have some of these papers? And you just realize that over time, you do need to build up this stable of actual best practices. I remember one of our senior cloud foundry directors mentioned last week that, you know, we were selling the version 1.0 of PCF and they were asking for best practice documentation.

I was like, we haven't even shipped this thing yet. I don't know what the good, any practices are of this. So now we're, you know, years into PCF and have these things in place. Did you feel like as we were putting this together, this is actually did have some of that kind of battle earned experience that we're trying to pass on here? I think so. And, you know, two years in, you know, cloud native platforms is a, is a long time. And, you know, that was one of the things that struck me as we were going through the papers is the depth and the rigor behind, you know, the platform in a lot of ways. If you look at, you know, going down to the very guts of the cloud provider interface, you know, with, with Bosch through the different, you know, four layers of HA, the platform provides to how you can run microservices for Java and for .NET, you know, to how you can, you know, start to think about, you know, meeting these, you know, really onerous, you know, compliance rules. There's a whole, you know, slew of things in there that the platform, you know, has a pretty decent answer for. So that was one of the things that, that definitely struck me. And again, it's not coming from, you know, somebody that is a, is a purely, you know, communications type of role. These are platform architects who have, you know, done hands on keyboard alongside our customers to help make these things real. So again, there's a kind of this, you know, authentic, you know, actionable spirit throughout what we've tried to write. So just to delve into the content a little bit, I'll pick on the, on the first one I wrote down. So in the, in the PCI one, so, so just, just give us a gist. There's, there's always two things with compliance. One is like, so what do you actually need to do? And, and then, and then like give a brief overview of like how, how like the pivotal stack of stuff helps out with that. Yeah, with, with PCI and compliance, like you say, it's, it always is, is very tricky and it's a mix of, you know, product. It's a mix of people. It's a mix of tools. It's a mix of, of process. And so, you know, in that particular, you know, paper, you know, John Field, the author who lives and breathed this stuff, you know, goes through, I think the, the 12 major requirement areas of, of PCI and how the platform is affected by it, or in some cases not affected.

So it goes down into, you know, how you want to configure, you know, firewall rules to ensure certain levels of isolation and segmentation to getting into things about how you think about the, the platform can do auditing and logging and do, you know, access who's, you know, drilled into what, who's access what subsystems to how this, how the platform can actually do things like, you know, patching. There's, I think a, a kind of a unique quirk in PCI where it says, you know, have a, have a documented process and then follow that process. That's kind of what the instruction is. And so in the paper, it talks about where that comes into play for Cloud Foundry, how it can support that particular process with kind of a bare minimum of, of manual intervention. And you want to be, you know, automated whenever you're talking about establishing a process and then following it. And I think there's a lot of that, you know, technical depth in that paper too. Yeah. I don't, I don't know if this is an early draft, but I remember reading over maybe a year, year and a half ago. And I think it was by him, like a, like a PCI sort of white paper that we had floating around. And, and it was great because, because, uh, you know, most of my, my sort of like, uh, computer nerd career life, uh, to word salad it out. Uh, like, you know, everyone's always like, Ooh, compliance and audit. And it seems spooky. And I remember reading to that paper and realizing that, Oh, it's just a bunch of tedious work. Like, like, it's not that there's like some magic thing that you need to do or some, like some impossible thing. It's just like, yeah, it's, you just got to go through all this stuff and make sure, you know, like you're saying, like you should probably patch things when there's a security problem. Right. And, and like, and then there are, you know, there's other, there's other funny little thing. I mean, from our perspective, being infrastructure, funny things like all your desktop computers should run antivirus software, but, uh, it, it's good. And it makes me assume that with a lot of other compliance stuff, it, uh, it's equally demystified in the sense of.

It's not like, it's not like from a, an agile perspective, there's some compliance out there. That's basically like, and now wait six months. Right. Like, like there's, there's no weird onerous stuff in there. It's just a bunch of like things to make sure you're doing, which, which I would imagine, uh, when you get into kind of like a cloud platform stuff. And also when you add a build pipeline to it, you can automate a tremendous amount of this stuff. And more importantly, well, not more importantly, but for some people, you can also automate proving that you're doing it by, uh, well, as long as you trust the system, but you can spit out a lot of what you're doing. That's probably the key, right? Otherwise it often becomes ceremony or theater like, Oh, we, we check this box. We, we did this versus like, here's an audit trail that proved what we deployed into production last Tuesday at 2 PM. You know, here's the credentials we rotated last Thursday. Like that, you know, Jared, I think your point from the paper, I think is key is you have to show what practice, not just, it's not just technical checklist. It's how does this actually hit the spirit of what these things are with PCI or HIPAA or any of these compliance things. It's how is this actually solving the spirit of it? Probably in a better way than you were doing it before manually. Yeah. And I think that's probably the thing with, with compliance is that it's the conversation is really not one of roadblocks and obstacles the way that maybe it has been historically. But when there's a lot of folks in the boardroom of the company excited about getting better at software, going faster, you're building new revenue streams with, you know, differentiated applications. It becomes a question of, you know, how can we be compliant and do this? It's not so much that compliance is a big hurdle. It's people have an attitude of, I want to help the company get better at software. We can't, you know, negotiate on compliance. So how does that play into it? So there's a nice, you know, different buying attitude that I think that we've seen the last couple of years here too. And so, you know, since we were speaking of it, so, so you've got the, the CICD paper, the build pipeline paper, if you will. And, and, you know, I, I, I've, I've been watching this evolve, uh, I guess for about a year or so.

Like, I think, I think while pivotal has been, had some common practices about build pipeline stuff, we've been a lot more vocal about like, this is our, this is our philosophy of build pipeline. So can you, can you give us a little overview of like, what's in that paper as far as saying like, this is like the, uh, this is what the, the overall pivotal community with its customers and ourselves, like what we think a good build pipeline is and things that we use. You know, you know, you know, our idea of, you know, our idea of it. Yeah, I think it's, there's, uh, when we, you think about, you know, CI, CD, you know, the, the important thing is to, you know, understand what the characteristics are of your development, you know, organization. Is your development organization really focused on, you know, velocity? Is it a KPI to think about how many releases that you do in a given period of time? Um, and are you deploying things to, you know, multiple infrastructure targets? That's another thing I think we've seen, uh, be really of, of interest in this, you can sort of be a multi-cloud movement that's come on. Yeah, so there, there, there are a couple of things if you think about, you know, modern, modern development, you know, microservices, velocity, you know, constant releases, um, many infrastructure targets. These are all things that, um, have come into focus, I think the last couple of years and that, you know, mimics what we want to do in the open source project that, you know, pivotal sponsors with concourse. But a lot of these philosophies, you know, really transcend any particular tool and help you take advantage of it. So I think it's, it's really about understanding your development organization and what's going to be important to you over the next, you know, decade when you think about your build pipeline. So I, I, I think, uh, well, I think, you know, CICD stuff, specifically CI, continuous integration is one of the, uh, the older schools of thought in application developments. But I always feel like every time you stared at it for a while, you like learn something new and interesting. And so I'm curious, maybe this would be a very short answer if the answer is no, but like when you were going over this, did you discover any new, uh, interesting things about build pipelines they hadn't come across or thought of before?

Uh, I think, yeah, the one thing that, that came across was kind of the, the visual nature of, of build pipelines, um, places that I've worked in the, in the past would wire up the build system to, uh, a lamp inside the team room. Right, right. That was quite the fad for a while. It was. Yeah. And so, um, that, that's a nice visual cue because when something goes wrong, everybody knows about it and things get fixed, you know, pretty quickly when there's, you know, red lights in the, in the room. And with, uh, with what we see people doing with, with concourse, some of them are pivotal customers. Some of them just use concourse. They've got these huge screens of their build pipelines up there and concourse has a really nice visual treatment there. And it's not just the, the binary, you know, green for good, red for bad kind of thing with the lamp, but it gives you a lot of really rich detail about what's happening. And that visual reminder of, you know, what's actually happening with your code. And when your priority as a business is a ship code, you know, frequently, that's a pretty good thing to have visible for everybody. Yeah, that's, that's, that's interesting. It's, it's kind of like a little bit of a shade of what we were talking about with PCI stuff where it's, uh, it's, it's making the, uh, the unintelligible a little more comprehensible, right? Like it's better than, uh, you know, this really poorly formatted email with probably like a Java stack dump in it. And you've got to figure out what that means. Like that seemed to be the primary interface for a while. And it is, uh, yeah, that's interesting. And it also like highlights what I'm sure was one of the more delightful and challenging marketing challenge, uh, challenges of the mid 2000s, which was, I have this glowing orb that you can hook up to a USB port. Why would anyone buy this? I'm sure they sold a lot of those little glowing orbs and cats based on pipelines. Naturally. So, uh, also, so then the other one, I mean, you mentioned several times as microservices, and I feel like, I feel like this is, this is another one that's kind of like, uh, to some extent writing down and codifying what we think of as our, as, as a pivotal approach and what our customers have doing that, the kind of stack.

So, so similarly, like what's, if you were to give us kind of an overview of the stackish approach or the, the, the approach that we talk about in that paper, what, what goes on in there? Yeah, there's a, a lot of the content about how to do microservices kind of in, in general is, is out there. And so, as I mentioned briefly earlier, this is really prescriptive to how to do it on, on PCF and some of the things that you, you know, get by using, you know, spring boot, for example, you know, kind of the compatibility you have with pivotal cloud foundry there too. Um, and then there's also a few things that we talk about making the leap from the monolithic architecture where, you know, a lot of, you know, monitoring and logging, you know, those were all pretty straightforward because it was just one thing that you had to, you know, think about to now this interdependency. So, so some parts of the paper, you know, underscore, I think some of the challenges with microservices where you have to think differently for logging, you have to think differently for, for metrics, you have to think differently about, you know, a lot of things operationally. Um, but then it also contrasts that with how I think the industry in general has, you know, rallied around, uh, microservices and has answers to some of these, you know, problems like distributed tracing, um, with things like, you know, Zipkin, which we embody in, in PCF metrics. And then, you know, you know, things that we've done, uh, purposefully with cloud foundry, like the logger gator, uh, you know, tool that, you know, aggregates up all the logs from the platform, from the code, all these different components and makes it, you know, a single unified stream so that, you know, it's not such a charring experience operationally. You can still plug into this one, one thing and understand what's happening. So it's a pretty decent look at day one, day two microservices with, um, a practical approach to how things are, are different from the world of, of monoliths. Um, there's also a lot of investment that we've done along with the community for .NET. So it was a purpose thing, purposeful thing for us to work in, you know, windows and .NET into a lot of these papers as well, since, um, you know, microservices isn't just for Java anymore.

Sure. You got it. You got to represent for the glacier swimming holes. Make sure that the .NET stuff gets in there. As always. So, um, uh, uh, I just, I just joked myself into forgetting what I was going to ask, which, which is, which is nice. But, um, I, I think, you know, what, one of the things I always struggle with is to like rattle off examples of, of, well, it'd be easy to rattle off examples of bad microservices, but of good microservices. And, and, and did y'all, you know, along with the platform architects you're working on, did you come up with a, did you encounter and come up with a handful of good examples of what a microservice would be? Other than the canonical books you might like to buy, which, which I think is always, uh, it's always good. There's, uh, some that we talk about, uh, for, um, the insurance industry, financial services, where you've got, uh, imagine say, uh, open enrollment period, um, when there's a new company, uh, that's signed up for an insurance service where this enrollment service, um, may be something new that you want to, that you want to have as a, you know, providing software as an insurance company. You're going to have a spike in enrollment once new customers, you know, come on board your insurance benefit management, you know, type of platform. So being able to scale that independent of your other services, uh, is one example that we talk about. And then in that same vein, um, once you actually have somebody, uh, somebody that's a customer, you know, that that's filing a claim, you may want to scale that differently. Or when it's come time to renew your benefits, that would happen at a different cycle. So just being able to scale the system, um, independently, these different services to correspond to the business cycle, uh, is one, is one thing that we mentioned. There's also a handful of, of reference architecture that we talk about kind of, you know, more holistically this, um, you know, CQRS type of structure. And then some other examples of how you do, you know, data enrichment, uh, event-driven architectures, things of that sort, just to, you know, go a little bit, you know, meta big picture on what a holistic system would look like.

Yeah, that is interesting. So it seems, it seems like you have a nice mix of things for architects, for some operator. I mean, I would assume the Bosch paper is probably the most operator centric. What do you think? Yeah, I think that's definitely, uh, definitely the case. Um, and then we try and, you know, hit those other constituencies in the, in the buying center, uh, with the others too. Yeah, but at the same time, hopefully, you know, if you're a manager, if you're a, I don't know, if you're an architect, if you're a manager, it's good to have some cross-pollination. Even if you're a dev, it's probably good to read the Bosch paper. You know, if you're a operations person, understanding the microservices imperative that devs are thinking through. So hopefully these things are, you know, I know when I look through them, very digestible and folks should be trying to cross-pollinate with their other teams as you're trying to do either fake DevOps or real DevOps or whatever. You're trying to have some empathy. So hopefully papers like this actually break down that barrier just a bit. Yeah. It's, it's, it's sort of like you're talking about, we were talking about what the hype cycles is, uh, you, you could, I guess you could print them out and physically do it, but you could, you could metaphorically stack these papers together. And they, uh, they kind of inform the other one, like, you know, the last one is, you know, an overview of Bosch and, and, and how it's awesome and all that. And it is like just delving. I mean, you even have, uh, I don't know if there's code, but there's a YAML Cody example, but you give a, with some diagrams, a pretty good overview of like the way this works and therefore how it works. And therefore why it enables all this awesomeness up the stack of, of automating things and helping you scale and things like that. And I think, uh, I think, I think it's, it's a good, it's a good way of explaining how, if you sort of, um, I was talking about this with someone earlier today. If you sort of homogenize the, uh, the lower levels of infrastructure, so you don't worry about them so much. And, and as always you trust it and it working is key. That's a good requirement. Uh, but if you do something like, you know, uh, automate your infrastructure and do all your health checks and basically keep your infrastructure healthy with something like Bosch and be able to run on multiple clouds. It, it, it gives you a lot of latitude to, uh, do all this stuff up the stack all the way up to, you know, the PCI level where now you can actually trust the automation that's going on and the automatic enforcement and how that gets supported by deploying with build pipelines and running microservice and the fault tolerant type of stuff.

I don't know if the microservices people would say fault tolerance, the resilience of microservices. Um, but it all kind of is, is possible by the, uh, as we've talked about in previous episodes by the scary clamshell, which I think, I think y'all, uh, y'all have done a good job unscarifying. I don't know what the opposite of scary is, but, uh, that's, that's a good overview. Yeah. Hopefully the, the Bosch, uh, as a project is more approachable. Is that the opposite of, of scary maybe? Uh, but yeah. And like, like Richard was saying, you know, the cross-pollination of, of content, you know, a lot of times we talk about the contracts you have between components. And we like to say, you don't need to care about that, but maybe you can take 10 or 15 minutes to read a paper, to find out, you know, what your operations team might actually be doing, you know, to give you, you know, this resiliency and, you know, the other things that are essential to you as a developer. Cause in, in reality, all these, you're trying to break down these silos and share information. So, um, hopefully a lot of folks find the good information and all of these, regardless of what their, what their role might be. Yeah. You know, because I'm such a, uh, moderately fast scurrying flanard across all this cloud native stuff, I never actually go investigate this, but I always think, I always think it's, it's interesting to look at the, uh, the cloud provider interface, the CPI, uh, that Bosch has. And, and to kind of contemplate like, are, is this the minimal set of functionality you need to run any piece of software? Right. And, and every time I look at it, it seems like it, right. I mean, obviously you need to install the software. So that's good. And then you need to configure it. And then you need to see if it's up and running. And if it's not up and running, you should get it up and running. And there's, I think like, you probably remember better than I do. There's like 18 or 20 different methods that you implement, but it almost feels like that's the bare minimum you need to actually run software on computers, which is, which is, uh, it's a, it's a curious thing to look at every now and then in a good way. Well, do you have any other, uh, did you get any other, uh, like fun insights as you were working on these papers that you wanted to throw out there before we wrap up?

Uh, just hopefully that a lot of folks, you know, find it, um, pretty easy to read. There's been some good feedback about that. And so for a lot of these things, uh, the, the secret sauce for me has been, uh, the Hemingway application that, uh, allows you to copy and paste some, you know, text you've written and gives you a readability score. So that's been a bit of a cheat sheet to, uh, you know, help make sentences shorter, digestible, use more forceful kind of language. So, uh, for aspiring writers out there, that could be a good tool to check out. So the papers have been run through this, uh, Hemingway filter. So hopefully it, uh, it, it makes it more readable regardless of people's personal feelings about Hemingway. I mentioned that then people go into tirade about how they feel about him as an author, which was not really the point I was trying to make by mentioning it. Yeah, yeah, you know, I, I think, I think Richard mentioned this earlier, but yeah, the papers are extremely readable. So, uh, good, good job on, on y'all doing that. Yeah. You know, I think, I think when it first came out, I tried to use the Hemingway application. I think I brought down the internet, so I should probably not put things I write through that, that, that would not be good. But, uh, yeah, but you know, since, since you evoked, I think Hemingway was a great author. He's like, he's like one of my two favorite authors. So he did a good job. You could do worse than reading him. I mean, if you want to be fancy pants, you could go read a bunch of Faulkner and kind of get the same effect, but, uh, Hemingway is good stuff. Well, with that, this has been another Pivotal Conversations episode with a little, uh, literature nook, uh, visit for you. Uh, as always, if you want to get the most recent episodes or see all the old ones, and we have some little playlists there of kind of sub runs that we have with various analysts or with, uh, customer interviews that we've done. And you can go to soundcloud.com slash Pivotal Conversations. I saw that someone decided to infuse some cash into soundcloud. So they'll be around for at least another year. We'll see how that works out. Uh, it's a fine place to host podcasts. Uh, if you want to, uh, reach out to us, uh, I am Coté, C O T E and Twitter. How about yourself, Jared?

I am Jared Ruckel at Twitter. J A R E D R U C K L E. And yourself, Richard. You can find me at our Saro there. So all, uh, all hot takes welcome. And about every Thursday, if I'm doing my job, uh, moderately correctly, we'll post the full show notes, uh, at pivotal.io slash podcast. In addition to it being on soundcloud. And we'll have links to those papers and, uh, to the Hemingway application. If you, if you don't want to use Google, we'll put, we'll put that there. And the news items we talked about, and it's always good. If you just, uh, if you're listening to this on the web or you've downloaded it to, um, I don't know, some sort of moto razor that you still have manually. You should just subscribe to the RSS feed, which you can find in whatever you listen to iTunes, Overcast, probably Stitcher and, uh, have, have a listen there. And, uh, it's also great if you give us a star or a, uh, a review in iTunes. That's, that's fun. And I understand it helps things out. Also, we have several other podcasts. We have one called that moment that you can search for. I think the third episode of that is out and that's, that's a fun podcast going over as the name would imply sort of the thinking that people went through when they decided to, uh, finally start doing things in a better way, or they realized they needed to. We also have, uh, pivotal insights. I just listened to a really good one, uh, talking with, um, one of the people who heads up our modernization, our application modernization practice. And, um, it was really good because it was, went over kind of like the methodological way that they figure out, uh, what to modernize and how to approach it. So we got all sorts of stuff going on there, but with that, we'll see everyone next time. Bye-bye. Do we lose Mr. Coté? I'm here. I was, I was on mute. Now I have to go edit this. This is terrible. Yes, you do. Damn it. Let's see. Around 6.30. The rolling cooler helps for podcast editing as well. Yes. You got to get a rolling cooler. And, you know, you want to investigate having big wheels on it. You don't want to get those little wheels. You got to get some big wheels.

I've got them at Costco. I've got them at Costco here. So they're ubiquitous. Hmm. We do need to get a new cooler. So I'm going to check. I don't want to go get a Yeti cooler because that's a lot of money. And then also like someone's going to steal it. And then it's, I feel like it would be the equivalent of like leaving a box full of iPhone seven pluses just at your campsite while you went out for the day. And that's not good. Had to put that as a little jokey thing at the end there. Don't want to waste content. Anyhow. Uh, so yeah, what was I saying? Well, anyways.

Tanzu Talk · 🍕 Get more pizza.