Completing a large-scale migration and modernization with AWS

Oh, good morning. Welcome to ENT 215, Completing a Large Scale Migration and Modernization. My name is Jonathan Allen. I'm a Director in the Enterprise Strategy team here at Amazon Web Services. Thank you for coming.

Um this is the sixth time I've done this breakout at Re:Invent. And uh this year myself and Oscar and I'll let Oscar introduce himself later, have really gone to town updating this presentation again with all of our lessons learned over the last sort of year from when we last presented this.

And um we've got a number of topics for you today on how we're gonna break this down. Sort of eight different sections really taking the lessons learned from the thousands of migrations we've done around the world. And this focus is on large scale migration and modernizations today.

And one le one of the primary things we've certainly learnt is that customers um want to modernize as they migrate while there are many, many cus use cases of customers migrating very quickly for many different reasons. This modernization is really core of a of a catalyst of a of a number of folks and it's totally understandable when you actually look at why that is, you know, modernizing leads to this innovation, you know, breakthrough.

And so many leadership teams i work with um the word agility by the way, is incredibly important. In fact, i know it's important because it comes up on average once every nine minutes, i've counted it. So it must be important so that agility goal is clearly there.

And, you know, the next question that i get is, well, you know, who's done this before and, and rest assured, you know, there are thousands and thousands of migrations that amazon web services has worked through.

So i wanna sort of walk you through eight different sections of the breakout today with the lessons learned. And without a doubt, the most important lesson that we have learned, helping our customers migrate is really understanding the why at a senior level in your business, ideally with the executive committee and or a board if appropriate to how you're actually set up.

And that why and getting really kind of singular focused on that. Why is super, super important? And as oscar and i were updating this, you know, there's so many profound reasons of what might be right for your business. What is your why?

And often you'll find, yeah, i actually want all of those and really, i would encourage you to focus on what is that rallying, why for you and your leadership team? And it just becomes so important for you to benchmark that.

And a lot of questions you know, we get are, how can you help me with that? Why? With my executive committee and a board when we're doing a large scale migration and the hackitt report where they surveyed over 1000 customers who had completed their migration. It's actually full of really interesting insights that can help you on that journey and really put the data behind that. Why?

But of course, you wanna get your own why? And you wanna use your own data to establish that business case as well. Without that business case behind that, why you won't be bringing your executive committee on that board on that journey and it will keep coming back and stop you from moving forward.

So one of the tools we offer that'll help you do that is migration evaluator. Now there's two ways of using migration evaluator. This is a tool you can deploy with agent list collectors. Now my time as a cto before i joined amazon web services, um i know that deploying any sort of new tooling in your environment prior to getting going can actually be a lag, a drawback on you.

So you know, you can also bring your own data to migration evaluator if you wanna do it. And really what you're aiming to do with migration evaluator is to get that early data point, that quick insights that directional business case that you're gonna need to justify that why to your stakeholders.

So that's available for you. What about if you are, if you wanna go deeper, you want us to help you on that journey. And that's a very frequent ask. And yes, we can do that. We have a dedicated team called the aws cloud economics team that can help you go to that next level of data with you, that that business case expertise, they can work you with you through these these steps and eventually arm you with that information.

So you've got options here on satisfying that first lesson learned, which is is your executive committee on on board. Understanding that why the most powerful one and going on that journey?

And you know, there are many um fantastic stories. I always like this live nation story, you know, a 58% cost saving, you know, 10 crease, 10 times increase in innovation pipeline. Um amazing look, that's a awesome why there were multiple whys but that 58% for me sticks out there as primary all the ancillary benefits. Awesome. We'll take them.

And the next lesson learned after you've got that is well, who's going to own that business case? Like who is going to be that single threaded leader as we call it in amazon without that accountable executive, who's gonna bring the rest of the stakeholders on the journey. You are gonna struggle time and time again. We see that if that business case doesn't have an owner, you're gonna have a challenge.

So who is your single threaded leader? When i was a cto partnering with all of my other members across the stakeholders was really important. And when you're going and adopting cloud and you wanna get to that agility improvement, very often teams wanna get to small business outcome teams able to go really fast or very often you're gonna change some of the mechanics of how you operate as a business.

So bringing along the rest of the team at a leadership level, super important. If you don't bring these folks on the journey, they are gonna block somewhere. And the best way of doing this is when that single threaded owner is able to bring that team together as appropriate, maybe once a week to remove blockers to inform them of progress, maybe even twice a week if that's what's necessary. Because a new way of doing, if a team's not on board with it, we'll just deliver a blocker for you.

So this leadership team is hugely important and this leadership team, by the way, is gonna have a ton of questions and those questions need to be prioritized and answered typically by us as tech leaders or business leaders going through that and going. Yeah, that's a question we're gonna answer it.

And the best way i've found of, of actually answering those questions, time and time again is normally at our executive briefing center, either in seattle or around the world or in person at your offices, whatever's appropriate where we bring the experts and can actually answer those questions.

And every person's question, by the way, if they don't get it answered will form a blocker for you on a large scale migration. The next lesson learned for this leadership team is, and i know this is, this one's really easily ignored, but it's crucial is, have you actually thought about the principles of how you're going to achieve that? Why

So many folks and i put myself in this bracket as well. You know, we go straight to methods. Hey, let's look at, you know, dev sec biz fin ops, whatever you wanna call it, that looks good. But actually, have you really understood as a business, your principles?

So if you wanna move so many teams wanna go to get an agility benefit out of cloud and makes total sense, like agile and cloud go together like peanut butter and jelly. So have you actually got a principle where it says if you build it, you support it. Well, if you're still, you know, a pretty siloed organization with your different centers, you're gonna struggle unless you actually have a principle like that at a leadership team level. And people understand what that means. You're gonna struggle so principles really matter.

Next. Let's talk about cloud centers of excellence now. Um some people love them, but some people don't like them. I'm a, i'm a bit there as well. When i was a customer going through and establishing my own cloud center of excellence, there was a ton of lessons learned here.

Now, i, i actually like the fact that i'm putting down a team together that's gonna act as a fulcrum of change. I don't like the fact that this is like this is the only place or the only team that can do cloud.

So look, there are no hard and fast rules at what makes up a really excellent ccoe but we have seen some lessons learned. So ac co leader working with the leadership team who has great, you know, emotional intelligence and intellectual intelligence to understand the change that's required as you're going along, super important lead cloud architect, you know, infrastructure engineers, the best cloud engineers in my experience are normally the formal operating system folks or network folks.

You know, when i used to write cron jobs, actually, it's not much of a leap to go towards what a cloud formation stack looks like. And all that subject matter expertise of ip addressing dns active directory still super important.

So you need infrastructure engineers, you need security engineers to be on the journey with you. You know, those operations folks who understand the patching, the monitoring, the observ ability. And of course, yeah, if you wanna and i would say you should the best cloud center of excellence actually solve something early on.

If you're not already on your journey, they put something into production live, which is gonna stress your entire system. Now, i have seen some patterns and anti patterns of ccoes. So the first of all, the best ccoes recognize that they're actually an ephemeral construct. So they're temporary in nature. Eventually, i believe ac coe team gets disbanded and eventually becomes cloud operations team as everybody understands how to deliver via cloud.

So just maybe set that up as a mental model as you're going into it. And understanding the new cloud pattern is absolutely essential. You know, the first time i went to cloud as a customer, we dragged all of our patterns, all of our policies and realized the club was very different.

So, are you really understanding those patterns and crucially are you working to empower other teams? Because the moment the ccoe becomes a bottleneck for other teams to actually do stuff, you've got a problem.

So like their mental model has got to be, how am i gonna allow the other teams to become autonomous with cloud while still working safely? Because we don't want any of these teams to go wrong or do something bad. And you've got to establish these essential patterns first, please don't boil the ocean.

And are you technically self sufficient? So the moment this team isn't technically self sufficient, whether it's firewall network, i've even seen one customer put a lawyer into the team so that they can accelerate, actually agreeing open source software standards into their enterprise, like whatever it takes, technical self sufficient. This is not a side of desk project.

And very often you're taking some of your best and brightest folks putting them in this team, you're not gonna be able to do that unless the leadership team in that first principle are understanding the why you're doing that, which is why that comes first and then this is new for this year.

Very often in very large enterprises, we get the question of who hold on. i've got 1020 lines of business. they're all very big in their own, right? how do i make sure we, we're moving forward in the right way.

So when you're in this centralized versus federated pattern model, then there's some things to think about and this list i'm about to give you is not hard and fast. they're just some guidance of what we have seen work and, and what not work. this is not like no, you must do it this way, but at a global level, yeah, there's some things that might make sense for a central or a global team to look after traffic light of service usage.

What is that by the way? So it's sometimes normal for a team to look at those, you know, the 240 plus aws services and even have a, a red amber, green traffic light if can this be used? Um one case, for example, why would you have amber. Well, you might have amber if there's something you've not figured out yet and you're letting a line of business team figure that out. So very, very common.

The bottom one is really important, right? Are you sharing and learning? Are you empowering the other teams and at a federated level, if it's a line of business, is that federated ccoe working to empower all of their teams at that lower level? Like again, don't be a blocker.

So crucial, don't be a blocker, especially as you're about to go into the migration and then cloud business office very often ac coe will actually be the first construct of, of what this means. Um but eventually, if you want to scale your reskilling, rescale your migration plan, your budgeting, how you're working with finance your risk, your audit folks. If you're highly regulated business, establishing a cloud business office makes a lot of sense.

The most important thing though, the most important thing is reskilling. How are you enabling reskilling at scale as you're executing a large migration? It is not just a bit of training. Now, time didn't permit us to go super deep on this, but i wanted to give you a couple of qr codes, a couple of links. This will be on the video of this session afterwards. So you can go and look at this.

But the really crucial thing from my alma mater, which was capital one and customers like nab and verizon i've worked with actually getting to 10% of folks aws certified is a crucial moment. It's an inflection point of actually wider cloud adoption and scaling this human capability. Super important.

Yes, you can use your own resources to do this. You can use potentially your incumbent providers to help with this. I haven't seen it work at scale. What does work in my experience is partnering with aws proserve, partnering with aws managed services, partnering with one of those partners that specialize in migrations that yes, this works.

And of course that training that mechanism around reskilling all of us learn in very different ways. Um really important to tailor that. And then the final bit of this section, sometimes this can get quite emotional of what you need to do where you need to go

One of the things, and one of the tools I love using, is the Migration and Readiness Assessment, which allows you to provide a very sort of non-emotional question and answer approach to "Where are your weaknesses as an enterprise, whether you're a commercial or a public sector? Where, where do you need to focus both your leadership time, your CCoE time, your CBO?"

And then this leads us on to Section 3: Should I bring my existing tooling and architecture thinking to the cloud? This is an incredibly important question to ask, and there is no hard and fast answer. What I find is your AWS Solutions Architect is your very best friend here. They will be able to help you understand the pros and cons of bringing that tooling. It's so normal though for teams to go "I currently use XYZ. I wanna use XYZ when I go to the cloud." That can actually hold up multiple things though if it's not appropriate for that tool. So the most important thing here is to ask "why?"

And as for your existing architecture thinking again, ask "why?" When I started going to the cloud, this was where we started: "Let's have STA - you know, dev, staging and prod - one big account. Let's put all of our workloads because it's probably the closest to like a flat network if that's what you've been using previously." This is unlikely to scale. So this getting started the right way, so crucial for a large scale migration, and very often what you're trying to balance when you're setting it up is this governance versus agility.

Like what am I, what am I gonna empower the teams to do? But I don't want them to make mistakes. Of course we don't. So what do we do here? Well, when I started on cloud 10 years ago, you know, we used to spend a lot of time instantiating our, our landing zones, our control environments. And I have seen customers take an inordinate amount of time to do this and then, you know, have to manage that code and really Control Tower is now your very best friend in this regard.

So Control Tower there to create landing zones, to create even a vending account for your landing zones with the best practices that we have seen from thousands of customers operating on AWS at enterprise level. You know, it's gonna give you that centralized identity access and logging. It's gonna give you that compliant account provision. And really importantly, and this was launched last year at Reinvent, helps you establish your controls in a reason in a very profound way.

So one of the big things that slows down customers, especially highly regulated customers, is their control landscape. So whether it's PCI DSS, the Payment Card Industry Data Security Standards, or whatever compliance program that's appropriate or applied to your business, we know we have to work backwards from that to comply. And how do I do that across tens, hundreds, thousands of teams delivering on cloud?

Now there's a another deep dive session on this last year at Re:Invent, there's gonna be more here, but just to give you a very quick analogy - you know, a preventative control is a Service Control Policy which is a very hard stop of not being able to do something. We have detective controls. And launching last year at Re:Invent we now offer proactive controls. We're using CloudFormation, CloudFormation Guard with CloudFormation Hook as you instantiate and run CloudFormation. We're actually looking for misconfigurations as engineers execute that. For me that's an incredibly powerful mechanism.

And we're now working hard to establish those controls for you across a large number of services. The next thing that slows people down is beyond the AWS services - there's a lot of processes that enterprises and public sector entities have to establish, you know, from log storage, identity management, vulnerability and threats, support, backup, disaster recovery. You've probably got your existing knowledge, your existing nomenclature of how you're doing that. If you have to take time to establish that before you get going, it's gonna slow you down.

And our Solutions Architects have compiled a really interesting library called the CloudFormation Framework, Secure Our Code. Again this will be on the video afterwards, there's a link to actually many of the best practices, lessons learned. So go and explore that, copy it, use it, adapt it for your business as appropriate.

Next, partners. Super key to the transformation journey. I'd strongly encourage you to look at the AWS Migration Competency partners we have and on this getting going. One of the really interesting things is actually having the right application monitoring and orchestration. So again, I know deploying tools in any environment is always hard work. But when you look at the partners that work in this space, it's really interesting.

Now one of the partners I used on my journey was Dynatrace. So this ability to look at what you've got already, to have a baseline of performance, to have a baseline of interactions. So that when you're ready to migrate something you can understand what is the operating system dependence, what are the maybe the storage interdependences, the application independence, caching engines? What are the firewall rules that are currently being used? There's nothing worse than migrating an application in its data store and then realizing there was some weird job running at 3am which queried a data store from an ETL job. Like having that understanding is really important and you get an application baseline.

We know working in technology - if you move an application and the performance is the same, nobody will notice. Awesome. If we move something and it's better - you might get a pat on the back. If you move something and it's worse, you're gonna hear about it.

Now let's look at the Rs. These are seven mental models that you use. I'm gonna talk about five, my colleague's gonna talk about two. So let's start with the first one, Rehost. What I find happens by the way with these Rs is people, for all the right intentions, assume they know what they mean. And there's different people have talked about different things. What I wanna talk to you is how Amazon Web Services thinks about them - that having these mental models is really important for you to understand how I may move something and the downstream impact.

So let's look at Rehost. With Rehost I'm gonna use automation. And what I'm gonna do is I'm gonna pick up my existing maybe server operating system, maybe the database, maybe the application, maybe the caching engine, whatever it is, I'm gonna move it and I'm probably gonna move it into a single Availability Zone. And loads of loads of benefits to doing this - like I'm gonna get a probably a cost performance increase for doing that, but then I can optimize it over time. So I'm getting the immediate benefit of getting it out of my own premises environment. I'm getting that benefit of then being able to optimize it moving forward.

Now to help you automate this, we have the AWS Application Migration Service. The acronym is MGN. You might go "Why is it MGN?" Well, AMS had already gone to something else. So it's MGN. This is what was the CloudEndure software that we purchased a number of years ago now. And this offers an incredibly powerful way of automating your migrations. The most important thing for me when I talk to customers is the really wide platform support that you have when you're using MGN to execute and accelerate your migrations.

So just to give you a quick overview of how that works - obviously you're gonna start with your on-premises data centers, you'll have your applications running on servers, you'll then leverage the AWS Application Migration Service. You can either install replication agents or connect to vCenter. And then yes, it will instantiate and do a continuous block level data replication that's both compressed and encrypted as you execute that.

Some customers have benefited massively. One of the great stories during the downturn was Finnair who leveraged this, working with ProServe and a migration acceleration partner to massively and quickly accelerate their migration journey. You know, during that very quiet downturn during, you know, the pandemic, they were allowed to go really fast as they migrated with MGN.

Let's talk about the next door - the next door is Relocate and you have got some options here: VMware Cloud on AWS, moving to existing containers, moving existing containers, moving to Outposts, moving to Local Zones. You've got options.

Let's just take a quick look at VMware Cloud on AWS - covering 23 regions from when this launched in 2017 through to now with our partnership with VMware, this has come on and come on and come on and we've iterated and iterated and iterated. This is a really fast way to migrate your VMware workloads. Again it's all custom engineered with VMware, so we have specific EC2 instances to host that in the AWS regions. And then when you've moved your servers over VMware of course you can still then access any of the AWS services.

You may want to...

Let's look at the next one, Repurchasing. What do I mean by repurchasing? Well, your landscape right now probably has a massive amount of ISV software - Independent Software Vendors - installed. Sometimes you're gonna have custom operating system images running on custom hardware in your data centers. What are you gonna do with those? You're probably gonna have a ton of different software contracts.

Well that's where AWS Marketplace comes in. So we've got over 13,000 transact listings, over 3000 independent software vendors now have their software on offer in the Marketplace. So if you've been leveraging an ISP software, you'll probably find it in the AWS Marketplace, whatever form that takes - maybe it's an Amazon Machine Image or an AMI as we call them - that's available for you to use and run on an existing EC2 type that's now available to you.

And we've learned by the way that customers wanna maintain their direct relationships with their independent software vendors and their channel partners while consolidating some of that billing and that management. So there's multiple different offerings. This is available to you as you're executing a large scale migration. And there's huge benefits that we find customers have here - you know, 75% reduction in on-boarding efforts, 66% time savings, 10% drop in licensing costs.

So as you're looking at your landscape where you've got those ISP solutions check out Marketplace, there's probably a really fast way for you to replace like-for-like leveraging Marketplace. And it's not just the key infrastructure offerings, which are still very important if you want to leverage those existing tools or even change your tools. It's increasingly and for many years now, these key business applications that are also available in Marketplace.

Let's focus on the final two Rs - Retain and Retire. Now, I find that people are staggered how much they can actually retire. It was amazing to me on my journey, how many systems I had running on-premises which were maintaining systems on-premises. You know, I've worked with customers who have found, you know, suddenly they've got 35 servers doing nothing but a few maybe SFTP jobs. It's kind of like, why has nobody decommissioned that? So you do find an awful lot that can be retired.

But there's some systems very often that you just wanna sweat for a few years. You don't wanna do anything with them and sometimes people go "Well I still need to run that for a few years, so I might as well keep my data center." And I'm like "Actually no - you know, you can actually have the mental model of if I've got a tested and verified backup with guaranteed spares, I can actually pick up physically in an agreed downtime window and move that hardware very often to a Direct Connect partner's data center where I'm still gonna get super low latency."

And just having that mental model that I can actually move things if I just wanna, you know, sweat them for a while to a colo actually frees people up for going "Oh actually there's, there's loads I can do."

And then when you take these five Rs and Oscar's gonna take, you know, the two Rs, you can actually get them into wave planning. So how am I gonna join these up? How am I gonna build my migration factory of human resource to partner with the application teams to help them move? Because you can't just expect application teams to do this on their own - they need expertise, you know, from that resource I talked about a little bit earlier to come and partner with them to bring "Hey, I've got this tool..."

I've got this observability. I know how we're gonna do this. I can envision you an account. Let's get going. Having that resource available to you is crucial and planning this out. And what I find by the way is you need to go in with a mental model that this plan will adapt continuously. Because while you're migrating, you're also running your business, you're also making continual changes. None of us can just take five years out and migrate our applications. So this whole mental model is gonna continually change.

Oscar, let me just thank you. Ya tan. Hello, everyone. Welcome to Re:Invent this day. One cannot believe it is. Uh um so let me start with um introducing myself. My name is Oscar Rodriguez. Uh I lead the global practice for migration and modernization across professional services. Martina and I, we focus 24 by 7 helping customers to migrate and modernize on AWS. I have been working on the cloud data space, machine learning and many other areas for more than 20 years. And today, one of the main areas that I wanna cover is the topic around modernization.

Let's start with first uh why modernization? There are five drivers that we have gathered across, working with many customers across different industries.

The first driver is developers. Sometimes they have to wait days or weeks to provision the environment. Once they modernize, they can have the provision done in minutes.

The second driver is in many companies that we're working on, they still configuring the server manually. Once they modernize, they can have the server fully automated using the CI/CD pipelines and we're gonna cover later on, how can we accomplish that?

And the third driver is which is probably the one of the most important ones, security. Believe it or not, there are many companies that are still configuring security manually. The challenges when you do those manually is then you run into the issue that you make some changes, then you probably you're gonna start breaking out the applications. The solution is to have security embedded inside the applications.

The fourth driver is the lack of visibility. We see many customers that are running in the cloud sometimes they don't have access to the applications that are running in production, the ones that have access to the logs.

And the last one is probably this inconsistency of the tooling that probably you are carrying over from premises or legacy environment. So we have many customers where they have thousands of tools. Once they modernize, they can simplify the overall framework.

But you may be wondering, with hundreds or thousands of applications, how can my business understand the layers or the application complexity? How do we start? The answer is very straightforward. You have to start with an application assessment inside AWS. We have developed many tools, many methods that can help you to do that. I'm gonna show you in the next slide. There is one of our partners, they have developed an application tool that can help you to speed out the assessment.

So CA, which is one of our partners, they have developed a tool called CA Imagine. This tool allows you to discover all the applications that you have across your entire system. It will help you to understand every single detail that you have about the application, application dependencies, things that maybe you're not aware. Imagine trying to do this analysis without having a tool in place.

The other part also CA will give you is prescription guidance recommendations as follows - how can you modernize those applications on AWS? You may find that 20% of the applications that you have can be modernized as a container environment on AWS. Again, I highly recommend for you to take a look at CA afterwards.

Jonathan covered the first five Rs - refactor, relocate, repurchase, return and retire. So I'm gonna focus on the last two Rs - replatform and refactor.

Let's just start with replatform. What is the idea behind replatform? Number one is how do I move my applications to AWS with minimum changes? Minimum changes meaning it doesn't mean that I have to start everything again. Minimum changes probably will be changes on the configuration for the network, security and so on. But the main benefit behind the platform is that you can start moving, modernizing your application really fast.

There are six pathways that we're gonna cover. The first one is you have the ability to upgrade the operating system. Imagine that you have been running on 2003. I don't know how many of you recall 2003, right? And you wanna run in a 2020-2022 Windows environment. So you can either use Application Migration Service or you can rely on some of the partners that we have like RiverMeadow or Stromasys that they specialize. Sometimes we find in customers they have operating systems that they don't know they are aware. So by using some of the partners, they can figure this out really fast.

The second pattern, which is really, you're gonna learn a lot this week, is AWS containers. Probably this is one of the pathways that is in high demand. We have many customers that are looking to modernize and containers on AWS. So we have many tools, but one specific tool that I wanna share is called App2Container.

Think about this command line tool that number one would allow you to understand what you have in your environment. Number two, it will help you to build your Docker container. And finally, the tool also would allow you to deploy those containers on either EKS or ECS. I highly recommend for you to take a look at App2Container.

The third path is open source. We have many customers, they're looking to move away from traditional enterprise licenses. So one example, we have thousands of customers right now that are running on AWS, they have Windows workloads, but they want to modernize, they want to move to Linux. So how can they accomplish that inside AWS? We have developed extensive number of methods and solutions that will help you to move this fast.

The fourth pathway, which is probably my favorite pattern, is serverless. First of all, serverless is not just Lambda. Probably you recall Lambda - that was a major hit a long time ago. As of today, we have more than 25 serverless services. And also we keep improving those capabilities. Like last night, there was an announcement that now with Lambda we can improve, you know, by 12 times faster, the provisioning in Lambda so it can be really fast.

But what is the main benefit of this pathway? If you're looking to have a way where your team wants to focus just on developing applications and you don't want to worry about managing different environments, probably serverless will be the right way to go.

The fifth is CI/CD pipelines. If you recall, we covered one of the main drivers - companies that want to automate. And one of the things that I recall when I was a customer, I didn't understand the value of CI/CD. And the value of CI/CD is you have multiple components in your ecosystem. Let's say you have an application that you have to do all the testing, the approval. So if you develop all of this inside one single pipeline that you can build once and start reproducing across the board.

The last pathway that I wanna incorporate around the data. This is probably another favorite pattern we have. We have many customers that are looking to move away from a traditional enterprise database, probably could be an Oracle or a SQL Server. So we have a unique service called Database Migration Service that allows you to move large numbers of databases to AWS.

Inside AWS, we have developed unique databases that are developed to address specific business needs. So I would highly recommend for you to take a look at this pathway. And Jonathan is gonna cover further the data section later on.

Now that we covered the platform, let's focus on the last R - refactor. The first part is you may be wondering what are the different architectural patterns for decomposition. In other words, if I have a bigger problem, what are different options to break it down to start designing this?

So there are four patterns we're gonna cover. The first one is event-driven decoupling. Think about you have a scenario where your application probably needs to wait to get a response. You can move to asynchronous, so once you have asynchronous, you don't have to wait. There could be a lot of communication happening behind the scenes. One example is if you are developing an online ordering system, you don't want to wait. You don't want the users to wait to get a response. So a lot of companies they're moving towards having event-driven decoupling.

The next pattern is strangler pattern, which is one of the most useful patterns that we have these days. We have many companies that are looking to migrate and modernize large monolithic applications into microservices. So here is one example - let's say you have a large web application and you want to build it as microservices. This is not just weeks or months, probably takes longer. The first thing you have to do is start building your microservices. You start having some kind of proxy. The proxy will continue connecting with the monolithic application as well as with the microservice. And then at some point over time, once you have all the microservices ready to go, then you can retire, you can shut down the monolithic application.

I recall a few years ago when I was working with a customer, it took us probably one year to convert a large monolithic application. There was 109 million lines of code in there. So it was something that happened a few years ago.

The third pattern is domain-driven design. Again, this is probably you heard last week from Swami - event-driven is another area where components are moving towards, especially when you wanna focus more on the business side. But at the same time, you start wanting to map the software components.

This is a new pattern we're introducing today which is around generative AI. Many companies are modernizing right now, probably 99% of companies are modernizing. And they're asking us - how can we use generative AI to accelerate my modernization? So to that end, we have many tools. One particular tool that is getting high demand is CodeWhisperer.

AWS CodeWhisperer is your AI code system that will allow you to modernize. It will allow you to develop code faster.

As a reference is um what we learned as working with many customers, customers, they can gain around like a 57% of productivity values in cross whisper. So again, this is another new pattern that we are um uh introducing today.

But also another trend that i wanna share with you guys. And again, this is uh you're gonna hear uh this uh right now, another may ask from customers, they want to build cloud needing applications. The amazon, wait, what is the amazon way? The way how amazon we're building application for our customers.

So to that end, we have developed a unique service called uh uh modern application design, which number one will allow you to deliver uh results in a couple of days or weeks. We do a rapid discovery, rapid uxu i design, rapid technical design. We're bringing top experts from a technical domain, industry, domain security experts and you will see tangible tangible results in the short term.

The main benefits of this is you can take an idea and prove that it's gonna be real. We have many customers, they are going through this exercise and they're finding those ideas may not be relevant. The second benefit is it will lower your cost. The fact that you will go cloud native application, that means you are maximizing the use of ed place.

And the last one, which is something that we have uh probably a couple of 100 customers right now is uh we're finding those customer, they embrace this offering are with the proof of concept. Over time will be a pilot. But over time, i have like a one example, one customer that now they they build some kind of like a factory using this approach. So that's something that i highly recommend for you to take a look.

Or you may wonder what about my mainframe is uh in some cases, mainframe is in my experience and jonathan's experience is it has the largest footprint could be 60% 80%. So to that end, we have developed multiple uh uh tools. We have partnered with many companies.

Back in 2017, we started a journey, identify multiple partners. Uh we build some uh competive programs and late 2021 we choir acquired a company called blue edge, which is now part of the amazon family. We're super happy to have them on board, but also we have built a service called uh aws mainframe modernization service that uh i highly recommend for you uh to explore if you're you have a mainframe in your ecosystem mainframe has a specific pattern, right?

In my, you know, if you see in this slide, i don't have recourse recourse. So in my end is a lot of customers they asking this, can i do the recourse with the mainframe? The answer is is no, it's gonna be really almost impossible.

There are two patterns that that we see with many mainframe customers. One is refactor and uh reply. But also there are two additional patterns that we learn from many customers. One is data replication and file transfer. The rationalist, you have to find a way to replicate the data and the files while your modernization journey is happening.

This is a high level screenshot of how the mainframe modernization service looks like inside the aws console. And without they're gonna hand her over back to jonathan.

Thank you oscar. So let's talk about um data. Um this is quite rightly needs, you know, explicit consideration. And when you look at just moving massive amounts of data, you may be aware, we have the snow family of options, whether that's snow cone, whether that's the snowball edge, whether that's even the snowmobile that allows you to securely move vast amounts of data uh through these devices.

Now, this has matured a number of times. So i just wanna put this cos a lot of people ask questions about the exact technical statistics. So i just wanted to give you this, what we're seeing is both the snowball edge storage and snowball edge compute uh are used massively in migrations to help move massive amounts of data without relying on wide area network links.

And when you look more broadly beyond this, of course, we have the offline data transfer with the snow family, but we now have a number of online data transfer tools which are set up to explicitly accelerate the migration of your data. And i'm gonna dive into two of them now and i'm gonna start with the database migration service.

So if like me, we're looking at hundreds thousands of databases running on your own premises systems. Um the mission critical nature of those data stores, whether you've got, you know, um block storage, you know, whatever type of file storage you've got, you know, it's of crucial importance that you can migrate that. But as you modernize many folks wanna change their database engine, sometimes they don't, sometimes they do. And it's super important to have the choices.

So, you know, is this in a homogeneous or heterogeneous uh database change you wanna do is is crucial now to accelerate that on your journey, we have the database migration service and this tool has matured so much over the years. It's now phenomenal when you look at the actual sources that you can use um in the last year.

Uh for example, um ibm db two xenos now is now a source to migrate um and then your targets have also increased just in the last week, ti time series databases, a target came live. So we've actually migrated over 1.2 million databases for customers just with this tooling alone, let alone what customers have done with other tooling.

So this is a major tool that's available to you free of charge. You only pay for the instantiation of the infrastructure that might be used to leverage d ms. And now alongside moving the data, often you have the database schema and to help you with any schema changes, we have the schema tool.

Now, when you look at the schema conversion tool, this is gonna allow you to do a number of crucial things. So it can copy a database schema from a source to target. It can convert a database or data warehouse schema. It can analyze a database to determine conversion complexity. It can analyze a database to look at any possible restrictions.

Um really importantly, it'll help you convert embedded stored procedures and it'll do the analysis on those stored procedures. And if it can migrate them for you, it will do so or it will notify you of which ones require human intervention. And it can also migrate data warehouse data to a redshift.

So that schema conversion tool used to be a separate tool. But now this is part of d ms to give you that consistent experience. So this schema conversion as you go from source database. As you're looking at that provider to go through that schema conversion tool to your target data provider and your target database is now super important as you're moving forward.

Now, previously, as i mentioned, it was free, you had to pay for the infrastructure. But now crucially d ms also offers a service option as well. Now when you look at this, the d ms offers four things. One, it gives you your managed migration, it gives you a huge breadth of options. It gives you really high availability as you're doing that and it gives you this low cost. And as i mentioned, it's now available in servius as well to lower that cost even further.

What about if you're using and moving vast amounts of data? What if you've got a multiple terabyte database? Well, d ms and snowball actually work together. So d ms will work with snowball to allow you to move a massive corpus of information on snowball and then d ms can handle any trailing transactions which are required.

So again, this is there is a very powerful tool for you and when you look at some of the custom use cases, samsung uh still blows my mind a little bit when they migrated 1.1 billion users across three continents onto as amazon aurora. Amazon aurora is the fastest growing service in amazon web services has been for a number of years, offering post grows ql and my sequel open source database standards for you.

You know, an amazing improvement in their latency, amazing improvement in reducing their monthly cost. What about for the rest of your data stores? Well, that's where data sync comes in. So data sync's able to look at where you might wanna move your data and work with your existing nfs smb object hadoop data stores to migrate it quickly and accelerate that transfer.

You can also take that data from edge. We have a number of people using the snow family of options almost semi permanently in the field and they wanna pull that data off it into a region. And of course, also you can use it to accelerate data transfer from other cloud providers.

So that's data sync oscar. All right. thank you, jonathan. So we have few slides uh more than we're gonna now be wrapping up. So bear with us. So one part that i wanna cover is uh we have a unique program called uh map, which is uh migration acceleration program.

Think about this program that encompasses six dimensions, methodology, tools and services that we have built across different industries. Partners. We have excellent partners. So we mentioned some of them today, but those partners are ready to help you with your migration modification journey.

We have services, training certification programs. So jonathan mentioned the fact that uh your team is super important, the more that you enable the better and that we have incentive investment programs so jonathan cover and i, we cover many areas around migration mo ses. There are many tools i'm not gonna go through this uh in the interest of time, but are two areas that i wanna reinforce.

One is we are w we keep investing. Our goal is to automate as much as we can so that we can make the life easier for you and your teams. The second part, there are new services that are evolving and probably you're gonna see more announcement this week with the fact that uh ga i is a boom across the board. Probably you will see some of the services being uh released uh as we speak so many lesson learned, i was talking with jonathan.

Uh we can even write a book on this topic, right? And hopefully that's, you know, hopefully he will be ok with that. But you know, i'm not gonna go through this lesson learned slide. There are 33, there are three areas that i wanna highlight.

Number one, executive commitment is super critical. We have seen many companies that they don't have the executive sponsor and they really struggle. The second part, the business case is fundamental. We have experts. Um jonathan mentioned the cloud economics team, we have experts that are available to support your journey.

And then the last one is make investment in your team. Your team is the best asset that can help you to move the needle. This is a summary of some of the breakout sessions that i would highly recommend for you to go. I will pause here for a few seconds. So you can take a picture.

Um for instance, if you want to learn more about the map, the migration acceleration program, you can go to ent 220 and to conclude, absolutely, we'll go back. Actually, that was a good timing to have the the code. Alright, so we move uh and again, to conclude this, don't let perfect be the enemy was good. What will the deception inform our case is security reliability, durability?

So that's the some of the exceptions that we have. But again, with that, um jonathan, anything you wanna do say before we wrap up of it? All right. So that's thank you again, everyone for joining us today. If you have any questions, reach out to you and i afterwards.