PurePerformance - 078 Application Modernization – the 7-R Approach with Mandus Momberg

Episode Date: January 21, 2019

If you haven’t heard about the 6-R Migration Patterns, then you probably haven’t heard about the 7-R. The 7th stands for R(e-Fit).In this podcast we chat with Mandus Momberg (@MandusMomberg), Principal Solution Architect at AWS. Mandus is sharing what he has learned from small to large scale application migration & modernization projects. We learn about Modernization Factories, that it is key to have decision maker buy-in and that the most common migration scenario is R(e-Fit).Our biggest takeaway are the 3 key measures of success after a migration: Availability, Elasticity & Agility! Now listen in …https://www.linkedin.com/in/mandusm/https://aws.amazon.com/migration-acceleration-program/

It's time for Pure Performance. Get your stopwatches ready. It's time for Pure Performance with Andy Grabner and Brian Wilson. Hello, everybody, and welcome to another episode of Pure Performance. My name is Brian Wilson and I'd like to welcome back Andy Grabner. Andy, you got stuck in an airport last time and missed the excitement, but fortunately it wasn't, as I mentioned to Patrick Kimball, our guest on the last episode. You weren't picked up by Der Commissar again. So glad to have you back. Happy New Year. I was actually stuck on the plane, not on the last episode, you, you weren't picked up by Der Commissar again. So glad to have you back. Happy New Year.

I was actually stuck on the plane, not on the airport, because the plane had some very strange, two planes broke in a row. One was already midair, then we had to fly back. And then we got stuck on the tarmac. And so I spent three hours on that Friday when we were supposed to record on a plane somewhere between Cleveland and Boston. Mostly on the tarmac. Some of this time in the air, but then flying back.

But yeah, happy new year to you too. Sounds like a fun time. Yeah. So let's get into it, right? We have a special guest today. It's always a special guest, as we say. Why don't you go ahead and introduce our guest and we'll uh we'll get moving on the new year oh actually before that before that though um i just wanted

to mention and i think it's about a week before perform um i don't know about you but i've been going nuts trying to get everything ready i'm looking forward to to the day that all all gets going and hopefully it'll be a great conference for everybody so yeah but it's going to be good right one week for perform hopefully we'll see a lot of the listeners next week in vegas and if you listen to this at a later point and check out uh the recordings or all the um the podcasting we've done at perform because there will also be podcasting at perform yep and if you're going to be at perform stop by and we'll do a little interview with you. Exactly. But now coming back to the topic of today and coming back to my plane story earlier, they would have needed some modernization of their planes.

But today we talk about application modernization and application migration. And for that, we invited Mendes. Mendes Monberg, are you with us today? Hey, yeah, I'm here. How are Are you with us today? Hey, yeah. I'm here. How are you guys doing? Great. Good, good. Mendes, maybe for those people that don't know you, maybe you want to quickly introduce yourself,

who you are, what your role is, who you're working for, and then maybe also give a little, maybe you want to talk about why you think we invited you to talk about application modernization. Yeah, sure. I will. I just want to make sure that I never get on a plane with you, Andy, by the way, because I already have a fear of flying and flying with you sounds terrifying if two planes break in a row. So I'm just putting it out there.

My name is Mandes Mommert. I'm a principal solutions architect with AWS. And my core focus is to work on migrations and the modernization story that we have come up with at AWS, working with our customers, working with our partners, and how we can get them to digitally transform their businesses at an accelerated rate and really get from where they are today, which is probably a place of using monolithic applications and doing waterfall deployments and those type of things into a place where they're a little bit more agile, much more elastic, and really capable of iterating on their application designs in an accelerated manner.

So, yeah, I've been focusing on that and the technology choices customers make and working with some of our larger customers in those journeys that they've taken over the last two years. Cool. So now, Mendoz, let me, I think it's actually, I'm stealing a line now from Brian before we get started with the whole show recording. Brian said, so that means I can just stack my monolith into a container and then I'm just there where I need to be in the cloud. Is it that easy? Unfortunately, no, it's not that easy, right? So we hear a lot of customers coming to us and saying, oh, well, there's this new technology called containerization. If I just containerize my existing application, which is a thing to do, then I'm a modern

business, right? My application is running in Kubernetes or it's running in ECS and it's all just smooth sailing from there. The truth is, unfortunately, that's not how it works. You can containerize your application, but unless you also modernize all of the ancillary services around it and the stack around it, your business isn't truly modernized. Just putting an application in a container makes it easy for you to distribute that application, but it doesn't really give you an additional agility to iterate in that application, to really make it faster to break down that application and start turning into microservices. There's still a lot of things you have to do around that and a lot of technology and choices

you have to make around that to truly become more modern and compete with all the industry disruptors that you might have in your industry so the the maybe taking a step back and again brian i'm sorry to stole that line from you you wanted to bring it up i'll get over it i thought i thought it worked pretty well um the to take a step back typically when we, when people approach us or when we hear people of modernizing their application stack, they hear about this thing that is called the six R's, right? The six R's strategy. And Mendes, I'm not sure if you can kind of recount them in your memory. What are the six r's

that you guys yeah so the six r's is actually something that really goes along with migration a lot right especially with when programs like our migration acceleration program we talk to our customers about the six r's a lot um and it basically starts with the two easiest ones that you really need to think of or that's that customers uh can write off very easily is retain and retire, right? So maybe you have an application that for some reason has to be where it is today. You can't really move it away and you can't leave it or you can't throw it away.

It has to be where it is. You just retain it as is, right? You keep it on premises or in the form that it is today. And then retire is if you look at something and maybe it's technical debt that you just don't need anymore, right? You've replaced an old database system with a new database system, et cetera, et cetera. And you can just retire that information, right?

So those are some of the two first R's. Then you have rehosting. Rehosting is also very commonly known as lift and shift, where essentially you take an application or you take a server on-premises, you image it and you move it into a virtualized environment, whether that be like a VMware environment or an EC2 environment, but you're just copying on a block level, really, the environment from one place to another place. You're not really changing much. You're just making a virtualized image and you're moving into virtualized infrastructure. So, replatforming is very similar to a rehosting where you take this existing application, you lift it, but you reshape it a little bit, right?

So, for example, you'll take your on-premises MySQL database, but instead of making a block-level copy of that and trying to virtualize only that database, you adopt a service like RDS, for example, which is a managed database service, and you just transport your information. You transfer your data from the on-premises environment into that, and that's a replatforming architecture. Then we have repurchasing where you might, for example, have a CRM system or something like that, and you decide to completely repurchase a new CRM from another vendor that has features and maybe more elasticity or scalability that the previous one didn't have. So you repurchase that platform. And then one that is really truthfully the one that honestly gives you

the most ability to modernize, but also cost you the most and also takes the longest time is refactoring. And refactoring is the act of actually going out and rebuilding your application, rewriting the application, decoupling it from its existing application sources and application targets, and rebuilding that application to the form that you want it into to be a modernized application. So those are the traditional six R's, and they all come with some benefits and some drawbacks out of each other. So we've been working with our customers a lot over the last few years, specifically on the rehosting platform and what we call the migration acceleration program.

And what that really is, is we go in with partners like Dynatrace and we do a lot of information diving to see what it is that our customers are actually running on premises and then taking that infrastructure and virtualizing it for them on AWS. And that's been very good. We've been able to really accelerate that transformation and that migration. But the feedback that we've been getting from our customers is that they also want to modernize while they migrate because traditionally the guidance was get your infrastructure into AWS, get the cost savings, and then start modernizing, start breaking down the monolith, et cetera, et cetera. But our customers are saying,

we want to actually modernize as we move in this migration. We want to adopt automation processes as we move. We want to start refactoring some of our applications as we move. And working with some of our customers, we've been able to identify that the proper technology to do this modernization as you move is really to adopt the containerized technology and the ecosystem and the community

around that technology. So we're starting to play around with adding another R to the six R's and making it seven R's and calling this R something like refit, where it's a combination of something like rehosting and refactoring where you modernize your application stack through containerizing your application initially, moving that into an orchestration system, and then also putting in a lot of automation and security principles into it to re-modify your application stack and make your application stack more modern. And the three traits that we really test against to see whether your application stack is modern is really to look if you have achieved a couple of things. And that is, did you achieve availability? Is your application

always available to your customers? Did you achieve elasticity? In other words, are you ever overpaying for your infrastructure when your customers aren't using it? And can you scale up when your customers are generating a higher demand? And then most importantly is agility. Do you have the capability to make changes to your application and your environment in a short period of time to really be reactive and even proactive to your customers' feedback or to new features that you want to release? How quickly can you iterate on your application and your customer experience, right? That agility is truthfully one of the most important things for us in this modernization.

Wow. You know, Andy, before you dive in on that, I just have to say, I wish I had heard that before the previous episode. We were talking with Patrick Kimball from Samba Safety and they had moved to AWS and everything about the 6Rs you were describing is what we were discussing that they were doing without the context of the 6Rs though.

So if I had known that, I could have put that in much better context. That's awesome though. So let me just chime in. So it was fantastic to get this great, you know, fast overview of all the six hours, now seven hours. I like, and hopefully I got this correctly. And then, Mandos, if you said the four things that everyone, the four dimensions of was it a successful migration?

And hopefully I recount this correctly. Availability, obviously, right? You move it over and you want to make sure that your system is available. Scalability, make sure that at the right time you have the right resources available to handle the load. Then also costs, you don't overpay, which from my perspective also kind of goes into scalability

because scalability goes up and down. And the fourth one, agility. You know, can you actually now move faster to cope with market demand or any, you know, changes that your customers or end users are demanding? So, did I get this right? Availability, scalability, cost of ownership, and agility. Yeah, you almost got it right. You added four.

We only have three that we talk about. So we actually do combine scalability and cost into one, and we call it elasticity, where you scale up and down based on customer demand. So we have elasticity, availability, and agility is the three dimensions that we really test against whether your application and your environment has become truthfully modern perfect and um now i know we we you quickly glanced over uh the the existing six hours now you said the re-hosting sounds like

the easiest you just basically run your stuff on somebody else's hardware, right? Even though I would assume it still sounds easier as it is because if you're moving things from one environment to another, I assume people run into configuration issues when it comes to network, when it comes to firewalls. Is there anything else that lift and shift that can go wrong that people have to be aware of? Yeah, rehosting lift and shift that can go wrong or that people have to be aware of? Yeah, rehosting and lift and shift migrations always sound the easiest. And truthfully, they are the easiest.

But no migration is easy. No migration is easy. That's the first thing that everybody needs to understand. And there are many things that can go wrong. So, for example, dependencies on things like block storage, local storage, databases, firewalls and networking. There's so many things that could go wrong if you're just basically making an image of an on-premises environment and virtualizing that, for example, somewhere, whether it's in the cloud or in a virtualized technology on-premises as well. So it's really important to do a very intense discovery of the things that your applications are doing on-premises or where your environment is running today. It's really important to understand the connections between

those applications, the dependencies that those applications have, the security layers that you might have in between of those applications and those dependencies, and have a full view of what it is that you're moving. Because once you start that move, you need to also plan out which portions and sections of these applications needs to move when. Because you might have one application that's dependent or three or four applications that's dependent on one database.

So you might want to move the first database across and then do some syncing between it to keep it up to date, et cetera, et cetera. It's very important to know what it is that you're running and having a deep view of what your applications and your infrastructure is actually doing before you

move it as a lifted shift. I just want to jump in there too and add based on again on the last episode's conversation, one thing you want to make sure you know also is what is the relationship of the shifted environment to the old environment? Because when people are running stuff in their own data center, they have an intrinsic knowledge of what server is running, what, where it's running, what the name is, all this, you know, all this information because it was just, you know, it was, it was in their house. Uh, and then when they shifted over, it's got all these new names, all these new things.

There's all these other dependencies that they had to shift and they didn't even know, maybe here's some application. We're not quite sure what it is, but we'll throw it up in there. And then when, when something goes wrong and they have to jump into action, they're not used to where everything is anymore. So making sure you actually know very clearly what, where everything moved to, what the new names are, all that kind of stuff, uh, is really important because a lot of people slow down then on problems because they just can't you know it's a new pair of shoes or it's a it's driving uh going from maybe driving a model t ford to a tesla let's say everything is very different about the thing even though it's just a car still everything's very different and you moved

everything over but now everything's inherently different just because it moved yeah yeah and that actually, that's another reason why our customers are coming to us and saying, listen, we want to modernize our environments, right? Because they want to put in controls and planes that makes that end state a little bit easier to control and easier to monitor and allow them to focus on what actually is important to their business, which is their application, right? All the services that they provide. So we really work with customers during this modernization journey to implement things like automation around application monitoring against security, implementing

cultural shifts inside their business to allow them to be more agile in the way that they do things, maybe adopting scrum and those type of processes to really make them a little bit closer to that place where they are actually agile in their application development and focusing on their application. Because as you said, it's difficult to really translate the existing environment to the new environment and the management that now comes into that. If you're just doing a lift and shift and you're now using the native control planes, it gets a little bit tough if you need to learn new skill sets and stuff around that. But if you can automate a lot of that and maybe offload a lot of it to manage services that can take smart actions like scaling for you or let you know if there's maybe a CVE cut against some libraries that your

application is using so you can roll out new changes to that in security. Those type of things are really important. And that is a big part of the modernization journey. The modernization journey is not just about adopting containers. It's not just about putting your application into a container and running that somewhere. It is really about the cultural shift that has to happen in all of your teams from the developers all the way through to the business decision makers and how people trust each other how the difference seems to work together in order to really achieve that agility that makes them very scalable and very elastic it's it's a it's a very core portion

of what makes our customers that have done this successful I got a question. Now, if you're talking about these massive changes from, obviously, from the infrastructure perspective, but more so on the cultural organizational changes, that means a cloud migration project all of a sudden will include most likely large parts of the organization that never thought they are going to be involved in the cloud migration project. Because now you're talking about complete change in maybe even organizational structure, changing processes, changing responsibilities. I mean, for me, this now seems, oh, actually the question that I have to you, do you always, when people approach you and they say, we want to modernize our applications, do you right away go back to them and say, well, if you do this, we do it right?

Which means this is going to be a longer project than you thought because we need all these other teams involved as well. Or how do you do this? How do you get everybody on the same page? How do you get everybody involved that needs to be involved? Because for me, it sounds like this is going to be massive. These are going to be potentially massive projects. Yeah, it does sound daunting in the start, right? But the truth is, it's actually a little bit easier

because more people get involved and more people actually have the ability to take action. So we do approach most of the customers we work with that come to us about this. We do approach them with a very prescriptive model that we kind of say, these are the tools we believe you should be using and these are the phases you should go through in order to achieve that. But a very important portion of this is to have a distinguished idea of what the end state is that the customer wants to achieve, right? The customer must be clear about what the things are that they want to achieve in the business. And with the container technology and also the ecosystem around it through automation and, you know, whether you want to call it DevOps or SRE, et cetera, et cetera,

it's actually fantastic how the migration no longer becomes a migration but a modernization exercise in that they can deploy to multiple environments in hybrid capacities. And therefore, it really opens up the ability for all of the teams in the business to really become involved because they don't feel like they used to feel where they would have in the lock-in or technology lock-in, et cetera, et cetera, because these choices that they're making is analogous enough for them to transfer that information into multiple environments and run them in hybrid scopes.

So, yes, we usually ask for someone to be some kind of an executive sponsor that essentially owns the process and drives the process and puts down milestones for things to be achieved. And also just helps to unblock maybe some cultural blockers or internal blockers in the way the business is set up to structure and work at that point in time. We need someone that can break through some of those barriers that might over decades have been put in place just because of the IT infrastructure and how the teams work in those businesses, depending on the size of the business, obviously. But then we really break it down to these smaller teams where each smaller team owns a specific application that they want to containerize or modernize, and they build out the infrastructure scopes. And we kind of have the story about like a multi-lane highway deployment, where you provide them with the infrastructure like a highway, just like the government provides

us with highways to drive on. And we just put some road rules in there, right? So we limit them to certain speeds that they're allowed to go, et cetera, et cetera. The same way we do that with, okay, you have to report a certain security report to us in order to gain access to this highway, right, to this deployment pipeline. These are the things that we want to see first, and these are the tests that we're running. So, pain testing teams now work more closely to the individual developers. And we're also shifting, and this is actually very exciting, is we're shifting a lot of the responsibility for the customer experience to the developers, right? So that's the whole shift to the left methodology. Because we did that internally with Amazon a couple of years ago, is we started shifting a lot of the responsibility for the customer experience,

the way that the customer actually works with the product, to the developers. And something really interesting happened, is we actually saw the developers' code quality go up. And after some investigation, we found that the reason why the code quality went up when they got more responsibility for the experience and not just the code itself was because now that they have this responsibility and they have this feedback model from the customers, they don't necessarily want to get paged at 3 a.m. in the morning that something is wrong or a customer is having a bad experience. And it's also a pride

thing, right? They want the customer to have a good experience. So shifting this model to the left and giving more responsibility to the developers, not only on the code, but on the ultimate experience in production that the customer will have really ties back to that agility where a customer might report a fault, the developers get that information, they make a change and they push it back. And the best way and the easiest way that we found to do this is, for example, through a platform like Kubernetes or ECS, where you have this unified task definition, which is a specification in either JSON or YAML, where the developers can define things like container images,

the resources that they need around it, the dependencies that will need to consume, et cetera, et cetera, and deploy that as a part of their actual source code. So we are also changing this to infrastructure as code inside of the application as well. So the more you shift to the left, your teams actually become smaller and you don't sit with these large infrastructure teams anymore that need to coordinate things like networking, et cetera. They kind of become integrated into the smaller teams

and they work closely with these teams to really help them translate their applications to where they are today into a more modern approach. But yeah, so ultimately, we do ask for at least some executive sponsorship that can help break down these initial cultural barriers that might have been created over the last couple of years or since the company's inception. Pretty cool. pretty cool hey and um when you do these projects uh do you then i would assume you pick maybe an application or a service or some let's say smaller or let's say more contained application service that uh that you use as a like proof of concept to actually show them show the customer hey let's pick an

application that is important for you, but maybe not the most critical one and not the biggest one, and then get it modernized so you can actually learn how this whole thing works, and then we adapt the next app and the next app, or are you doing a big bang? We do all the takes. It's honestly a combination of the both, of the two, right? In the sense that if it's a new customer that really has no experience or no knowledge of the technology stack that has no DevOps culture really, then we usually do something like a POC where we take a smaller application that has little impact and we containerize that and we deploy that with all the systems and security and stuff. So those teams that ultimately need to be involved can build trust in the technology and understand at least the overall concepts of that technology, right? And we do see that to a fair

amount as well. But we've lately seen that most customers that come to us specifically ask for this technology, they've already done their due diligence around the technology. They know what they want from it. They know what they want to achieve with it. They just don't know what they need to choose in order to do it. Because one of the biggest problems that our customers face in adopting things like containerized technologies and automation technologies is that there's just the sheer amount of projects that they can use, right? The sheer amount of tools that they can use. Do they use ECS? Do they use Fargate?

Do they use Kubernetes? Do they use Jenkins? Do they, you know, all of these different projects and tools that they can use, they're just overwhelmed with choice. So they come to us and they say, listen, we're bought into this idea. We know that it works. We've seen it work. There's been so much content created about the fact that this is the right way to do it or the best place to go to do it. But which tools should we use, right? What tools should we use? And that's where we kind of step in with a little bit of a prescriptive view of what we have seen with other customers that are successful in the tool choices they make. And we kind of talk about, for example, compliance and our compliance customers and then the tools they used and maybe other regulated industries or automotive industries and the

tools that they use to be successful around their migrations and their modernization practices. And that kind of sometimes turns into a big bang, right? Where it's that whole thing of build it and they will come. Where once the infrastructure team's really putting the base operations and the capabilities for them to deploy infrastructure and containers and maybe even deploy serverless functions through some of these automation pipelines that they put in place, then these teams just get excited and they just adopt this very quickly because they already know the technologies.

The exciting thing or a surprising thing that we found about a year ago or so when we really started talking about containers in the enterprise was the amount of enterprise developers that were already using containers on their local development environments, as opposed to the amount of enterprises that actually adopted containerized deployments in production, right? So even though they weren't deploying into containers, developers were already using containers to test against and develop against locally on their own machines, and then handing off the source code after that to the actual deployment teams and, you know, going back to their old waterfall methods. So the technology is usually pretty well known in a lot of these customers that come to us. It's just honestly the choices in which tools to use, how to put those tools together securely, compliantly, and have success in that. That's kind of the approach that we've taken lately. I have another question,

kind of going back a little bit in the process now, kind of looping in something we've done together um not the two of us but you did it with a colleague um part of the whole you know replatforming and modernization is is the topic that i also brought up in the very beginning is breaking up the monolith and um i i know we did a session together at reInvent with we, I mean, Dynatrace and AWS. You did a session with Carmen and with Peter Heck on breaking up the monolith while migrating to AWS. Is this, I mean, this actually perfectly fits

into what you see and what you said earlier, your seventh R, right? It's a refitting. So you're moving things over, but while you're moving it over you're breaking the monolith you may replace some of the components um with something that is already available as a service so kind of replatforming uh you may even repurchase individual components that might be now delivered by some somebody that provides you know the software provides the software in an easier way. And then you are, because you're breaking the big monolith into smaller pieces,

with that become more agile. And therefore, in order to really fully leverage that new agility, you obviously need to change your delivery method. You need to invest in CICD, you need to shift left because otherwise it's a nice one-time effort, but you never really get the fruit of the labor, so to say, if you don't really also change the culture. And I think in your session, I know it's on YouTube,

it's the GPSTEC 320 session. And thanks for AWS for putting all these recordings up on YouTube. I think we can put a link in there. It's called Breaking Up the Monolith While Migrating to AWS. In that session, did you also cover all of these aspects? I believe you did, right? Yeah, we touched

on some of it. We were focusing more on the breaking down the monolith and the work that we've been doing with Dynatrace on how to identify the portions inside of an application once you've containerized it, how you can break it out of that monolith and containerize smaller microservices and turn each of these units into microservices, which is a very important part of the modernization process in order to scale independently and really become agile. And what you just mentioned,

well, essentially all the steps that you've walked through, we're now starting to call that the migration, sorry, the modernization factory because we want our customers to build modernization factories. And what we did in that presentation was kind of showing you one portion of that migration factory or the modernization factory where you have already

put in place the automation pipelines and now you've deployed your application into a container but now you want to slowly start breaking down that monolithic application into smaller services without interruption to your actual customers and the business that you're running and that's where dynatrace is really an important tool for us to do that because the introspection that we could get where we could actually see, for example, our Java application breaking down the functions that are essentially working together and calling each other and the dependencies on a functional level inside of the application code

to give us an idea of where we need to break down our application into smaller microservices and smaller teams essentially taking ownership of that. And those dependencies that they might have on external things like databases and Postgres and those type of things. So once that migration, that modernization factor is in place,

the automation, the security checking, et cetera, is in place and you get that information for breaking down the monolith through discovery and getting that information is really important because you need to plan as well the breakdown of the application. You can really go down into this modernization process where you are breaking down this monolith completely without your customers even noticing that it's gone

and made that transition from a monolithic application to a microservices application. Because of the environment that you're running it in now, you have things like service discovery through DNS and other mechanisms that you can put in place to route traffic between your monolithic application. Or you can even try and hit the microservice and the monolithic application in single requests and then make sure that there's a competency check to see if the data that's being returned is the correct data for a period of time before you switch off the monolithic routes, etc., etc. It's a really exciting technology for us to use to break down the monolith has now turned into microservices, you're really more modern in the sense of you're more agile, you can make iterations a lot easier, a lot faster to your

application, you will scale independently on the different loads, so it makes you elastic. And because you're elastic, because you can scale, your availability skyrockets and your applications will be a lot more available and integrating that with things like load balances and application monitoring and smart scaling and things like that, you truly sit with a digitally transformed modern application stack

without any downtime or any interruption to your customer services. Yeah, hopefully not only your availability skyrockets, well, hopefully just the availability, not your costs as well with the underlying infrastructure. But that's the whole point of breaking it into the microservices, right, Andy? Because you can scale just the pieces that you need to maintain that thing. So yeah, obviously anything can still go wrong,

but that's one of the big benefits is when you break it out that way, you only scale, and I'm not saying this for you, yeah, there's obviously anything can still go wrong, but that's one of the big benefits is when you break it out that way, you only scale. And I'm not saying this for you, Andy, because you know this, but for other people listening, you know, you're not scaling everything. You're scaling up one small little piece. Yeah. And that's where a lot of these automation tests and stuff come in as well, right? and do availability testing is the open source projects like Chaos Monkey, for example, where it actually goes in and just randomly destroys certain portions of your infrastructure to see whether your infrastructure can handle it, right? And then once you're in that position

where you have microservices and you have this easy deployment system in place where you can deploy to multiple environments without friction, then it's easy for you to deploy, for example, to multiple AWS regions. You might have like a pilot region or deploy into a pilot region in a secondary region so that if your primary region goes down, then you can fail over without interruption or even to on-premises deployments. We have some customers that are doing fantastically exciting things

where they are doing most of their analytic workloads, that they're heavy lifting, their orchestration, building, testing, all those things on AWS, but they're treating some of their local data centers as edge locations for customers, or they might be deploying into areas where there are no AWS regions. And they're using these modernized mechanisms that we put in place for them to transport their applications once dev and test and all those things have happened to these edge locations automatically. And some of these locations actually have really bad connectivity where they have to trickle down the downloads to get the container images into this new location because of low latency or low bandwidth availability.

And it takes them hours to get that image, for example. And then automatically that process will kick off in that local data center as an edge location. And they keep control and monitoring and pushing back information to the main systems that are hosted in AWS. And they keep monitoring it and seeing how it's performed. And they can action any changes pretty much as elastically or as agilely in those limited environments as they are in the cloud today. So they're doing really exciting things with this technology. But again, I stress it's not just about the containerized technology. It's all about the shifts around that technology as well. And once you've made those shifts,

a lot of customers are also adopting things like serverless technology in the forms of things like Lambda and using DynamoDB and those type of structures as well. Because when those modernized frameworks are in place, then the adoption of new technologies and the management of those new technologies become transparent in the operations of a day-to-day business.

Can you maybe to round it up, because I think obviously we could talk for forever on these individual seven R's now and dive into more of the best practices and things you've learned, but kind of to round it up, if one of our listeners now thinks, hey, you know, I feel our company is ready to make that move. We need to do something. We need to modernize. What is the best way to get started? What's the best way maybe to get in touch with you

or somebody they need to get in touch with? Who are the people they should bring with them and have the buy-in before they approach somebody like you and engage in the project? That's a good question. To start off with, we have quite a lot of information on our AWS blogs at the moment around modernization strategies. We've recorded a video series that will be made available pretty soon as well that talks about the basics of implementing this modernization factory. We have a workshop that is available online. I'll provide you guys with a link and you can put it down in the description where we

have a very basic workshop that a business or a customer can work through to give them an idea of what it would be like to implement these automation strategies and so forth. So all of that's available today. We're iterating on that. We're extending this workshop in the next two months. We'll be adding a lot of content to it. Then how to get in contact with us would be simply through your AWS account manager. Just work with your AWS account manager and ask them specifically that you want to speak to the containerized team and the containerized container team around

modernization strategies. And they'll be able to reach out to us and set up some meetings with us. It probably won't be me directly. It would probably be some of the other essays on the team that will engage with you and help you build this modernization factory. And then who needs to come with you is really the decision makers need to have a buy-in on this, right? At least if you don't know the technology

yet, if you're still just in your discovery phase and you want to ask us questions, then just bring yourself. We're happy to answer any questions and enable you with as much information as you need to take to the decision makers to help them understand what the benefit is for them to adopt this technology and this cultural change. You need someone that can have executive buy-in to really break down those barriers that we spoke about earlier. But if you don't feel enabled yet to speak, to bring those people, don't worry about it. Just come to us anyway. We'll enable you.

We'll help you get the information that you need and structure the value proposition that you can take to your decision makers. Cool. Thank you so much. I wanted to bring this out there because we often get people that come to us and say, well, how do we get started? I mean, what's my next step?

What's the information I need to provide? And I rather give them a list that you just iterated and say, this is the things you should do and then come to us or come to us anyway and we can help you. But I think it's always important to point out to help people with the next step. And so thanks for giving us that overview. Brian, is there anything from your side

that we missed? Andy, I think I'm going to happily, happily, happily, happily turn the rain back to you to summon the Summonerator because last episode I had to do it and let me tell you, it was a blast.

I had so much fun doing the Summonerator. So I'm going to summon the Summonerator for you to come back and do it now, Andy. Unless you have anything else you want to add before you go into that. No, no, I'm going to summon the Summaryator for you to come back and do it now, Andy, unless you have anything else you want to add before you go into that. No, I'm good. Please. Come on. Do it. All right.

Well, Mandos, thank you so much for that session. I think it's a topic that we hear constantly from the people we talk to that come to us when it comes to modernizing their stack. Obviously, they come to DynamoTr us when it comes to modernizing their stack. Obviously, they come to Dynatrace when it comes to the digital transformation and monitoring. But every time when people come to us now, they exactly say, well, we need to move to the cloud. We need to move to Kubernetes, to OpenShift, to Cloud Foundry.

And hearing from you on the approach to take to actually modernize not only individual apps, but basically what you said is you're modernizing the whole organization because it's not just about lifting and shifting, re-hosting, re-platforming. It's refitting, but not only refitting your software stack, but it's really refitting your organization to be fit for the digital future. That's what this is all about. That's why I also like your refit, your seventh R now,

where you said the best approach is really to take things, move it to the cloud, but then reshape and refactor it in one, but then also refactor your organization. Because with modernization, you can only reap the benefits of your technical modernization if you also make a cultural shift and that obviously goes hand in hand

with organizational changes. It's great to know that whoever wants to go down that lane needs to make sure to bring a decision maker buy-in because that obviously in the end you will need it because large organizational changes only come from decision maker buy-ins. And I think the last one that I want to reiterate is kind of the three dimensions of how you can actually measure the success of such a project. If you are modernizing your applications or services,

or if you're modernizing your digital organization now, you should be measure yourself by your availability, right? It's just, are your systems up and running and available at all the time in the 24 seven, you know, we're going to say community or culture we live in right now, availability is key. Are we elastic? So can we scale up and down with the right costs? And how agile are

we? How agile are we to react to new market domains? I really like these three dimensions availability, elasticity, and agility. And these are the three things you should take to measure the success of any application modernization, service modernization, or I now call it organizational modernization because that's in the end what this is all about. Thank you, Andy. Yeah, thank you very much for having me. I had a blast speaking with you guys.

And yeah, happy new year to everybody. I guess it's already a couple of weeks off the new year, but happy new year. Yes, happy new year. Thanks a lot for coming on. If anybody has any questions or comments, you can tweet us at pure underscore performance. No, pure underscore DT. See, it's been that long, Andy. Or you can send us an email at pureperformance at dynatrace.com.

We hope to see you perform. Mandus, anything you want to promote that's going to be going on maybe February or March that you're doing? Not specifically week. We have quite a few AWS summits and events coming up. So just go to our AWS events page and you'll see all of the AWS events that you can join. We have a host of webinars and in-person events happening. So please feel free to join us there at any of them. Great.

Thank you very much, Len. See everyone later. Thank you. Thank you. Bye-bye.