Best Practices in Planning a Large-Scale Migration to AWS - 2017 AWS Online Tech Talks

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
welcome guys good afternoon thank you for spending part of your day with us me need of Kataria I'm a principal consultant with a double use professional services joined by a team of consultants from professional services collectively between me and the moderators we've got a lot of experience doing large-scale migrations to AWS and we are here to provide you with as much information based on our experience as we can to make sure that this hour that your plan to spend with us is well worth it so having said that let's go ahead and get started the topic of the webinar today being best practices in planning a large-scale initiative eight address the agenda that we're going to follow is we'll talk very short real quick about migration to AWS itself we're going to spend considerable amount of time talking through three distinct stages of cloud migration that being the pre-migration phase what would you do interpolation of a migration the actual migration phase or stage ie how would you perform a migration and the last post migration phase in that we will cover once you perform a migration once you once you light up once you light up your existing environment into AWS what are some of these additional considerations best practices and then we will leave about 10 15 minutes towards the end of the presentation for Q&A question and answers we would definitely welcome any questions as we make progress during the presentation if there are specific questions on individual slides feel free to post them in the chat window the moderators are standing by to provide you with to provide you with an or the response in the chat window alright let's go ahead and kick it up kick it off so before we begin before we start talking about stages of adoption on the slide Quinton can we bring in the first poll question to gauge what's the majority of our audience are you guys trying to do some small project in AWS or the other here I have a foundation set up in AWS have you done a project you know you build yourself a foundation are you actively migrating something or looking to migrate something and then last but not least you're done with migration and you're right now optimizing or transforming your existing IT running in AWS you perfect like about 42% 4345 so pretty much close to half of the participants on the call today on the webinar today are are in an active migration phase ie unison AWS and you build yourself a very solid foundation in AWS that allowed me to perform a migration and active migration of an existing application or workload to be running in AWS and that kind of goes well with the cloud stages of adoption slide that you see the picture that you see right now on your screens again this is based on our past experience working with a lot of enterprise accounts a lot of customers such as yourselves what we are typically also happen is adoption of cloud adoption of cloud goes through multiple stages the first stage being a project of a lack of a better word this is where customers will tend to provide things by things in individual silos so you might have a network team you might have a corporate IT crying out a VPC you might have an application team testing out RDS or you might have a different application owners trying to do agile devops test so on and so forth so it basically starts with a with a very small project it's not a high value it only allows you to try test what the technology has to offer it allows you to familiarize yourself with what AWS is once you once you're done with a small project once you realize I want to identify what's the real you is going to be for you we've seen a lot of customers go into the second stage of adoption which is foundation this is the stage when if you are operating in a silo if you were testing IDs on your own if you were testing out and easy to instance on your own this is the time when you will reach out to the corporate ID and you will start making this project or or test a real scenario so you'll go back to your corporate ID define requirement of running a real application into a cloud and therefore seek their guidance seek their help in setting up a good solid foundation with network security disaster recovery backup so on and so forth so that all of that foundation will allow you to run your existing application or an identified workload into a table yes once one customer go past that stage comes the third stage where now that you understand the technology by doing a small project now that you've built a solid foundation in which you can run one of your existing application or a couple of resisting applications with that maturity comes a stage when customers start thinking about migration into cloud that's the point when depending upon what's a real use case customers tend to follow either the green projectile or the blue hazard time and each one of them is slightly different so the way it's represented in the picture if you are going to build a net new application you will think of building this new application in a very cloud native design or the cloud native architecture and therefore you will follow the green projectile forces if you are running an existing application in your data center or Apolo Oracle location service provided that is the time that you will follow the blue projectile and you will really think of migration or migrating your existing what you are intimated is that's the stage that we're going to get into more details on what you see after that migrations phase is it also gives you an opportunity to retire your existing technology decks and we're going to talk about an example on what are some of those consideration or what are your options to retire your technique techno technology decks go ahead and start talking about and the first stage of migration that is a pre migration stage so the first spring first things first what we really want to talk about even before you start thinking of migration even before you plan your first worker to be running in AWS what do we what what do we recommend based on that experience is identify key resources and these key resources doesn't have to be an expert knowing cloud technologies are knowing AWS what we are asking you to do is today your IT organization may look something like this there will be multiple silos there will be an architecture team there will be a support team there will be an application team via a security in a network team and so on and so forth what we're recommending what we're recommending you to do is identify these key resources and set up a center of excellence the cloud center of excellence or si si si si si o that stands for cloud center of excellence this will have representation from all of these individual teams that you have in your writing organization today for example people from architecture people from security people from operations people from leadership teams finance things everybody will be a part of this cloud center of excellence reason we're recommending this is these are the guys this are this is the internal team who has a lot of tribal knowledge supporting you supporting your applications supporting your compliance and security requirements and that tribal knowledge is is what we want to be represented in the cloud center of excellence by doing so what you're doing is bringing together one single team which has pretty much knowledge across all the domains of your IT organization and therefore any problems any decision-making any aspects of art picture security compliance finance operations can pretty much be dealt by this Center of Excellence or cloud center of excellence so that's our first recommendation at which point once you have identified the team once you've set up the team once you have identified a contact charter for the game our recommendation is when you think about starting starting your migration journey in pre-migration stage we highly recommend that you do a first card okay and what do we really mean by that is you've seen a lot of customers going down the path of performing and analysis paralysis of the entire IT portfolio imagine your environment having 5,000 workloads and you doing an assessment of all of these 5,000 workloads to identify what's the best way to MyPlate what each of those 4,000 workloads will require in terms of security authentication availability backups so on and so forth if you try doing this analysis and paralysis you will you will spend a lot of time and it may not be perfect either because by the time we're done with analysis a part of your IT environment would have changed and therefore recommendation here is wings don't get into a lot of analysis and paralysis before you perform a migration we highly recommend you start with a very small first project a project doesn't have to be a significant complexity it doesn't have to be a super complicated project either what you really want to do is just kick off a project and in the process of doing so okay what you're doing is you're validating the foundation you're making sure what you created in AWS to run these applications or to run this first project is it valid what kind of network what kind of routing requirements what kind of access requirements would you need and therefore by doing this first project it will allow you to perform a very good validation of the foundation that is already created in another word once a dimer bag look at what what also happens is now that you validated foundation you will also in the process of performing the first project identify invalidate and the turn-on but the in which you will be performing this Malaysian so when you start small allows you to do a good validation or foundation process methodology and apply that in full to perform one successful Malaysian with each migration when you tackle a new use case you will go through a similar process of the beaming and thereby you will get a lot of lessons learned out of this pre-migration phase which will allow you to identify any such corner cases which could tend to be a problematic when you perform the actual migration so Peter we used on the previous slide and and and we thought it would be good to to kind of benchmark the baseline what the term really means so the term we use on landing zone and what we really mean by landing zone is a pre-configured secured enterprise AWS environment think about if you guys are aware of AWS think about this as your first an EPC as your frustratedly account um and for folks who are not aware about eight of us our EPC we TC is it's a virtual private cloud it's an extension of the data center you will run this we TC on a predefined IP r is defined by you you're putting your IP address the route policy you know tables the security posture of this vp c is pretty much defined by you and therefore this is an extension of your data center into cloud so in summary a landing zone is an environment that will allow you to iterate and extend over a period of time based on your use cases with every project with every use case with every first use case that you try in in AWS in the pre migration phase what you're really doing is you created a minimum viable landing zone 1.0 and as you uncovered additional requirements you modified your landing zone and therefore by the time you're really done with the pre-migration phase what you have is a very solid foundation multiple versions of your data center or extension of a data center you the minimum viable landing zone which by the way could also be a code something like a CloudFormation template that heatedly supports and therefore what's happening is even before you really started tackling migration in itself you came out of a lot of learning you quite a few projects in the classes you were able to validate methodology you are also able to build out a landing zone that pretty much seats your requirement and support you when you'll be performing the migration so summarizing that first stage pre-migration stage start small and you crate with use cases do few smaller projects and perfect your Minimum Viable landing zone that will support you through your your migration of first set of migration create a center of excellence all the knowledge that you have within the organization that's a good knowledge definitely ported over transform or bring that learning in when you're creating the cloud center of excellence do a small representative project create a process based on the lessons that you've already learned doing a small project and in the process validate the foundation in the technology a few considerations that you want to leave behind in this section prevent doing a lot of analysis paralysis don't waste a lot of time because all you know you're heading is changing why doing an upfront discovery of the entire portfolio because again as I said if your migration is a two-year journey within two years a lot of things are going to happen to your IT you might be retiring hardware might be refresh and hardware you might be retiring some technologies so you don't have to do in upfront discontinued our portfolio create a Minimum Viable landing zone or an MDL code it if possible so that you can version control your MBL's and have each version of a miel available to spin up during the actual migration alright so moving on to the next slide the section that we want to cover in next few slides is stages of cloud migration the actual migration itself the first the first key learning that we want to share with you is our multiple ways in which a migration can be done on both or all the ways of doing a migration are are right ways but then there are some additional considerations that you want to think about sure looking at the picture on the left it says bigbang migration so you can also think about that as a waterfall methodology what's happening in in in that type of a strategy is you are looking at an entire application portfolio assume that you have an application that's that's that's built on a three-tier architecture what you're doing is you're picking up your web tier your application to your database tier everything picked up together and one entire application migrated at a time when you do when you follow that kind of a Big Bang migration strategy um it's obviously a little more time consuming because you're moving an entire set of application with every possible here and every possible workload because it's a little more time consuming and it's a significantly large effort um there could be increased risk because say hypothetically your first application which ingredient application at sixty servers now you're going to move 60 servers in one batch all the data associated to those 60 servers will have to move in that batch and if one of those systems are 60 fail during a migration you'll have to put your letter fail back on your entire migration strategy so that's right it comes with an increased risk compare that to the picture on your right we're what we call it as an iterative migration methodology think of an agile methodology and what's happening is you're breaking down the application into more functional components into smaller functional components such as web Pierre is built separately than an application tier then a date is dear when when when following a strategy like that or in iterative migration strategy because these efforts are in smaller functional groups yeah they were really fast you will be migrating each gear faster because the number of servers and the amount of data that needs to be moved that gear over the group of servers is small and therefore it's also it also comes with a minimize risk as we move on to the next slide here's here's a slightly loaded example of the edge I love the iterative migration methodology we're doing is you're breaking up functional components of an application and moving each one of those functional here in one sprint and sprint being two weeks in here it doesn't have to be two weeks that's just it but that is just the reader addition of the diagram back but this is the process that we highly recommend this is the methodology that we want you to assess and wherever possible apply in your medicine strategy the next slide and before I get into the details of this slide Quentin can we pause question number four all in question number four how will most of your applications be migrated I like that when it when the polling was open 100 percent was rehoused that's a fairly good mix of response people have identified Rijos free platform we architect it's pretty much an equivalent makes about 55 percent 57 now say that it will be rehoused so just a little said before we get into this on before we get into this slide um garden I did a did a significant amount of work about three years ago about four years ago in identifying five hours of migration and what we did we array WS did was we took that definition that effort that that Gardner had already put in and what we came up with based on our experience was six hours of migration on each our stands and it doesn't have to be six it could be seven in future but the way it goes right now the first R is reading which is um you don't know what you're going to do with this application either the application is going to sunset in near future or the application is going to retire or the application has some complex technology dependency on a USB dongle some requirement which will not allow you to migrate this set of application and therefore you have decided to continue running it in your data center or maybe revisit application in future but as it stands today will continue running it in your data center that's reading the second type of are on the circle our strategy in retire we're urban ancestors gonna retire the application because it has duplicated functionality or it used to do function which is now available in some other application or you know it's going through hardware refresh cycles on and so forth and therefore because you're going to sunset this application in future you're going to you're going to consider it as guitar the classic guitar our strategy is rehearsed people also also tend to call it as a different shift and what you're really doing is you're for lifting an application along with the operating system configuration kernel fine-tuning application fine-tuning it's just lifting and shifting it from your existing data center and running it in a DES bit before I before our strategy could be we are connected um what you're really doing is looking at components of your application and you re architecting some of these components of your application and a very good example of such is in a three-tier application you identified that you may not need to run a database the way it is today but you may want to consume a managed service such as in another Nadya's and therefore you might have to go through a little bit of a Ryoka tech chure of your application your code might chain a little bit but basically you are we are connecting the whole application to suit your model use v v possible our strategy is refactoring what you're doing is you're looking at your application code you identify what's the desired end state and you are completely rewriting this application perhaps for reasons such as now that you are planning to run this in cloud you might want to consume some cloud native functionality such as auto scaling or auto recovery and therefore you want your existing code which is tightly coupled hard-coded IP addresses to loosely coupled code and therefore you are rewriting the entire code and that's refactoring and then the last one is Reap lat form where you're writing your existing workload a good example of such you're running your s AP instance on IBM AIX and you want to run it on Red Hat Linux going forward so that it allows you to be ported in AWS or on a traditional native XR x86 architecture so you're swapping out the underlying platform for my RISC architecture to NH 886 architecture so those are these six RS on back to the slide what we're recommending is once you have identified an appropriate path for a given application whether the body's Rijos whether it's really take over three platform what-have-you once you've identified in appropriate path for your application we highly recommend setting up what we term in the migration factory if you really think about what a migration Factory is every name suggests depending upon the migration path or or the our strategy for example reals you will sort of a migration factory which will have resources who are qualified in performing application discovery using some tools who are trained to perform a lift and ship using either a need just provided tools or a partner provided tool and therefore their expertise being trained in usage of all these tools that allows you to rehoused a particular work out into AWS and so people are if that kind of skill set with that kind of training with that kind of background will be a part of a migration factory that's responsible to perform a host ok on moving on to the next slide well we really want to emphasize is while you are performing this migration regardless of the path that a particular application is going to follow or a migration strategy that you will follow for a given workload what is imperative what is what is of utmost significance is remember there will be additional contention constraints on your resources resources being your application owners as well as your IT resources your application owners will now have to perform a double duty of while supporting your migration initiative they are also keeping the lights on and running business as usual and that would be additional constraint on your human resources on your IT resources there will be additional constraints such as the same network bandwidth that was used to provide I was used to serve your business traffic is now also supporting seeding of data into AWS in preparation of the migration and therefore given all those constraints on Human Resources as well as your IT resources what is significant during migration phase is you set up a very good governance and communication framework okay you got a prior progress you got a set of dashboards so you got a set of reporting templates you got a set up a way in which you will have an ongoing communication with all these stakeholders this will come in super handy and cost and trust me on this there's a good long way in ensuring that your migration is is successful that kind of brings me to another polling question and I want to say this will be our last question in interest of time what tools does a country use in connecting migration census [Music] also a lot of people about the P 455 going up to 60% people are saying to use G and which is an awesome thing by the way it's a very good practice to use something like GI which will allow for a dynamically update in reporting communication mechanism if you were to think of a static webpage that you will go and publish a dashboard on it will lose it lose it lose it it's its purpose so let's move on to similar that section what we're asking is over we're recommending is prioritize agility think about smaller iterative migration with a logical title Big Bang medication hi small validate apply lessons learned um sort of a migration faculty depending upon your use case depending upon your path of migration highly recommended sort of a migration factory with specialists with expertise in performing back part of migration don't underestimate the power of crack tracking communicating the progress our communication is never never never harmful some considerations appropriate migration choose appropriate medicine tab based on what our profile set up smaller sprint teams consider additional contention on resources both human resources and IT resources when you think about migration so moving on to the last stage which is post migration um this kind of completes the whole circle we started our first slide in the dream ideation was identified three resources and set up a competency center cloud competences Center the competency center will come in handy once we're done with migration as well and when they will come in handy is they'll help you defile based on the experience serving your internal customers the application owners the business units they will help you define a very standardized governance framework we have been there done that help them use that knowledge which exists in your IT organization to surgery to know customers better don't forget the importance of organizational change now that you're running a workload in AWS there will be aspects of organization change management that again your core competency center which is nothing but your existing IT organizations representation welcome in Annie you might have to go and teach or communicate their application owners that if it is a development environment the assistant will be turned down in the evening until next day in the morning to save some cost and that's pretty much valid as that's possible but this needs really communicated the change that the organization will go through especially our IT organization my adoption of a cloud strategy will have to be communicated and it has to be run formally as an organization change process now in next couple of slides it's about three or four slides if you go back and think about the first slide stages of adoption after migration there was this blue bar where we spoke about potential opportunity to retire your technical debt so the next three slides what you want to cover what are your options to retire your technical or technology debt let's assume let's let's play a scenario that you were migrating your existing data warehouse into AWS following the iterative migration methodology that we recommended you migrated your data warehouse and you'll now using rhe hosting strategy you are now running your data warehouse on top of an Amazon ec2 instance for folks who don't know what's another than ec2 instance think about that as a virtual machine available from Amazon on an on-demand paper use hourly basis that's basically what your machine that your provision yourself um and you're running data warehouse on top of these ec2 instances this was this is a good enough success that now you're running your data warehousing ec2 instance but are there additional opportunities and you have 3GS they're wrong once you're done with this migration once you stabilize consider optimizing the existing data warehouse worker by swapping out and underlying database order technology as such with a fully managed a W service such as an RDS for folks who don't know about audience it's a manage relational database management service offered by a Tobias what it really does for you is if you think about 80% of your support and operations tasks that you have to do on top of an existing database and friend it will include things such as fine-tuning performance tuning capacity planning on availability management patch management all of you our routine mundane tasks that doesn't really add any value to your business but you still have to perform them the ratio of the database on Prem is up and running and it's performing to a desire driven that your application honors and your business groups have a need for if you were to outsource if you were to offload these routine mundane tasks by consuming the managed service such as an Amazon RDS that will free of your resource to focus on what's critical for business imagine that with a single check box you can run a two side active active multi easy RDS what else you want it all have to manage availability if an underlying if an underlying system in a multi ad department fails we will promote the secondary to become primary and we will replace the fail instance with the healthy one will synchronize all of this for you wherever possible do evaluate and consume a managed service free up or offload the burden of routine mundane tasks and thereby get better flexibility better performance and an optimized cost and then that's not the end Sade even you swapped our databases now go a level further consider swapping of the entire technology stack such as data warehouse with a welding solution that Amazon can offer redshift is a data warehousing solution that amazon offers a fully managers it's the fastest-growing a division is in our history and if you consume a service such as redshift you have no more responsible to capacity plan you're no more supposed are you're no more required before got the capacity for your real warehouse cluster two years down the line imagine when you consume something like redshift not two or three dials such as what in the performance you want what's the availability what and what's the capacity do you need today you set of these dial and we will ensure that you get the desired capacity at your required or predetermined availability levels all of that configure the dial of a button and this is the example where we wanted to talk about how can you retire your existing technology debt going from a fully self-managed supported era data warehouse on prime to a fully managed Amazon redshift and any passes now not even has to gain any code most part your existing code will continue on in years is and the underlying technology will change allowing you to retire you attack that and any process if you where availability better performance a better cost so let's summarize that post migration section apply learnings you know can't emphasize enough on that the center of excellence that brought your learning from the past is now going to apply all of that learning all of our tribal knowledge into your migration we're going to support you all the way through post migration setup governance we create reusable building blocks wherever possible so that they could be repeated they could be faster education continue to evolve don't don't rest once you are done with migration look for additional opportunities no considerations organizational change management process is important please provide it enough of importance and run it as an organization change management don't underestimate power of communication use existing IT organization knowledge migrate and optimize in past when I did one of these seminars at Greenland um after after my presentation a lot of customers walked into me and said it why should we do rehoused because if there are issues with rit we're just going to bring them over to eighth address and that's where my response was we host is not a bad strategy can think of we host is your first step and then migrate from there and then I ready just to do that now that you're already running lean eight of us using the rehabilitation strategy you've got additional options you can experiment with virtually unlimited capacity and resources available in AWS and optimize your existing work lives without taking any downtown or outage so consider doing that last couple of slides before we open up for Question and Answer um two slides that we want to leave behind is everything that we said so far um you know the first ones it doesn't have to be risky a lot of customers have done it if you go to our website you will see a lot of customer cash carries on and therefore there's a lot of knowledge and there's a lot of dual assistance available out from the AWS as one of our partner ecosystems so quickly quickly touching upon a few tools in a migration space itself um there's a tool called the application discovery service as the name suggests it will go and discover every application that you're running in a data center plus it will also draw up our dependency map for you so if you were to prioritize which application should go in a tub is first depending upon the number of interdependencies the application discovery service will let you do that once you detect once you discover a workload and its dependency when you're ready to look at over there's a super tool available called database server migration service at all as the name suggests allows you to migrate an existing server into AWS and it supports a wide variety in use cases for example depending upon the amount of data that you want to move this server from one file server migration service will allow you to go ahead and start reading data ahead of time and to find a frequency in which you can synchronize your data or create a consistent snapshot in a tenuous and launched an an ec2 instance out of that snapshot that's already available in in in a DBS likewise there is a native base database migration service and the tool is specifically designed to assist or to help you migrate your existing databases from on-prem in to AWS again it kind of supports a wide variety of use cases so you can go from an on term database to an already yes instance or you can optionally also consider changing your database engine going from a my sequel on friend to an ER already be in a degree less it will support all kind of use cases almost no in those cases and there are additional tools that I will not get into details in interest of time I'll move on to the next slide and this slide talks about a lot of existing system integrated partners that are available with very nice skills to assist you in performing migrations and you can imagine any any any kind of use case for example I have an SAT system running on AIX in my data center can i migrate this SAT on a Red Hat Linux running in AWS and the answer is yes and there's a partner to do that there's a partner and specializes in doing that and and and all these partners are not just supporting migration use cases and with my throwing number of resources at it a lot of these partners have also developed their own intellectual property or IP around automation in tool assisted migration to support your specific use case no matter what your use case is we highly encourage you you're welcome to visit our website um if you if you were to Google ID of this migration competency Center ah you will you will will come across a hyperlink a URL on our website which will walk you through all these existing partners optionally you are also welcome to reach out to your existing database account team to help you will make your recommendation based on your use cases what's a good partner or a tool that you should be using in your migration strategy I think that's all I had so quickly summarizing three phases of migration um three migration migration and post migration what you're really doing in pre migration is identifying your key resources to set up a cloud Center of Excellence this cloud Center of Excellence will help you perform smaller pre migrations and learn lessons out of it so that you can start building a minimum viable landing zone and then iterate upon your landing zone to a point that supports your malaysia needs when you're ready with the landing zone you will start performing the migration um it's highly recommended that you think about an iterative methodology of migration versus a BIGBANG migration set of specialized migration factories depending upon your of migration so that liscus goes ayah in evident enough of stress on crack and communicate progress a good governance goes a long way when you're done with migration some of the post migration state is you know apply lessons learned margins cloud competencies centered and your existing IT organization create reusable building blocks and continue to evolve don't just migrate and scale like that highly recommended that you continue to you all and in the process gain better IT and a lower cost
Info
Channel: AWS Online Tech Talks
Views: 56,423
Rating: 4.7119999 out of 5
Keywords: amazon web services, aws, cloud computing, webinar
Id: NcgBAUBtFA8
Channel Id: undefined
Length: 45min 14sec (2714 seconds)
Published: Fri Jun 02 2017
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.