 Good evening and welcome. Everyone ready? Well, it's always nice to see that people came to your session because you never really know, you know, with all these multiple tracks So I'm really glad to see you all here I'm Kamala Desika and I work on the product team focusing on the cloud platform and ecosystem at Pivotal The product specifically being Pivotal Cloud Foundry Pivotal Cloud Foundry has been at the center of many enterprise digital transformation projects where we've worked and helped our customers with the technology piece the cloud platform and sometimes they want us to work with them a little bit more on Changing the culture and the practice and the way they deliver their Software within the organization And so in these kinds of engagements, we often work together with other partners really great partners like Dynatrace Where we together join forces to increase the impact that we have on the overall For overall for the customer and make that digital transformation project just a little bit easier on them So Michael you want to introduce yourself? Yeah, so I'm Mike villager. Obviously as Kamala mentioned I work for Dynatrace I have the unique role inside of Dynatrace and that I'm focused explicitly on working with Cloud Foundry And more specifically working very closely with with Pivotal on a regular basis both in terms of you know internal Inside of Dynatrace evangelizing the values of Cloud Foundry and some of the things that Pivotal talks about As well as then a customer focus as well helping my customers implement Dynatrace on on top of Cloud Foundry deployments All right, so this session is about to refactor or not and how to systematically Modernize your applications if you have decided that you actually want to do that Refactoring so before we get into the actual process of how we start to do that Let's talk a little bit about the goals right since we've worked a lot with our enterprises What is it that they're really going after now the context for a lot of changes has been that enterprises really want to get from a delivery model that kind of looks like this where they're delivering this monolithic application in a fairly linear and sequential manner Where all of the changes that they're making in feature productions into the application at one time And they're probably deploying it to something like a virtual machine and they're doing it sparingly at very specific windows because this might actually require You know restarting the application possibly downtime for the end user And so all of the surrounding activities are sort of planned around that one deployment event And there's an entire team and a host of people that are involved in all the day-to operations You know keeping the application secure patchable resilient and all that other really non trivial engineering tasks, right? And they want to get from this process to something that looks like this where they're deploying Composed applications where they have these individual microservices that are essentially decoupled from each other They have their own lifecycle and therefore their Cycles can essentially be shorter have more iterations bring the customer feedback into the Service and the product features into the microservice more frequently and From a developer perspective, no one really wants to deploy or think about Servers anymore. They really want to think about things just in terms of applications and their backing services and Pivotal cloud foundry or cloud foundry in general Does a really great job of doing exactly that where you have everything from the application down to the operating system? Treated as a single version controlled unit and what that lets you do is great, you know, it's a great way to do horizontal scale it's also a great way to Roll your features out without too much consequence because you can always roll back blue green deployments are extremely easy to do With with this kind of an environment and therefore you're ready for production at any given point of time because you've de-risked Your your your delivery, right and of course the operations team are in a position where they're no longer managing Servers and they're in a position where they're looking at the overall picture of managing services Now that's really great because you get a ton of advantages from an enterprise perspective and so a lot of them for new initiatives, this has kind of been a no-brainer, right and It's a good place for a lot of enterprises to start resetting their technical debt Problem is most modern enterprises actually have very heterogeneous workloads where they run the gamut of you know technology stacks inside of their walls and More and more of them really want to start seeing these kinds of benefits for Applications that are currently in their portfolio already, you know take advantage of things like more automation more resiliency More visibility and speed at which they're able to deliver features to their customers So now that we have the goals in mind we can start talking about the process a little bit more So when you have these large set of applications In the enterprise portfolio the first thing that you can start to do is to do some affinity mapping right and get a Group together your applications based on things like technology characteristics Business functions and things like that and then you can just do like these very simple prioritization as I think this is the group that I'm Going to attack first Now within a particular group for each application you can start to apply filters that have you know business Economic and technical attributes that you will start to score So for example is part of your business framework you can look at things like Does this application have a really deep backlog, right? So that means it's an application that potentially really benefits from having that fast feature release Does the application is the application actually even business critical to begin with does the application have? Customers how many customers does it have? Is it a revenue-generating application and sometimes you might make a decision based on things that you might not really think of for example there are some Applications that have staff that have a very specific skill set that may have left the company and So these orphan applications are perfect candidates is essentially for for refactoring. So sometimes staffing decisions will drive You know this this kind of changes Other things that you would look at our economic in nature for example licensing costs of the middleware and all of the other software That you need in order to run the application there are time-to-market implications The costs of the infrastructure itself that that you're running your application on There are things like operational costs. You know, are you spending a ton on? staff that is You know trying to meet specific SLAs or maybe you're missing SLAs and paying a ton of penalties because you've done that, right? So these are all the consideration you would put down the scores for This kind of Analysis and then the last bit is the on the technical side Your worksheet would have things that you're looking at the application the nature of the application itself Does the app accept inbound connections? Is the app actually very tightly coupled with the application server? Is it very highly dependent on a particular operating system that maybe is not supported in in Cloud Foundry? What are some of the services and service integrations that you need in order for the app to function? Properly does it have a need to do persistent storage? Are you storing HTTP sessions and some of these I think are Are things that are familiar to you as what does it really take to bring an application in? Conformity to 12 factor or 15 factor applications. Now. Those are all the things that you would score here you can further narrow it down by saying if you still have a large number of applications you're dealing with you further narrow it down by Picking applications that currently already have a little bit of automation Associated with them. Are they running on some group them by CI systems that you have in place there? Now the anti-goal of all this really is Analysis paralysis a lot of this information really should take you know It should be a snap judgment and kind of get to get to this information in a couple of hours Not necessarily, you know days and days where you're delivering this giant deck to management and trying to get funding for it, right? So at this point, I'm going to hand off to Michael to show us the techniques on How you can arrive at some of the data so you can get the the appropriate information for the app? Thanks Kamala, so Obviously Kamala walked through a couple of techniques here in terms of you know determining some sort of score to Start prioritizing applications for the replatforming effort Now what I'm looking to talk about here is you know some unique applications of APM technology and more specifically What Donna Trace is capable of doing very rapidly in an environment? to start Attempting to use some of the information from the APM tooling to build out that score for you And I like to kind of look at things through through a couple of different lenses and the first lens that I like to help people utilize is user experience and behavioral analytics so because Donna Trace is looking at the entire stack from the user all the way through the technical details If we start with the user experience We can slice and dice the data in a couple of different ways to to you know, maybe come up with our Refactoring candidates. So the first thing that we can look at is the frequency of actions So what that means is how often is a specific piece of functionality being accessed? Right, is it something that's being accessed very frequently, you know on the order of you know dozens If not hundreds of times per second And then you can take the inverse of that as well. You can take a look at things that Maybe are very infrequently accessed I've had customers that have have taken both of these approaches and really the idea here is you know, do you want to try and take that? Giant business critical piece of functionality and replat from that first for that huge win that is going to you know basically You know really justify a lot of the the efforts or do you want to take the the low-risk approach and and maybe take something that is You know very very infrequently accessed and and move that over first All right, so then the other thing that we can look at as well then would be you know Once again looking at that user experience But looking at transactions that take a long time right things that are very poorly performing these are generally going to be really complex transactions typically given the amount of time that they take and and something like this is You know sometimes a prime factor for a prime candidate for refactoring just due to the complexity of these types of transactions and Then there's another measure That combines the two right so it's a it's a multiplication of the response time as well as the Action rate and and that results in kind of an overall user experience consumption value Right, so you know really it's kind of looking at things through that user experience lens To try and figure out what might be a good candidate for refactoring The second lens is to look at things from a topology perspective Right, so understanding at a service interaction level What components you know even when we're dealing with monoliths? It's extremely unlikely that the monolith is completely existing in isolation, right? So sometimes you have multiple monoliths that are talking to each other So we want to understand where in the scope of a user-facing transaction the amount of time and the frequency in which the services interact with each other and then you know you also Want to utilize tooling that's gonna quickly map out the environment. This is actually like a pretty key Like generic cloud migration use case right in utilizing something like Donna trace We've often had customers Identify interactions that they were not even aware of You know because there's there's you know environments that have been in place for so long That they didn't even realize that you know service a is actually calling service B and service a is actually Interfacing directly with the database that maybe it wasn't even supposed to be talking to right So it's important to be able to quickly Deploy some tooling to help you slice and dice that data to to really uncover some of these candidates for refactoring and then you know, we want to kind of take a look at things from a resource consumption perspective Right, so we want to take a take a look at resource consumption at the hypervisor level At the virtual machine level, you know, are we are we looking at you know? Some really really bloated monoliths where you know There might be some cost savings involved in trying to maybe spread that out a little bit so that we don't have to You know try and run a bunch of you know 64 gig virtual machines or something like that and Then taking that into the process level, you know once again, is it something that has? You know particularly poorly performing garbage collection or something like that and then obviously taking a look at that that service level Which represents the you know the actual user experience of that service So it's kind of taking a look at things once again From the user experience level to really understand how frequently Services are being interacted with and then to take a look at things from You know the bottom-up infrastructure type of perspective as well And back to you come on. All right. Thanks Mike So this next bit actually now that you know coming back to the the model that you're scoring and you have a List of applications essentially that have bubbled to the top where You have relatively low amount of investment that you would need to do in order to get a higher degree of business gain, right? So this next bit is a little bit like cooking where you know someone else's recipe isn't necessarily going to work out the same way in your own kitchen But you'll make some tweaks and eventually you'll make the recipe your own so so far You have projects like we've done have really fallen into these two buckets here So going back to like the technical score that you guys that you've all arrived at You can see that applications that fall into the quadrant where you have a Low amount of effort that require you know, but high degree of return will fall into the replatforming area and that You know examples of those would be things like your spring boots Spring applications that currently running on Tomcat or if there are ear files that are easily Split into spring boot fat jars that you can deploy and just something simple like just go ahead and do it like push it onto the cloud foundry See what fails and write a test for everything that failed and work on your application until that test passes So what you're doing here is trying to address the lowest level of the maturity model So what exactly would I mean by maturity model? A lot of our customers have these staged processes with which they measure their success and you know at Pivotal we have Let's say our three stages would be something like you know runs on Pivotal cloud foundry Runs well on Pivotal cloud foundry runs great on Pivotal cloud foundry so at this first stage what you're trying to do is just address what are the minimum set of things that you need to Have the application run you don't necessarily have to address all of the 12 factors or the 15 factors That you need to get your application running And I think this is a good way to start showing early results and sometimes you may just want to move You know your application and leave it at that first stage Maybe it's not a candidate for taking it all the way to Running well or running great on cloud foundry and the second bucket we have the Modernization now these are those applications that are high value, but take a lot of effort in order to get on Pivotal cloud foundry So the go-to approach here has been using techniques like domain driven design Where you're identifying some of these natural seams within the application That you can slice off into their your own microservices at these you know, this is kind of where your science meets art and and communications at this point and Yeah, the mod you can just take some of the more Objective information that you retrieve from this whether it's through static code analysis where you're figuring out You know how the code code interacts How the transactions are bounded and you can take the information from your monitoring tools where you have the the baseline of the performance metrics of your application You can capture the flow of events that are happening with the within the application and take all of that Other techniques that you can apply together with this information is things like Conway's law. Everybody knows what Conway's lies All right with some hands all right So Conway's law essentially states that the structure of your application mirrors the structure of the communication within your organization So the team structure sometimes Helps you identify what the seams are inside of your application another way that Conway's law actually helps you is When you currently have broken off your vertical slices for For creating your microservice the bounded context that arise from this may not necessarily match the existing team structure within your organization And that doesn't really bode well for the success of the microservice once you actually have it deployed So trying to blend the data across those two Those two data points is actually a really good way to kick off your your team and kind of get that communication flowing within the organization We've got a ton of material that we've written on the subject actually my colleague Rohit Kilipur has done a lot of these kinds of projects and if you guys are interested in Learning more or reading more material on domain-driven design and these kinds of replatforming efforts Please go to our website pivotal.io and look at the replatforming section and you can get a lot more detail on that So ultimately what we're trying to do or accomplish here within these modernization efforts is Reduce the amount of cohesion and coupling that exists within the application What do I mean by that? That is how badly is a change in one part of the application? Going to impact another part of the application. So last year at CF summit I saw this example by Mike Gehard, which I thought was a really simple and great way To to to demonstrate exactly what we mean by this so on the left side you can see Let's take for example orders. There are actually three places if you change orders There are three places where you have to make that change But if you look on the right side, which is a more well-formed application Making a change to order is really just the one place, right? So what you're trying to do here is group things and things that change together should be together, right? And so Mike I'm going to hand off to you so he'll talk a little bit more about the implications Sure of what that looks like so obviously, you know one of the things that that we've done here is it's kind of like the almost step one of the replatforming effort to take you know an existing monolith and transform that monolith into a well-formed monolith and When we take a look at that well-formed monolith it'll allow us to Model the behaviors of how that Application might function once you've carved out a piece of that functionality to a microservice So as you might take that order piece that we that we talked about and actually carve that out of the monolith Into into a microservice so once we've got that well-structured monolith we can take our monitoring tooling and Understand how that's going to operate When that transition has taken place so you know, we're still in the contact You know, we're still bound by a single JVM. We still exist as a monolith But we're able to transform the visibility from from this relatively simplified view to a More complex view where we're seeing what things would look like if this was in fact a monolith and that visibility is going to allow You to you know ensure that You know the architecture is validated that tears aren't you know inadvertently crossing boundaries and so on So, you know, then you want to continue to utilize that service flow information that that's captured on a every Transaction basis to continue to perform that architectural validation As you're going through your replatforming efforts Right because we really want to make sure that we've identified those those bounding context the bounded context That that actually represent that the way that we're slicing and dicing our monolith and you know this kind of transitions into What in my mind is a key topic and that is as we're going through these efforts To carve up our existing monoliths. It's it's unlikely that we're doing this in isolation It's it's unlikely that we're gonna be presented with an opportunity to do the whole thing I'll you know to basically do it all and Not have the users interacting with it as we've gone through and made some of these changes So it's important that you have a monitoring Strategy in place to ensure that the changes that you're making have had the desired impact right we want to make sure that You know, we haven't resulted in a degradation and user experience And we want to ensure that you know our regressions that that might have been identified can quickly be rolled back You know, maybe by taking advantage of functionality like blue-green deployments and a lot of the other pieces that Make the Cloud Foundry platform wonderful for operating these services And then, you know once again as we talk about user experience, there's two lenses to user experience, right? There's the the you know the the hard values of things like response time But user experience also incorporates business metrics as well, right? So you want to ensure that you know if you've taken that Well-structured monolith and split the orders piece out of it that you haven't somehow resulted in a loss of conversions Right you want to make sure that that your technical changes haven't had a negative impact on the business and once again, obviously As we continue to do this. It's important to Understand and quickly identify regression so that we can roll them back quickly and back to you Kamal Well, thank you So what we're trying to say here is that it is possible and it is actually relatively easy to move new workloads onto cloud foundries And a lot of these if you if we do them well enough and if we show ROI well enough The funds that you save from that can actually find you know fund new initiatives within Cloud Foundry and tools within the platform itself make it much easier to run your newly re-platformed applications use technologies like spring boot and spring cloud services as you go through these Applications for 30% less code than JBoss so you can reset your technical debt there work You know you use it to transform your enterprise to delivering code quickly get your features out to your customers quickly If you wanted to play with this some more Mike awesome. All right, so final summary slide here So, you know, there's a couple of different things that you can take a look at here So we release our full stack add-on, which is what allows you to have this visibility Either, you know in your existing environment as well as your you know net new cloud native environments We provide a add-on that's distributed via pivnet for for pivotal customers as well as you know Elsewhere if you happen to be you know utilizing a different flavor of cloud foundry and if you're interested in taking a free trial of Donna trace we've got a Code there pivotal 17 that allows you to have significantly more credits in your trial than you than you might have had otherwise And if you're and if you're interested in learning more about this we actually have the spring one platform That's coming up in December. We hope to see some of you there And we will talk a lot more about the subject a lot more deep dives code examples and snippets that we will do over there That's all we have for you. We're here for questions. Yeah, any questions? Nothing Everybody awake Very last session that you had a question. Yeah, so the question was about you know kind of the the the cultural ramifications of You know running commercial software in an environment that is you know, maybe primarily free or open source software, right? So it that that's actually a really interesting question because that's all that's a it's a very philosophical one right, so I've always been under the of the impression that There is no free lunch. So you're you're you're there are a finite amount of There's there's a certain amount of costs that are going to be incurred You know in in utilizing software, right? So the question is do you pay a vendor or do you pay your team? right So so that's kind of like the fundamental business driver there is you know one way or another Somebody is is is going to be collecting some sort of funds for that, right? That doesn't necessarily address the the more philosophical area where you know, am I only going to use open source software? that that that's like a trickier topic that you know, I've personally followed since like the early days of Linux in the mid 90s and you know Reading all of rms's papers and so on and so forth. So that's kind of a little bit that that one's a little bit trickier but often in In our opinion what kind of like what we see at Donna trace is okay So certain elements of the stack might be open source But when you really want to ensure that? the users are having a great experience on Your platform right whether you be a bank an e-commerce shop, whatever you might be That tends to be a great platform to invest in in commercial software because Quite frankly there isn't a lot of open source APM solutions out there It's it's not something that's really well addressed in the free and open source market right now Does that answer the question at least reasonably well So I mean that is a that is a pretty frequent issue that I run into is that the what can be called not invented here syndrome? I've kind of actually seen it referred to that elsewhere and it quite frankly tackling a issue like this is generally, you know, not something that Can be taken lightly and you know, you see some of the the pivotal folks will will you know basically release Some quotes like was it the one that like it was a tweet or something like that like you know Thanks for thanks for building a new DNS system said no CEO ever, right? You know the one that I'm talking about That was there was something that was in one of the pivotal presentations at one point in time so so yes, there are Philosophical differences to the approach But APM is actually a market that's not very well served by open source solutions right now So it you are part of the the cloud foundry foundation aren't you mm-hmm. Yeah, so they do support I mean, so we've in a different way I guess we invest in the success of cloud foundry both in terms of helping our customers operate cloud foundry as well as investing in the foundation So any other questions while we're here Yeah, Conway's law Yes, they do and that's actually a big part of why you know Pivotal works with a lot of our customers at least the initial few to help them kind of come up with the right roles and Team structures to help them that and actually it's actually a great team optimization mechanism Where you're co-locating your team because microservices it's a very different paradigm than when you're developing monoliths And so yes to answer your question the team structure does change Any others all right well, I hope everybody has you know pleasant travels back to wherever they came from and And have a pleasant evening. Yes. Think of something else Give us you know tweet us at our handles. They're here on the on the slide. Thanks everyone