Modernizing Legacy Applications with the App Transformation Program

Episode 92 · 51:36 · SRT · archive.org · all Tanzu Talk

You know, I was told by someone recently, Richard, one of our Dutch colleagues, that they enjoy the aimless rambling we have at the beginning of the episode. So rather than try to be more professional, let me just tell you one thing I've encountered recently. And that is, well, have you ever tried to move a pet, like a dog, from one, let's say, city or country to another one? I thought you were going to say from, like, room to room. Like, yeah, I have done that, Coté. It's, you know, pretty normal if you own a pet. No, I haven't actually moved one long distances because that idea of sticking them in a crate or being worse, bringing them on the plane with me like some sort of crazy person, neither of those sound appealing to me. So I think I would just sell them and buy a new one. That makes me sound heartless, but that's one option. Well, you know, the nominal topic of today's episode is replatforming. So that is a pattern that I guess you could use. Not the lift and shift. And in the course of doing it, you might move from, let's say, like a Great Dane, a series of small shih tzus. And so you'd have a bunch of microservices that coordinate with each other instead of a monolith. Because, you know, every time you try to teach that monolith a new trick, you just have to recompile the whole thing. Here's the issue. It's easy to stick. I'm trying to. It's easy to put the thing in a crate. But the problem is, apparently, the airlines wanting to be, I always think the term humane is kind of funny. Well, I shouldn't say funny. It's just incorrect to apply to pets. I mean, but I get where you're going with humane. Like, what are you going to say? We're going to be canine main or something? Anyhow. Sure. Apparently, if you want to airlift a dog, they won't do it if it's 85 degrees or higher. Now, I don't know if you remember, but I live in Texas. So this is presenting some logistical issues. Because unfortunately, although Pivotal is very kind about helping me relocate, they have not taken on the task of changing the weather in August in Texas. So if anyone has any ideas about how to move a dog overseas when it's 102 degrees Fahrenheit in Texas,

you know, I'd love to hear about that. That's a challenge that I don't think you can have some snap analysis to solve. That's true. I mean, you just have to drive to a cooler state and fly from there. Bam. Now, this has come under deep consideration here in the Coté-Skotak enterprise. It's looking like, barring a solution, we're going to have what you might call the road trip to the birth of freedom, where we go to Philadelphia, where there is a direct flight to Amsterdam on American Airlines. We'll see. We'll see if that solves a problem. Well, re-platforming. Why don't you all to introduce yourselves? Why don't we go in alphabetic order by last name? I believe that's me. My name is Sarah Eamon. And I originally come from labs, but I've been on AppTX unofficially for the last nine months and officially for the last four months. Awesome. My name is Rohit Kelaphir. I'm one of the App Transformation Practice Leads. I've been doing App Transformation for the past four years. Well, as always, we have a few news items. So I think the largest one of interest to us is that Poodle. Container Service, or PKS 1.1, was released. Now, this was sometime last week, right, Richard? I was traveling, so I kind of lost track of time. That's right. So this was last week. And, you know, we've actually shipped, I think, six times in the last five months. We've done a lot of little, you know, incremental releases besides the V1. This is the first kind of bigger release since then. And this was upgrading the supported version of Kubernetes to 1.10. We added some additional availability options like multi-AZ deployments and then some pretty cool integrations with other VMware tech like Wavefront and improved some of the NSX work. So it was a big release. We're excited about it and already have folks getting going on it, which is great. Now, between the two of you guests, I'm interested to hear a little bit of commentary here before we get to the talking about application transformation and the whole, like, like oftentimes what you hear is, you know, you got your PAS,

formerly just Pivotal Cloud Foundry, your rapid delivery and your CF push and all that are the cases. And one of them that comes up is you have existing applications that you don't want to run in Kubernetes and PKS. And I wonder if y'all have some interesting examples of those, like when you're trying to replatform things or modernize, you started to think, oh, maybe PKS is a good idea for this. Yeah, I think a lot of it depends on what level of abstraction and what outcomes you want from the effort, right? In some cases, lift and shift or just like replatforming it, doing minimal changes to the app, getting it running with the Java build pack makes sense. In some cases, you truly want to increase the release frequency, right? That app is strategic to the business. So it makes sense to break it down, take it completely all the way to cloud native. And so then at that point, you are more in the refactoring or in the modernizing zone, modernization zone. But there is also another category of apps that you really don't want to touch at all. And you just want operational efficiency. And these apps generally are gnarly. They are like stateful. They have complex networking requirements. Those are the kind of apps that you generally just want to containerize and run on PKS. So it really depends on what kind of outcomes you want to drive from your app transformation effort. I actually have some concrete examples of this. On my last project, we were using PKS. And there were two use cases. One was that the existing application used an instance of Elasticsearch where they'd sort of hacked in this plugin to modify the results before they came back. And there was no way that we could do that without having like full control over the deployment of Elasticsearch. So we decided to move that Elasticsearch with the wonky plugin onto PKS

because they were already using Docker and everything to deploy this thing. So it was just a very easy move to PKS. And another instance was they were actually a government customer or a government subcontractor. And so they had contracts with the government. And some of their government clients or whatever consumers had like an aversion to licensing fees because they only had so much budget for this product. And to throw in, I think it was Mongo, there's a Mongo licensing fee for using the Mongo tile. So to avoid that licensing fee, they wanted to have the option to like deploy their own database, right? Mongo instance in PKS so that they could deploy their software as a unit without that licensing fee for those certain clients that couldn't pay it. Oh, that makes sense. Well, yeah, and those are good. The all too common affliction of licensing fees. Well, also in the news, I think one of the main drivers of people, you know, wanting to update their software is always, you know, the marauding force of Amazon. And it seems like there must be some like giant room. I don't know if you're supposed to know, should they just like tape up infinite appendixes on them onto a wall? But there must be some room over there where they're just like, they have every single industry in the world and they've prioritized the backlog of trying to take it over. And in that area, I think it's called distribution company, which, which, you know, if you fall asleep of vertical boredom, that's a pretty big industry there called PillPack, which I had never heard of, but that sounds nice. I guess they mail bills out to you, kind of like our CVS Caremark system, which, which I guess, I guess what that gets someone like Amazon is, you know, just some domain knowledge and then like right into a industry that almost seems perfect built for their model of, you know, selling stuff, which, which will be, it'll be interesting to see what they do there. And I think also last week before they announced that they have that,

that partnership with like Berkshire Hathaway and JP to like, I think the idea they're going to come combinate combo, all their employees and then put them all in the same like healthcare or something. And then it's like a million people or something. And they have, they announced the CEO of it, whose name I can never pronounce, but he's like Dr. Checklist guy who always seems like he's, nothing's figured out well. So yeah, there's interesting, interesting, like digital moves going on there. And no doubt, as we always joke about on my other podcast, software defined talk when Amazon does something, there's going to be a whole new industry that is going to, you know, that you can draw on if you're at Azure or Google cloud for customers, namely a pharmaceuticals probably are very excited in Amazon now. Yeah, no doubt. I mean, it's a good move for them. As you say, tap into their existing kind of supply chain. And Hey, if you, I guess buy more pills, you can get free prime or however they, they kind of couple things together. That'll be cool. But then what was interesting to see is, I mean, obviously some stocks dropped, I think it was Walgreens, CVS and some others got a hit, but at the same time, it's been fun to watch companies like again, Home Depot. I saw got a story this weekend about how they're kind of coming back against Amazon or even Kroger getting into driverless delivery. So the old guard isn't necessarily sitting there waiting to get overtaken at this point, which I actually think is an exciting subplot to the sort of digital giants taking over the world is kind of the entrenched interests are actually fighting back a bit, which is always a fun storyline. For sure. I remember I was looking at the picture of that Kroger thing. It's almost like a, I remember in total recall, they have like the Johnny cab, like the car almost looked like a Johnny cab without a Johnny in it. And then, and then finally, I hadn't put up on this one. I think you just put it in as we were starting here, Richard, but it looks like there's, there's some sort of a container security problem. What's what's going on over there. Yeah, there was a survey done or research done actually. And it showed that a lot of there's a ton of kind of publicly exposed Kubernetes

container management view wise. So when you have that sort of default management dashboard, a lot of people are incorrectly exposing that to the internet. And depending on if you don't change credentials or not, you're more or less inviting the world to hack around what might be production could be all sorts of environments. There was 20 some thousand listed in this exposure. And just one of those reminders like PKS, if you're a PKS customer, you can't have this happen to you. Like we've probably have locked things down appropriately. You can't accidentally get into this state, but just one of those be careful things. If you're running open source, you're doing things on your own with some other platforms, you can get in trouble there. And I added just to kind of freak you out more. There was a secondary story that, Hey, a lot of these container images in the Docker hub are being injected with different malicious code and malware and things like that. So kind of good luck to you, building your images and running it in your open source container orchestrator. Cause it's kind of dangerous out there. And from my cursory reading of the story, it looks like it was ultimately this resulted in generating about $90,000 worth of Bitcoin. So it seems like maybe it's not a lot of work, but man, that's a good old, good old, good old Bitcoin seems to be working out for everyone. Now you're helping our SEO by mentioning that in the podcast. So that's good. Well, welcome to our new audience. That's right. I had someone, I was in, where was I? I think it was in, in Cologne or, or as the Dutch say, coolen, or as the Germans say something else with the umlaut on it. And I was, I was saying like, I was mentioning someone at an insurance company was talking about blockchain and I had no idea what that would be used for. And then sure enough, someone from a, someone from a big German insurance company came over and explained to me why blockchain would be very valuable in insurance, which was, which was kind of fascinating. It, it also exposed the, you know, often in it, the words practical and boring are synonyms.

So with that said, it also explained some of the practical sides of a blockchain, namely just like verifying that a thing happened, which as you can imagine in the, the insurance industry is valuable. And to bore everyone more, he told me that in Germany, there's this interesting regulation with insurance that no matter what channel, which is to say what method through a person or a website, or, you know, maybe you're at the back of a magazine and you mail in a little postcard that was in there. You all, you have to consistently be offered the same terms and a rate for your policy. I guess you could say their policy procedure is item pot, right? Like it generates the same thing every time, which is kind of a fascinating. I, I asked him why that was, and it was something about, I don't know. It didn't really have like a very great answer, but it sort of made sense from a being nice standpoint. So speaking of introducing blockchain and insurance, it's always lots of details like that. So we have our two guests on, you're on, or, you know, what we call the app TX team. And I think I forget if the X is capitalized or not, but why don't, why don't one of you give us a kind of an overview of what you do on the team? Like what's the purpose of it? How long has it been around? And just a little synopsis of what it is. I can give you kind of a brief introduction app TX, right? X small D capital. That's the most important thing you need to know. Well, we can stop now. Yeah. Our mission really is to help and enable customers migrate workloads and applications onto Pivotal Cloud Foundry to get the benefits of the platform, right? So Cloud Foundry and Pivotal Cloud Foundry is an opinionated platform that offers multiple level of abstractions. We help customers on that journey to move their applications to the cloud. And what does that mean?

And in concrete terms, we practice our Pivotal techniques of extreme programming, test driven development, pair programming, lean, lean outside in product engineering. And we migrate and transform applications to Pivotal Cloud Foundry. We deal with all kinds of applications. So if you consider applications as T-shirts, we start with small, medium, large, and go all the way up to triple XL. Now, the techniques kind of vary as you move along the spectrum. And a lot of it depends on what, what outcomes you're driving for. Are you looking for operational benefits? Are you looking for increased release frequency? Are you looking to retire technical debt? It's a, it's a small team. It's a team of about 40, 40, 40 engineers, I would say. And we work with the customers very, very closely. We pair with them and we kind of teach them and give a, give them our secret sauce so that they can do this at scale, move all their applications to, and get them to cloud native. That's a good description. I think it, I often see it as kind of like not, you're not selling that sugar high of just like use technology here, go try it. And then you get frustrated and it kind of just sits on the shelf somewhere. You're actually helping them actually activate the first step, like actually learn how to do things and then kind of have the skills to keep doing it. But one thing I see mentioned in kind of your domain, Rohit or Sarah, if you'd like your take on this is help me tell the difference between some of the terms you see thrown around sometimes as synonyms. So like replatforming, modernization, refactoring, are those synonyms or those meant to be used to describe different aspects of app transformation? Replatforming. You can think of it as another term for it that we hear a lot is lift and shift, right? We're taking some legacy application and we're just getting it to run on PCF. And then that's more of, it's more of a spectrum, right? So replatforming can go all the way up to modernization.

If you think about a, you know, a spectrum with replatforming and modernization modernization in the middle somewhere, there's this idea of like refactor where we're applying the, you know, 15 cloud native factors. And, you know, in order to get the application running in order to successfully complete that refactor or sorry, replatforming, we're going to have to modernize a little bit, right? And, you know, reduce your dependency on the file system, right? All these kinds of things get your app to scale and run in the cloud. So we're going to move along the spectrum and get some of those 15 factors running, right? But on a replatforming engagement, the focus is getting as many applications running on the platform as possible. And then we get as far along in that line as we can in the time. Whereas refactor is like, Hey, we want to go full cloud native, right? We want to address this application and basically massage it as though, massage it until it gets to the point where it looks like we wrote it green, right? Greenfield. And we can run on any platform agnostically. And then at the like far end of that is modernization where you're saying, okay, now I want to actually choose the best architecture for this application, right? And maybe I'm good. Maybe I'm going to carve off some microservices. Maybe I'm going to put in, you know, service discovery, right? That sort of thing. And architect my system, you know, and, and get it with some nice test coverage and things like that, get some confidence around the application. So it's, it's not a switch, right? It's not a radio button where you say, I'm going to refactor or refactor or re-platform or modernize switch those first to re-platform, refactor, modernize. It's a spectrum and you're going to, you're going to try to hit some goal along the line and you're going to hit the others kind of along the way. I see. That's a good description. So a lot of it comes down to how much you're really messing with the source system. Whereas obviously re-platform, you're probably messing with it as little as possible. Modernization, it may from the outside almost appear like a new system.

Is that fair? Yeah, I think that's fair. So when you're thinking of that though, I'm assuming that that's not a black and white sort of this app gets this, this app gets that, because there could be components. Correct me if I'm wrong, where you say, look, we're going to actually modernize this aspect of the app. Maybe it's the front end, maybe it's a backend component, but Hey, for this sort of set of things, maybe the database, like you mentioned earlier with Mongo or other things, maybe that thing, we just re-platform and we just run it in Kubernetes before, before we just ran it on a VM or a bare metal box. We're just looking for incremental efficiencies. Is that fair? Do you see it sometimes span, even within an app, how you behave and how you, what you do with it? Oh yeah, that was actually very much to the point of what I was going to say was there's a factor of size in this, right? The bigger, the source application that you're looking at, the more different that journey is going to look, the smaller the application is. You're probably going to be fine with just re-platforming, right? Because it's small and self-contained, but as your application gets bigger, just to exactly to your point, you're probably going to start carving some things off and modernizing little pieces, maybe pulling them out as microservices, maybe not pulling them out as a microservice, but isolating them in the code base and getting them well surrounded by tests so that in the future, if you need to, you can pull it out as a microservice. So, so there's a, I'm sure there's many, but there's a couple of great talks from SpringOne platform that, that I was watching. And, and it kind of goes over how y'all do the practice. And, and, and I think, I think one of them draws on explicitly like a Liberty Mutual case of, of how they're doing things, speaking of insurance, just coincidentally. And, and, and, and, and it strikes me that like a lot of, a lot of going through modernization or application transformation is a very disciplined process. And, and how it seems, the way that y'all go through it is how it differed in the discipline process we're used to, is it tries to do things as quickly as possible or in small loops. I mean, that's, that's my very high level summary of things, but I think, I think what would be interesting and maybe,

maybe, maybe you can go over this is like, what is, what's like the general process that you go through, right? So let's say, and, and to, to sort of set that up, let's say I'm a, we'll just use insurance. It's the insurance episode. Let's say I'm an insurance company and I've come to your team. And, and I guess, I guess the complaint is usually, I need to innovate and add new features to my, my overall claims and policy selling system, but it always takes like 15 months and that's not cool. Like I want to be able to do things faster. So then what, what you get everyone in a room, like what generally happens over the course of the next 10 or so weeks? Yeah. I mean, so even before the engagement, the 10 week engagement begins, right? There's some pre-work that you have to do beforehand to kind of understand which application are you looking at? Is it a single huge system of systems monolithic application or is it about four or five smaller applications that come kind of comprise a suite of portfolio of apps? So that kind of dictates the, the engagement. Now let's assume for, for an instance that it's a big application. It's a really a monolithic application with one plus million lines of code. So most are most of our exercises kind of begin with an OKR session where we drill down into strategic goals, objectives and key results. So we try to quantify as much of the work that we want to do. So which is why we believe we start with what are the concrete outcomes do you seek? And what are the key results then? So that's kind of equate those as the soft practices. Then in order to even achieve those key results, like increase business agility, what does, what does that mean? Does that mean that you want to increase your release frequency? or if you also sometimes we hear reduced technical debt, what does that mean in concrete terms that we need to reduce the coupling that multiple parts of the system can be updated independently from one another. So we drive out key quantifiable results.

And then you begin the process of modernizing that, refactoring that, rebuilding that, whatever you want to call it. And that typically starts with understanding of the domain from our side. We want to understand the entire application. We want to understand the data flows within the application, the commands, all the, all the constituents of the application that, that, that lead to the, that give us insight into the business logic and the domain of the application. So we have multiple techniques here. We use primarily in order to understand the domains. We leverage a technique called event storming. Event storming is both a technical and a non-technical process where you get the domain experts and the application and the technical experts and the domain experts together along with the pivotal team. And everyone models the, tells the story of the application in terms of domain events, commands and aggregates. And those, once you do event storming, it gives you two things. It identifies the top constraints. So if you're familiar with the theory of constraints from, from, from Goldratt, it kind of gives you the top problem to solve to, to give you the maximum benefit. So it gives you the top constraints. And the second is it gives you an understanding of the domains of the application. So once you understand the domains in the mounted context, you then begin a second series of exercises to map relationships across the two and then figure out which services to strangle out first. And then you use, after you figure out the, once you draw the interaction between the domains through a process, we have diagram called Boris. You have now identified the coupling between all the domains and you pick a particular service to decompose and strangle. And once you do the first one, then you pick the second one. Now that's one axis of decomposition. Sometimes it's obvious that you have to separate the UI part of the application from the backend processing of the application. So sometimes modernization is obvious. A customer already has deep insight into it. In other, in other cases, we kind of help them bring out the pain and the technical challenges and figure out

what are the best, what is the best way to decompose an application. So that's a spectrum of a huge application and how we kind of, and then in those 10 weeks, you see a lot of those 15 factor being implemented for the applications. We have, we implement CICD pipelines. So all, all of that application is done in such a way that those apps are modern and can be updated independently of the larger app. So, so to interrupt you and then we'll, so, so basically we're sort of past event storming and there's a few more steps and you're making the dragon happy, which is exciting. But you know, when I was, when I was, well, first of all, where's this concept of event storming come from? Did, did, did, yeah, even somewhere else or did y'all make that up? No, event storming was inspired, was popularized by this Italian guru called Alberto. I'm going to screw up his last name. It's Zandolfini. Perfect. And, and he was inspired from game storming. It's a series of facilitation techniques of group facilitation techniques that is, that brings out the domains from a domain driven perspective. It's a, it's a, it's kind of a very cool technique to, to draw out a mental model of the application. If there are groups of like them, because for an application that is 2 million lines of code, no one knows everything. It's kind of, it's, you have to have everyone who understands all parts of the elephant to show up in the room so that you can draw a picture of the elephant. So that's the, this technique kind of helps you do that. And yeah. And you know what, and maybe, I don't know, I want, I want to run my sort of summary of it and by the two of you and see if this sort of makes sense. It seems like it's almost, I don't know, it's kind of akin to a, a value stream in the following way. Like you sort of have an existing system that in reality, no one really knows how it functions completely.

Everyone has like one little particular view of it. And so instead of having like a descriptive way, your classic, like a right click on your application and extract a bunch of UML diagrams or whatever it is people do nowadays, which sort of describes what, what the system looks like. I don't know, theoretically, it's almost like you're, you're rediscovering the purpose and the reason things are running, which is to say, as there's a process going through your system, like, I don't know, answering an insurance claim, what are the significant things that is say events that occur and how do they kind of pass off between each other from, from a business process sense. And in that way, it almost seems like it's a good way to do a bit of like architectural archeology where you're trying to find out how things actually operate versus how they should be operating. And, you know, and then by having all those different parties involved in a room, it seems like, well, they're, they're the ones who know they're small little, they're part of the elephant as it were. And you get, you get a, you get a actual, it's important because you not only get a picture of how you think things operate, but you get an idea of how they actually operate, which is clearly a lot more valuable than theoretical operation. Yeah. And I think, Michael, you're, you're spot on. Value stream mapping is, is, I look at it as just another form of event storming to tailor to a specific outcome. Yeah. That makes sense. So, so what, like, like have, have, have either you or Sarah, like, what are, what are some examples of, of that you might have of like, I don't know, fun aha moments in event storming? Like, like, like I imagine it often occurs that someone, some, some architects or some other people say, Oh, I, I never realized that was happening. Like that's a, that's an important part of the system. The ones that I have seen are just, everyone kind of confirms their understanding of where the, the pain is in the system. It, it often leads to the,

the, the business developers and the technical guys, them themselves having a better understanding of the system. So it's kind of like a cathartic experience. Think of it like counseling almost in some way. I don't know if I have any aha moments for you. It's, it's a gradual series of progressive understanding of the app. It's, it's, it's very effective way of care of transferring knowledge as well. And one of the cool parts, it's not even just for current state, even for future state, right? Like you are in this system because of various problems that you have had. We also, in my recent engagement, we did it, a colleague of mine did it for future state event storming, where you can then imagine the art of the possible with the newer system. So event storming is not just for the old existing monolith. It's also for how will our new system look like? How would the, what would be the flow of events for the new system? And that helps you design your APIs and contracts for the new system. That's cool. So one thing I wanted to, you know, the event storming stuff is pretty cool stuff, but you, and you touched on this Rohit a little bit and Sarah, I'm interested in your experience in your, your real four months, maybe your fake eight months of being on aptX is when you kind of see success metrics and Rohit called out some of, some of this. And I think it's important to call it, this is quick. This is like 10 week projects. These are not like nine year life transformation. Everything changes projects. These are pretty quick. You see feedback quickly when you've finished your projects. What are those sorts of things that go back to the customer and say, Hey, this seemed like it was worth it. Like we check this box. Is it, is it things that feel like they're sustainable changes? Like, Hey, we've got so many apps on pipelines, or is it things about just raw number of apps that have been moved in general? What sort of things do people define as their success? So before we go on to that one, I just want to say one more thing about the event storming, which is not every project does an event storming, right? That's more of a modernization technique. So if you go in and you know that you're going to need to modernize your system,

we usually do an event storming, but I've been on primarily replatforming engagements where we haven't done one. And my experience on replatforming is like that stuff comes out organically. Whereas with event storming, it kind of comes out upfront with more of an organized method behind the madness. And my experience of app transformation is more like you're riding a tiger and you're just hanging on because like you said, it's a very short engagement and you don't have a lot of control. You're not in a greenfield environment. You're in their environment and every environment is different. So as far as success metrics go, right, it's, you know, how far did the tight, you know, how much, how much progress did the tiger and I make at working together? Right. And are we going in the same direction at the end? And obviously we want to get to production, right? Because until apps are in production, they're not making any money for the customer and they're not seeing the benefit really of the platform. Right. So one of our primary goals is, Hey, let's get stuff all the way through into prod. And, and then enablement, right? Like, like you said, it's a very short engagement, four to 10 weeks. And if you're on a four week engagement, that's not a lot of time, right? That's a very, very small amount of time. And so we need to make sure that in the short amount of time that we have, we have brought people up to speed enough that they can continue this without us. Right. So we want to have some really, you know, intense conversations. We want to show them, you know, the, the path forward, the light at the end of the tunnel. And we want to leave them with some tools to get there on their own after we're gone. Yeah. And to give you some insight into numbers, Richard, our average for replatforming is roughly 10 apps in 10 weeks. And those 10 apps, think of those 10 apps as like maybe three medium or four medium apps, three to four large apps and three to four small apps. We've done vastly more. And sometimes we do a little bit less, but that gives you an idea. 10 apps in 10 weeks. That means you're basically doing one app in a week across a team of roughly three pairs

or four pairs. That's how fast it goes. But customers often are amazed at how much gets done in 10 weeks because of the way we work. We work in a dedicated pair programming fashion. We work for, we have a very rigorous style of work and we do take breaks. But when you work in this kind of setting where you are enabling the other partner and you have dedicated time, a lot can get done. Yeah, it seems like, and then one of those things that you touch on there, it seems like at that pace, settling for just a pure, you know, let's just containerize our apps and call that success and move on. It seems like you can do better than that. And I think that's what we're trying to sell here, I think, which is like that alone may not give you the benefits you're looking for. It might make sense to have some of these apps that go much further than that. Is that fair? It seems like that lift and shift is sometimes incremental benefit versus if I'm looking for actual benefits and availability or scale or what have you, that does have me move a little further down that spectrum. Is that, is that how you categorize kind of positioning that to people? Yeah. I mean, so when, even when we say replatforming, like Sarah said, it's a spectrum. Oftentimes it lands somewhere in the middle where we have, where we have externalized the configuration. We have stored the secrets in a vault. We do, I mean, I to be to, I mean, we, we do a lot of just taking applications and moving them to, to cloud native. We do less of a pure lift and shift model. We, we prioritize how much changes we need to make based on, on what the customer wants as well. But we innovated in, we most of the times land on the right side of the, of, of the modernization zone. Sarah, what do you think? How, when, when we re-platform applications,

where do we end up landing them for the most part? I think it's very different based on the application. And that's a hard question, right? Because the, the goals of each client are different. The goals of each application are different. And, you know, I think it's important that we don't always hit every goal, but we do show the path forward, right? We, we leave with the knowledge of how to get to the next step and maybe what those next steps are. Not maybe, definitely what those next steps are. So, you know, we, we want to get it when we have this suite of small applications, we want to get one application, you know, all the way through the system. Right. But then every other one, we get to some point where it can run on PCF. Right. But it's not necessarily done, done. And, and, and instead we leave this map, like we said, Hey, we've, we've shown you the way with this one and you have the tools, right? You have the knowledge of what we did together on the one that punched all the way through. And here's the roadmap for the others. So, so speaking of next steps, I interrupted the, the overview that we were going through of what the process is. And I think, I think we left off like maybe after event storming. And if not, I forgotten what we did. So maybe we can go to that part, but do you want to keep summarizing what the overall the, the dragon happy process looks like Rohit? Yeah. So the event storming may or may not happen, right? It does not happen for all applications. It happens for these huge system of systems, monolithic applications for the small, medium, large applications. We have, we have a couple of processes in our tool belt called snap and, and another set of automated tools where, so snap stands for in a snap, not analysis paralysis. So we have this process where within like roughly 15 minutes to 20 minutes or half an hour, we get, we get an understanding of how much effort it will take to re-platform the

application. And then we also have some tools that we can run in an automated fashion. We combine that expert insight from snap into automated tools and basically generate a t-shirt size score for the application. So the applications, like I said, would fall into small to medium, extra large. And then for the huge apps, they are, I categorize them as double XL and triple XL. So, okay, you've gone through snap, you've gone through PCAT. you have an understanding of the modification points of that application. We create a backlog and all that typically happens either in the pre-work or it happens in the first couple of days of the engagement. We want to start writing code as soon as possible to start the learning. So the process, the actual engagement begins with an inception where we drive out the objectives and key results. We, we review the results of the snap analysis. We create a backlog of all the stories for and tag them for each application. We also tag the backlog of user stories and associate them with specific key results so that at the end of the engagement, we can track exactly how much of those key results we have completed. And then essentially we start with stream in a replatforming engagement. You typically start off with three or four apps, depending on how many pairs you have. Each pair tackles an application and starts making changes to it. And then you begin the series of changes for replatforming. And so typically that begins with, if you, if there is an app and you, you inject spring boot into the app, you look at some of the dependencies, you remove the JNDI dependencies, you go through the process of what I call as bootification. Take the app to make changes to the app so that it becomes cloud native and cloud, almost in some sense, cloud agnostic. And then typically like, like I mentioned the 10 apps in 10 weeks, usually our run rate is it, you take a pair takes probably a week to move an app, sometimes more,

sometimes less. And we see that the velocity typically increases towards the end. And towards the end, we also put more focus. We also may do a value stream, a path to production, because in some cases, it's really important to get the apps to production. So we figure out how to automate CI, CD and to bust any of those blockers there. So we also put a particular focus on getting the apps through the pipeline, all the way through the environments to production. So those are the things that we, that kind of happened during an engagement. We have mid engagement reviews, end of engagement every week. There is a retrospective. There are iteration planning meetings. There are demos. We closely align with the product owners from the customer side and make sure that they accept our stories. It's a very close collaboration till the very end. And because we have been pair programming throughout, there is no knowledge transfer at the end. All the developers are enabled. And after that, they can sell, divide and spawn other teams at the customer side. And that's how it scales. Yeah. There's a, you know, as, as to the point of a lot of it being sort of a process oriented and all of that. It's interesting that a lot of the technical aspects you know, actual coding and architectural stuff that I think people often struggle with when they're dealing with legacy sort of happens at the end of the process. And there's a, there's a good little vignette of that from another rookie at Liberty where he, where he talks about, I think a three stage MVP that they go through to, to break up a, an ear into smaller services. And then also to like remove database dependencies. And it's, it's a nice overview of the technical part of how you kind of systematically do what, people often feel is impossible, which is to take, I guess, like a classic three tier application and, and break it up into microservices. So the, the, the, you know, sort of after that process, I'm curious to hear, I mean, as, as you keep bringing up Sarah, that I, and I think this is not unique, but well, I'll say it's unique for marketing purposes, but it's one of the hallmarks of a lot of pivotal stuff is like,

the hope is that like, you can figure out how to do this in the future after we've helped you do it. And I wonder like what advice y'all give as far as like, here's like the hygiene you should be maintaining so that you don't have to hire us again to fix your, your sort of legacy problems. Like certainly there's some sort of habits that people fell into that caused them to have something they didn't want or problems in the first place. And kind of like, what are the, what are the pieces of advice you give them and sort of practices that they should start following on going to not fall into this, this situation again? Well, the first one is pairing, right? And that's not practical in every organization, but we like to encourage it where possible. Because if you're pairing, you've got continuous code review, right? You've got two problems, two brains solving the same problem over time, you go faster. And, you know, a lot of people are reluctant to pair at first and they're not really sold on the benefits, but once they've done it with us for a while, they kind of see, oh yeah, I see what you're saying, right? About these benefits. So that's, that's one of, you know, the hygiene things. If you've got two people looking at code at any given time, you know, right there in the moment, solving the same problem, you're more likely to create a good solution or to highlight the problems and then go have a conversation with your pair or with, sorry, with another pair. So pairing also, you know, testing, right? We get into, you know, a lot of these systems and we see, oh, we've got some cucumber tests or we've got a Q18 that does manual testing. And our unit tests are, you know, like, I don't know, we have, we have 200 tests for, you know, 1 million line software system. And it's like, oh, that's, that's great. You know? And if we can, if we can instill the values of TDD, right? And, and show you the benefits of that. And that's a commitment that you're willing to make long term. You know, that's, that's another one of those hygiene things. Like it's not easy to do TDD. It takes an actual mental shift and kind of a responsibility to yourself and your pair and your code. But it's another,

one of those things that pays off long term. The thing is, Michael, the, sometimes you, the 10 weeks is not enough. You do have to, like we also work with partners to create that long term journey for that application or suite of applications. So oftentimes after app transformation is done, we work with pivotal labs to, to carry the long tail of the project through. And then we work with customer partners as well. So it's not just, we come in for 10 weeks, we are gone. We, we sometimes can do multiple engagements. We like to work with labs and then with the customer preferred partners to kind of get them all the way through the journey to where they need to be. There was another hygiene thing, which is we maintain a cookbook and we build a cookbook while they were there as we were pairing on these problems. And, you know, part of what we're trying to do with app transformation and what the clients are trying to do with app transformation is move a lot of applications, right? It's not just this one. It's, hey, I want to identify patterns using this one as an example to make me successful in other projects, right? With other applications. So we, as we go along and we identify, hey, this thing was difficult or this is a pattern that we have in other applications, we write it down, create a cookbook, and then that cookbook can get shared out with the organization, right? And teaching people to kind of have that discipline, right? Once you've identified a problem that you think other applications are going to have, writing it down, recording it, that goes a long way, I think, towards being successful in the future. Yeah, I was going to ask you a cookbook question. So you somehow teed that right up. So I was going to, because specifically, you know, there can be this mindset of like, look, we bought this certain tech. It's really cool. Hey, we're just using public cloud. We took some training. We bought the books. We're going. And that obviously sometimes works for some orgs, but does seem like legitimately, seriously, that when customers are doing app TX with us, that, that leads to an evolutionary or maybe even a revolutionary shift in their approach.

If they learn the things you just talked about around hygiene and pairing and testing, but then they also learn how to keep doing it, right? Not just while we're there that, yes, we partner and we pair, and that's awesome, but we don't have to be there for life. If we may come back and help and tune up, but it seems like you're actually teaching a healthy lifestyle, if you will, and then leaving behind all the things you need to keep going versus making them codependent on us. Is that a, is that a fair characterization? I think that is very fair. And that's something that I, I actively strive to do with every pair that I have is teach them like, Hey, let's, let's ask questions, right? It's okay not to know. That's, that's a really hard thing for people, especially the more senior they are to kind of do sometimes, you know, there's this pressure that we have to know everything and we can't show weakness. Right. And so we're going to go off into a hole and research something and then come back with a solution instead of just, you know, kind of being more upfront and saying, gosh, I don't know. And I guess I should say not just senior people. It's, it's everybody. I see that with a lot of junior people too, right? That was a, that was a bad characterization on my part. Sorry about that. But yeah, teaching people, like you said, to kind of have a healthy mindset and just, being transparent and being empowered to say, Hey, this is, you know, anybody can raise their hand and say, Hey, this is, this is something that's missing from what we've done so far. Or, you know, I think this is a better solution, right? Or I'm worried about this or, you know, whatever, bringing up those questions, not knowing, being able to explore and you just being a little bit more transparent with, you know, yourself and your team is, goes a long way. I mean, that's, that's sort of wishy-washy and not technical, but, it's, it's a huge, it makes a huge difference, right? If everybody's driven by fear, fear of losing their job, fear of not making their date, whatever, your team is not going to be very effective. Right. Yeah. But at the same time, I think what I hear from you and Rohit throughout this talk is that, again, this is still a very personalized approach.

You don't come in, drop down a 400 pound cookbook on someone's desk and go, go at it. Like ride the tiger. Here we go. I think from the sounds of it, you're describing something that from the start is still very tailored to that company's sort of personnel, their tech problems, their challenges. And then what you do leave behind is, is the sort of recipes you've worked on together, right? not just a generic collection of things that, that they may or may not use. Yeah, exactly. And that's where having, you know, for us, we, we maybe bring the process and the experience of the technical replatforming and all that to the pair. But what they bring is knowledge of their system, right? Knowledge of their applications, knowledge of their company, knowledge of other applications in the company. And so, you know, our, our pairs are usually the people that are like, hey, this is a good recipe, right? Like we've got, we've got 50 applications that use the same patterns. Like, well, great, let's write a recipe about it, right? And something that we think might be a good recipe, they're like, yeah, this is, you know, I don't think so, right? This is just, we just did this, this one time. So it really is a, an intense collaboration and, and the cookbook that comes out of it is designed to be useful to that organization, right? And their suite of applications. Yeah. And this is a second order derivative effect to the cookbook, the CICD pipelines. The, we've seen customers then create centers of excellence, right? That, and then create like a factory there where all the teams come through the, factory and create hubs, like almost like a hub and spoke model. So once we see this wave of, of, of momentum getting generated after a successful engagement where other teams kind of build on that success. Well, that's great. Well, I'm glad we had the, the two of you on to give an overview of this. It's like, it can seem like a huge bundle of things, but I think we condensed it down pretty well with y'all's help. So before we leave, you know, if you could pick like one or two things to point people at, if they, if they're interested in more,

I, you know, whatever you might like, whether it's technical or, or, or more meat wary or whatever, like, what do you think, what do you think some good materials are when it comes to how people are doing app transformation to dig into more? Yeah. Yeah. There is pivotal.io slash replatforming. You could, you could head on there and kind of see what customers we have worked with. What, what are sort of the key outcomes? See if you are into like single page or two page briefs or white papers or webinar links, that's the place to kind of land. Talk to your neighborhood, pivotal platform architect or rep. if you want more specific help, we have, we have done talks at, I think SpringOne, which you referenced, Michael, maybe we could put that in the show notes. And then yeah, overall we are very active in the community as well. So yeah, if you, if you have any interest, please, please reach us, please reach us to pivotly, any of the pivotly channels. We are more than, we are more than eager to help you on your journey on an established and get that roadmap going for you. For, for me, I was first starting, you know, my work with app transformation right before SpringOne, in 2017. And so going to the talks at SpringOne, 2017 was really helpful for me. So that's kind of where I would say start because that's where I started. But there are a lot of really interesting talks about, you know, carving up your application, replatforming, using some of the architectural patterns, right? With the Netflix OSS that, that I think are solid and, and I end up using every day. Oh, that sounds good. Yeah. I was just watching those this morning and thinking like, man, we have, we put a lot of resources, thankfully into posting recordings of sessions that we have, which is nice. We should, we should calculate one year, one year, sometime, the total number of hours we have out there.

I don't know what we do with that, but it seems like, that seems like the kind of thing you would have one slide with the number on it, and you could post about it. I'll put the interns on that this summer. We'll be set. There you go. The army of interns. Well, you know, if there's any of those interns listening, and you're not aware of where you can find the back catalog of episodes, if you're interested in pursuing other great episodes, and maybe even not so great ones, if you're just looking to fill your time, of Pivotal Conversations, you can go to soundcloud.com slash Pivotal Conversations, and there's all sorts of episodes there, and more or less every Thursday, we keep referring to show notes. We'll post those show notes at pivotal.io slash podcast, and also I believe if you're interested in a kind of thorough overview of all the replatforming, aptX stuff we have, you can also go to pivotal.io slash replatforming. No hyphen in there, just replatforming, and with that, thanks again to our guests, and we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.