Learning cloud native architecture and coding, with Michael Barinek (Ep. 84)

Episode 69 · 45:50 · SRT · archive.org · all Tanzu Talk

All right. Well, what I want to talk about as we open up. Well, first of all, you want to briefly introduce yourself, Kest? Sure. My name is Mike Baranek. I'm a VP at Pivotal, and I now run what is called our education and enablement practice for customers and partners. Well, that's something I can always use more of, so that'll be fun to come back to. But here's what I wanted to ask you all. So we're in this whipsaw weather stuff. It's time for the weather update. Everyone enjoys this. And it's warm, but I feel like it's just cool enough that I can pretend like I live in Orange County and wear shorts and a hoodie, which is exciting for me, like I'm in a Veronica Mars episode or something. But let me ask you this, both of you. So I always have lots of issues with a hoodie, primarily because it has sort of like this soft outerness to it. I feel like I need something more rugged than like a soft outer thing. Like if I get stuck in the rain, I'm going to get soaking wet. So, you know, are you all big hoodie wearers? And then do you wear like the kind of like more structurally sound waterproof outside? Like what can you give me over here? I feel like I need some sort of more assurance in a hoodie than just cloth. Wow, that's a, yeah, you put a lot of thought into this. So I'm actually wearing one today because up here in Seattle, it's like a high of 50 at the most. I was in the Bahamas last week, so my entire body is messed up at the moment. And I was not wearing a hoodie there because I was living dangerously. But yeah, no, I go with the regular cloth hoodie. I don't go with like the slick kind. It's just up here, if it rains, you just have to accept it anyway. No one uses umbrellas. How about over there? I know you're only temporarily in St. Louis, right? But what are they doing there? So I typically go sweaters. And then some of the sweaters, you could catch a lining for the wind. So the Colorado, you know, where I am most of the time, heavy winds, little bit of snow, not a lot of rain.

So the sweater with, you know, a bit of a liner in it goes a long way throughout the entire... Now, that's fascinating. Now, what is this liner thing? Is that like one of those synthetic fiber shirts you put underneath? Like, or just a normal t-shirt? What's a liner? Yeah, think of that rain jacket, you know, you'd put on the outside and that's on the inside. Oh. So kind of the wind protection, if you will, but then the sweater look and feel. Windbreaker, they used to call that, right? If I recall. Windbreaker plus sweater. Yeah. That's the new combo. You know, you know, before we get to the news and then the actual technical stuff, this reminds me of one more thing. I was, my daughter had her, how old is she? It's probably important that I know that. Her fourth birthday party and she had a Wild Kratz theme. So of course, everyone made a vest. Not everyone. My wife made a bunch of Wild Kratz vests, if you're familiar with that. And so we had to buy nine size 40 t-shirts. And so it's hard to find that because they failed to deliver them in time. And I went to like Sears and some other department stores and they had like white label in-house members only jackets. And I felt like I should have almost bought one of those, but I didn't because I feel like that would satisfy what I'm looking for. I was just about to make a members only joke. And when you're talking about windbreakers, I can't believe you pulled out the members only garments. Exactly. I mean, it's from the same era, right? When all of our grandparents were still alive and there were windbreakers and members only jackets. And like, you still see this with some older people is there's almost this uniform of what looks like a dry cleaned windbreaker or a members only jacket and maybe some casual slacks. And then a lot of, a lot of standing there looking bored, holding your hands behind your back. I think, I think that's a look that maybe I should look into. Some iron jeans. We can get you there at some point. Oh yeah. Some rain. That's good. No, that was a good pull there. It was only our chemistry has never been better.

That's right. That's right. Well, uh, but before, before we get back to, uh, to, to Mike and feel free to join the news, there's just a few items. I think news wise to go over, uh, like the, the OpenStack summit was in Sydney, uh, last week. Now, for some reason, I didn't figure out some reason I should be there. So I could go back to Sydney. That's terrible. I need to write that as a, uh, are we doing annual performance plans yet, Richard? I need to put that in there. They have to. Yeah. Make sure we get this on your record. But, but I think, uh, I think one of the more interesting things, I mean, there was, there was some, uh, some messaging and positioning of, uh, you know, the, the, the continued spread of, of OpenStack in Asia and particularly China and based on their, their community survey and, uh, something about people using multi-cloud or hybrid cloud as they were, they were calling it. And I think there was some mention of, of, uh, edge, which I still haven't really figured out what that means, but it sounds cool. Um, but I think more interestingly there, uh, as they often do, they put out their community survey, which kind of confirmed a lot of these things. And, uh, another thing that was in the community survey they had was they, uh, they asked people what, I forget what they call it, but application infrastructure, uh, sort of, uh, things that they put on top of OpenStack. And I think, uh, I think Kubernetes was the top one that people were installing on top of it. And cloud foundry was in there with a few other ones, but I, I, I'll have to look back at the previous surveys, but I don't remember seeing that a couple of years ago when I would, uh, look at this stuff. So you get more of a sense of the, uh, sort of demographics of people with OpenStack installs types of company and, uh, geography, and then a little bit of, uh, what kind of container orchestration. I don't know what to call that layer that people are running. And then they didn't put this in the PDF, but if you go to the dashboard, you can look at the workloads that people are running, which if, if, uh, if you're not someone who remembers what members only jackets are, workloads means what you use it for the type of software you run on it. And it's interesting. I always hate this one category that people have, they call it, uh,

infrastructure services, which sort of begs the question for what? So that's kind of a bummer of a category. But then also I think there was like 30% or so that was for like, basically, uh, your, your, uh, software development and QA kind of like you're working on the project. Uh, what would you call it? Uh, staging stuff, which is also another weird category because again, it begs the question of for what, uh, but whatever, it's fun to go look at that dashboard and kind of poke around what, what people are running on these things. Yeah, very much. Yeah. Some other OpenStack news. I saw this morning that, uh, HP and Rackspace are doing a pay as you go OpenStack. And so it's interesting resurgence for people who are, again, again, you mentioned that survey shows multi-cloud is alive and well, this idea of a true pay as you go, not a long-term commit is interesting. So yeah, I guess don't, you know, don't write it off yet. It actually some interesting use cases and people are putting some good things on top of that. Cloud Foundry, Kubernetes, a number of things. And hey, if we can make it more interesting by not just focusing on infrastructure, maybe OpenStack, it's more interesting again. Hmm. And then, and then, and then somewhat related, there's a, uh, you know, I don't know if they actually run OpenStack in this, but there was a long, uh, sort of, uh, the kind of, the kind of, uh, since I don't actually like talking to people like coverage, I love doing where you just go read the internet and write a bunch of stuff instead of talking with people, but over at, uh, it's mostly like an ERP sort of news site called Diginomica, but I think I forget what they call it. But, uh, there's an interesting writeup of how SAP is using Cloud Foundry and Kubernetes and how it's kind of being threaded through their, their new things, which I think I've, I've been curious as a subtopic about the idea of for all of these cloud native platforms, what's the, uh, I don't know what people call it nowadays, but, uh, whether it's off the shelf or COTS or ISVs, what kind of like off the shelf stuff people are writing to that to be installed as images. So it's a pretty lengthy piece kind of well, uh, cited if you will, uh, which is to say it goes to lots of sources,

not that it's good at looking at things. Uh, and, uh, it's a nice overview of what, what big old SAP is doing there. And then also there was a little, there was a little mention. I forget maybe this came out through quarterly calls or I don't know why this became a story, but there was a mention of like Kroger and other people, as you might expect, not being too cool with running their stuff on AWS. And so showing, showing kind of the trend of retailers and, and grocers, which I guess are a type of retailer, uh, definitely being interested again in the multi-cloud thing, which is to say not only on Amazon, I guess, and how they're, uh, looking forward to that. Mm-hmm. It was an interesting story. I mean, Kroger will be talking at, at SpringOne coming up to plug that about some of how they do kind of cross cloud CICD and use spring and other abstractions that help with that. But, you know, I'm sure Amazon's not losing sleep over, but at some point you do have to think about how do you kind of do this frenemies model where you don't feel like this, you know, my, my key sourcing providers about to compete with me. It's, it's a tricky, uh, it's a tricky world with them right now, but that's where multi-cloud abstractions are awesome because your risk is a little less if you need to move somewhere else. Yeah. I forget if we mentioned this in a previous thing, but I remember reading some revenue breakdown for, uh, for Amazon as a whole. And it was something like, like 30% of retail revenue was basically them being a, uh, I think as Gartner would call it a BPAS, a business processing, like they, they do all the logistics and stuff for other retailers or something like that. I guess that's like the marketplace you go to, but it does sort of raise the interesting thing of, uh, what if they're really good at like your omni channel stuff, but they're also your competitor, but then they'll sell you those capabilities. It's kind of like all the hand wringing people do in the media about Facebook where they're just like this innocent looking platform. And then they sort of just, you know, use you as blood transfusion for their business essentially, which I guess lets you live on satellites or something. So not related to satellites, but also, uh, there was a post that it's the 15 year anniversary of Red Monk, the little industry analyst firm. Uh, you know, I used to work there,

which was thrilling, but it is a good, uh, a good overview and it was, it's fun to think about all the stuff that they've been involved in. Uh, you know, I mean, I think, I think the hallmark of what they, the hallmark, the main thing they started off with is, you know, having blogs way back when is where they published their analysis and then they covered open source and developers and cloud and all the kind of like, uh, commercialized rainbow and sandal kind of stuff. And, uh, you know, I think pretty, and nowadays they, they do all sorts. They, they, so I think one of the things they're more popular for is their programming index. And then of course, ongoing coverage of, uh, what's going on in the infrastructure area, but yeah, they've been around for a long time. I guess it won't be that long since they'll be, uh, they'll be 20 years old or so. Yeah, definitely unique. It's easier for them to stand out in industry of which, you know, you and I and others talk to a lot of industry analysts as part of our day jobs. And I know I enjoy talking to all of them. They're all good conversations, but the Red Monk ones just come from a different place as I think they're a little more in the trenches with some folks than, than others. And it's really good candidate advice. And honestly, if you're a large software vendor today, who's not talking to them, I think you're at a disadvantage. So it's funny how you're able to grow up into that in these 15 years. And we're glad to have, uh, stolen Coté. That's right. In a roundabout kind of way with a roundabout way. That's right. So, and then I just wanted to highlight one thing, just some research that, uh, that I've been doing, you know, I like to, uh, if you see me talk ever before I talk about this, uh, this IRS case where, uh, the IRS applied a bunch of like agile and cloud native, you think, to, uh, help people pay their back taxes. And I was coming, I came across a whole bunch of, uh, publicly written up sources about how the, uh, the air force had transformed this tanker refueling process. It's like a literal digital transformation where they had this analog process of a whiteboard. And, uh, and then they decided that was a bad idea. And instead they, uh, I guess they worked with pivotal actually. And, and through, there's this little outfit in the, uh, the

department of defense called DIUX, which is all about, Hey, procurement's pretty awful around here. We should do it differently. And so they, they worked with them to, uh, digitize it fully and, uh, basically have a application that does it for them. And so there's, there's been, uh, someone must've done a PR campaign cause there's about three or four write-ups of it out there, mostly in the, I don't know, military trade press, if that's a thing, but there, there's a few other write-ups. And if you're really into it, there's a video of the, uh, I forget what it's called. The like defense innovation board. And it's like this two hour video that if you scrub through it, you can see them presenting, uh, about this process, but it's a good example of a, uh, before and after of, you know, for example, a lot of what's quoted in there is that normally if they want, had a, had a project, a software project, and they had an idea for it and maybe not one feature, but they wanted to do something like this. It would normally take like four years or so all in to, uh, have the idea and deliver it, but because they, they, uh, were agile basically and did things as you would hope people would do things in software. Uh, it only took them about 120 days or so to do it, which is a huge, uh, if you follow government IT at all, it's a huge speed up for doing things. And then of course, you know, you don't have to update a whiteboard to figure out how to refuel, you refuel all these jets flying around, which is probably quite astonishing, but I'll, I'll, I, there's some links in the, in the show notes to those write-ups, which I think, uh, I don't know. It's, it's a fun case to look at. It's a lot better than, uh, the usual sort of, I don't know, like, uh, you know, talking to a stick to order more, uh, fabric softener stuff. That's right. And if you really liked the story, uh, Lieutenant Colonel Enrique Adi, who leads up that group is going to be speaking at SpringOne. So he'll be on stage giving a short version of this, this kind of summary and the business impact. Yeah. He's the guy in that lengthy video. Uh, if, if you want to go see that he's, he's, he's a good presenter. As someone jokes, he'll have to remember when he's a three-star general

that it was all about this little tanker project, which I, I guess that's an encouraging compliment to give someone. Three-star seems a lot higher than Lieutenant Colonel, as I recall. So, uh, so let's bring our guests back. Why don't you, why don't you tell us what you do around here? Yeah. Um, so this is Mike, as mentioned earlier, I run our education and enablement group and that includes three teams. So one of them, uh, pivotal training, another, the platform acceleration lab, and then the third developer enablement. So pivotal training, you could think of as a bit of, uh, traditional enterprise training, a bit more of the one-to-one pairing with our products and courses, the PAL or our platform acceleration lab focuses a bit more on how we work and ensure just naturally the technologies we work on. And dev enablement kind of recent to the, the portfolio, if you will, focuses on helping customers stand up their own cloud native center of excellence. So they could move forward without, uh, my team being attached at the hip forever and ever. Mm. So, I mean, to that last one, as you think about the way you work and the kind of the architectural aspects of, of some of the development back when you and I first kind of hung out a few months ago, and I think it's easy. Sometimes pivotal talks about the cultural change. We talk about the technology change and you were really adamant that you can't lose that kind of third leg of the stool, which is the architecture and thinking about, you know, it's not just about having a good way of working and then dropping things onto a cool new platform. You have to rethink how kind of what you're building and how you structure it. So do you feel like, I mean, which of those things you just mentioned, those kind of three programs really focuses on the architecture and, you know, what, what kind of things are we helping people figure out? Yeah, definitely the PAL, you know, jumps to mind. There's a bit of dev enablement as well. Um, maybe it helps to talk a little bit about the PAL or go a little bit deeper.

Yeah, please tell us about, uh, kind of where that came from and what it really is. Yeah. So I think it helps to talk a little bit about maybe pivotal history where, you know, kind of being an XP shop, um, you know, naturally we would, we would pair with customers and, you know, for a long time that worked out really well, um, with the scale though, and getting folks to kind of, uh, be a bit more cloud native, you know, we bumped into things with partners, you know, how do we teach both partners and, you know, customers at the same time? So the PAL was originally created four partners, got, got by the name of Nick KU and alliances, you know, said something like, Hey, we need a solution here. You know, we have a ton of folks, you know, working with our customers these days, and we need to get them ramped on all things cloud native. So that became kind of, you know, first conversation around, Hey, let's, let's kick off this thing, you know, IE platform acceleration lab to really train partners on all things cloud native and a bit of the success of the PAL moved to customers, uh, now as well. So for example, I'm in St. Louis today, uh, teaching a new cohort, uh, the first week of the PAL, which is what we call cloud native developer. So what, I mean, so that, that's great. What are we teaching though? I mean, what are we, why would an SI who's been in business for 50, 80 years come to a four year old company? Obviously there's a history we have beyond that, but why would you be coming to this company like us saying, teach us to be more relevant? Yeah. So I think it's a few things. Um, there's a bit of the, how we work. So patterns practices, you know, how we tackle things like replatforming existing apps or moving them onto pivotal cloud foundry as well as then modernizing applications. So you could think of replatforming, you know, Hey, let's get apps to run on pivotal cloud foundry and then modernization. Let's get them to run well on pivotal cloud foundry. The first week of the PAL, you know,

backpedaling a bit, we actually paint a bit of a reference architecture. We introduce things like, you know, cloud foundry for the first time, potentially spring boot, spring cloud services, you know, have discussions around architecture, microservices, you know, when to make that jump from kind of a well-factored monolith to, you know, a full-on distributed system. I think just the, you know, platform as a service, you know, as a whole, there's just a whole new way of thinking about apps and the apps in prod. And the PAL is really the first introduction for folks to that. What do you, I mean, when you think about that though, and some of those architectural changes, what are those things that you've discovered you kind of bump into the most, especially as you're talking to consultants who've maybe been building custom apps for years or focused on just hooking together existing commercial apps? What are some of those big hurdles that someone has to get past when they have this app mindset and this custom dev mindset, distributed systems sort of concept that you preach here? Yeah, I think the first is just knowing when to make the jump, knowing when to, you know, decompose that monolith into a microservices architecture. I think there's a bit of, you know, being able to look at a bounded context or a domain and say, yes, that is, you know, its own separate component, separate service that we need to deploy and potentially scale differently than the rest of the overall system. Interesting. Yeah. I mean, are people coming at you with that with monoliths typically? I mean, is that how most people are starting with you or people doing classic SOA sort of concepts and you're rethinking that? How do you help someone think about tackling their existing architecture and actually decomposing it? What are those steps you're helping them walk through? Yeah, there's a couple of ways. I guess most folks, you know, start with, you know, hey, I have this big app, you know, what do I do? I think I talk about maybe outside in as well

as an inside out approach to that decomposition. So outside in, you could think of as more, you know, stepping in front of an API, maybe internal to the system and then creating a net new service, you know, so that might be a message queue that you step in front of or a database connection and say, hey, we're going to, you know, not use the existing in favor of something new. And that turns into a bit of, let's call it for the moment, greenfield development or adding new services. There's also maybe the inside out approach where, you know, that one you could think of more heavy refactoring. So, hey, let's take that code base that may have been broken out into model view controller directories and actually start looking at, you know, where the seams are in terms of those bounded contexts so that you'd be this language. And so the outside in approach, you know, handful of techniques that we teach there. I think the PAL is a little bit heavy, though, on the inside out, really teaching folks, you know, how to refactor, how to move code around. You know, we heavily use Gradle, you know, to start breaking out those components. And then they eventually make their way into their own Git repo where their lifecycle, you know, becomes their own lifecycle as opposed to attached to that monolith. And then do you like I always come across a lot of methodologies for like modernizing and they always have some cutesy little name to them, of course. But like, I mean, is there like like so so you sit down there with the people, the people and and they're like, so we got like 500 applications. And, you know, if you if you can modernize them this week, that would be great. But we probably also live in reality. So let's select some to work on. So how do you like go through selecting ones to target and work on? Like what kind of attributes are you looking for that are good or bad that would make it a good candidate to, I don't know, tell people how they would modernize it, find the seams as

it were. Yeah, I think it's important to maybe just break apart the or talk about replatforming and modernization as two separate things, meaning that the replatforming, you know, we're targeting, you know, those 10 apps that we could quickly get deployed onto Cloud Foundry, Pivotal Cloud Foundry. And, you know, you could imagine something along the lines of, you know, simple app that has a database, that database connection, they're getting from JNDI. And now they need to get that connection from the environment. So there's a bit of just simply, hey, let's get it deployed. Let's watch it break. Let's write a test that ensures the page gets rendered based on some data within the database. And then let's get that test green by hooking in, you know, the database via the environment. So replatforming, think, you know, a bit of the push approach, you know, so let's push a lot of apps onto PCF, see where they break, and then get them running. The modernization bit, you could think of as more of maybe the pull approach, that earlier example I described, where we may pull out, you know, a net new service in favor of kind of the overall, you know, or a path towards that overall decomposition. Techniques, you know, think of a lot of the apps that we're looking at are maybe traditional EE apps that maybe if you think of the 12 factors is a good way to think about replatforming. So a lot of the things that 12 factor apps do, you know, kind of address some of maybe the bad behaviors that have been, you know, kind of known within the EE space. So anything like writing to disk or, you know, not preferring the environment. So really replatforming, you think of getting your app healthy in terms of those 12 factors. But then sure, modernization, you know, bit more heavy lifting there, you know, think significant code changes, you know, we're breaking

apart repackaging, you know, versus very little code changes on the replatforming side. Does that make sense? Does that help? Yeah, yeah. Yeah. And do you find there's like a, like, like a repeatable process you go through to do those that selecting? Or is it just kind of like you're saying, it's let's find the technical attributes that fit well for this, and then we'll work on those. Or is there other inputs that go into deciding what what would be good to look at in both those situations? Yeah, I think when you're looking at the larger portfolio, I guess, from my perspective, there's a bit of, you know, hey, let's take some of the easy ones that we know will move over, you know, really just to start getting feedback, you know, putting together these kind of cookbooks of best practices. You know, when you tackle the example, I mentioned, you know, hey, we need to get the data source via the environment, versus JNDI, you know, we'll document that, and then leave that cookbook behind for other developers to, you know, be able to follow same, you know, patterns practices without kind of rediscovering, reinventing the wheel each time. But I guess from my perspective, there's a bit of, you know, take some of the easy ones, even the easy ones are going to give you a lot of feedback in what, you know, some of the more complex applications look like in terms of re-platforming. And more of the complex apps naturally become, you know, candidates for modernization, they just move through that re-platforming step a little bit faster than most. So when, as you were mentioning, you know, a lot of this is, I don't know, you could call it training, education, evolving. Yep. And I imagine, I imagine you're in a situation where you're kind of like, you have a room full of people who are learning to do things in a new way. And like, I don't know, how do they usually receive it? Are they, are they like into doing things in a new way? Or are they like grumpy? Or like, what, how do people usually react to this stuff? What are the two or three types of reactions they have ongoing?

I think most folks are genuinely excited. There's a bit of, you know, some of the Pivotal Labs practices that we'll bring into the PAL. So we get folks pairing early on, we get that conversation going. You know, most folks, you know, after the first few labs, look at this as a bit of a breath of fresh air, you know, a bit of thank you. Thank you, Pivotal for, you know, putting together Cloud Foundry, as well as, you know, Spring, Spring Boot, you know, supporting that community as well. I think folks walk away with just a, you know, whole new understanding of, you know, how to build distributed apps at scale. And what's, what's your sense for like the, the existing ongoing education that most organizations have, like, and, and this is a bit of a loaded question. Like, my sense is that most organizations don't spend a lot of time training their staff and educating them. But I don't know, maybe I'm wrong. Like, what are you encountering out there as far as what the ongoing education is that people are getting? Yeah, it's, you know, there's not a lot. I think even with, you know, the first week of the PAL, we get a lot of pushback on, you know, hey, four or five days, that's a big time commitment. I think the, the shift right now, though, in the industry is pretty big. I think, you know, students, once they're in the class, it's, oh my gosh, you know, I've not only, you know, this week, but I've, you know, another three months to dig in after, you know, I leave the class, whether it's the first week or the full three-week program. I think folks are starting to realize, you know, our customers, a lot more are signing up for, you know, full PAL cohorts, whether that's in a pivotal location or one of their locations and, you know, are starting to acknowledge, yeah, hey, this is different. It's not just, you know, another library that we're using. Cloud Foundry is not just, you know, another piece of middleware. This is a big change and we need to get folks immersed.

So one of the things I've been struggling with recently, or I don't know, maybe over the last few years when I go out and, you know, try to give people the good news, as it were, is like, I was just talking with someone about this last week, that like, it's almost unbelievable, right? And, and, and it's almost the sort of improvement that you would have. And, you know, we have these, these fun little t-shirts that are like, you know, eat dinner at home instead of at your desk and, and all sorts of like life improvements and stuff like that. And so I wonder, like, other than actually walking people through doing things in, in a newer way, right? Like, as, as I would sort of snarkily argue, like actually doing agile software development, like supported by all of this, you know, fully automated platform stuff, like, I, you know, experiencing something firsthand, that's a good way to like experience it tautologically. But like, have you figured out any other ways to kind of like tell people that like, this is going to be awesome, like before they try it, or do they just have to get hands on with it? Yeah, handful of, you know, articles out there. I've, I've put a few together myself. There is something interesting about that hands on nature of some of the programs that we have where, you know, folks show up and they write, they write software. We'll even screen folks before and, you know, make sure, hey, you know, you've programmed, you know, last week, last month. There's something about just diving in and bumping into, you know, the problems at hand. A great example is, you know, think of the, the Equifax breach, you know, one of our labs is, you know, simply struts to spring, you know, where we take out, you know, existing struts controllers in place of, you know, spring MVC controllers, REST endpoints. So there's, there's something interesting about just getting hands on seeing it. And sure, there's naturally a couple of places that we've introduced, you know, pitfalls for folks to fall into intentionally so they could dig themselves out of it. Sounds like an exciting video game. We got to put some challenges in there every now and then.

Yeah. Yeah. I've, I've enjoyed watching you do this beyond just Java now though, right? Cause you're doing this for .NET developers as well. So this isn't just a, let's kind of get you well-versed in Spring Boot, Spring Cloud. I believe you're, you're stretching this further. Am I right? Yeah. So, uh, it's interesting. It's almost the same app that we build, distributed app that we've built, um, except we're using .NET Core and then SteelToe, which you may know integrates with Spring Cloud services on Cloud Foundry. Uh, Microsoft is, uh, interesting these days, you know, for me, um, it's always been a bit about, you know, how I write software and sure that the, the, what normally, you know, kicks in at some point, the, the Java and .NET worlds have really come together where, you know, day in the life, it feels like, um, you know, very similar, uh, in terms of programming. You know, I'm a fan of C sharp and we've written the first week of the pal and .NET. I think we have a trial beta course, the 15th, maybe of, uh, or the 11th of December coming up where I think you're actually invited to, to come through it. I think that's right. Yeah. So, I mean, that also fits into, and Coté touched on this with kind of, you know, how do you have some repeatable methodology? How do you have some even leave behind? So tell me about the app continuum. When you first sent this to me, I think in a Slack chat or something, what the heck is this? But you've put together this kind of exercise, if you will, it even works for, for Java and .NET. Can you describe that a bit? We can put a link in the show notes for people to check it out. Yeah. The intent is to describe kind of the evolution of a distributed system, you know, the kind of starting at the point where, you know, Hey, it may be just fine to have, you know, a monolith at first, especially if you don't see product market fit, you may not want to spend a lot of upfront, uh, time upfront on design or, you know, operational features.

Uh, so the continuum, you know, walks you through, you know, that first commit all the way through kind of a well-factored monolith, if you will, down to, you know, microservices architecture with three microservices dependent on a fourth. You know, we talk about things like, you know, how to version your API, when to tease out databases, but it's really meant to give folks a kind of a hands-on, Hey, here's a code base of maybe what your code base would look like as you're building these days, especially if you want to be positioned for, uh, you know, evolving that system over time. Yeah, I like that. Good. One of the other things I wanted to ask you is, is you have a kind of a front row seat in your work with, with Nick and our partner team, as well as our kind of education teams for how some of these companies now are trying to figure out how to actually kind of seed and scale their, their transformation, their learning, all that sort of thing. So how do you see companies starting to try to actually do real education strategies? And Coté or either you or Mike mentioned, there's not the same sort of investment in people sometimes nowadays is these big in-person training exercises we had 10, 20 years ago. But how do you see modern companies who are trying to make sure that they actually stick your transformation, take these different sorts of options, right? Pal and, and pivotal labs and self-paced training and all these sorts of things. How does that come together for the, for the best companies? Yeah. And one thing we didn't dive into it, but there's the dev enablement, uh, team that I'm, uh, putting together. And again, it's this kind of notion that, anybody who's making that cloud native jump should have their own center of excellence, best practices. You kind of talk about things in maybe four different buckets, one being, you know, all things app architecture to the extent of maybe having, you know, their own reference

architecture that favors, you know, tools, sign on, you know, whatnot that they, uh, prefer, you know, over just maybe the pivotal reference architecture. Another is just tool chain, uh, you know, decisions between Gradle versus Maven, IntelliJ versus Eclipse. Uh, another might be early spikes on new platform services that open up, uh, kind of doors for new apps or existing apps to get on the platform. And then that third, you could think of even the PAL content, you know, our customers, you know, folks who are embracing cloud native to also teach, you know, portions of the PAL or portions of, uh, pivotal training. And we call that more of our train the trainer model where to truly scale, to truly kind of continue, uh, you know, again, without us, you know, somewhat attached at the hip pivotal training PAL team attached at the hip forever and ever, there's a bit of, you know, Hey, you should take on, you know, kind of this modern way of, uh, teaching folks, you know, this kind of highly immersive, you know, hands-on instructor ratio, maybe, you know, more four to one instead of 10 to one. And instructors may be people from the field, you know, that are coming in and, and teaching lessons learned, you know, really teaching their experiences. But I think that, uh, that team, we've seen a lot of our customers stand up that internal team, whether it's, you know, uh, dev enablement center of excellence, kind of pick your, pick your term, but that's really, you know, how to accelerate and continue, you know, moving forward around that education enablement path. That's awesome. So I have one more for you. So I think I was sitting in a, uh, some sort of executive thing where you were there and I was amused by the fact that you were hacking away on code as well as a couple of other exact types that pivotal do, but you know, you still build stuff. You're not a, uh, you don't do architectures and PowerPoint every day. So what are you having fun building right now? What's getting you excited? You know, technology wise, what's, uh, what's in your toolbox right now?

Yeah. So mainly, you know, think Java programmer for years and years, uh, spent a little time writing Ruby, little time writing go. I think for me, Kotlin, uh, I think I tweeted this maybe last year or so that Kotlin plus Elm is going to be the stack of, uh, kind of 2017, maybe even 2018 now, but I'll, I'll write a lot of Kotlin. There's just something nice about, um, you know, being a better Java, you know, so same SDK, same tool chain for the most part, it's really just less verbose. Uh, so a lot of the tools, uh, apps that we write internally for the PAL pivotal training dev enablement are mainly Kotlin and then Elm, you know, there's something nice about Elm as well, being a Java developer. I think, you know, front end feels like every other year there's a new front end technology. Uh, Elm has at least stuck for the past year and a half, maybe, uh, maybe two years now for, for my team. Awesome. You know, along those lines, the, the, the, this, this wasn't a planned topic, but since you mentioned, uh, coding there, my, uh, my seven year old son, he's made like 30 different like pictures of things he wants to put in his video game. And, uh, I've been trying to tell him, you know, you got to program a video game and, and like, do you have any good ideas of like, if he actually wanted to make a game or more importantly, if I wanted to have him probably watch me fiddle around with it so that he could learn it. Like, uh, what's the state of the art in like simple game programming? They still use logo, use a turtle or something. What have you encountered that recently? Oh, you got me there. I, uh, I've stayed away from games a bit, but, uh, I've, uh, pointed folks towards a couple of books on, uh, Python Java to get going. So think, you know, 10, 11 year olds, uh, usually that fifth, sixth grade is when they first have, uh, you know, kind of that afternoon programming course. Oh yeah. Um, well, you know, you're reminding me,

I have, I have an old book that's like, uh, teaching kids Python or something. I think it's got a wizard on the cover. I should go find that. Maybe, maybe that'll be helpful. But yeah, I, I told him, you know, he should just make all these images of things he wants in his game. And unlike most things, he actually listened to me. And the other day he showed me like these 30 images. And then I realized, oh crap, I got to follow up on this and figure out how to actually make a game. But I figure, you know, something like Kotlin's probably a little too advanced. And we had to run him through object orientation first, try to figure that out. Probably, probably late teens when you want to do that. I don't know. We'll see. Well, uh, more seriously. So, um, before we wrap up, so like, do you, do you have sort of, do y'all have like a, uh, whether it's your own materials or others, there's sort of like a, uh, speaking of late teens, like a, a homework reading list that you recommend to people or kind of like the background assumptions that you would have, like you mentioned, you know, bounded context and things like that before it. So I assume there's a few concepts like that, that while of course y'all would be happy to tell people about it, it might be helpful to know about these things ahead of time. Yeah. Happy to share a few things. I think the app continuum website's a great starting point. You know, it's based on just the simple concept that, you know, Hey, if you name things, well, organize your code base. Well, uh, you're, you're going to be in a position to evolve that code base over time. And, you know, also reducing those nasty circular dependencies that tend to get into our code base. Um, but the continuum is a great starting point. As mentioned, there's a kind of a companion code base that walks through each of the commits and, uh, folks will get, yeah, get, get a handle on kind of what the pal looks like, what, uh, maybe kind of offices within labs, whether it's Boulder, Denver, Chicago, it kind of our approach to writing software over the past several years. Um, which is pretty fun. Yeah, that does seem like a good start. Do you use that, uh, that paper app to make these little

diagrams? I do the 53, I think. How long, how long do you think it took you to figure out how to do that? Like do it comfortably? Oh, uh, I don't know. I'll actually use paper, uh, in front of customers. Um, I don't know. I, you know, being an architect myself, there's a certain just, you know, gravitation to drawing diagrams. I get a lot of people give me a hard time about, you know, standing in front of a whiteboard too much. Nick Kay, who I mentioned, you know, kind of waits for the moment to say, all right, all right, he's breaking out the pen and paper. Yeah. I, I think, I think as, as they titled one of my register columns a while ago, like you shall know us by a trail of diagrams, like definitely a big, big architect thing. But so you got like a big iPad for that. And like, how would you just show them on an iPad or project it onto a screen or what, what do you do? Uh, both does really well for remote, uh, sessions too. So yeah, I just project it's a, I don't know what 12 inch iPad sound, right? It's the one with the pencil, obviously. Um, but, uh, yeah, whether it's, you know, remote in person, um, or then, you know, drawing and putting it in the continuum, it's, uh, yeah, there's a nice touch to it. It's a bit of, yeah, I drew that. Yeah. Yeah. I mean, if I feel it's a little bit like the, uh, the last sort of, uh, cargo culting thing, post-it notes. And I feel like this is fast becoming the next cargo culting thing for, uh, for cloud native stuff, which is to say a genuinely useful tool and you see everyone using it. And so it's a, it would be easy to get confused that you made your diagrams and you were done just like with post-it notes, but it's, uh, it comes up over and over again, which, which is, which is interesting. Hence my interest in like, is that, uh, is that hard to figure out? Cause it seems easy, but you know, drawing stuff on screens is always a little funky, but your comments are encouraging. So snapping, uh, you tend to draw, erase, erase quite a bit, um, until you get the

swing of things, but it's a much better, you know, than if you think of those big whiteboards that had those special markers where you could then print the whiteboard, you know, that, that was faster. So this is, yeah, nice evolution of the whiteboard. Those, those were the good old days, especially when they had like a little ticker tape printout on the side. That was like a little printout. That stuff was awesome. Yeah. That might've been late nineties. Yeah. And then, and then, and then you could fax it to your developers afterwards, I guess, given the new diagrams for their small talk code or whatever people were doing back then. Well, uh, thanks for being on. That was a good overview and a bit of a, uh, you know, we got some hot tips on, uh, doing some programming for kids and how to do diagrams. So some bonus material there for the listeners. Yes. So if people wanted to, uh, so, so where, where is that app continuum thing? What's the, what's the URL for it? Uh, it's just app continuum.io. And then, uh, you got your Twitter thing at the bottom there in case people are interested in, uh, decoding whatever that is in your header, some sort of map of guardrails, which looks odd to go stare at that. Oh, uh, it's the, uh, Maui. It's surf spots in Maui, I believe. Oh, very good. It's a little map that the surf shop gives you, um, says go, go hit these spots. Yeah. Uh, yeah. Surfing, uh, coding. Yeah. Yeah. It looks like next time, next time you're with the surf shop, you should show them that paper app. They can, uh, they could do a similar sort of thing there and help out with that. Well, as always, this has been a Pivotal Conversations. If you want to get the most recent episodes as quickly as they're available, you can go to soundcloud.com slash Pivotal Conversations. Now, of course you should really just subscribe to the podcast. Just go search for it, wherever you're doing that. You're probably already listening to it there. And, uh, also as, as Richard mentioned several times, uh, in the first week of December, December 4th and 5th, we have a SpringOne platform and there's some associated little fun times around there. But if you want to come out

to, uh, San Francisco, uh, you, you can come there and Richard went over, I think you managed to put in like 15 different talks that are there, right, Richard? Potentially. Yeah, that's right. Plug it where I can. And I've been, I've been talking with two other people who are presenting on some of, uh, our favorite topics, or at least mine, sort of like how, how they scaled up all of this kind of change to their whole organization. And there's one in particular I'm, I'm eager to see, which is the, uh, uh, the realities of talking with people in rooms through PowerPoint to improve your software, to put it in a funny way and all of the little tactics and, uh, sort of, uh, what's, what's the, uh, Machiavellian real politic of cloud native. There you go. Let's string together a bunch of nonsense words, but there's a lot of good sessions there. Uh, and definitely if you go to SpringOne platform.io, you can use the code S1P200_COTE, that's my name, C-O-T-E and get $200 off registration, but you should definitely check that out. And, uh, more or less every Thursday, we post the formal show notes. We'll put a link to things we mentioned over at, uh, pivotal.io/podcast. And with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.