Eating elephants one bite at a time, large scale application modernization with Rohit Kelapure

Episode 173 · 56:47 · SRT · archive.org · all Tanzu Talk

Hey, this week we've got a new type of episode for Tanzu Talk. My team has been using Twitch. If you go to twitch.tv slash VMware Tanzu, you can see the original recording that we did here, kind of live and unedited, and all sorts of other things we're doing. But I've edited this one down a little bit to be more audio compatible, and just because it's nice to edit my inane chatter down. So hopefully you'll enjoy it. But if you want to see the visuals, I'll put a link to the original video in the show notes, which is at, again, twitch.tv slash VMware Tanzu. And you can also see the show notes at Tanzu.vmware.com slash podcast. Also, I would be remiss if I didn't note, as you can see here, that we've got our conference SpringOne platform coming up on September 2nd and 3rd of 2020. It's free for everyone. It's online. I've helped put together some of the talks, I should say. I've helped select some of the talks for the agile leadership track, which is going to be great. You know, I'm always trying to make sure that we have a lot of good case studies and sort of like tactical things for people to kind of learn from. So you should really come check that out, September 2nd and 3rd. If you go to springone.io, you can register for it. And again, it's all free and online. So hopefully it's something you enjoy. So with that, enjoy learning how we help people go through the big, important task of modernizing their portfolio. And this is kind of part one of just an example of how you walk through that strategy, putting it together and thinking about what to do. Why don't you introduce yourself, guest? My name is Rohit Kilapir. I have been in this app modernization space for a long time. I work for VMware Pivotal Labs. And my primary role is to help customers migrate applications to the cloud.

You have been on many editions of Tanzu Talk over and over again. I was just listening to one, I think four. I was just listening to one and you had a great overview with someone from Travelers, essentially about, I think, tell me if I'm wrong, but how they moved over from the mainframe, essentially, and kind of systematically went through. And I think the application y'all were talking about was like an insurance approval one? Or no, someone trying to get a price for insurance. A rating application. Yeah. I mean, Travelers is great to work with, right? They have been a long-term customer of ours. So kind of they work and get our processes. Mainframe is always painful, right? And you have to kind of keep that elephant one step at a time. And so there was a rating for commercial insurance, I think, a rating application that used to run on the mainframe. We kind of ran our processes, primarily VMware Labs processes of domain-driven design and Swift to pull out, start strangling out pieces of that mainframe application and rewrite it on .NET Core, on distributed, and running it on Cloud Foundry or Pivotal Application Service. That project, we kick-started it. And then we came back and kind of helped them with a big push. I believe most of it is in production now. And they have, like, actually been successful on getting off the mainframe, which is kind of a big deal. That was last year, right, that y'all were talking with them? Yeah, we spoke about it publicly last year, but the project was started a couple of years back. So it takes a while to talk externally about something. So we had to get up to the world.

And then, but yeah, the webinar happened last year, but the work was kind of ongoing last couple of years. And so I was asking that. So I wanted to have you on, because I was thinking, like, a visual medium is perfect for a lot of the stuff I've seen you kind of go through with your pencil there. And kind of going through how people, I mean, it's a multi-stage thing. Perhaps you can start with the first or wherever you want to jump in. But I think the process that you all go through to kind of say, like, here's your gigantic portfolio of existing software or legacy applications or heritage or whatever, whatever people want to call it. And you all have a good process of figuring out, never minding actually doing the work, which is great, but actually figuring out what projects you should work on, like what to actually do, which will be fun. But before we get to that, like, as I was listening to the Travelers thing, I was reminded of a conversation I've had with a couple of people, because I think the person you were talking to, there was some, like, motivation they were responding to. Or no, they were talking about how it's really good to, like, you know, not let yourself get, but not get stuck being happy with things being okay. And all of a sudden you have to, like, handle a bad situation, right? Like, that's the worst time to fix legacy software. And it was reminding me of something people, I've heard a lot of people talk about, you know, nowadays with the COVID and everything. And, you know, I was early on, you know, working in marketing, people are always like, what's the COVID angle on this? We got to get the eyeballs. And so they want me to talk about that kind of stuff. But it always seemed like a bunch of overly opportunistic. But in hearing people, like, talk about what their organization is doing near this, I've realized for some industries, it is this crisis moment that's required them to, like, do things differently really rapidly, right? Like, especially with stores and banks and things like that.

And some of the commentary I've heard is really interesting, where because there's such a, I don't know, not time dependent, because there's such a deadline, like a lot of the normal slow ways of doing things, they're given permission not to do them. And, you know, I was wondering, like, that seems like the opposite of what you usually are doing when you're doing application modernization, right? Like, it's really hard to go in and be like, hey, we're going to modernize this stuff. And it's kind of sort of going to result in it looking like we did nothing. And so, you know, I was wondering, like, are you, whether currently or whatever, do you ever get in a situation where it is kind of like a crisis that you modernize something? And, like, what does that look like? Yeah, I mean, see, like, now in COVID times, one of two things happen. Either customers want to really, like, start modernizing because they have a critical pain point. Like, for instance, in retail, we have seen that volumes have gone up 200%. So if an existing retailer was looking at modernization, they are basically pouring rocket fuel on that. And, like, just, like, just get it started yesterday, right? So there are two classes of engagements. One is customers want to get started now or yesterday. And then where it has had a long-term chilling impact, like travel or airlines, there the pipeline has almost completely stopped. I mean, they are basically only in, like, survival mode right now. They don't have any money to spend on modernization. So either you are pouring rocket fuel on it or you are icing it. Like, these are the two things that are happening. Right. Usually, like, customers and enterprises are middle of the road. But, like, COVID has either dramatically accelerated or dramatically decelerated, like, your modernization phase is how, like, I have seen it. Yeah, that's interesting.

It's like there's no middle ground. Just the two. A classic convex situation, if I remember. No, wait. Convex goes up and concave goes down, if I remember. I forget. I was never good at geometry. I was bad at anything. So, as I said, like, what? So you all go in, your team, and you're like, all right, we're in a mostly large organization, unless it's a small organization for one of these exceptions. And they're basically like, all right, let's modernize. And you go in, you know, you've had that awkward thing that we all do, working in an external company where you showed up 30, 45 minutes early, and you hung out in the lobby until the person who knows them shows up, and you got to go give your driver's license or your passport and everything, and they, did you bring a car? And then you got to wait, and you go in, and you, like, get some coffee, and it's always from these little, like, little cups that have been around. Whatever. So then you finally, you're all set up. You're like, you got the Microsoft Teams to work so the remote people can view it. You had to switch out the HDMI to USB-C dongle several times. And you're finally ready to start. What are we going to launch into? And feel free to jump around to whatever part of the process you're most interested in. But, like, walk us through what it feels like to do some modernization. So I'll just take it slow. So what customer has is, like, they call us in, right? And let's start with, like, they have generally a problem statement or, like, a problem that they want us to solve. So in this case, let's say they want us to, like, modernize my portfolio, right? So this is, usually when we get caught for app modernization, it is some flavor of problems like this. Now, from here,

you kind of take two paths into the, like, essentially two pathways that this breaks down under, right? So either they want to move a portfolio of apps to the cloud, right? So what is the best way to move a portfolio of apps in a line of business or a particular, like, a particular stream of business, right? To the cloud, right? So this is portfolio of apps to the cloud. Or the second way is, like, help me to, what's the best way to modernize this legacy, like, critical app, like my crown jewel, the one that generates a billion dollars of revenue every year, which is this massive monolithic application. So there's a whole bunch of small, medium, and large apps, right? And then there is, so I'm going to put star here, and then there are these Excel, double Excel, triple Excel apps that are massively monolithic and generate tons of revenue. So that's kind of the problem space that we see, Michael, when we show up at a customer site. And, you know, I mean, tell me if you encounter this or if it's just an infrequent thing that I come up against every now and then, but I remember there's often a, well, I'll cut to the chase. It's often like the mobile apps are done very well and work out nicely versus the other apps. And I think, I think maybe a lot of that has to do with the, we don't say client server anymore, but the client server nature of mobile apps where the mobile app can just sort of exist all on its own and it has to work with backend services, but, you know, they can kind of do things all on their own. And I remember one organization I was talking with a long time ago, I was pointing out that I'd used that, that company's mobile app and it was really nice. And they had been for an hour or so talking about all the problems that they have.

And I was saying, well, why don't you just do what that mobile app team does? Cause that's really nice. And they were like, oh no, no, no, no, that's the mobile app team. They follow completely different rules. There's, there's no way we could actually do that. And it seems like, it seems like the small and the medium, you know, sort of apps, they're almost kind of like this island of, of pleasure over there where, you know, people can do things in a nice way, but for whatever reason, that change hasn't percolated down into the, the XXXL apps, so to speak. The, the island of pleasure, I like that. So like, you are right. And I missed a critical part. Sometimes they call us to, you know, we want to build a new digital experience. We want to build a new, like, we want to build an app in this new area of business. Help us, like, drive, help us figure out the product market fit. Help us do, like, the lean and the UCD processes. So they, they also, VMware Pivotal Labs has a very strong, like, product development arm as well. So that's another thing that they call us is, I don't know exactly what I need to build. I have, my users have this problem. I want you to run outside of hypotheses, do XP, lean, UCD, figure out what to build and help me build it. So this is all green field though. So this is like net new. Of course, it does interact with old, but, and then there's a set of existing apps that live, and people don't like to call that brown field. Usually, these terms are not so popular anymore, but like, it helps, this is green and then these are brown. So these are like the three flavors of things that customers, enterprises need help with. So we kind of categorize this as like the ask, right? So next step is like the plan and the prioritize phase of the work, right? So let's get to plan and prioritize. So in plan and prioritize, right? The first thing

you do is like you assess the, you assess the portfolio. You assess the portfolio for cloud native readiness. So you want to go to the cloud, right? like what, how messed up is your application, right? Is critical to knowing that case. And there is a set of tools that we bring to bear that tell us how, that tell us the degree of cloud nativeness to the application. So I'll give you an example. You know that cloud native can be defined by the 12 factors or 15 factors. When you have an application that is running on VNs, you need to know what do I need to do to take it to Kubernetes or to run it to put it in containers? Do I need to just, do I need to make sure that my application just restarts? Do I need to inject external configuration? Do I need to, so there are these various factors partners? And as an organization, you need to understand where, like, what is the degree of technical change you need to do to migrate this application to the cloud? Right? Yeah. I like the way you put that. I was almost, I mean, you have it more of a, in a gradient. I was almost going to summarize by saying that you, you assess the technical feasibility of moving the workloads or the apps to the new platform. But then, the way you're phrasing it made me realize it's more of, the more helpful way of saying, what is the technical suffering it would require? So, so that we can, you know, we can judge like, not so much that it's, it's, it's, yes or no, but that it's really like, how much effort would be, would you have to put in to move this over? Perfect. Effort, like feasibility and the thing is you, you have to realize that it's, it's like a, a subway train

with 15 stops on the way, right? So this is like my first stop and this is my 15 stop. Now you could just choose that to stay on the first stop. Like what I'm going to do, like one factor app, my application just needs to be able to restart correctly. If it does that, then I can live in Kubernetes. It will not be optimal, maybe it won't auto-scale, like as long as I can restart reliably, Kubernetes can manage my application. But then the 15th stop on the subway is, hey, my application is API first, it has externalized configuration, it is completely stateless, right? Like it has all the patterns encoded for cloud native. So you have to not think about it as a binary outcome, but rather as if I want to be on subway stop number four, this is the amount of effort I need to go get through. So don't think of it as binary, but as a journey of where you want to stop for each app, and the effort is dictated by that. So that goes into feasibility, right? Now, when we do, so there is another, this is the second lane, which is the digital, build a new app digital experience. In this, you have to kind of figure out what the product is, you have to determine what the product market fit is going to be, and then you have to do like, you have to run XP techniques, you have to do lean, and you have to do like, you have to do user-centered design to figure out like what to build, right? Yeah. So here, a different set of practices kind of come to bear, right? More, because there's a lot of uncertainty here, right? So you have to, you are in like the discovery phase, you do research, you do interviews, you do joint analysis, cohort analysis, to figure out what the hell are we building to satisfy our customers. So this is where like

our traditional labs like pivotally got started, used to help Twitter and Google and stuff like that. So this is, we have strength in this area and then we, and this led to the Greenfield, Greenfield development, right? So does this kind of swim lane make sense? And yeah, and so in that area, you're not so much modernizing things that's, you know, new apps and new, new things that, that you're developing, which I think to your point is sort of what most people think software development is all the time, right? That, that, that you're sort of like, you just, you just imagine, you whiteboard out some wireframes or, you know, draw something out and someone, someone writes this stuff and then you have the, the thrilling adventure of, you know, mapping it to, to either what people want to buy or how to run your business or, you know, in the, in the case of government stuff, like to satisfying whatever mission you have, like to, to citizens or whatnot, but it seems, it seems very creative instead of tedious. Yeah, but often the, but the dirty secret here is even for new product development, you almost always have to interface with back-end systems. Yeah. Right? Like there's no escaping that in any, unless you are a true startup or you're just creating a new bank, like you will always have back-end systems that you are interfacing with. So even in new product development at times, not at times, like 70-80% of the time, you have, you need a facade or some gateway to talk to the systems, old systems. And so there is always that interaction, intersection and interaction with older systems of record or older API and older legacy systems. Now, now, now this is another parenthetical footnote, so to speak, you know, over the years when it comes to external

services that are hard to change, people are always talking about the strangler pattern named after the, as I like to say, named after the tree, not the psychopath, even though you may wish for the second. And, you know, is that real? Do people actually use strangler patterns a lot successfully or is it just something that's fanciful? No, it's all, you use it all the time and that's like, this is perfect segue to my next third swim lane. I got this massive app, right, which I need to modernize. How do I do this, right? And this is where when the application is so massive and you can't really leverage your traditional techniques of lift and shift and like just containerize it. Like, I can't do that. I need to break this thing down. And so, so like, why is that? Like, why can't you do that? So, why you can't do that is earlier, like about a couple of years ago, like containerization technology just hadn't moved to the point where you can fit in a massive JVM, like, around 4 gigs, 8 gigs, 16 gigs of memory and run it reliably inside Kubernetes, right? Now, you can do that. Like, it's, so the, you could potentially run a 32 gig JVM or run three massive apps, but then you run into other issues where if you just lift and shift these massive applications, they have a complete lifecycle management that is, that fights what Kubernetes is trying to do to the application, right? So these massive applications have been written on WebSphere or WebLogic and they are completely married to how these proprietary app servers manage them. They have, they make very, they are very incestuous in terms of how they interact with one another, they make deep assumptions about the platforms that they run on, they have certain optimizations and networking protocols that

you can't find in the cloud, they reach across different modules because they are a single monolith, they have no, like there are no boundaries in between, they reach across different packages. And so you can try and maybe today now like in 2021, you could potentially move these three massive apps and run them on Kubernetes, but they would not operate correctly. And in fact, you may be able to do it, but you may be in a worse position than you started off it. you might actually encounter more pain. So do you really want to go there? Right? Like you have to make that assessment. Like am I like you might be making it truly worse rather than improving things. So this is a judgment call that you need to make. Yeah, yeah, yeah. You had a this week sometime you published a great article in InfoQ and I think there was a part of that, you know, you kind of explained even more of this where to do it in the optimistic way. way back when there was, you know, JEE and app servers and it was great. Everything worked really well. And as this is another speaking of the phrase dirty secret, I don't know if there's clean secrets, but one of the secrets of like, what would you call it? I think all programming probably is that, I don't know, it just rots after about three or five years. And the reason it rots is not the software and you were explaining this, but it's a it's a would you call it a social issue? It's like a person issue where people just like sort of to say they get bored is to be dismissive, but there are other things they start paying attention to and they start making this series of decisions where like they're going to get around to this older thing and they're going to get around to it until finally they never get around to it and people have forgotten how it works and it just like hasn't been updated and it becomes neglected. And so what was once like a really nice app server or whatever is now just it hasn't been updated to run in

modern ways for years and years. It's sort of like discovering it'd be like it'd be like if someone came, I don't know, time traveled from England in the 1530s and their language would be incompatible even though technically they speak English. It would just be a totally different They would speak medieval or old English. That's right. That's right. Like those movies where cavemans are defrosted. Cave people. Some people say that all modernization is basically converting a 20-year-old stack to a five-year-old age stack. It's what it is. Like Brandon the other day on I think Lord Podcast or someone else said the best thing to do is on January 1 just shut down all the apps and then see who complains and start the ones up that people complain and give them ownership for modernizing them. Yeah. That comes up in compliance a lot too. Just try not following some compliance thing and see if anything happens. Usually you find things don't. So these massive monolithic apps, why do they become big? we get into how to take them to the cloud. But just like these are literally heritage apps that generate a lot of money for the business. There is active feature development that is going on on these applications. And what has happened is certain decisions got made in the past that led to technical debt. All applications have technical debt. Just a matter of is it good debt or bad debt? Right? And so the debt basically simply keeps accumulating on top of the other because you have to do new feature development. And at some point, it's more like a call option. At some point, you have to pay for the option. Hopefully, if you have architected it correctly, it

never comes to the point where you have to modernize it. But in some cases, like for instance, with this COVID pandemic, your hand gets forced and you absolutely have to modernize because application cannot sustain the pace of business features that need to get added. So it's a delicate balance of when do you modernize a critical system, critical app that generates tons of revenue. But usually, if you pay attention to how you're accumulating technical debt, you can postpone modernization to a point where you're comfortable with it. If you don't do that, then at some point, the option is going to expire and you will have to modernize at a time which may not be so good for you. So you have to think about that. So talk about that more, about how you make the decision to postpone doing anything. When do you decide to, I don't know, metaphorically speaking, refinance your technical debt rather than pay it all off? That's a good question. So the way, if I were a VP of line of business, if this application is able to provide the features, like if I'm able to meet the needs of the business in a time, fashion and horizon that is suitable for them, we are able to add features to the application, business is happy, right? Our own customers that use the app are happy. At that point, like, okay, I have stabilized this application, I'm primarily in value capture mode, right? But in some cases, there is a new business driver, like a new digital experience or my retail load has tripled. There is some key critical business driver, like I'm paying billions of dollars to IBM, I would like to stop paying them for MIPS on the mainframe. Then at that point, I have a massive business driver to spend the money and time on modernizing

a monolithic application like this. And usually that is when it is successful, is when there is a key driver, COVID or digital experience or volumes going up or like something and then you use that vector to modernize the legacy application. Yeah, that's kind of a theory, our fellow co-worker. I guess that's redundant, but our co-worker Rick Clark and I discuss on a little ongoing podcast series we have where basically in order to change, you need a crisis. There's a minority of cases where you proactively have a crisis. But in general, unless there's something that comes up, it's like the situation you were talking about. When you do the business evaluation, it's fine. There's no reason. If your costs aren't out of control, if your customer satisfaction is good, if the revenue is coming in, it's sort of like, yeah, everything's all right. Whereas you need some kind of pressure, unless you're like the metaphorical equivalent of a health nut that's just proactively jogging every day and eating really healthy. Like, yeah, it's annoying, but I guess that kind of stasis is kind of nice to be. That is nice to be. Like, people say technical debt is bad. I mean, whenever you write a single line of code, you are adding technical debt. Unless you are deleting code, then you are actually reducing technical debt. But even when you write, like, think about it in debt terms. when you're writing a greenfield application, think about it as just transferring from a high percentage APR to a lower percentage APR. You're still going to have some technical debt when you write the new application or strangle the application, but it's at a much lower, higher quality debt that can get repaid

much faster. so the debt and the financial analogies apply really nice to this. I think Domain would like that. She did, I think, a talk based on derivatives. maybe one of these convolutions, we can model technical data as a call option and then talk through that. Sure. So I distracted you and the point you were making is you have found things, you had this other class of things that were like these problems that made it very difficult to modernize these apps. Correct. And so now we begin with, okay, I want to know, so now you know that you want to modernize the application. So customers then I want to know, right, the process to modernize the app, like the process, the tools and the techniques to, I'm going to just modernize the app. So this is key now at this point, right? But when they want to modernize, they want to do, they should do it in a fashion that is iterative right? And demonstrates actual ROI to the business. And I will get into the technical factors of how to do this. So this is plan and prioritize and this is, I would say, modernize. We have now gone into the modernize section, right? So you want to modernize in a very iterative way to demonstrate ROI to the business and on this side, I want to re-platform the application, right? I'm making minimal changes to the application so that I can land at the right cloud native, at the right cloud native pit stop, subway stop for my application. So there are two ways here. There's the re-platforming, which some people, I don't like to call it lift and change. So this is re-platform and this is the modernized path and this is the new development path. So like re-platform, develop, or modernize.

You have now come into these three stops. So let's come back. So now let's go to our next screen. So we have the re-platform quadrant, right? So I have a whole bunch of applications that I would like to take to the cloud. Remember, these are small, medium, and large apps. And then I have one massive monolithic app, right? Or a distributed monolithic app. So this is one giant app. So let's draw this as a giant app. And then I have new product development, right? And we can cover that separately, but there is a set of practices that are critical here as well. So when you have a number of apps, we have tools that allow us to determine cloud-native effort, right? Feasibility, as I said. And then there's a whole bunch of tools here called Snap, ARG. It basically tells you the series of remediations that you need to do to the application. And then you actually go to the containerization phase of the application. Over here, you can use build packs to containerize your application. You can use Docker files to migrate to make a container. So these are the two techniques. You also have plugins. Springboot has... So you have a Java application and then there's techniques for bootification. So I need to delve... This is a longer form topic, but your application might not be ready to get containerized. You have to do certain things to it to get it ready so that you can make container out of it. And those may... If it's a Springboot app, then you can just use the Java buildback or you could use the Springboot plugin. But what

if it's a legacy application that runs on Web Sphere? then in then in that case your options are either to use the Helm charts to this as well. Your options are either to remove the Java EE parts and take them to Spring or you could use one of the WebSphere or WebLogic Helm charts to package your application in Kubernetes but managed by the WebSphere or WebLogic operator. So there are a number of paths to go to containers and some of them are I would say there are different choices you make. If you want the least amount of effort then you are inclined to just use what traditional app server vendors have provided for packaging like Helm charts or operators but in that case you're still on WebSphere or WebLogic. You could choose to remove those parts by going to Equivalent Spring frameworks. I call that process as bootification and then you could use Spring Boot plugins or container. So even for the small medium large apps there are multiple parts of containerization to go to run on Kubernetes or Cloud Fountains. So those various app servers they've been Kubernetes I guess if you can use a Helm chart to deploy them then they can run on a cluster as well right? Exactly right. So we dig into this I have my Java app running on Tomcat so there's my Java apps running on WebSphere or WebLogic and then I have my ESBs and my VPNs and stuff like that right? So there are Helm charts that will allow you to deploy these applications and increasingly all the ISV vendors also provide application

like Docker images to package their software and then of course we have build packs to package these as containers so I'm going to use build packs here as the analogy ultimately all this ends up as you now have a Docker image that you can then write a manifest for and deploy on the so those are kind of your three parts now to your point earlier about like it's often hard to like lift and shift things like I mean you were kind of alluding to this earlier but you know in the app server world there's a whole lot of crazy stuff going on as far as networking and security and all that and how do they handle that if they're running on top of Kubernetes like is there I don't know is that a lot easier to move over onto that kind of environment than I'm thinking it is yeah so like you got it right like how is security managed I generally we our recommendation for the most part is to go down this route is you try to make it cloud native strategically don't have to change everything out but at least for the pieces that make sense replace them with equivalent spring framework constructs replace them with federated security and standard based security like OAuth and OIDC instead of leveraging the proprietary security mechanisms offered by the app server because those simply don't work in the cloud right you need to have equivalent replacements now in some cases the vendors have provided hooks to make those work or work around to make them work in Kubernetes but long term you're better satisfied by making your application a self contained unit and potentially decoupling it from the underlying infrastructure which is the

app server right so you want to make yourself a self contained starting with the services that the app uses versus starting with the app right like you're saying that you know you have to you know let's say you're depending on some security service inside the app server that just like is difficult to work in Kubernetes right and so maybe instead like maybe one way would be let's replace the security service and then just make the change in the app to use this new security service instead of the other way around or I don't know do you always start with the app or do you sometimes start with the underlying things or how do you figure that out most of the times you just start with the app first you make a decision right and then when you push it first in your development when you push the app that just stop just breaks security no longer works right right it's you turn off security because you know it's not going to work you get it functionally running right like an unauthenticated user can access that resource then you kind of you create a fuss up ideally if you have implemented the application correctly you have layered in security in a standard specific way so that you can just plug in the SSO provider of the cloud like you can plug in SSO authentication authorization provider like Okta or some of these other providers usually that is not the case so then you refactor the app to use OAuth or OIDC so that you can plug in Okta or you can plug in Ping as a security provider so there is work that needs to be done to provide security as a service and usually then the idea is all the applications then leverage that that library common

library in the cloud that's how generally the transition occurs so these are our three roads we use buildbacks we use modification where we basically replace Java EE or J2EE construction equivalent spring ones right and for these ESBs and BPMs either you are rewriting them or you're using the Docker images provided by the vendor to repackage them or something like Tipco either you have to refactor them again to more independent self-deployed units or you leverage what is provided by the vendor like Tipco buildbacks or Tipco operators to put them in the cloud so those are kind of your options either you take the effort to make it cloud native or you kind of go with what the vendor has and then get a reduced set of ROI with that okay so this is the re-platform flow the monolithic flow is kind of fun because there isn't really there's only one way through that jungle and I'll explain to you so strangler plays a role in it facades play a role in it so you have this massive application where different modules and business domains are all kind of like conjoint twins playing with one another everyone calls another one there is no encapsulation of code there is no modularity right it's basically a big ball of mud right so step one is understanding what are my domains right like what are like the question you need to start asking is what are my domains right one what is the like the top pain point like what what is the top constraint that I am solving for right and then like I said what are my key like business drivers

here and this is important because you have to do this iteratively you have to solve it in a step-by-step fashion for each thin slice like the way to think about it is this this is the application it is satisfying in number of use cases like that go through it each of this provides a business value right so you have to when you modernize make sure that I'll get into the actual techniques of doing it maybe next time but you have to do this iteratively for one two and three finish one complete then two complete and then three complete you can't just modernize a massive monolith across all the use cases for all the end to end flows in one go you will definitely fail if you do that it is critical to do this in prioritized thin slices across like domains where you strangle domains the key what so maybe we'll get into the how later but how can you fail with this let's talk about how do you fail with monolith modernization you can fail if you do everything in one go right so if you do everything in one go you're guaranteed to fail another way to fail is you look for silver bullets right when people show up and say okay this is your critical app let me just take all of it to kubernetes I have some I have some secret sauce that will generate code like mainstream modernization fails to this where there are vendors that will generate code for you but they don't tell you fully the delta that you need to move all of it in one go move it to kubernetes or something like that I

would be very wary of silver bullets yesterday I'm sure your son has asked questions like this my son said he heard that someone figured out how to bring people back to life and it cost something like $50,000 because that's a lot of money right and I was saying I try never to be like that's of course not you must be wrong so I was like oh I haven't heard that that's interesting and we were walking and kind of like with this point I'm imagining like I was thinking like well what if they died of cancer when they come back to life does it also cure the cancer because then they would die again and you know I probably repackage everything to run on Kubernetes and then you're going to find out that these like five other services that you're relying on don't work or these other things don't work so it's like you know you might have a silver bullet that can like you know chop a finger off but you're not going to really like take care of the whole thing that's kind of a drastic way of putting it but you might be able to solve one bit of the whole system but rarely the whole thing yeah and to what end you have to work your way back from the outcome that you want like why are you moving this why are you modernizing it why are you breaking it down like what what do you want to achieve do you want to achieve a faster path to production for features do you want a new enhanced digital experience are you migrating this to the cloud for for optimization and for consolidating infrastructure you have to make your way back from outcome that you want like have an outcome oriented roadmap especially when it comes to massive projects you have

to work your way back create an outcome oriented roadmap to then understand why are we doing this and we are breaking this down and modernize that's another driver to understand should I be doing lift and shift or should I be modernizing it figure out what you want first and then work your way back another couple of things is you can't half ass this the thing is what I have seen a lot in the while with customers is the projects get started and then because almost always what happens is it will get worse before it will get better I call that WBP because then you have the application is under development you have another alternate stream that is trying to strangle it at the same time it almost always gets worse before it starts getting better if you are not able to cross that chasm and then you just abandon it halfway then you have a series of half started app modernizations where you didn't really achieve anything and just spent a whole ton of money don't half ass it and it will get worse before it becomes better there is no outsource provider that can just magically do this for you at an x amount of money it's a very collaborative effort where you have to work with your partner very close to make happen you know those hit on two of the main things I generally talk with people about what I've seen over the years is like one you need to actually do the work right like you have to you know whether you're working with someone or you're going through this tediousness of doing it there's work to do like you see this all the time and like agile people don't actually follow all the agile practices and you're just like well I don't know what to tell you right like and then the other thing I think is a lot of those not

another general point is like it's going to take a while right like it took you a long time to write these applications we can't just like do it overnight or even in six months right it's going to take a while to go through your entire portfolio so I see you starting with success maybe that's a great cliff cliff holder cliffhanger because of course you want to know that but there was we got we're lucky to get one question maybe we can close out with the question and that is so you know you're mentioning like security and we're talking about all these services and stuff do people using service meshes whether it's ISTE or other things does that help alleviate some of those things a lot of the issues whether it's with security things or databases or services get down to networking and in distributed applications networking is just like on the internet right you have to know what you're looking for then you have to ask a registry where that thing is then you have to authenticate with that thing to make sure you have permission to talk to that thing and then you have to hope the thing understands what you're saying to it and then you also have to get the stuff that it sends back to you and then you have to understand what it's sending you never minding that principle about be strict in what you send and loosen what you hear or whatever but how does the service mesh help out with those kind of issues yeah so the service mesh basically provides a consistent back plane right for service discovery so that this monolithic application can discover all these other microservices kind of transparently right without like much churn like in the way that he expects to find things and these microservices can find other things the service mesh basically provides a way to encapsulate

right service discovery and do it in a way that is kind of that is done in the way the monolith expects it and how the individual microservices can discover it so it makes just service discovery easy it provides examples like Istio or console it provides a consistent way of finding services in both monolithic apps and in microservices and so if you employ this like throughout your organized then any new application that comes across automatically can discover these other applications as well as monolith service meshes can straddle both your on-prem environments and your cloud environments so they provide that uniform layer of encapsulation so access they can also provide security security can be paid into a service mesh they provide throttling of traffic so they provide observability of interaction across various services so there are all these second layer advantages that security meshes can provide that allow that give you deeper insight into your application workload right you could in fact just instrument everything with a service mesh and then use those insights to decompose your application as well it basically allows you to bake in a set of non functional kind of requirements and reduce the amount of heavy lift that needs to be done by the monolids or by the on-premise applications or by the cloud applications it provides a way for you to make it consistent now the thing is like this can become a service mesh can become kind of you have to be careful with service meshes because you can

get married to them they could become their own kind of web proprietary more you get married to a particular service so understand the trade-offs that you are making I like to use them for like stuff where you can take advantage of it but you cannot be just completely dependent on it so that's kind of right but beware of but buyer beware see understand what you are getting into when you use something like Istio or console right otherwise you just replace your ESB with an ESM just an enterprise service mesh and everybody has them there's Tanju service mesh there's Istio service meshes have service meshes like blue right like it's yeah and I think the point you raised I mean that's a that's a good way of risk managing accidentally getting you know to use my joke an ESM is to think how am I using this service mesh for functionality versus like platformy stuff or I don't know what the second one is so much but you know like eventually you want to get to that but as you're sort of sorting out how to use it kind of like having a critical operational what would you call it not priority dependency on it like it's probably good to like learn how it fits in and works out before you locked yourself into that very early on with your applications or not I don't know yeah make a think through the trade-offs and make an explicit decision early with respect to what trade-off you're making then you don't have to put some of that observability in your application that's okay you're delegating it to the mesh but you made a trade-off there right so be very cognizant about the trade-offs that you're making when you get when you marry yourself to a service mesh they are very helpful and they make your life

easy because peanut butter spread all these convenient non-functional services on your apps so we'll schedule you to be on and we can follow you know the I think one of Hemingway's best tips of writing is you always stop right in the middle of whatever you're doing that day so the next day you know exactly where to pick up now you've already written down the header for success so we've got we're stopped right in the middle and we'll get you back on I don't know who we is me and you know we'll continue down that and I know you know there's a lot you wrote down some of these things but there's a lot more as you go down those fallen over swim lanes the horizontal swim lanes there's more types of analysis and things that you go through and snaps and borises and things like that or is that a bore I I always forget but we've all sorts of fun stuff to go through and in the meantime I don't know I'll put in the show notes I'm going to put this as a podcast episode I might have to edit it since it's highly visual I'll have to listen to it and see how it works but I'll have to put a link to your info article which goes over a lot of stuff as well but what's your handle perfect all right well thanks for taking the time to go over this it was fun and we'll have to do it again thank you this is good all right everyone bye bye bye

bye

Tanzu Talk · 🍕 Get more pizza.