Dino Helps Us Figure out What to Do With Legacy Applications (Ep. 50)

Episode 37 · 55:53 · SRT · archive.org · all Tanzu Talk

Well, sadly, today, there's no rain discussion to be had. Frankly, it's a really nice day here. I think spring has ended in Austin, and we're right into summer. The early days of summer. So that's going to be exciting for us. How's it going on up there in Seattle, Richard? Yeah, it was like a balmy 50 yesterday. Walking around with shorts on, shirtless. It was early summer somehow, but back down to the 40s this week, so it was short-lived. Now, is that the kind of weather where you get your Columbia or Patagonia fleece out, or do you switch to one of those thin rain slicker things? What do they do up there? That's a good question. Now it's almost jacketless. I was seeing people walking around in just short sleeves yesterday. It was anarchy. How about the vest? What's the status of the vest up there? I mean, there's the hipster vest. I don't know if I've seen vests sprung out too much lately with the Seattle crowd. So it's not back to the future up here. How about yourself, Dino? What's going on sartorially according to the weather in your part of the world? We also had a nice warm weekend. It was great. I got outside, washed the motorcycle. That was nice. Rode around a little bit. You know, whatever weather Seattle and Portland gets, we generally get it too. So if it's raining, it's raining on the West Coast. Now when you wash a motorcycle, what do you do? Do you just like spray it off or do you have to be careful about the engine and stuff? Like what's going on with that? You ride in the rain all the time, so no problem getting it wet. It's just mostly getting all the mud and garbage off of it. I see. All the bugs, I guess. Yeah. You get bugs. Yeah. That makes sense. Well, why don't you briefly... I'm just picturing you driving through the regular car wash. You know, just like a badass. Sitting there with the helmet on. Like not moving. All the soap and the weird brushes are getting you. I'm sure that's not what happens, but that's what's important. Well, there's been some rainstorms I've been in that it's felt that way, but...

Hopefully you get a discount for that at the car wash. Yeah. Less surface area to... But then they have to dry you off. So who knows? Maybe it's equal. So why don't you introduce yourself briefly? We'll get to an extended introduction later, but just so that people know who you are as we're talking. Sure. So Dino Cicerelli, I run the... What you could call the professional services organization in the Americas. It's focused on PCF. So I was thinking we should have you and some of your compatriots on because I was watching some of the excellent videos from our global field kickoff. And you and a couple of other people on that panel had a good overview of how we... Sort of what happens once someone wants to get PCF up and running and how they move applications around and do other things like that. So we'll get to that on the second half. Hopefully it's more than half of the episode. But until then, what kind of news do we have, Richard? Yeah, we've got a few things. I thought it was interesting last week, Microsoft released this program, what they call this, something fancy around IP protection. And so the idea is that you have access to, I think it's around 10,000 Microsoft patents if you run in Azure, you can do for enterprises that, you know, look, if you're worried about patent trolls and things like that by running in a public cloud, by the way, we'll protect you as part of being an Azure customer. So I thought that was a pretty neat program. I'll have the link in the show notes. But that's one of those enterprise-y things that Microsoft can do given their history and patents that others probably have a little tougher time with. Yeah, it's kind of more of an intriguing use of patent stuff. I don't know if other people do that, but it's, yeah. And I guess in some sense, it's also sort of troubling, like, oh, I never would have thought about, like, patent stuff running in some cloud thing somewhere. I guess that means you can use your, what do they call it, the 8.3 file format stuff. I think Microsoft still has that patent, right?

Hopefully that's expired. But I remember there used to be all sorts of wacky battles over, like, you know, how many letters, characters you could have in a file extension, all sorts of things like that. Yeah, I mean, working for cloud providers in the past, I can tell you there's definitely weird patent requests that come in from trolls that are for just comically basic capabilities that how can you possibly try to claim a patent on this? So I think it's Microsoft's way of trying to say, hey, look, feel comfortable running in the public cloud without thinking that you're going to get, you know, have problems. You get indemnification to some extent by running on the public cloud. So that's nice. Yeah, I wonder, you know, I'm no lawyer or a country doctor or anything, but, like, I wonder if, given that Oracle just likes to sue everyone who, like, tries to do something with Java, I wonder if they have some, like, cross-nuclear protection stuff so that if you wanted to run Java, you're sort of legally incented by patent protection to run in Azure. That would be fascinating. Well, I have to get that. There's that reporter, I forget her name, who covers, who, like, lovingly, covers all Oracle-related lawsuits over at Vice's motherboard. Maybe I can run that theory by her. Her coverage is fantastic. Basically, her coverage amounts to, oh, no, not again. And then she gives a detailed analysis of it. Awesome. So then I was also seeing you found that there's a manifest editor in, a Cloud Foundry manifest editor in Visual Studio, which, I mean, that's pretty straightforward, right? You got manifest as a way that you define your application. And here's, like, a IDE-driven way to set them up. Yeah, that's right. I mean, Visual Studio Code's taken off as this sort of cross-platform editor. They don't really even call it an IDE or development environment. It's an editor. You know, I run it on my Mac, run it on Windows, run it wherever. You can build Node apps or .NET apps or whatever. And in this case, look, if you're building Cloud Foundry apps now, you can just build these manifests and get that little nice type-ahead IntelliSense stuff when you're trying to figure out if it's instances or instance for the property name. A little bit handy. Always good stuff. So I think we helped contribute to that. Maybe we'll see some more if people try it out and have some feedback.

They should definitely submit it in. Now, I thought this would be a good opportunity because, well, maybe long-time listeners know this. You're kind of like a .NET Microsoft type of person. You probably have a closet full of MSDN DVDs. Do they still send those out? That was always delightful. But do you get those still? Because it would be a good way. I remember when those coming out, it was like every year you would get a new CD holder that you could put all your old Wu-Tang and U2 albums in, whatever you might have. I don't know who would have such a collection. That was almost like the photo albums of my parents. Yeah, you'd have all these photos of CDs for the MSDN collection. So here's what I want to ask you about that. So I remember, even when I would code a little bit, that Visual Studio made everything really easy compared to being a Java developer. And other than saying Visual Studio is the cure for terribly cooked food everywhere, what's like nowadays, what's kind of like the mental expectations of developers in the kind of like Microsoft world? Like, are they still like latched on to Visual Studio as like their only tool or do they use other things or like what are their kind of expectations tool wise of what they use? Visual Studio 2017, I think, comes out next month. So people still obviously use it a ton. Visual Studio code has taken off. I've seen a lot of my .NET friends using that as their preferred editor now because it's lightweight, nice plugins. But I mean, even Visual Studio for Mac is coming out now. So you don't have to be on a Windows desktop to be developing this way. I mean, Visual Studio, I was building Node apps in there for the last few years because it was the best Node editor. So it's heavyweight and it's a beast. But at the same time, there's probably not much better from at least a Microsoft world IDE. But I've been using Eclipse or the Spring tool suite for the last 10 months since I've been learning Spring. And it's not bad itself, but Visual Studio is still probably the best IDE out there. And then Dino. So it's relatively new that we've had like .NET and Microsoft support.

Like it's been in and out. But like as described earlier, you do a lot of work getting you and your team, getting getting Pivotal Cloud Foundry up and running, getting people running it. Like what's your sense for like what's up with Microsoft style stacks nowadays in Pivotal Cloud Foundry world? Like is it on the rise or has it always been there? And how do people deal with it? We're definitely seeing it on the rise. It's actually one of the areas that we're starting to see in the app re-platforming space is increasing number of people wanting us to look at .NET. And so we actually are, and I'll probably plug this a dozen times in this conversation, we're hiring and we need people. And we definitely need .NET people. So, yeah, no, it's, I wouldn't say it's half yet, but it's probably a third of our app re-platforming is starting to touch on .NET. So how would you like categorize the types of applications people have in .NET stuff? Like, is it just like everything? Or do you think there's any particularly interesting types of things that people make in that? Right now, it's kind of across the board. There isn't anything that's particularly interesting. You know, we're trying to look at, a lot of the stuff is, is the platform kind of set up correctly to handle the .NET stuff. And then there's also the aspect of if people are going to move to core or not. That's kind of a big conversation. Right. And what is, I'll turn this back to you, Richard, then we'll go to the last news thing. So what is .NET Core? Yes, the .NET Framework or family has gotten complicated. You have .NET Framework, which is the traditional Windows-based, you know, full-based libraries and so forth, ASP.NET, all those sort of platform, a little more lightweight versions of ASP.NET

and MVC and all these components. So .NET Core is really where it seems like Microsoft's putting all the new attention that this is the cross-platform version of .NET. And then .NET Framework's kind of the classic Windows-based version. So PCF does support both, but as Dino mentioned, I think a lot of shops are trying to figure out, do we migrate these apps to .NET Core? What does that look like? Does it matter? And so I know we've been doing some things to help with that. That sounds good. All right. Well, the last news item now, over on my other podcast, Software Defined Talk, we talked about this for a little bit. It's interesting to sort of figure out like all this spending, what it's for. But why don't you go over the last thing? Because it'd be interesting to hear your take on why it's interesting and what it is, me having discussed it already. Yeah. I mean, the news was that with Snap filing for IPO that they had put, I think, in their reports or statements, they were committing a couple billion dollars over five years for Google Cloud Infrastructure. So it's like 400 million a year, if I can do math. So it was some healthy amount of using Google Cloud. Now, initially, there was some hand-wringing, like, oh my gosh, that's a lot of lock-in for one cloud. What about multi-cloud and portability? But I guess as people read it further, they saw there was another billion dollars in there for AWS as well. So I guess the takeaway is, boy, that's a lot of infrastructure. And then also, it probably makes sense to spread that workload across these. I don't think we know whether they're running the same things in both or they're using certain capabilities from each, probably the latter. But hey, that's a lot of infrastructure. Yeah. When we were discussing it this past Friday, I was thinking, anyone who's probably older than 30 feels the need to make fun of Snapchat and the kids, or at least in my school of thought. So of course, I did that a little bit. But then, more realistically, I was thinking, how much processing does that really require? Maybe a lot of network bandwidth and storage. And I think maybe it was Matt Ray on the podcast who suggested that, well, there's the entire back end of figuring out just where to place activity stream stuff.

And then also, as we were thinking about, there's also the back end of, well, what do you sell to advertisers? Like, you've got to constantly be analyzing all the demographics of your users and the best type of placement and all that magic stuff so you can tell the father that his daughter is pregnant by sending coupons to him that we used to read about. But I would imagine, you know, plus redundancy and also, I mean, the networking stuff and then the video rendering must be insane for that kind of stuff. I bet they must output several different formats of video plus stream it. But still, like, it's reasonable that something like that could add up to that amount of money. But man, that's a lot of spend. That's interesting. It is. I think the resilience is the interesting one because this isn't something where you can tolerate any downtime. So I'm sure they're so hyper resilient, almost unnecessarily. But you have to with a service like that. Yeah. Well, before we get to the meat of the episode, I thought we might try something a little new. We do this every now and then, but we'll see. We'll do a little mid-roll thing. Now, the first thing that I wanted to mention is that we have your team recently put out this DIY white paper thing, right, Richard? You want to tell us about that real briefly? Yeah. Jared Ruckel on our team put together this great, one of the financial considerations or the operational considerations. And so really good white paper. You can find it online for free as a download. But just a good paper if you're trying to think about, well, what should I do versus what could I do? And I think those are good questions to ask regardless of where you end up. Those are things you should address because I think a lot of people forget the hidden post go live costs of running your own platform. Yeah. I think to summarize it, as they say, TLDR is like you can have your own cloud platform for $7 million a year with 50 people if that's what you're into. Plus all the incumbent risk involved in that and all of that. Like I remember there was one some time ago I heard about some company that had, what had they done? They had sort of built their own infrastructure cloud and they got everything up and running and then the whole team that did it like quit and went to go work at some startup somewhere.

Which is... Yeah, that really happens. That's scary stuff for people. I mean, basically, my team's trying to get out any white papers, Coté, before your massive thing comes out and distracts everybody. So we're just cranking out papers and blog posts right now that you suck up all the oxygen. Exactly. I have to say, like, I think we have had a marked difference in the past six months of the type of content that we push out. We even put it in the URL. If you go to content.pivotal.io, we got lots of it. I noticed that... What do they call that? A subdomain? I never knew my networking stuff very well. That should work. I don't know. Some sort of CNAME? Is that what that is? I don't know. Anyways... That's the top name. Keep going. I don't know if we have any sort of, like, dandy URL for it, but I made one for the other podcast. If you want to get to the paper, you just go to softwaredefinedtalk.com slash DIYplatform. And maybe we'll come up with some fancy short URLs for the future. But, you know, you got a legion yourself, but whatever. And then you can get a copy of it. And it's a good paper. It goes over, like, the components that you need and, like, an estimate kind of aggregated from our customers of what that looks like. And it's good for your consideration. So just two more things. Here in Austin, on February 22nd, 2017, I'm going to be at the Austin Cloud Native meetup. And I'm going to be giving, like, a version of my normal stump speech. Just sort of stories about people doing cloud native and DevOps and Agile and kind of, like, the tips of how they succeed and fail at it. And then also, coincidentally, we're having a Pivotal Partner Day here in Austin. Or days. I think it's February 21st to 23rd. You know, something like that. We'll put a link to it in the show notes. But if you want to learn about working in the Pivotal ecosystem and partnering, I think there's even a day, like, if you want to, like, code stuff and bring all your MSDN CDs or DVDs, you can, like, try that out and see what's going on. But I'm going to try to go there myself because, you know, it beats work and it'll be fun to see what partners show up and what they do. Yeah, it's a good event. Yeah, yeah. It should be cool. It's nice. It's in Austin. That's great planning.

Anyhow. Yes. So, you gave a brief introduction to yourself earlier, Dino. But tell me, let's start getting into it. Tell me, like, the team that you work on and kind of the associated structure and Pivotal. Like, I think a lot of people are familiar with, I guess, people listening to this, sort of like our outbound talking wonderfully about ourselves effort. And you got the developers and then you got those account executives or reps, as people like to call them. Like, people are familiar with all those people. But, like, what's your part of the organization? What's that look like? Sure. So, the way I always like to say it is, is we're the ones responsible for making what marketing and sales spins into reality. So, we actually have to go out there and do the implementation, do the integration, get it used, and get the customers to a point where they're actually starting to see benefit from all the investment that they've made in us. Right. You're sort of like the anti-shelfware device. You know, you got to make sure that people use it and are successful at it and that it's actually valuable. Yeah, we're kind of the cold, hard reality. That's right. Well, I have the urge to ask you how our marketing reality is matching up to reality reality, but I don't think I'll ever ask that. You know, I think it's just better just not to know. It sounds like things are going well. Things are going well. You know, there's always the push and pull between what you sell and what's reality. But, I would have to say that we as a company do pretty good at it. We don't oversell. We don't overpromise. We definitely try not to under-deliver. So, we're actually seeing a pretty good uptick from what we've been doing with customers. So, it's actually pretty exciting. Yeah, yeah. And, I mean, joking aside, I mean, this is a bit like a parent showing you the wonderful

drawing of a bird that their kid did over the weekend. Yeah. Kind of biased. But, you know, in my mind, I think just over the past few days, I've been in some email threads where all of a sudden there's like, oh, and then someone came and told them they're using Pivotal Cloud Foundry as a centralized thing. Like, there's companies switch over pretty interesting to being interested in stuff. So, it seems like it's working, which is always great. So, there's kind of two areas I wanted to ask you about. One of them is just like kind of what it looks like. I don't know what you would call it. Maybe roadmap is a word that people like us hate to use, but probably a lot of people use. But, like, what's the, like, typical roadmap or journey that people go on once they become a Pivotal customer? Like, what do they need to do to get up and running? Like, who gets involved? And what kind of time period does that look like? And then the second one is about migrating applications and things like that. But let's go back to that first thing. Like, you know, you've, just like in eBay, you've won the auction and you've been given the ability to get this shiny new platform. Like, what do you start doing next? Sure. So, we actually, to get an understanding of how we look at the world in kind of a macro view when it comes to PCF, there's, you know, one coin, two sides. One of those sides is really around operations. It's around the platform. It's around working with the IT organization or the existing cloud organization, the people responsible for, you know, ping power and pipe and services and the people that are going to actually install the platform, right? And get it integrated. And something that, and I'm definitely more of an infrastructure person than I am a developer. My developer days are a little bit farther behind me.

And I've always been of the adage that, look, if the operators and the people that own the platform, the responsibility for keeping the blinky lights on, if they are not seeing benefit and they're not making their lives better, they will resist change, just like anybody else. Yeah. And I mean, just to editorialize, I mean, I would add, I think one of the core value propositions, which is fancy marketing speak for why you like it and why it's valuable, is basically how much optimization of the operator role and therefore the resources you spend on that changes. And then also, you know, by the nature of automating it, how much it kind of reduces manual error and things like that. So it makes sense that, like, that's sort of the first thing you work on. Yeah. And keeping in mind from a selling motion and a valued motion, it's never wise to go to those that camp first. Generally, because you can fall into the trap of, if you build it, they will come. Right, right. And my history is I built a lot of clouds in my history. I was an old VMware guy for 12 years and built out their cloud practice and everything. And we built a lot of clouds for a lot of IT organizations and then wondered why people didn't use them. And so, luckily, we've kind of, we went through that phase very quickly. And now we're doing a lot of selling back into the lines of business and developers that are looking to move fast and wondering, how can they do that? And then we introduced PCF and then we introduced that to the IT organization and bring them both into the same room together and say, introduce the developers to the IT people and go, we're going to teach you how to go fast. And are those groups like the business or the lines of business and the IT people? How do they, how does that relationship go nowadays? Seems like it would be a little awkward, but like how, is it better than I'm imagining it?

Well, as with all answers, it depends on where that company is in their journey down the automation path, right? Going from, I used to have physical servers I used to hand to developers to, I used to have virtual machines I used to hand to developers to. I have a cloud infrastructure where developers can do self-service type stuff all the way to, nah, developers don't even get VMs anymore. They get CF push. Right, right. And so as an evolutionary thing, right, the interesting thing is, is when we go in, the first part to go back to your original question, the first initial thing we do with customers that have bought PCF for the first time, generally, this is kind of the general path, is we do something we call Platform Dojo. And that service is really focused on installation, integration, and getting the stack to a usable level so that we can run code on it. It's generally a four to six week process. It kind of has about three phases. There is the actual implementation phase. So, right, we are a predominantly application-focused company, right, from the outside, right, Pivotal Labs, a lot of the app stuff that we do. However, PCF is shrink-wrapped infrastructure software, right? I mean, it is ping power and pipe. It integrates into security and networking and storage and compliance and backup and recovery and monitoring and management and all those things that you have to do in the infrastructure space. And so, we ensure that we're integrating into that. We then also look at how that fits into their CI, CD tools and their development process, because if it doesn't fit into that, it's not going to get used.

And then we generally like to try to get an app or two up onto the platform. We throw out the specter of we'd like an app in production. If you say the word production, people start to kind of freak out a little bit. And security people come fading in out of the walls when you say production. Like, wait a minute. If you're bringing this in production, we have to add some more stuff to it. Yeah. Nothing is more deadly than a security person suddenly emerging out of the wall. That's the way it is. You want to control the wall emerging. So, we actually kind of force that so that we force those questions of, well, there's a compliance issue here and there's a test and someone's got to check a box before you move this into production. And that's when we start having conversations about, well, could we just write a test for that to see if we pass that, then automatically move it to production if we want to, without having to fill out a ticket. So, you talked about those kind of first couple apps that you moved to just kind of flex platforming. Do you sit down and do a real profiling exercise to figure out which of the quote-unquote real apps that then a customer wants to do either follow-up work with us with? How do they pick those legacy apps to modernize? So, that's a great question. So, that goes into the second phase of services that we do. And sometimes we run these things in parallel, right? So, that doesn't have to be so linear. But the other thing that we do is to start looking at – think of it as three kind of buckets. And this is always controversial because terms are always conflated, depending on who you're talking to. There's obviously just net new development work. Labs is, you know, excellent at it. We write new applications. It runs on PCF. The next two kind of get – can get messy and difficult. One of them we look at is candidates that are – or applications that are candidates for application re-platforming.

You go, okay – and then there's others for the modernization. You go, okay, what's the difference between re-platforming and modernization in our vernacular? Re-platforming is generally what we classify as small to medium apps. What are small to medium apps? You know, there are things that are, like, less than 5,000 lines of code, less than 20,000 lines of code. Generally, Java, web profile, spring applications are ready. Things that take very minimal code change to move and run on the top of the platform. And we can go through and identify those relatively quickly. We can talk more about how we do all that. And then start the process of moving to the platform. The modernization side of it is when we start getting into the large monoliths, the big things. So what we call the kind of double XL, triple XL size code that's around lines, you know, 100,000 lines, a million lines of code, a million lines plus. Things that take a lot more focus to decide on what we're going to attack and what we're not going to attack and move to the platform. That, you know, all of these are done within somewhat of a time-bounded engagement. And it's really about teaching the customer and or partner how to do this work. Which is the key, because we're not going to be there forever. Right. And we're trying to get them into the process of doing it themselves. How do we do that? That's the answer we can drill into. Yeah. I mean, how do we teach them to fish? Sure. So the important thing to note is everything that we do out of my team, which is Pivotal Cloud Foundry Solutions, that's the name of our team, follows the pivotal way in everything we do.

So we do inceptions, and we do retros, and we do everything to kind of an extreme programming methodology, same way as labs, same way as R&D. Interestingly enough, we do this in the platform dojo. And that's a little bit shocking at times, because the people there are used to implementing infrastructure, and that's generally kind of a waterfall-type process. And we go in and start talking about writing stories and Pivotal Tracker and how we're going to move stuff around. The poor people at our customers show up with Gantt charts, and we go, we don't know what those are. But after about 150 of these things that we've done in the past couple of years, I can probably say, honestly, 95% or more of the customers, when we're done with that, come back with, that was the greatest experience ever for implementing all this stuff. Just because of the nature of being able to do things in small iterative steps. And you do that on site, right? They don't come to us in that case, not like with labs, where we like to bring them in and truly indoctrinate them. We actually go on site with them to their place, right? Yeah, we generally go on site most of the time. A couple of times that we can convincingly come into the offices, we do. That obviously helps us provide a bit more of a hermetically sealed environment. On site, it gets to be a little difficult at times because there's distractions and easy for backsliding to old habits. But yes, we are generally on site. And so, you know, across those like buckets of apps, can you give us like a few examples of like applications that you've moved around? Like what, I don't know. I mean, I feel like I go out and I'm like, oh, you can migrate stuff if it's like packaged and behaves well and is simple. And then I like quickly change the subject because I don't have good examples. But so it would be good to hear like what actual, you know, ideas of those kinds of applications are.

Yeah, so as I was saying, I mean, like most of our applications are in the Java world. We're getting more and more in the .NET world. Some of the smaller apps can be services or, you know, connectors or all kinds of little things that are out there that we can look at them and say, well, I guess it'd be easier to walk through a little bit more of how we handle like the app and platforming side of it. What will happen is, is we will provide a kind of rough outline of what types of apps the customer should be looking at. And we're generally looking where the line of business, that line of business will work with them to ensure that we're kind of picking the right apps based on, you know, three general parameters. Like, you know, what is the business need and criticality of this app? What is the economic cost? Like, you know, how much do you want to time to market kind of implementation, you know, aspects of it? And then, like, what is the technical aspects of it? Like, what is the code base and, you know, how hard, you know, how hard is it into the file system and whatnot? And from that, we work with the architects at the customer within that line of business, and we may identify 100 applications. And we try to go through and say, look, let's not identify 100 applications that all have the exact same pattern. Let's try to pick some things that are different, right? Different web profile or, you know, we try to stay with full profile right away. Do they have any spring applications? You know, what do they have in their environments that allow us a good cross-section of the types of applications that represent the rest of them? Because a lot of times customers come and go, we've got 5,000 job apps. And we're like, okay, well, let's get a representation of those we want to go after. And then once we kind of hit that, we'll go through something that we – and this is – the process is we do a scoping.

We do kind of an iteration zero that lets us understand what their environment looks like and how they're set up. Like, what tools do they have? What infrastructure do they have? What CICD tools they already have in place? How do they – you know, what is their code repositories? You know, just so that we know a lot about their environment before we get there, right? And then we start handing out, like, here's the, you know, the applications that we want to look at, Java E, web profiles, full profiles, spring apps, non-Java apps, you know, anything, right? .NET, Node.js, JavaScript. We kind of ask for the kitchen sink, and we narrow it down to – let's call it 100 apps, and then from there, we'll narrow it down to a representation of anywhere from 10 to 30 apps or so that we'll then do a snap analysis on for each of those apps. It takes about a half hour per app. And then with that, we actually kind of go through a laundry list of questions, right? You know, how is the configuration handled within the application? What's the login? What's the SLAs? How is it packaged and built? Is there a CICD in place? You know, what is the app server that it's running on? You know, what is some of the statefulness of it? All of this, like, a laundry list of questions. We have a data sheet to kind of collect these things on really quickly. And then from that, we can quickly kind of score each one of them and then decide from there, say, okay, we think we can, like, start with these 10 apps. And when we're talking about that level of complexity, we've seen in the past we've moved about 10 to 12 apps in 10 weeks where we've gotten fully up on the platform and running in the same process or, you know, in the same performance and way that they were before. The benefit now is, obviously, as we're moving into the platform, we're writing a lot of tests.

We're ensuring that we're starting to instrument those things better. And we're getting the customers able to start, you know, changing those apps. The whole point of this is so they can change those apps quickly and reiterate on them and keep them running on the platform. So what are, like, some typical changes that you need to make for, like, these 10 apps you find initially? Right. So it's taken its config from the app server. We got to point it to, right, the spring config server. Or it's logging to disk. We want it to log to out. Right. You know, persistent file system access. Do we need that, like, what does that mean and what does it look like? Right. Have they even written any tests around these apps? Right. So some of these are tests around code and then their interactions. And then some of these things are tests that we write around deployment. So we kind of riff on the test-driven development and test-driven deployment as well. So the key out of this is what we wind up doing with the customer is we write cookbooks. And within those cookbooks, we have recipes. And those recipes are snippets of code that we write with the customer that they can reuse across other applications of similar ilk. Right. So if there's a way of us saying, like, well, okay, we found a way of pointing to a new spring config server. And this is how we're changing the Java EE config to get it at runtime by pointing at this config server. Right. And it's a little snippet of code to do that. It's a recipe. So when you run into other applications like this, you don't have to rewrite. You can just go back to the recipe. Right. You can start from there. So we teach them how to start doing those different things. And then that's kind of the app re-platforming phase. And we've seen, like I said, about 10 weeks, we can do about 10 to 12 apps. But once again, it's really teaching them so that when we leave, they keep that flywheel going.

Do you see that, you know, how do we make sure that we don't accidentally add more complexity than they thought they could handle? Right. You take a monolith that maybe is brittle, doesn't scale well, but it worked. And then we tease it into 10 microservices. We add CI, CD. We add some backing databases. More moving parts. How do we make sure that their operational cost doesn't go up? So that's a good question. And it starts to, there's a lot of factors that go into that. And one thing that's important to note, I think microservices becomes a term that we throw around a lot. You don't have to use microservices to use PCF. You don't have to necessarily break things into that. Some of these applications just move and max. And you don't have to break them apart at all. And moving them up there because now you're hitting a lot of other factors like, oh, I don't have to use WebLogic or WebSphere anymore. I'm doing standardization around my runtime environment and my build packs. And I'm able to iterate on the platform and blue-green deployments are easier. And I can change the blue button on the interface to green whenever I want to and back without having to do massive QA because I've written tests around this. So there's a lot of efficiency that's driven out of that. Talking about addressing your question kind of goes back into the app modernization side of this. With that, we've done some really great work. There's some insurance companies that we've done some awesome work around this. They have an application that they wanted us to attack. We did an app re-platforming for them and moved a bunch of code. 10 apps in 10 weeks, I think, that was the case there. They really fell in love with the process and said, okay, we've got this massive system that's used to essentially write insurance policies for people. It's about six years old, and it's about five million lines of code.

And it's a nightmare. And we can't update it quickly. We have to figure out how to attack the parts we want to be able to change quickly without doing what you said, which was kind of crushing ourselves with adding additional complexity. And interestingly enough, a bunch of people on the team, you know, Joe Soprid and Rohit and Dan Frey and Dave Transky and a bunch of guys, they actually decided to, in this case, for this big monolith, they kind of came back and said, well, you know, let's look back on some of the techniques that have been used in the industry around domain-driven design. And let's actually attack this through essentially an event-storming type of process. So it was really interesting. We brought together people from all parts of the company, from IT to developers to VPs over lines of businesses. There was probably 20, 25 people in the room for a full day. And we walked through with a lot of sticky notes and just started putting stickies on the board. Like, when somebody writes an insurance policy, what happens in this system? And they started walking through it. And there were kind of, oh, crap moments of, wow, that's a big problem. Put a red sticky there. And as all that stuff started to happen, what was noticed was is there were natural bounded contexts that were created. And it just kind of organically happened. And we saw kind of the domain events in the bounded contexts and the context of connecting the bounded contexts just naturally evolve on this giant whiteboard full of stickies. And from that, people started to narrow down farther and farther what were really some of the problem areas that we wanted to attack where we had different, I guess, parameters you could put around it is we really want to be able to massively change this part of the system.

And we believe that if we start attacking these and moving these parts to Cloud Foundry, that's going to be our biggest way of starting to break apart this monolith. So, I mean, I like that. I mean, you're tackling this more from, again, the bounded context of the domain versus saying, let's modernize the UI first. Then let's tackle middleware. Are you seeing it more as trying to do it by function versus just strict application layer? Yes, it's more by the function where they find the greatest kind of bang for the buck or where they've had the hardest problem of we really do want to change these areas. And we haven't been able to do it without touching too much of the system. Like, how do we separate that stuff out? And what we eventually came up with, like, 10 MVPs, right? And I think we broke it down into three that we started with. And in that process, we then went back into our normal, with those 10 MVPs, we went back to our snap analysis then. So instead of where we can start with a small app and kind of do a snap analysis around all the particulars of that app and how to move it or not move it to PCF, we had to go through this event storming to get down to a bunch of MVPs that we could kind of treat like small apps to then do snap analysis to then figure out which ones we were going to move the platform. But all of this took, like, a couple of days. And then we were writing code. And at that point, even if for some reason the funding ran out after you did three of them, you still added value. You don't have a half-finished app. No, no, no. Yeah, yeah. So whatever we've moved is still functioning, right? Exactly. It's still running. It's just now you've broken out small pieces of it. And now the customer can look back and go, well, is that enough? Is this where we want to be and we don't want to touch any more of this? Or do we want to go through the next level and keep working? Because there will be some pieces of that they'll never touch, right? It'll just continue to run where it is. And they don't make huge changes. And it runs just fine. And there's no reason to move it.

Yep. That's an important designation. So is the phrase snap analysis, does, like, snap stand for something? Or do you just mean, like, quick, like the colloquialism? Like a snap judgment. All right. Fair enough. Yeah, it's a snap judgment. It literally goes through and looks at, you know, what are the versions of the APIs in use, right? So Java, Java EE, J2EE, Spring Framework. Okay. Check, right? Is there external integrations? What are the databases, caching, messaging queues? What are the other things we use? Okay. That's, you know, that app needs RabbitMQ or whatever, right? And we just kind of go through a checklist of things to look at the app and what it touches and what its external needs are and internal needs are. And if they, if we see some that are, we have to weigh back and forth and say, well, how important is it to modernize this application or for this piece of it versus the complexity? All right. So it's sort of like a, whether it's standardized or kind of informally done, like a checklist, like when you go see a doctor and they're sort of like go through a checklist of things to see if something. Check the weight, check the blood pressure, check the glucose. Well, this, this I think is a major to do for the marketing side of the house is we need to come up with something that SNAP stands for. I think we should maybe, maybe good KPI in three to five years. There should be a Wikipedia article that describes this concept of SNAP analysis. I'm pretty sure the S should stand for software, but the rest of it, I don't know. Maybe, maybe P is process and then you just got the NA in there, but we'll, we'll figure it out. That's a, so the, uh, before we close out, like there's, there's a, um, I don't know, there's a couple of like abstract pivotal concepts that, that, that you've touched on that I want to, uh, I want, I want to statement question you with, so to speak. Um, and one of them, you were kind of, um, you're alluding to this or, or touching on it in, in the, the approach that we have. And, and, and I don't know, a non-snarky way of putting it, but it seems like a lot of

what we do at Pivotal is sort of forcing people to learn a new way of doing things. Right. And, and this, you know, going over the analysis of things to do quickly, it sort of says like, instead of getting stuck in some analysis paralysis of stuff and analyzing and writing some report, you should just start doing things, you know, obviously in a rational way that we've been talking about this whole time. But, but, but I'm curious one, like, I mean, is that something you consciously do? Like we should start doing things really quickly. And then like, does that, uh, do people, are people resistant to that? Or do you just kind of like take them along without them knowing that, that we're doing it? So that's a really good question. And what we've seen is, uh, we have to be careful and I, and I catch myself and I make sure that I'm careful on this. I was just at a customer and we were having this conversation to not trivialize the complexity of their environment by saying, oh, come on, let's just get started. Let's just start banging on some code. No problem. Right. Yeah. Yeah. That's, that's, that's a, that's a good point about how you position it. That could, that could, that could, and it's, and it's not that, right. So, so we're very conscious of the, um, the complexity of the environment. Uh, and we're, and we're also very conscious of not, you know, for looking out for the, as the term goes right, yak shaving, right. Um, and, and, and the, the regression of, well, if we do this, we gotta do this and we gotta do this and we gotta do this. Um, so, but what we, what we have found is as we're taking people through this, like going through this event storming, like looking at this one system, that's 5 million lines of code. Right. And everybody, there's not a single person in the company that can answer all the questions about the system. So walking people through and having them say, well, what happens next? And what, where's this touch? And who knows if different people in the room kind of move around and, and start putting these stickies on the board.

Then you see people looking at each other going like, oh, I didn't realize that you knew about that. And what about this over here? And all of a sudden there's a larger conversation that happens. And then out of that, uh, we start to go through, through and break it into characteristics and then write user stories, metrics, and kind of describe risks. And as we're going through that process, people start to realize, oh, wait a minute, we're not trying to do an analysis paralysis here where somebody has got to come in and figure out how to pull the spiderweb apart. We're breaking this stuff down into kind of smaller chunks. And then we're introducing the, yes, and then we can act on those smaller chunks and we can start reordering these things. So when we say we start working very quickly, it's not in a haphazard way. It's in a very structured way. It's just that we're taking small baby steps in each of those. And what naturally happens over time is people start to, the anxiety of making a decision goes down. Because that's an interesting result. Yeah. I can back out of this and I'm not losing four weeks of work here. And so people then become more comfortable with taking smaller steps and smaller steps and smaller steps. And you start getting that, that, uh, acceleration of the work being done because it's easy to back out. And then that is very much kind of the pivotal way, right? We iterate, we break things into stories, we break problems into very small chunks. We work on that small chunk. If it doesn't work, fine, throw it away. It's not a big loss. It was a couple hours. Yeah. No, that's interesting. I, you know, I, I was, uh, I was doing a lot of laundry this weekend and I was, I was trying to test out big batch versus small batch thinking. Right. And, uh, you know, we got a two story house and so I would like do one basket of laundry and then go upstairs and put it away sort of a small batch. And I, and I kept thinking like, wow, this is getting me a lot of exercise. I think this batch might be too small. And, and, and, and I was thinking like, there must be some interesting intersection of curves

where you find out the optimal, I don't know what the characteristics that drive it are, but you find the optimal amount of batch size, so to speak. And, um, and I suspect, I mean, being less laundry oriented laundry ops, as it were, I suspect part of the process that, that y'all go through is that in each organization, it depends, right? There's all different parameters about how you optimize the batch, but you know, the interesting aspect, uh, it's sort of like turtles all the way down. I mean, this gets to the second point is, um, you know, it's almost like, so you, you introduce this learning organization, this learning organization thing, and you're kind of forcing it through, as you're saying, narrowing the, the batches down. And there's another interesting aspect that I've noticed is sort of key to pivotal engagements, which is, um, all training results in actual business value, which is to say, it's like on the job training where you're actually doing something that is actually shipped to, to the business, which is, and I think a lot of that comes through the way that, that we pair with people, as you were saying, from programming to your work. But it's almost like one of the goals is like any training that we do shouldn't result in some sort of BS project. It should actually be a real thing. And, uh, those, those two things together have some interesting, uh, quick results to how, how you go about doing things. So that's probably one of the biggest takeaways you hit right there that, that we try to drive into our customers is when we show up, we, we're very explicit about, we have to pair, we have to pair with you or we're not. I mean, there's that time we've actually kind of slowed the project down and said, your people aren't here. We have to pair with you for a reason. There's a reason why we're doing this. And, um, and, and we actually don't, we call our services enablement services, uh, for that exact reason, right? For us to install PCF only takes a couple of three days, but we'll be there for four or five weeks because we're trying to pair with their ops people to do operations enablement. Um, same thing around rapid platforming and, uh, to the point where we actually at times

now interview people at the customer to work with, to pair with, right. Uh, to ensure that, that they're dedicated and they're going to actually work with us and pair with us. And so, uh, you know, you don't have to do things the pivotal way to be successful or to use PCF, but we as pivotal have an opinion around this. What, what has worked well for us and we, we are showing our customers and including our customers in this, uh, and, and more times than not, they're, they're welcoming the change and, and seeing value out of it, both on the application side and the operation side. And so we're trying to bring that modern, um, cloud native blue, green, deploy, treat everything as, you know, something you test then run, uh, or deploy across both operations and applications. Yeah. No, that makes sense. Well, uh, thanks for being on. This is good stuff. It was like hitting on exactly what I wanted. I think, I think, um, we, uh, this is sort of, I don't know if it's the number one. And I mean, all the things people talk about are number one, but it's definitely one of the huge topics, uh, that, that are sort of overall pivotal community talks about, you know, as, as I'm fond of joking, like legacy it is the stuff that makes all the money. So it's, it's important to figure out not only getting started with new things, but like how to, how to work with your existing, uh, I don't know, corpus of applications. So, uh, it's, it's been a nice like way to add in kind of a, uh, I don't know, like a qualitative way. Like, what does it all feel like? What does it look like? And, and I think, I think the other part that's always that you discover with a lot of like, uh, agilely DevOps stuff, as you were alluding to just a few minutes ago is like, there's actually a tremendous amount of discipline to this. It may look a little weird from the outside, but it's very programmatic and, and, and time worn and checklisted and it's got the patina of success on it or patina, depending on how

you like to pronounce it. It does. And I think that's where the, uh, the, the misconception of we come in and do things fast doesn't mean it's undisciplined and chaotic. It's actually very disciplined. It's just done differently. Yeah. Yeah. I think anyone who's tried to cook a perfect omelet knows you can do things quickly that come at their high quality and awesome, but it takes a lot of difficult skills. It was very hard to make a really good omelet quickly. So, uh, so if people want to follow up with you, I mean, do you got a, you got a Twitter account? Are you in Snapchat? Maybe they can send you a snap. Where should, where should people go if they want to see what you're up to? Do you know? So, uh, internally Slack is always a place to catch me, um, uh, and, or, uh, email is generally the best place to get me. Dino, Dino C. You got a fancy one. Usually it's, it's first letter of a name, last name, but no, no, no. I don't know. You got Coté at Pivotal. So I'm just planning about that. Well, you know, I find, I find the secret to a good email address is just ask. Yeah. Yeah. I, that, I got through that already. And mine was, uh, uh, I, I called foul because my, my, my other one, my, the real one that's there, it's not my alias is D Cicerelli. I said 13 characters. I think is a, there's gotta be a limit to the, right. Punix used to be eight, right? You can only have eight characters. That's right. And you can, uh, 13 got to be a bit much. So I got Dino C. There you go. Well, that's fantastic. Well, as always, this has been Pivotal Conversations. If you want to, uh, check out the show notes for this episode, you can go to pivotal.io slash podcast. Uh, you can also, uh, if you want to see this episode and past ones and, and find the RSS feed to subscribe to it, which you should, you should go to soundcloud.com slash pivotal conversations.

And what you should do also, if you liked this episode, I was just looking at our stats earlier. We had a lot of people who listened to us in overcast. You should go in there and hit the little recommend star. I have no idea what that does. I don't think it's actually very effective, but it's fun to talk about it. It'd also be good if you went into iTunes and left us a review or even a star rating. Would it kill you to do that? It's pretty easy. And, uh, as always, if you want to share it with people, that's nice. Basically Richard and I, and our weekly guests like talking with each other, but it's also nice to know that, uh, other things are happening out there. And with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.