Gigantic Stranglers and Crazy Infrastructure, Working on Legacy Code with Rohit Kelapure (Ep. 33)

Episode 20 · 51:47 · SRT · archive.org · all Tanzu Talk

Well, hello again, everybody. It's another Pivotal Conversations. Today, we've got our usual format of going over a few interesting news items, and then we've got a guest. And before we get to the news stuff, why don't you introduce yourself, guest? Yeah, my name is Rohit Kelap here. I work on the Pivotal Cloud Foundry solutions team. We are also known as the Pivotal Cloud Foundry services team. My day job involves helping customers install Pivotal Cloud Foundry on their infrastructure as a service. A second aspect of my job involves migrating applications onto Pivotal Cloud Foundry. So there are two aspects to my job. Most of what we are going to talk about today involves migrating applications, decomposing them in microservices, some of the trade-offs and challenges involved in moving applications to Pivotal Cloud Foundry. Yeah, exactly. You have a webinar that you've done recently. We worked on an ESB paper a while ago, and over at your blog, there's always all sorts of things about breaking the monolith, which I was going over the, we'll get to it, the sort of questions I might ask you, and the liberal arts major in me was kicking in with the sort of a close reading of this idea of breaking a monolith. But anyhow, we'll have to go over that when we get to it, as it were. First, there's a few little news items to go over that I think are actually pretty pertinent to our stuff here. It's not, I have one thing that's highly unpertinent. Oddly enough, though, it is. But the first thing, I noticed this last week, you know, having worked in M&A and corporate strategy, I get all giddy when there's some gigantic merger or acquisition. I haven't quite figured out what to call this one. But it looks like it's confirmed that our friends over at HP Enterprise or HPE are, as they say, divesting of their software group. Now, you'll have to, you two will have to

tell me your view on this. I never actually found a list of the assets that were coming and going, as it were. Wait, that are remaining and going. But I think it's basically most everything is going over to Micro Focus, except, like, the OpenStack stuff, which would also be the Cloud Foundry stuff that we have, kind of like, that they have, like the sort of pure cloud software. So, I think in the systems group at HP is where they file away their cloud stuff and there's some software over there. I think that software is staying, but everything else over to Micro Focus. That's right. Everything must go. Yeah, it was a lot of stuff. Looked around. I think the headliners were, you know, some of their big acquisitions they've done in the past that they let go of. So, autonomy being the big one that they had bought for almost $11 billion however many years ago. So, you know, things like that, I think, disappear as part of this. But yeah, keeping the OpenStack stuff, keeping the Cloud Foundry stuff, you know, trying to figure out what their core competency is around hardware and that part of the stack and trying to lean up a little bit. We'll see if it works. It was also a good opportunity to relearn about Micro Focus, a company I haven't looked at in a long time. I think I was reading some coverage of this and when all the numbers have done, they'll have like tripled their revenue. So, it's interesting. It seems good for them. That'll be interesting to see what's there. It reminded me, I used to also work at BMC a while ago. And in the early 2000s, the team I was on at BMC was all freaked out about Mercury, something that is in that bundle of stuff. So, it's, you know, there's a good walk down memory lane of things. What a good name for a software portfolio, Mercury. So cool. From the perspective of an application software developer, the only software that I remember using from HP is their load test runner. Totally. I forget what it was called, but that was the only thing that I remember from HP.

And that was so painful to use back then. You had to schedule time on it and just that is my only thing that I remember about HP software. Yeah, and I'll have to go look this up, but I think, I think, or I'll actually probably never look it up, but, you know, just pretend like I will. I think, I think, I think Micro Focus also bought the test automation stuff from CompuWare some time ago. And so, they'll have like, I always get them mixed up. I think the Mercury one was like Silk Test, but it was like, I mean, they're still pretty big in automated testing. And so, they'll have a pretty big portfolio of testing tools, which is thrilling. Indeed. So, the other acquisition news, I think I saw you tweet about this first, Richard, maybe I didn't, but is that Google bought Apigee, which is, I would say, most notable in that Google doesn't buy a lot of big companies in the infrastructure-y space. Maybe in the consumer ad space, they buy big things. And like, if you want to control your AC and stuff like that, they'll give you a lot of money. But when it comes to like this kind of stuff, I think they usually prefer to buy small and do things on their own. Indeed. It was a small acquisition. Apigee is a friend of the family, as is Google. You know, we've been doing some great stuff together with them. So, this is a good, you know, piece of news for pivotal customers. And yeah, we love Apigee. They do great stuff with API management. And, you know, we've got some cool integration with them with route services. And this was a pretty big acquisition. I think it was, what was it, $650 million or so in cash. I think it was small bills, unmarked. So, it was a good transaction there. But, you know, what's going to be interesting is did they buy them because they couldn't build this themselves? Meh. Did they buy them because they have a really great customer list and this helps them increasingly with their enterprise credibility? That seems more likely. Yeah. I was thinking, you know, apropos to our nominal topic on this episode, maybe it's just like a gigantic like strangler pattern play on like

private cloud and stuff like that, right? Like if you make everything go over to use an API hosted by Apigee, you can slowly just get rid of all the non-cloud stuff behind it. Be very excited. I mean, gigantic strangler is probably going to be your nickname after this episode. That's right. But yeah, I think watching Google have a run at building up their enterprise thing and gobbling up a lot more than they currently have. That's fascinating. And, you know, and it's kind of related to the, there's a lot, as it were, going on in the large tech company space. Lots of reinventing and going private or divesting or not going on. Like, I think, I think last week we at Pivotal also officially became part of Dell or I should say Dell Technologies. And so there's, that would be, if you're interested as I am at like looking at the tech industry, I think in the next five years it'll be fun times as far as entertainment value. Hopefully you'll be on the right side of the fun times. We all hope. So then you wrote up a piece, Richard, that I think allowed me to remember a few other things that I don't know if we've mentioned. Well, we mentioned the survey, the container survey a while ago, but you had a crack at the sort of what's up with containers and the history of it recently. It was published last week? It was, yeah. Last Thursday. I mean, there's the fracas that's been going on in the Docker space and, you know, I learned from my last job as a cloud provider to not do two things. First of all, you never gloat when another cloud provider has an outage because, you know, that's going to be you at some point soon and it hurts the industry as a whole. And the same goes for open source. The second thing is, you know, open source is hard. It's hard to monetize open source. So, you know, as this challenge of Docker figuring out what things do they make available kind of in open source and what consortiums are they part of versus where do they innovate uniquely? That's a hard problem. I know you don't, but it does create

some uncertainty for customers. So, the one thing I wrote about was simply, let's remind people of the Cloud Foundry history and that we think infrastructure is supposed to be reliable and stable, maybe boring. And that's what you want out of infrastructure because you're building crazy apps on top. Your infrastructure should never be categorized as crazy. It should be just, hey, it just does its job successfully. And we've been doing containers for years before there was ever popularity in the mainstream around containers. We've been evolving it. You know, we containerize Windows and Linux unlike anyone else at this point, at least in production. So, it was just kind of a quick recap of we think infrastructure is supposed to be boring. Cloud Foundry customers don't have to worry about this sort of mayhem going on with containers right now because we believe platform abstractions matter and we're able to do things at the container level without ever screwing up with customers. So, you know, I think there's something that we should all just be educated on that. It doesn't mean you stop using one technology or another, but you should be very well aware as to what's happening because it could impact whatever is running in your data center. Yeah, and there's the related thing I was thinking of is there's a, so Abby, who is the, she's a pivotal person but currently a fellow over at the Cloud Foundry Foundation. She had a brief little write-up. I think it was on the O'Reilly radar. It's always difficult for me to pull apart the octopus of O'Reilly properties or maybe it's a squid. Who knows? But anyways, she had a write-up of sort of like the top three interesting things from the Cloud Foundry Foundation's container survey, which as you can imagine includes Cloud Foundry talk, not just not it like most other surveys. But I think one of the more interesting charts in there was just what are the difficulties you have with dealing with containers? And I think to your point of crazy infrastructure, just managing them was I think the number one thing. And the other ones are kind of variations on that. Well, it seems like people who have to deal with this stuff, their number one concern is not management. That means they're not using it yet.

I mean, right? Otherwise, you're screwing around with it, right? I mean, when I'm learning Spring, my concern is not managing apps in production, it's I can't bootstrap this thing, right? Because I'm a monkey. So people who answer that way haven't used the technology yet. If you don't have pain with Docker right now, you're not using it because everybody should, right? Even Cloud Foundry or other things. Once things get big, they get tricky. And those are the people who I really love hearing from because they're solving really hard problems with any technology that gets more complicated as it scales. Exactly. So finally, before we get to, I don't know, the realm of what was once sane, placid infrastructure and then through a process of aging becomes crazy infrastructure, otherwise known as dealing with legacy. I noticed one quick thing that I wanted to note here. Now, I don't know if this was based on a survey or some P equals 0.9 or some sort of thorough analysis or just the opinion of the person that wrote this piece. But I noticed a piece that says pink hair is now mainstream. People, you know, you can use it for highlights. They're seeing all age brackets going having pink hair. So, you know, there's a little bit of a subcult in our space of infrastructure management and stuff of people having pink hair. And I just, you know, I think now it's official. You know, there was a time analogously where if you were going bald, you just would have, as a man, you'd have to look like a monk. That was just the way it was. But then all of a sudden, I think maybe it was around, you know, the 13 monkeys. What was that thing with the guy who was in the tower with the kidnapping? What's his name? Bruce. Bruce, not Wayne. The other one. Willis. Yeah, Bruce Willis. There you go. Bald monkeys? You're one monkey too big. Yeah, it was 12. So anyways, remember in that movie he was bald? And I think maybe that kicked off that if you were losing hair as a man, you could just shave your head and no one would be like, oh, it's a bald person. They'd be like, that guy looks cool. So similarly, I think this is maybe the watershed moment for pink hair. Doesn't matter where you are,

you can have pink hair. I think it's colored hair because, you know, it's go back to school season. So my Facebook feed is full of people taking first day of school pictures. And there's a lot of kids with colored hair, which may mean how it's gone past coolness because now there's an eight-year-old with a purple strand in the front. I see. Now that's a Vanguard situation right there. That's like way out front. Just multiple hair. In the back ranks of Comptitude, we're kicking it with the pink hair and the bald heads. There you go. So, yeah, if you feel a little out of place that a DevOps stays, just go pink. You'll be fine. You'll totally fit in. So, on that note, someone who, as I recall, doesn't really have pink hair, although maybe things have changed since last time we've met. You know, like, I was recently watching one of your webinars. Did I say webinar? Webinars. And it was like 90 minutes. And I was thinking this is like the longest webinar I've ever come across. But, as I was watching it, you basically have let's say a condensed version of a book on tape about, like, dealing with legacy software and, you know, breaking monoliths apart. So, it was good stuff. You just, you know, I have this habit of just, like, laundry listing my way through things. And I do that because I like it. And that's, I think you were doing that pretty effectively. There's all sorts of patterns you were going through. But, before we get to the, what's out drawing on the laundry line, like, how did you get into the situation where you're talking about breaking up monoliths and dealing with legacy? and stuff all the time. How'd that come about? You know, I mean, I joined the PCF solutions group as a consultant. And we basically, our job was to install Cloud Foundry. But what we found that after installing Cloud, Pivotal Cloud Foundry, their customers had a hard time getting their applications running on the platform. so it was the equivalent of building a superhighway and not having any cars running on it. Given that a number of people on the team had background

in application servers and in Spring, we then sort of created, our team created an engagement model around migrating applications. And so when you move applications to Cloud Foundry, sometimes you can't move the entire application or it's not the right end state. so then having done this a number of times, we created patterns and recipes around how to move these existing applications to Cloud Foundry or to the cloud. And then what is the right way to break them apart? So there are multiple scenarios, there are multiple trade-offs around making a decision. So that's how I came into this becoming more of getting a deep dive into this process of breaking monoliths. And then I got interested in the theory behind breaking monoliths. You start reading the work of Vernon Vaughn and Eric Evans and then his latest book which I meant to everyone which is DDD Distilled which is a short 200 pages. That's the best book to read in the entire series that will get you caught up on all the 20,000 pages of domain-driven design theory behind monoliths. Well, you know, I like anything that's distilled so that sounds good. Now, you know, I have this like cheesy definition of legacy and we'll use monolith and legacy somewhat synonymously that I use which is, you know, legacy is like any code that you have to change that you're basically afraid to change. And so I wonder like how do you define legacy? to me legacy has it doesn't have a single definition some I look at legacy as something that makes money right I don't call it legacy oftentimes we call it classic applications so I mean

that makes money that's legacy 80% of your app portfolio right there stuff that is written in 15-year-old frameworks that talks to mainframes and does weird stuff that you know you cannot touch because it is it does all of commercial insurance things like that those are typically your legacy applications but it seems like there's some aspect of it of like it's not easy right like I mean that's hard to change like you said that's a big yeah so an aspect so typically a legacy application is an application that has grown and morphed over time it had a certain intent when it was designed before and either explicitly or due to various factors it has grown to a point where it has become difficult to maintain difficult to update people find it people hesitate to touch it because they don't understand the complete the ramifications of changing one component of the system these are typically big balls of mud and those could also be categorized as legacy applications these are large code bases that have grown and serve a substantial need for all our customers I define those as legacy applications so there are various layers and tiers to it typically we differentiate applications into two types green field and brown field brown field applications fall into this big category of applications that already exist and green field applications are ones that you typically start new green field apps are typically apps that you go to start.spring.io and spin up your typical reference spring application with the right set of dependencies whereas with the legacy app this is an app

that already exists in subversion cbs or git that you are modifying or updating most of the applications that enterprises work on are brown field or legacy or classic applications whatever you call it right yeah and to your point about it being the I don't know in a profit world the revenue generator or enabler of a company that's one of the things I often notice about the large organizations we talk with is one of their defining characteristics is having a lot of legacy applications right like there's not a lot of brand new startups that start life with legacy applications you know maybe not any that's true but yes and no but as you define these things sometimes are hard to build even when I worked at a cloud computing startup there were apps we would have considered legacy that were the first things that got built and they weren't really built for agility right they were built here's a SharePoint site for stuff oh good lord we hated that thing after the first two but it kind of became the legacy because it was hard to update nobody knew what was going on but I think again your point these are the things that make most companies money so anybody coming in arrogantly saying get rid of your legacy and make it all whatever whatever I think we're trying to make sure we show people that the agility is the value and those apps still matter but maybe it's time to modernize them and I think that's the message that in the earlier there was somewhat of a messaging problem around there is actually I still believe somewhat of a messaging problem around Cloud Foundry where Cloud Foundry was initially modeled as just a place for cloud native apps for 12 factor apps that's not the case you can run apps that are of various degrees of 12 factor in Cloud Foundry with certain trade-offs as long as you understand those trade-offs so it's a place where you can run all kinds of processes not just cloud native applications but you can run also legacy applications

in Cloud Foundry just you have to understand some of the constraints that the cloud imposes on you so that is what I and our group does in our daytime jobs which is we move applications to the cloud and they don't just become cloud native overnight there's a scale where you have to first it becomes compliant with four factors and then six factors and then it becomes cloud native so not all applications end up as your ideal application sometimes you just do barely enough to get it running because those benefits are good enough so there's a scale here in terms of cloud nativity as well yeah I mean tell us about that scale so I mean I think it's also can be a misunderstanding as you mentioned where the right places to run are but even how far you have to go that for some people doing two factors and making something cloud friendly is good enough for that particular app and then they can move on what do you think of that spectrum what is that spectrum from end to end yeah I think the spectrum varies from like you said just fixing the configuration so that it runs in cloud foundry or eliminating your application server dependencies so that you are not heavily tied to the app server fixing those so that the app can run in spring boot and tomcat putting it in cloud foundry our goal initially when we move applications is to do the bare minimum changes necessary to move it to the cloud once it reaches or it starts running locally in tomcat then it becomes easier to fix all the other factors so you almost when you are breaking these bigger applications your goal is to do the least amount of work possible to get them to the cloud and then you iterate on the application and get more and more factors compliant so for a bigger application your typical challenges revolve around configuration because the configuration is typically strewn all over the place another challenge that we see that I see

often is that they are heavily tied to the application server so you have to remove the application server dependency use the features of Spring Boot where Spring Boot magically wires up data sources databases messaging queues and so on security becomes an issue because sometimes security is tied to local OS mechanisms so you have to use a more federated model and so on so the factors vary a lot but the key is to start small and then iterate first get your app to the cloud and then start fixing some of the other factors so I categorize apps in sort of three categories in low medium high it helps to think of those like that for your high apps that are huge applications that are distributed monoliths in those kinds of applications where you simply cannot move the entire application it is too painful for those kinds of applications then you have to undergo a series of exercises to figure out where the teams lie for those applications what is a good way to split this application into smaller units that you can start remediating before you move to the cloud for low and medium size applications typically initially it is just a matter of making changes to certain packaging and then put it on cloud foundry and see what breaks but for your big monoliths right for your super size monoliths you have to undergo do a series of exercises be it event storming or context mapping or just whiteboarding to figure out what kind of design decisions have gone into the distributed monoliths before you put to the cloud so there's different approaches depending on the size of the application so it seems like you know when I was reading through some stuff and watching through your webinar that and in my mind I was starting to theorize that there's maybe I don't know what percentage of it

is if it's like a 30% or a 60% or what kind of situation but there's sort of like common things you do when you're you're migrating a legacy app or breaking apart a monolith and for example you named a few there like well if you're probably in the area of security you're going to have to do something if it relies on local OS things or if you've got some hardware key management thing or whatever and then you know another common one would be the way you configure this at runtime probably has to change and so I mean I'm curious A like if you think there's a significant amount of common things you have to change and then B like what are some of those things like what are the what's the template of stuff that you go into a project with and think like well more than likely we're going have to change these things around yeah this is very simple Michael we've done it so many times typically what we first do is when we get an application that we have to move to Cloud Foundry we try to get it running locally in Tomcat right that's our first step we try to what we do is that we look at the dependencies of the application we try to not we convert it to Spring Boot so we introduced a Spring Boot starter project in the main dependency tree of the project so essentially the high level steps are bootify the application get it running locally and once it starts running locally push the application to Cloud Foundry and then fix things that break those are the top four steps when before the fact when you get it running locally at that time you remove the dependency on the application servers you let Spring boot or Spring framework set things up in terms of

data sources typically the things that we end up configuring are databases and messaging and once Spring the beauty of Spring in the recent times is that the development experience code is identical whether the app runs locally or in the cloud with configuration options like profiles and intelligence around how the Spring boot code libraries work once you have the app running locally you have an 80 to 90 degree confidence that the app runs unchanged in cloud foundry so that that's our typical flow the first thing that we do is build it you will not believe in certain cases there is not even a build script we start with writing an ant with a maven build for the project we introduce the spring boot starters as a parent pom and then we get the process rolling yeah I mean having talked with other people who are thrown into a legacy situation it seems like as you were joking there about building sometimes you're not even like migrating you're just sort of like introducing sanity into the situation like instead of copying source code around to someone's laptop and stuff like that you're just like no no we should have a process to do this yeah yeah I mean writing tests is also a big part of it because oftentimes the cause of the people and process aspect of these organizations is not where we want it to be the testing in a lot of cases is completely manual a core part of re-platforming is adding tests to figure out to just adding custom health indicators that Spring Boot can use to figure out if the app is healthy adding some smoke tests to validate external

function things like that we also do that it's not just matter of adding and modifying source code whenever we modify source code we also add smoke tests to make sure that the app does what it is supposed to so adding tests is also a key part of re-platforming and refactoring applications so there's another sort of like microscopic thing that I was trying to generalize I think when you were discussing data migration which is a whole topic on its own one of the things that you noted was interesting is that you could use these tools to suck out and transform your data model and migrate it that way but then you were noting that you like to start with a pristine I think you said green data model but a brand new data model and as an aside I think if I remember right you kind of indicated like you know because maybe you don't need that stuff or you didn't say it that way exactly and so you know it reminded me and I see this as a reoccurring pattern especially when it comes to like audit and compliance and changing your process but then you talk with large organizations you have a lot of mainframe stuff and they basically bring up this point that one of the challenges is that maybe you don't need all of that code or all that compliance stuff I mean it's like we had heavy trash pickup here earlier today and I was thinking like how many times have I moved this box of stuff around from various houses I've lived in right like I should have just gotten rid of it and similarly I mean it seems like there's a good opportunity to get rid of stuff that's not needed anymore yeah I mean there so even we talk of legacy breaking a monolith and legacy transformation there is there is a universe of applications that are java applications or .NET applications right then there is an entire parallel universe of stuff that is locked in the mainframe right that is dying to get out a lot of the mainframe applications are just like batch processes this batch

this COBOL job runs writes a file another COBOL job runs picks up that file does some transformation a lot of it is just integration you can stop using the mainframe for doing file based integration you can do it in java code instead right things like that where the mainframe application or the mainframe code is not doing what a mainframe typically does best so there is an entire suite of transformation around just mainframe COBOL code that is trapped in the mainframe my spring one talk went deep into how to move your workloads from the mainframe to distributed systems so that's another category of transformation and we've just scratched the surface there because a lot of it is still locked there most of the techniques around mainframe transformation revolve around API enabling these mainframe systems and then writing microservices that talk to the APIs but the maximum benefit you can only you can gain maximum benefit by just moving and replacing the code and logic from the mainframe and doing it in distributed system and typically you do that only with the strangler pattern where you essentially write the same feature function in your desired greenfield application and sunset the feature from your older application using front-end routing magic and cloud foundry enables this using blue-green routing and you can use also micro proxies netflix OSS components to enable that front-end routing magic worth 600 some odd million dollars that's right so I mean when you you explained the paths that was a great description of the paths I'm assuming you know

the tomcat to boot to pcf path works the same if I'm dealing with a .net app that I'm refactoring or even a ruby app again you get it locally push it look for improvements but you know when you encounter someone who says I have this giant app portfolio it's a lot of it's old stuff I just want to pick it up and move it into this new thing and get all the new hotness that comes with it why are you making me change things I mean do you encounter the lowest common denominator just give me all the coolness without any work do you see that I mean is that something that we should be trying to satisfy more or do we really want to encourage the agility that has to happen with some light refactoring yeah now most serious customers developers enterprise architects don't want to move it just for the sake of hotness right so we don't like I haven't run into those kinds of primarily I'm on the we are on the post sales side so maybe all of that already gets filtered by the time the engagements reach us so maybe I'm not the right person to answer that there are the use cases for docker and I mean I have seen cases where the apps are so big not big but they have gotten tied so closely to what the application server provides and if they are sufficiently non-strategic and they are meant to sunset then yes it does make sense to get a docker image for web sphere application server and just put it out there and run it in AWS or even better run it as a docker image in PCF on AWS so there are use cases where you don't want to deal with it you want to package it up and you want to gain the advantages of a platform like PCF where we will automatically patch the underlying subsystems you get some routing enhancements you get

the resiliency of a PCF on top of AWS so there are some use cases but most customers who want to do these migrations really want business agility they want the ability to make changes to the application to respond to their other business users down the line faster so invariably if you want to do that then you have to do some kind of refactoring so that you can make changes in smaller units to your application and that is where you want to break either break down your application or put it on a platform that enables rapid changes like Tomcat and Spintool so can you like come up with like I think we should kind of like wrap up with a kind of an example of a couple of the areas of patterns that you use to migrate or break things apart and so like do you have in your mind or maybe you can make one up but like an interesting example of like an application that you might have and then you know I mean it strikes me that there's multiple things you have to visit when it comes to updating your legacy stuff like we talked about you know needing to change the configuration around so you don't have a dependency on an app server and needing to figure out we didn't really talk about data and state yet but needing to figure that out and then also this idea of breaking something down into smaller services right and so I mean there's you know in your fuller talks and things on this there's you know you generally have if I remember there's like five to eight sort of things areas you talk about but if you pick a couple of those that you think are the most important like what's an example of like you know you get called in and sit down and like you've selected an application and now the fun begins like beyond getting it running locally and things like that like how do you start mucking around with the code and the services and breaking things down so in

terms of breaking things down the easiest way to do it is based on functional decomposition right often times what we see is that the UI of the app is completely enmeshed with the service tier of the application whereas they could have been completely separate the UI portion of the application could have through a published language talked through the services part of the application so your first iteration is to split up the UI part of the application from the services part of the application and you go into the services part of the application and discover and then you discover that there are five different categories of web services within the services application so then you break those five different categories of services into five different applications five different microservices each providing a certain set of rest APIs in that particular domain so then that's how you then decompose the services app into five smaller applications so that is how I would go about in a functional decomposition that's the easiest form of decomposition and to kind of hopefully not interrupt your train of thought here but it strikes me that one thing we haven't really addressed is why are you breaking these things into smaller parts like what was wrong with it being a giant thing in the first place and then what advantages do you get once you've broken it down yeah absolutely I think the key advantage is that you can wrap your head around it right every time you start working on the application you don't have to page the entire state of the universe into your head right it's the guarantee that if I change this line of code my blast radius is only this particular confidence that you can make changes faster that you have

some cushion that you won't blow up the entire application this is especially true because on these legacy applications the people who have written the application have long gone you are probably the fifth or the sixth guy down the poll who's reading comments that are probably completely outdated but those comments are still valuable to you because you are getting insight into what someone else along the line saw in the code I was actually in this situation and as working with IBM I became the tech lead of a component that was 10 years old and so essentially you just have the code to rely on taking it into smaller pieces gives you confidence that you can make these changes with certain degree of confidence and you can make those changes faster turn around respond to your customers faster as well okay that makes sense I mean I guess if I were to categorize those it's that we would like to make changes to this software as quickly as possible that's sort of like the problem statement that's the desire statement and then the problem is like man using your explosion metaphor if we touch this thing it's all going to blow up just because it's hard for us to understand it and it's also as an effect of it being hard to understand it's extremely high risk to make any change because you have no understanding of what problems that's going to cause yeah I'll give you a concrete example when you are in an application where you are petrified of making a change what you end up doing is that you end up introducing millions of these switch conditions in your code where if this is the original logic if under this runtime variable move to this alternate line of reasoning and logic so you keep all of the old code and then you bolt

all of the new code with millions of switches in between so that if it goes wrong you can then go back to your older way of working and this then just keeps piling on top of one another think of like stratification you have one layer over the other just living on top and this is how you end up in a ball of mud imagine someone new looking at this code and their mind is blown apart because there are five different flows of the code every time a request comes in so this is the problem you and the complexity becomes squared every time you do this exercise this is where you have the metaphors of unraveling a bowl of spaghetti it's just like a very low rewarding difficult tedious affair yeah and just to finish up those you asked me for some concrete things around what we see in terms of patterns configuration is a big one right where configuration is captured in files either in the proprietary descriptors of the application servers or in properties files or sometimes hard coded so we have to remedy the configuration so that it comes from the environment or it comes from a same place in the file system the second thing that we often see is a reliance is a reliance on persistent file system where the application has been coded to rely on the file system to persist across JVM restarts oftentimes a lot of these applications these batch office back end office applications rely on writing a file to an NFS file store and some other application picking up the file from the file store so we have to remedy those kinds of batch integration

applications to use file system as a service we have to remedy often two phase a lot of the code that is written in enterprise applications since two phase commit was so readily available and distributed transaction managers were baked into the app server a lot of applications use transactional when they don't need it or they don't fully understand the ramifications of it so we have to make changes to convert those two phase transactions to either one phase transactions or rely on eventual consistency there is an entire blog post or an entire webinar just on how to fix two phase transactions in the cloud there is an excellent article from Dave Sire that's still the golden standard on that we should put a note in link in your show notes for that we do distributed transactions those are the things in terms of security we typically rely on we move from a SAML token aware security to something maybe more federated like OAuth or federated security models those are things that we fix logging that's typically some of the that is the first thing that we fix we change the logging so that instead of logging to the file starts logging to standard out and then you go to your higher end gravy features like the Netflix OSS like Circuit Breakers your dynamic service discovery with Eureka Spring Sleuth and so on so those are your level two features first the bread and butter is to just get the app running in the cloud you gotta lay down your foundational stuff then pour gravy on it always I mean you made a great point there about the agility piece and just it's funny when I think of microservices I'll jump to the Netflix mindset and think about scaling each application component uniquely and all these fun things I'm sure most people haven't even gotten there because they just have a mess that they can't

update with any frequency that those other sort more advanced value props of microservices come in after you've actually started to decompose this thing and get a handle on it yeah I mean Richard in most of these engagements I have I mean you just circuit breaker the basic of all these Netflix OSS patterns the stuff that is as good as gold we don't even get to implementing circuit breaker in a lot of these apps and forget Eureka and all that that's much later but those are the kinds of challenges we face in just fixing the basic stuff before we get to the high end right so I just wanted to ask you a question you wrote a Coté mentioned it in the beginning that you if we start decomposing monoliths I think it's pretty easy to say in many cases the ESB has become a monolith for many companies so if you want to summarize the point you were making in that paper around the evolution to a model that's simpler than having this big heavy centralized bus that everything passes through but where do you think from where customers are today where ESB served a really key value prop but now they're maybe a little hindered by it given the change in skill sets and the pace of the type of integrations you need what's the right future state for people who have a lot invested in their existing integration middle work yeah that's that's a tricky question so first I would take a deep look into what exactly the ESB is doing ESB are good for certain things but once you start encoding business logic into your ESB at that point it truly becomes a central point it becomes the it becomes a bottleneck for everything the advice is radically simple you have to slim down the ESB you

can do that through various ways like using lighter weight integration frameworks like spring integration or camel and once you lighten the ESB then you have to carve out vertical microservices from there align your ESB along microservices in a certain domain and eventually the long-term goal is to move all of the logic out of the ESB and move from an orchestration to a choreography view of the world so there are five phases phase number one if you don't do anything you can run the ESB in the cloud this is your main frame strategy where you're basically just living with the problem except that it now has it's like lipstick on the pig you have an ESB but it runs in cloud foundry step number two is simplification where you start reducing your ESB on the gym and you start gleaning things out using spring integration or spring cloud data flow and then step number three is try to completely eliminate the ESB by creating vertical microservices and bring more of choreography and reactive microservices using messaging as you're using messaging as your back plane rather than the ESB interesting good good stuff yeah I mean the ESB it's going to be interesting to see where you know as we keep decomposing I mean where do you think if we all you know we interview you again in a year or two or three or four because Coté and I will never quit but when we interview you in the future with this our new problem is going to emerge when we all wake up and some of these big companies have switched to a microservices architecture again not just doing a pure pivotal plug but we think we're trying to make operations of

that environment easier but as you're advising these customers and all of a sudden they went from one big hairy somewhat known monolith to 150 kind of well known but just more services they're interfacing with whether those problems are going to pop up when we interview you in a couple years and people have actually adopted microservices at scale the harder problems richard especially when it comes to the ESBs are more on the people and the process set because oftentimes what happens is that there are two camps in a company and that one camp has completely wedded itself to the ESB and the graphical tools that the ESB provides another thing that some of the ESB vendors have got right or not gotten right or their marketing has gotten right is that they portrait as when you use this ESB graphic tools you can ensure governance and that your developers don't have to actually write code so then it is viewed upon as an excellent tool to just give offshore developers go use this tool and I think that's wrong impression of both the developers and the tool itself but what I'm trying to convey is that the people and the process challenges when people completely get wedded to the ESB and are not willing to give it up those are the tougher challenges of migrating ESBs to the cloud well I think that's a good place to wrap up thanks for being on here I think we did a good job of miniature and lengthy laundry lists which I always appreciate and you also rattled off all sorts of references and hopefully I've written them all down and we'll put them in the show notes that people can go look them up but yeah it's true as ever on any given topic in the pivotal world the overall community there's always a lot of content on it if you can just pull it together so I'll be sure to

put those in there so thanks for being on and if people want to look into more of what you're up to or read some of your blog posts or follow you on Twitter anything where should they go for that they should just Google my name they'll see my blog and my Twitter post oh very nice it's a Matt Mullenweg thing he used to have the wordpress guy maybe he still does but he had these business cars that just said Google Matt and that was my surname and name are so kind of unique as long as you can remember my surname you should be good well there you go it's a challenge for the readers thanks for having me guys I really appreciate it keep doing this I think you guys are doing fantastic job well that's nice of you to say that's fantastic if you happen to want to go into iTunes and look up pivotal conversations and leave us a rating or a review that would be wonderful or you could just harass us on Twitter or email us at podcast at pivotal dot IO over there in Twitter land I'm Coté Coté what are you Richard you can find me at rserotter and you can find all for this if you go to pivotal dot IO slash podcast I believe and you can find the pivotal conversations podcast there somewhere also if you just want to go directly to the sound because you're not interested in text you can go to soundcloud dot com slash pivotal conversations and be sure to subscribe to that and your podcast thingamajiggy and we'll see everyone next time bye Bye.

Tanzu Talk · 🍕 Get more pizza.