AWS re:Invent 2018: [REPEAT 1] Executing a Large-Scale Migration to AWS (ENT205-R1)

so good afternoon welcome to day three of reinvents my name is Jonathan Alan I am AWS enterprise strategist and this is ent 2:05 executing a large-scale migration to AWS um just sort of fast-forward there was a repeat of this session on Monday this is this is now the second session just going into the agenda I'm gonna cover obviously some of the high-level business drivers but overall this session is actually focused on the how not the why I'm going to talk about setting yourself up for success and some of the common things we've learnt around the planets going through thousands of migrations I'm going to deep dive a little bit into the seven hours for application migrations and some of the technical elements and best practices for patterns we see in that regard then Nike are going to come and share their migration story on stage and then we're going to go through the migration acceleration program in some detail so business drivers for migration we really see a massive number of different reasons from our enterprise customers around the world for why they want to migrate everything from wanting to get to that agility and developer productivity improvements through to changes in outsourcing contracts facilities lease is expiring improved security the bar obviously for security is raising every single day through to costs obviously wanting to get cost out of those data centers and through to talent a lot of the talent we see from the graduates leaving universities and colleges have worked with cloud for a number of years and actually want to work for employees employers that are cloud native and obviously going global quickly is also a really strong factor people want to build their infrastructure in applications and actually use common api's around the world consistently to provision that infrastructure but by far the most common use case we see for mass migrations is obviously unlocking these savings and rapidly positioning yourself for modernization and we truly have thousands of customers migrating I'm sure you saw Andy's keynote this morning where he covered a couple of them in detail ever from everything from in L through to ask last year and through to my own alma mater Capital One I've actually been with AWS for going on two years now but in a previous life I was actually in Capital One for 17 years as a senior director and divisional CTO and helped lead the early adoption for Capital One in the UK into AWS and if you look at some of the benefits that these enterprises are getting from migrating they're truly profound you know if you take a look at an L on this screen migrating 5500 instances in nine months reducing their storage costs by 50% in compute costs by 20% these are profound changes that are positively impacting their business through touch coca-cola who obviously migrated 600 workloads to AWS in just 14 months now over the last two years I've had the privilege of personally working with over 170 different customers around the world that are transforming their business with AWS and working on migrations and it can actually be a little bit intimidating when you're faced with thousands of servers hundreds or thousands of application workloads can feel a little bit overwhelming and this is a really common question that I get so with the benefit of hindsight from that collective learnings both from my own personal experience as a customer but from all those customers we've worked with and the thousands of customers the AWS have worked with how can we go really fast but safely now I want to share some of the most powerful lessons that we've seen around the planet with you today now first of all the most powerful lesson and one that has the most profound effects on positive change for migrations is when a single-threaded leader declares a bold goal for your organization to migrate we see this time and time again being the primary driving force for effective transformations and obviously when this goal is linked so your business's goals themselves and typically from my own personal experience in capital one when Rob Alexander the global CIO stood on stage at reinvent in 2015 and really announced to the audience and the world the Capital One was moving from 8 datacenters to 3 by the end of 2018 it removed massive amounts of ambiguity inside the organization and we see the same from the likes of Anil where Fabio set a very similar goal so time and time again we see this being hugely important and these leaders then obviously have to bring an holistic group of stakeholders in your business together to make sure across the dimensions of people process and technology that there's a consistent understanding of moving to AWS there can be a natural fear of the unknown so typically best practice we see as an executive steering group coming together that has procurement folks the legal folks in there obviously the chief information security officer or a direct report security is job zero for us all through to the finance officer if you're moving away from a traditional capex intensive business now to an OPEX it can be very liberating but your finance folks need to be on board with that through to the head of infrastructure and again these are not consistent roles for every organization but they're a good indicative direction whoever has been running the infrastructure she or he needs to be brought in to where we're going and again the head of delivery or a comparable role now best practice often says from my own personal experience and with organizations I work with that a cloud center of excellence is incredibly important I'm going to cover it on the next slide but having the CCO leader CCO a leader part of the steering group can be very empowering for the executive committee to understand those steps were taking technically and with our people and with that process is to get the most out of cloud and if you're a highly regulated business bringing your risk and audit leaders on board and making them part of this journey is crucial for their understanding and of course HR we're going to be people to get the very best out of AWS so bringing it together this steering group really important and it works best when it's round about six to twelve this is obviously a to Pitzer model this is an amazonian representation of course two pieces being to be teams being of course that you can feed this team of moderately hungry people with two pieces and then of course this team best meets once a week ideally twice a week to remove blockers to understand how we can and migrating to set ambitious goals to remove any blockers that might occur and I guarantee at this point when you bring this group together for the first time they will have a ton of questions about the migration about cloud about best practice and time and time and time again we see that when this executive steering group can come to AWS ideally in Seattle but we can also do EB C's locally they can get these answered these questions answered and move forward with a lot of pace and the next thing we see happening time and time again from both my personal experience and come from customers around the world is putting together a cloud center of excellence team works incredibly effectively and the best team composition is where you have infrastructure engineers security engineers application engineers operations engineers and architects coming together with a CCO a leader to define those security objectives there's availability objects reliability objectives compliance subjectivities objectives and getting that first workload if you're not already using AWS into the cloud now it used to be that the first thing this team would do was create a landing zone and figure out all the different components all the different building blocks and that would take time in my own experience it did take time we learnt things we changed them we changed them again as we learn new things and this was taking too long as Andy talks about this morning in the keynote and since June this year working with your solutions architect or pro serve we can actually provide this landing zone this best practice for you in code form so what you get with the age of blessed landing zone well you get a well thought through account management proposal you get this Identity and Access Management core you get this security and governance and of course you get this extensibility so we know that the platform is very very configurable and we've also has had customers approaches saying actually we know there are so many different things we can configure we don't want to spend a lot of time figuring that out for us help us so we've developed this as best practice now obviously this morning we launched a control tower which you can apply to be in to preview for and when that releases to GA this would be an evolution and a step changed forward in this ability but when you would take this new landing zone code you can actually get to a point now where it's like an account vending machine so you can take the service catalog which obviously you can define which of the building blocks you want to use you can take organizations and then you can create these accounts in a very repeatable way so you can do this right now now when you've got your landing zone set up when your questions have been answered what's the next best step that we see and the next best step is trying to break down that almost sometimes a little bit over of what if I got how can I move it and we see this best being done in probably two phases one is discovery really understanding what you've got and I'm yet to meet an organization who has a 100% accurate configuration management database and the next is to look at what are the right application migration strategies you can actually use so I'm going to cover discovery first of all so with Discovery you can actually use the AWS application discovery service now this has two modes if you have VMware 5 5 6 or 65 you can actually use this in agentless mode if you've got physically installed operating systems we have agents for those operating systems mentioned and shown on the slide aw application discovery service will then take this data put it into CSV format encrypts it and place it onto Amazon s3 then using Athena you can then query this data this query dates that the CSV format data is also readable by the migration hub this is the point that can provide you that consistent look of here's all the data that it's got here's these key key performance indicators that you need to track for your migrations this is the work to do very often we see having the right KPIs for migration for the executive steering group to show that tangible progress is incredibly important so here's how you can discover really effectively now let's move on to the application migration strategies so we used to talk this with a framework of what we call six ours six different migration strategies we now have a new seventh migration strategy which is course using VMware with relocate so let's take a look at this if you're running vSphere six or six five you can use cold migration or hybrid link mode to actually take your instances and actually move them into AWS in these five regions is where we have the current functionality and in vmworld on September the fourth this year we also announced the planned role out of the next regions where this feature will be available so that's relocate what about the next one so this is rehearsed this is where you're actually going to take the existing server operating system that's running the application and you're actually going to move it up its existing hypervisor and put it on top of ec2 now there are a lot of tools available to do this I'd also suggest that you actually do it manually to understand what is happening in this process the first time so you can clearly see how this is happening what is going on so let's take a just a quick double-click into re hosting so we've got our instances in this case we can use the AWS server migration service to now create a Mis into our region and again the migration hub is there it works with the migration hub you can also use a number of partner tools from the marketplace here with cloud in jaw ATA data River meadow offering different features and different elements of which you can do for this now as of the 19th of November you can now Rijo stat integrates with the key management server to create encrypted a.m. eyes it's the application migration service so this is we're getting updates of course we're iterating on this all the time from customer feedback and actually I'm pleased to announce that recently through codified moves we've had over 750 750 thousand servers migrated this way so that's Rijo stting what about re-platforming what is replac forming will reap platforming is where you take the existing application or database and move it so for example you could take oracle weblogic move it to the pati tomcat you could take your existing database and move it to dynamo DB this is re platforming so let's take a double click at that so this is where you take your application you'll create a golden ami at the target version that you require and best-practice says keep this simple if you're running on RedHat version x creates that version X also over here you're going to reduce potential kernel incompatibilities and then you can move your application again you can then take opportunities to maybe use opsworks to create that golden ami in a consistent way you could take the application codify its install with opsworks so we see this is a very popular choice what about databases here we have the database migration service so again you can have your database types from the left-hand side here you can then use the DMS service to create multiple different types of target for your database and obviously some of these databases are extremely big and you don't want to be saturating your direct connect link or your VPN link when you do this so the ability to integrate with snowball edge and the DMS service to actually put your data store in an encrypted format there are no keys hex caps on this have this shipped into a region and work in conjunction with the database migration service is incredibly useful service and as of July the fourth this year with migrated over 80,000 databases in this way with our customers now just as a snapshots earlier when I was a customer in the audience a couple of things going through my mind was well what are the sources for the database migration service I just want to put this on the screen for you because I know some of you are thinking well will that work with what I've got so these are the sources right now this is changing continually as we again iterate and improve things so these are the sources and these are the targets and just in the last few weeks the elasticsearch service was added as a target for the database migration service what about when you've got a check the application compatibility of database code objects including views may be stored procedures functions to form the compiler compatible with the target database now for this we have the schema conversion tool so the schema conversion tool runs actually on a desktop host it supports four operating systems and in this regard you can actually use the schema conversion tool to look at your source databases and use it to convert the schema and it can identify where it can't do this automatically for you as well so where it can it'll do it and where it can't it'll show it for you so using the database migration server and the schema conversion tool together you can effectively replac form your databases what about repurchasing so you know personally from my own journey and working with customers very often the conversation with the leaders and the engineers and the developers is what you really want to be focusing on supporting what is going to truly differentiate your business where do you want to spend that precious engineer and developer resource innovating for your customers because if you're hosting systems which are not core for your business and you're maintaining a Mis and and software from your vendors I think you've got to ask yourself why so when you're going through this really look at the repurchasing angle is it right to actually look at the marketplace and say what can we get from the AWS marketplace to really remove that undifferentiated heavy lifting whether it be for software as a service or where we can take an ami straight from a an independent software vendor to remove the heavy lifting of us even having to maintain that operating system or the application installed on the Amazon machine image so obviously for here we have the marketplace and you know we've got 1,400 independent software vendors well over 1400 now with 4200 product listings we have over 190,000 customers using the marketplace in this regard so again as you go through your application catalog being able to almost go actually this isn't cool to our business we are going to move this to a repurchasing model it's incredibly useful and actually these are the most popular categories most often provisioned that we see from the marketplace a really diverse offering here refactoring what is refactoring very often the conversation I have with with teams around the world easily strays into that of DevOps I would like DevOps teams I would like all my applications to be microservices I'd like to have dev up teams across the board so am I going to refactor my applications to be cloud native to look at using lambda to look at using dynamodb to really remove the maximum amount of then differentiated heavy lifting and obviously when you move up the stack as it were you get to the very best price point the very best efficiency so there's a lot of attraction but when you're migrating keeping momentum in place is incredibly important so my advice here is be really mindful about when you want to use refactoring in a migration now if you've got some of these older non x86 systems obviously putting teams together to tackle and move to native cloud services can be an extremely effective way of actually moving these older incumbent systems out of your data centers but be mindful about it if it's a core thing to your business and you want to move to a DevOps you want to get those upper-level services by all means put the energy unerring effort into refactoring and obviously if the cloud first the cloud native for what you're building new you can embrace these these new ways straightaway but for migrations be mindful I guarantee is engineers and developers by the way it's what you want to do by default but you need to use all of these different ARS in combination for an effective migration and then of course what about retain or move what is that well we do cc's seek some customers that want to rapidly move out of their data centers on incredibly aggressive timescales so for that we see some customers actually picking up these systems and moving them into Direct Connect partners or to coalos where they can get really low latency for those systems to still have access into the regions so we also see this coming along as an attractive option and of course retire decommission if it's not caught your business if it's maybe an application which supports maybe monitoring in your existing data center and you'll be amazed how many you find of course you can label this with the retire or decommission label so using all of these seven R's it can be an incredibly clear way to actually label what you want to do and I actually spend a lot of my time going into customers when they seem almost overwhelmed by the migration possibility and actually getting just seven sticky notes says when different colored sticky notes going through their applications in two days and just literally writing the name of an application on a timeline and just almost getting a bit of a strawman going of actually how do you want to migrate these it's never going to be a hundred percent accurate but it actually gives them a really good strawman of actually I can see some linkage here I can see if I move this group of applications I can avoid a big capex investment which I had brewing here so actually I'm going to prioritize those first it can really help with your detailed business case and then of course moving vast amounts of data we have snowball in two different varieties and we also have snow the bill with optional armed guard if you so choose again this is this is securely held and encrypted format there are no keys held on these devices and this is giving you a chain of custody of the data into the region and snowballs have actually now traveled equivalent of 500 times around the planet so I get asked very often what sort of mix should I use when I'm doing a migration and there is no hard on fast rule for this the answer is you know you've got to look at the practicalities of each one of these options and right for you but we typically see this being a pretty good guide and noticed that re host and REE platform works pretty effectively when you're looking at 70% here now I guarantee as engineers and developers who live technology there's a real propensity to want to go and choose REE architecting or reap platforming but really again for that speed of migration when we saw the tools available for Rijo stting actually Rijo stting gives you the best speed so here it's Riley indexed higher so use all of them but be aware of some of the natural tendency to want to build almost this Crystal Palace of code perfection as you go on when you're migrating momentum is incredibly important tracking your progress incredibly important into cloud and typically we see this coming through don't let perfect be the enemy of good enough so what is good enough mean well I'd say as a minimum your security objectives of course need to be appropriately defined your availability objectives but actually you can spend a lot of time tweaking things when you migrate when your goal is to migrate at pace so an interesting example from edmunds.com who completed that all-in migration a few years ago when they were working with their teams and putting together what is the minimum viable refactoring to actually get applications into the cloud they came up with a really interesting two-week rule which basically said we're going to re-platform you and if we can't do it in two weeks we're actually going to repost you you'd be amazed at what just setting a deadline like that as you go through that what that can drive what a team who's doing that Minimum Viable refactoring learns that's required for these applications for the operating system as they move them into cloud again you get that momentum you get that pace you get those learnings coming through and you can go really quickly with that I'd now like to hand over to Mike thanks John the chef hello I'm Mike Witek I run global infrastructure for Nike and as John said we're gonna talk about our cloud journey which started slowly and then has gained a lot of momentum in the last 18 months but before we do that I want to share a little corporate strategy with you so you got some context for why and how we're using these technologies our mission statement is to bring innovation and inspiration to every athlete in the world and there's an asterisk next to the word athlete to refer to a quote from one of our co-founders Bill Bowerman that if you have a body you are an athlete so we are here to serve the entire population to allow them to engage with sport and be more athletic and that athlete asterisk has increasing demands and expectations for how they interact with our brand and how we connect with them and we do a lot of that through our mobile apps like sneakers and the Nike app Nike Run Club and Nike Training Club on the off chance that you don't have those apps on your phone right now this would be a great time to download and install and those apps provide a good insight into the way that we started using cloud technology we launched new products every day and some of those products especially with our Jordan Brand generate a little more attention than others and the biggest of those product launches happen during this time dear and what we used to do is look at the biggest launch that we had from the previous year and add capacity in our data center to handle that traffic and for the majority of the year it would sit there just looking at us and not doing very much at all and we had a real issue with being able to scale out to meet the demand that we generate and that people have for our products so with the sneakers app was originally there to do it was to have that elastic ability to really go out wide before our launches and then shrink back down when they were done to do that we also wanted to make certain that we were only writing the stuff that we needed to write write the functionality in the app itself not all the other components that are necessary to sell product and then to ship it to you so getting to the point where we had direct connects in our data centers and really there are now network hubs not necessarily data centers that allowed us to take all of our existing applications and many of them are the large third-party applications that I'm sure you folks run as well and turn them into endpoints and we can take the sneakers app and put it directly into AWS and then it can talk back to our order management system and all the other things that are in the flow as endpoints without having to rewrite all that stuff because not all of it needs to scale out the same way so that Direct Connect was a huge success for us and we've now got them in us too in East one in Dublin in Frankfurt in Singapore in Beijing and we'll go live with Tokyo in January and having that infrastructure there and that connectivity there that allows us to leverage all of those regions as and when we need to John also talked about the importance of sponsorship from the highest levels of your company and that has been a huge part of our success so our CEO Mark Parker announced a triple-double strategy which is laid out here and that is two times innovation with our ability to come up with new product that we are then getting into the marketplace very quickly and so that speaks to the product design applications that we have to times speed which takes a normal product life cycle from the time that you finalize the design until it's available in the market from eighteen months down to much smaller than that and two times direct the ability for us to engage with our consumers where they are and things like sneakers app in the Nike app and he has been very specific in each one of our quarterly earnings calls and with our entire company how critical technology is and our digital transformation is to this triple-double strategy and as we talk about scale I just want to give you some numbers from our fiscal year that ended in May our fiscal year runs from June 1st to May 31st so these are the numbers from FY 18 just to give you a sense of the number of products that were due with the number of locations whether they are factories or logistic centers or a retail stores and another statement that came from our CIO that was hugely helpful was to say that we were going to move not just cloud native workloads that we were rewriting ourselves into the cloud and more specifically when any hardware is fully depreciated that hardware refresh will not be a new cardboard boxes full of equipment but rather we will redeploy these applications into the cloud and that confused some of us at first because we're not talking about very cloud native apps and we had to come up with a process to do it and the way that it started was to understand the way these applications talk to each other look at the network traffic and know which apps need to be within 20 milliseconds of each other which need to be within 100 milliseconds and then from that we got a sense of which apps needed to move together and how we could leverage those direct connects to make certain that we could move them successfully and we also had to look at the storage that was required a lot of these applications use NFS to talk to each other and to talk to themselves and understanding those I ops requirements through the EFS service that we use in each of these regions was also key to our success and the first time we did it with the first of these migrations it was a bit scary because not only are these really important applications for our business but these are apps that have production instances they have DR instances they have five or six or sometimes more development instances so we're talking about a big move but to trust that process with the first successful migration and then the second and then the fifth and then the tenth got to the point where now we know the process that we need to use by looking at the data of how these apps talk to each other understanding the compute and storage and networking requirements that they have and then making certain that we have the ability to redeploy them and now we are seeing huge benefits from doing this one of our other strategies is what we call our key cities so we believe that over the next five years 80% of our growth will come from 12 key cities and due to the fact that you know some companies may be said difficult expectations about how quickly things can be delivered and maybe people have an expectation about how quickly things can be delivered now we have to get to the point where our supply chain is present in all 12 of those key cities because we host our warehouse management system in AWS that allows us to more quickly deploy that technology to improve our supply chain speed in those 12 cities without having to order hardware and the other thing that's happened just over the last week is when we hit peak times of the year unexpected things happen when you get to the edge and you see new traffic volumes you know the bottleneck can shift a little bit and having AWS there so we can quickly add capacity or adjusted to these applications that again at first we didn't really expect it would be the ones that we hosted on that platform has been instrumental it has been fantastic because we can respond quickly and we know exactly what we need and help how quickly we can get that additional capacity provision so I'd say getting to that point where you have that senior leadership and that stakeholder stakeholder support established that's important pay attention to network proximity leverage those direct connects understand the way your applications talk to each other and that will guide the way for which need to move together and which can move at a later date and don't forget about the importance of storage and making certain that you've got the I ops that your applications need when you can drop them down that's what usually successful for us and I hope it'll be successful for you too thanks very much [Applause] well thank you Mike that was awesome story it's always great to hear from our customers and and just see how they're able to take advantage of some of the benefits that a DBS provides hi everyone my name is Joe Chun like John I'm also an enterprise strategist I spent time talking to senior executives but I also spend time with our business development teams thinking about ways that we can help accelerate the cloud journey and one of those ways is through our migration acceleration program of which I've had the pleasure of being able to support and participate in so what I'd like to do to close today's presentation was to talk about how AWS is providing prescriptive guidance to you as customers to help with this migration journey and take some of the best practices that John has shared about and as well as Mike and package that up before joining AWS I was the chief architect in group technology officer for Accenture RIT and one of the things that's really important just to reinforce again some of the things that John and Mike said is to have a really ambitious goal we had a goal to be ninety percent in the cloud in three years I'm happy to report that my alma mater has actually exceeded that and the reason why we did that is around innovation it was part of our digital transformation journey John shared a number of different outcomes but they generally kind of resolve to kind of these three areas and I think it's really important as you're starting to socialize this journey because the move to cloud is it's just as much a people and cultural transformation as it is a technical one innovation is simply to me moving from idea and opportunity to delivering customer value and those companies that have the ability to do that more quickly and at scale generally are the ones who are going to be perceived to be more innovative and certainly moving to the cloud does that the other aspect is being able to retire technical debt analysts say that 60 to 70 percent of IT budgets is spent on just keeping the lights on and even then it seems like the lights aren't always staying on they're actually flickering and while the term tuck we trying technical debt may rub some of you the wrong way particularly maybe some of you coders out there we do tend to use this term a little broadly and I do think there's an amazing way that moving to the cloud can help retire technical debt and then finally talking about reliability it's unfortunate I've had too many conversations with CTOs who've had really bad experiences data center outages and as digital services become so core and central to the way business is conducted these things get the attention of boards and CEOs these are not just things they get hidden I was speaking with the infrastructure lead of a retail organization they had a hard down in their data center and they were still recovering several weeks out and while at AWS we say that everything will fail and that's like what Verna Vogel's our CTO likes to say the way that you can recover from those failures is dramatically different and there are ways that we can leverage our availability designs in our infrastructure that can help alleviate a lot of these concerns and with the rise of natural disasters and certainly in the u.s. in the southwest and the East Coast we've had many conversations with customers who are getting really nervous particularly if their backup data centers are just a few kilometers away so what AWS has done is we've tried to package all of our learnings from thousands of customers with migrating hundreds of data set of scale migrations and pulled together what analysts are telling us is the industry's most comprehensive migration program it starts with the methodology packaging up all of these learnings investing and working with the ISV ecosystem as well as some of our own tooling working with partners that we've vetted and actually shared these methodologies with to our own professional services organizations who can act as on-the-ground experts to help guide you to training which is what I can't overemphasize and being able to enable your organization to be able to do these types of migrations and in certain cases you as customers may qualify for investments helped take care of the migration bubble that often arises as you instantiate your infrastructure in in the cloud so we'll go into these into a little bit more detail so how does it start we typically like to start with an assessment john mentioned some of the discovery that you might do in your infrastructure we also like to start with what we call on migration right ease assessment which we'll cover in a few slides as well as starting to get a picture of what the high level opportunity is usually people start to kind of peel back the covers start to replace some of the assumptions with their own data because we have a number of tools where we can do sort of a back of the napkin analysis of the size of opportunity but of course everybody wants to replace it with their data and that's where you start to create a more detailed business case being able to take advantage of lovers of the storage savings opportunities which a lot of people don't realize is actually one of the primary lovers in which you can save on infrastructure cost and then what we like to do because we understand that this is a set of capabilities that many organizations have to deploy which we've organized across these different work streams and investing in the people investing in the operations because it will require a new or different operating model in the cloud to revisiting your security policies oftentimes there's a pretty dramatic impedance mismatch with existing security policies and making sure that you tackle those things head-on is really important to establishing the sort of the muscle to be able to manage this journey and to create that roadmap so what we've done is we've got sort of a standard playbook that we can deploy into your organization's and work with the cloud Co EE to start executing and instantiating this capability the other part is just to make sure that you're breaking this up into logical waves some people do it by business unit others do it by data center and you can kind of rinse and repeat we work with some customers that have that operate as large conglomerates and you may find that it's kind of a distributed process which is great and we have the ability to support and tailor that let's go a little bit into the business case now when we used to talk about migrations a lot of customers would tell us you know you're over indexing on cost what about some of these other dimensions that are important as part of the migration process and while cost savings is one of the levers and it's not uncommon for us to see 30% on average savings when you even in when you take into account the migration cost there is these there are these other dimensions around staff productivity and operational resilience and business agility I'll share one of my own examples to augment some of the examples that you see on the board is when we moved to the cloud and we did a massive lift and shift with the workloads from my old organization we saw a 30% drop in incidents just like for like it was the same application the same database and we simply moved it into AWS a 30 percent reduction we've seen other organizations that see close to a hundred percent reduction just because of the resilience and the architecture and the design that you get with AWS and and it's no surprise to me because I saw some pictures of our our of our facility and it was not as nice and neat as what it probably could have been and then certainly talking about business agility it's really hard and I'm sure all of you guys would agree to drive agenda strictly from a technology perspective they have to align to the business unit and making sure that your business stakeholders are on board and that at the end it's not about serving eyeties interests it's about serving the businesses interests in being able to deliver customer value much more quickly and being able to have these types of digital experiences that are always on highly available and extremely performant I mentioned the migration readiness assessment it's actually a piece of work that I originally contributed to as we were trying to mature our migration acceleration program which is this is our third year in which we've been had a formalized program and what it is is so it's about a one-day workshop where AWS or partners will facilitate a conversation with the leadership team in your organization ideally your CIO and CTO and their direct reports and what we do is we walk through AWS this cloud adoption framework which is simply an organizing framework that talks about not just the technical pieces of the platform operations and security but talking about some of the things that are challenging from a governance perspective a business perspective people perspective and what we do is we have a dialogue to kind of uncover some of the capabilities and really highlight some of the gaps and potential inconsistencies of being able to execute a large-scale migration and what we do is we do a readout I've done many of these I know John has done as well and we give a kind of a readout a scorecard and and while some of my colleagues have told me hey does it really have to be red you know yellow green because people have this like aversion to red we pretty much kind of said no it's it's good we want people to have sort of that reaction of hey let's go close these gaps and well essentially we do is if you look at the previous slide is we shoot those gaps and say okay we want to give you credit for areas that you might have already invested in we also want to obviously help you close those gaps across these different dimensions in areas and it's a great actual change management mechanism as well as you socialize the scorecard across your organization of things that you need to do now one of the things that has happened as we've tried to socialize this and we work with lots of companies is they said you know that migration methodology is great but you know man it seems like we if we don't have the capabilities and we're not that mature it's gonna take a lot of time to put in all of those piece components that you say that we need wouldn't it be great to do something a lot quicker and so what we've done based on some of the work that leading organizations like GE has done is programa ties what we call the 50 and 50 50 applications migrated to the cloud in 50 days and what I love about this is that it sets a pretty ambitious goal it's not like a sandbagging type of exercise and it really can show the organization hey we can do this because I've unfortunately I've spoken too far too many organizations who get stalled in their migration journey they talk about cloud first they have you know said they're gonna do these things and at the end of the day there's just not that much that is migrated and the way that we can kind of do this is one being able to really quickly create that landing zone or as I like to call the virtual data center that is a non-trivial piece of work that we've now systematized and programme' ties so that we can deploy that very quickly it's going to be secure operable and safe but the second linchpin in being able to do this quickly is to be able to leverage Amazon managed services so it is not an MSP in your traditional sense essentially what Amazon is done is said hey how can we take care of some of the heavy lifting on the lower ends of the operational stack logging monitoring and patching but do that in a modern automated way and do that for customers and so what it essentially allows organizations to do is to quickly bootstrap their migration journey it's not a one-way door and in Amazon we'd like to talk about one way in two-way doors in our decision-making process any two-way door you should be able to execute because if it doesn't work out you can just back out of and that's the way that we've designed AMS think of it potentially as a sort of training wheels to say hey we'd love to understand how to be able to run a modern cloud operating model and if I want I can take it back and if I say that's awesome I can keep going and we've even seen some organizations say you know what maybe my traditional workloads I'll run in AMS all of my net new stuff I'll run in my own kind of captive set of accounts with my own operating team it's a powerful change management mechanism when it's executed and for those of you who are feeling stuck I would highly recommend talking to our AWS teams and we can give you a lot more detail on how to execute this kind of exercise and playbook and really potentially bootstrap and get the migration journey going in your organization we have tools we've partnered closely with the ISP ecosystem sean has already covered a number of these at the top so I won't go into too many of these in detail but as you can see across every step of the way we've worked with closely with these ISPs to help you whether it's helping to understand that inventory very few people are willing to bet their careers on the accuracy of their CMDB to helping to generate a business case a company like TSO logic who all just kind of call out will not only take that data and sort of help you sort do the dispositional or Enterprise Agreement actually make recommendations for the right instant size which can really accelerate and add to the business case to a number of other tools that I won't go into too much detail on and the other thing that we've done is in partnering with these ISVs we've made it really easy for our customers to provision these tools and in some cases have pre negotiated the licensing and the fees and making that a really seamless process from a procurement perspective I'll close with talking about our partners I know a lot of organizations say that the biggest issue that they have with being able to move to the cloud is having this lack of talent and we've invested heavily and work closely with all the partners this list continues to grow and we as I mentioned before share every aspect of the methodology we're not here to try to keep this to ourselves and just benefit our professional services organization but to help all of our partners in being able to help you as customers migrate so whether it's helping to instantiate your cloud co e or helping to move with the migration factory some people say you know what I'm not interested in moving my stuff it's something that's going to happen once and so building some muscle around that is not super interesting to me or perhaps it's with helping you do it yourself the the nice thing that I like about this list is that it's not just the largest size in the world that we've partnered with but many boutique companies like flux 7 as an example who really specialize in a devops oriented migration path so with that I'd like to thank you for your time really appreciate the investment with the time that we have remaining and if for those of you that want to stick around we'd love to take some of your questions so what I'd like to ask you to do is walk up to the mic that's on this side of the room and then John myself and and Mike would love to answer some of your questions but enjoy the rest of your day and have a great reinvent thank you very much all they can come sure from the question no I think some people are gonna like I see some people still staying if you don't mind yeah just and if everyone walks out then we'll just move to the side so I heard that you do the 50 day 50 axis migration we did hear from and by the way I'm from Commons okay and believe you what he was Sean from we had seen some of these things that you're shown today but the question that I have for you folks is this right in a 2's sense right most of these companies that are adopting the journey of cloud truly do not have these cloud center of excellence mm-hmm okay and we are one be just getting into that location after so that is a big showstopper right number two is and again Cummins is a hundred-year-old company so we are turning 100 next year so the number of applications and technologies that we have are ready spread out 600 plus technologies and so the question that you have shown about the identification and having an application details sort out it's not going to happen in the timeframe that you're really showing up there yeah so any thoughts any things from your other experiences please yeah so I think there's two questions there there was a question around what do I do if I don't have a co e and then there's a second question of like if I've got this really complex landscape of applications in a 50 and 50 context how do you identify what those applications are great questions so first of all we are pro serve and our partners do have capabilities and best practices to help you stand up that center of excellence I truly believe it's really hard to make that journey without having somebody who's a leader and having people whose full-time job it is to doing the cloud work you know one of the first litmus tests of that I ask of you know when people are saying our cloud journeys not going well is I ask what's your team look like and when I hear that it's like 50% of Joe's time and 10% of John's time and 5% of Mike's time you can guarantee things are not going to move very fast because essentially it means that cloud is a hobby project and I don't know about you I love to play golf and play music but it's like the last thing on my list right so to make kind of one of the terms I say is go professional just go all-in and and many make sure you dedicate the resources to go do that and we can help you with that the second question is around how do you disposition these applications there are a couple different heuristics or rules that you can use you know in Summit and by the way the companies that have executed some of these 50 and 50 migrations are some of the oldest and most kind of like gnarliest enterprise companies that I've ever met and you can go as simple as let's take some kind of non critical workloads use some of the dependency understanding to say hey maybe some of those workloads that stand alone so one one option is to kind of cherry-pick the easiest stuff I've also seen some people say you know what let's not just cherry-pick let's do some a couple of really critical ones because that will really send the signal to the organization so happy to double click that with you but that's kind of the approach that I've seen people take yeah other questions where can we get these slides when you get these slides so these slides will be on the App the reinvent app available is a URL afterwards after the session yes 24 hours and all of the sessions are posted will be posted to YouTube YouTube yeah your own consumption and so you'll be able to share this with you yeah you are alone for the slide whereas well there's a question back here sure hey Chris well yes we did and and I think also initially we probably didn't prioritize that as much as we should have and particularly with some very large third-party applications that are specific to our supply chain that use NFS to talk to other apps and also stuff like printing shipping labels for example that is a big file system with lots and lots and lots of files as images in it and you know when that slowed down to the point where we weren't able to potentially print labels as quickly as we needed to we felt that immediately and so particularly as you get to peak seasons like this one and those volumes really go up that's the thing that if you know we don't have our math right about provisioning enough capacity specifically with AI ops then the apps just don't work and so once we got to the point where we knew to prioritize that and we had formulas that we could be confident in because that led to the writing of arrives provisioned then it it's a thing that you know we we always check for but we're not nearly as concerned about because it's just part of the discipline thankfully question hi my name is cozy Joseph I'm with next hour energy in Florida my question is for Mike I'm curious to know how how large was your team did you have a big migration team and also how much pro serve did you have to do if any how much pro serve did you have to do from AWS to be successful sure thanks for the question initially we had a lot of help from AWS and some of it was just to understand how we could get our networking set the right way particularly we were setting up those direct connects so we'd have internally R audible address space that would be present in the V pcs that would then have to talk back to the applications that we still had on Prem getting that going initially we needed a lot of help and I think probably one of the biggest mistakes that I made early on was not recognizing how much our cloud journey would put a strain on our networking team and how much you need more capacity in the traditional networking sense in order to not only maintain the pace but then also to do the investigation to understand how the apps talk to each other it's make certain that we were moving them correctly just to maintain the infrastructure that we've built so our team is a father-son team we've got my team and told about 400 people and we've got folks in Portland and Amsterdam and in Shanghai and those are kind of beautifully spaced about nine hours apart so we can pass off between the teams but it took us a while to build up you know the the core set of capabilities in each of those teams so now we're at the point when we could just move that work across all three oh yeah that's right 400 now 400 80 yeah so one of the things I'll share is that we do see a life cycle to these cloud center of excellence --is and we have more detailed guidance but what I would say is you know for example the peak of our Mike Lee cloud team including doing some of the migration factory work was around 30 to 40 people but what we typically ask is to start with a you know a tiger team some SWAT team that's dedicated that has some of the personas that John had mentioned earlier use that as their acting fulcrum and then as you start to grow your cloud capabilities and your journeys you'll start to see kind of the specialization maybe some focus people focused on migration some people focus on the clinical cloud platform engineering being able to do the design of the infrastructure and maybe even going so far as being able to provide templates of application architectures particularly if there are new architecture patterns to having a cloud business office that can focus on things like cost management optimization and so there's a number of these kind of functional areas and then you know usually what happens over time and and what normally happens is you end up seeing sort of resources transfer more and more into the cloud center of excellence and and kind of absorbing other functions within the enterprise if that makes sense the CSeries an ephemeral constructs really we know my own journey when we got to a certain timeline the RSC cieariy team I split them in half but more people into re-skill and overtime cloud first cloud native having more teams and skills to be able to micro apps actually unlocks and scales it and I think you end you know with their cloud operating model on Jo slide you might end up with just a small cloud ops team that finding maybe gold am eyes may be continuing to tweak some of the guardrails as you scale out and your teams are far more capable to just build and maintain what they need to one cloud everything but time for one more yep like I'm going to take onto the IOM's question that we had so you plan for the I ops you learned in your migration that you needed more items for the season ability or whatever that is right so at this point do we have fixed I ops for your peak season and that's what we're running at I look at I also the capacity it's like soda is like CPU right I am II need more when I have more traffic going through I'm formula for nancial industry and beer on like Montagnes quarter and there's like peak loads around that so if I needed more I hope so I could pay for that and then I just go back to my normal usage in videos I jobs in order to pay for the PK ops or how are you managing that yeah ETFs is a little tricky and I would definitely say that's where we also got a lot of help initially because you know there's different levels that you can buy sometimes the amount of AI ops that you receive or based on the amount of capacity that you're using so there it takes a little bit to get that tuned correctly but it's been such a critical element of the success of our migration and now it's the point where I mean we're looking at it all the time particularly during these peak periods of the year and it's one of the key parts of our monitoring is just to make certain that you know we're not running out of gas at that layer but I would definitely recommend speaking to AWS getting some expertise from them on how to get EFS configured because it is a little tricky and what I'll close with is that you know some people think the traditional infrastructure roles are gonna disappear right you know the people who are used to racking and stacking servers managing emc storage arrays and doing fibre channel and all that kind of business like that's like gone and I think that's like the farthest thing from the truth because there's still storage in the cloud it's just different you know in the way that your provision it is different but there's got to be somebody in the organization who has to understand the underlying characteristics because no offense to that you know the app folks out there but they generally don't think too much about this stuff and so having your resources learn and skill up on these kinds of concerns I think is really important same goes for networking same goes for servers the list goes on and on and on so I would HIGHLY encourage how you can leverage some of the resources you have in your organization to learn these kinds of characteristics so we'll be able to look at how Europe so fee if you migrated there sorry I will be able to look at the IOM's if you migrated to AWS like the utilisation ops right oh yeah I'm talking about the HPC kind of workload that we run and we run into these kind of issues all the time I don't know yokes what's just about mapping to what the workload needs and you're looking at the storage that's provisioned how many NFS mounts it has you know how hot those things run when the app is is going through its cycles and you know being from financial services you said month and quarter and yeah take a look at those at those Peaks and you know the apps will tell you you just you just got to look okay think yeah sure cool thanks very much thank you guys very much appreciate it thank you

Channel: Amazon Web Services

Views: 11,557

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud, re:Invent 2018, Amazon, AWS re:Invent, Enterprise & Hybrid, ENT205-R1

Id: ABbByVDJjGk

Length: 63min 40sec (3820 seconds)

Published: Mon Dec 03 2018