AWS re:Invent 2016: Enabling Enterprise Migrations: Creating an AWS Landing Zone (ARC314)

so good morning good morning and welcome to one of the last sessions as we invent and we were to thank you for being here it's been a rough week and we're going to try to do in this session is to make it useful for you the session is titled creating a landing zone in AWS for application migrations my name is Cunha form a big liar and I'm representing a team of aw solutions architects and we support our large multinational customers and with me I've got three guest speakers today first one being hanged from Awesome from Philips hangars manager platform and hosting and he's going to provide insight and how Philips is addressing the application migration journey and how they've been building a landing zone secondly we've got Scott Macy Scott may see as the AWS representative for service catalog and then John Steiner and John Steiners my direct colleague and together we support our large enterprises and when we discuss about a large enterprise obviously one key topic that comes up every single time is a topical application migrations application migrations because I want to close my data centers I want to reduce cost or I want to increase my business agility increase my reliability and preferably both of these and the topic of application migration if you put it into a program links back to hard work trademark business days how do I create my target operating model what am I going to do with my partners and actually how am I going to migrate to my existing environment to my AWS environments and the AWS environment that's the topic for today how do I configure more AWS environments so it suits my application needs and that's all referred to as a landing zone so the landing zone is it configured secure environment that suits your Enterprise migration needs based on best practices based on native AWS services and which will allow you to start to iterate from the start to iterate from add your additional components and to customization adjectives party services so we'd like to do in this session get a lot to cover we got a lot to cover in 60 minutes all the slides will be available offline we'll be discussing couple of solutions and we really recommend you try these things out at home we're going to do is to give you an insight is what we believe is a landing zone where we believe are the different steps you need to make in order to create this landing zone and at the same time hand will give the inside in Philips and then we have John and Scott giving further insights into the application migration journey and our end users can use this so how we're going to approach this we're going to approach this for first a couple of chemical iterations that we see when discussing of enterprise customers and I quickly remove into the landing zone itself we started the accounts we configure our network and in our accounts to support application migrations and before launching any services obviously we're going to look at security we're going to look at security first in terms of insight what's happening in my accounts who's doing what how do i configure my log files etc and second part is how am I going to configure matters management how am I going to allow my end use into my environment Philips will describe their journey and then Scott will come on stage and provide how Service Catalog can help to enable this landing zone to empower your end users and we'll end up with John describing the landing zone as part of the enterprise application migration journey so let's dive right in let's start right in and let me give you some perspectives all the things that we see when discussing of enterprises we typically have two type of conversations one conversation is an essential IT departments an essential IT department is responsible for provisioning monitoring and managing my IT infrastructure and therefore we see typically approached as heavy environments where the lines of businesses request our infrastructure get it managed from the lines of business perspective we see the requests we want to move quickly we want to be agile we want to be able to use all of the cool services so we're in the key topic we'll be discussing here is how to balance this control on one hand and the agility one hands and we hope we can convince you that with clouds there's an option to combine this two to combine this two in a sense that the central IT department is providing the hand trails for the lines of business to consume hand rails in terms of providing these configured AWS environments hands rails in terms of what can we provision what are the actual landscapes that the lines of business can provision in the AWS environments and I'm from the line services perspective as much as ourselves as possible self-service enable them to iterate the other thing here is what we see is the move from prescriptive to inspection controls prospective prescriptive controls it's about I'm gonna tell you what you're allowed to do inspection controls is I still we're going to do that to a certain extent but more importantly I'm going to monitor what's happening and responds to the issues I'm seeing and this radio automation comes in so what we believe are the three key guiding principles for defining your enterprise landing zone first one is security obviously as you've heard in the past couple of days Security's job zero but for a landing zone is not a really important argument to start of security in mind and that is it's quite difficult to add security as an afterthought this links back to automation and automation in order to improve your business agility also reduce cost and in a couple of slides we'll see like an example how you can use a simple way of automation to reduce your costs by automatically starting and stopping your compute instances in AWS and then the last one is how can end-users consume this landing zone how can any use your developer or your application migration manager how can they access the AWS environments in a self-service way so let's start the starting point in AWS is an account an account provides you the highest level of segregation and the good news is you can create as many accounts that you'd like accounts are not a scarce resource at the same time recommendation is start simple don't overdue on day one but take into account that you want to have different accounts for cost allocation different lines of businesses segregation different cost allocation second thing is resource ownership you may have a central team providing central services and different accounts you may have different partners providing service on top of your infrastructure different account you may even have different legal entities or consider selling off parts of your businesses different accounts that would allow you if you sell this part of the business and need to hand over your infrastructure it's as simple as handing over your security keys and your billing details and lost one in security and complies Oscillation think about test death on one hand production on one hand interpreting your enterprise you have data classifications in terms of your normal production workloads your business critical loads you may have PCI workloads etc then if you look at the account structure the account structure starts with payer account the payer account is the account which actually pays the AWS bills recommendation is don't use this account to provision any services in this rather create a linked accounts under the payer accounts and the first level of linked accounts we see are the services accounts or central accounts right central accounts can be used to centralize information such as your billing reports such as your logging or your service catalog central portfolios and products and also you can use central accounts to have a read-only account for your auditing make it easy for your auditors never going to move to the actual service accounts the service account which you're going to launch your compute and your storage which you're gonna migrate your applications into as a starting point we see a central account providing central services and then we've got the accounts for test and death production and the specific version for production business critical workloads you may want to replicate is over time for your different lines of businesses and in addition you get your accounts for your digital platform sure IOT your mobility and all the cool stuff you're going to do on AWS and what we see a lot of multinational accounts do they create this overall structure per region per region as this allows them to have the segregation and this allows them to have different legal entities responsible for paying the AWS services now if you've seen the presentation earlier this week about AWS organizations an AWS organizations allows you to easily create accounts you can use API to create accounts but also to manage your accounts top down this presented I think last Wednesday it's available in limited preview and if you're planning to lounge and manage a large number of accounts I highly recommend to look into AWS organizations the interesting thing of AWS organizations is she can apply policies top down so you can group your various accounts you can group accounts for your testing your development and production and impose a set of policies which are moved top down using AWS organizations so now we've got our accounts another thing what we're going to do is to create our networking within those accounts networking in those accounts your VPC your virtual private clouds you own data center or an AWS an account lives within an SRE a vbc listed in an account you can create multiple V pcs what in that counts but let you I shoot you if you have different V pcs won't create friends account structures so typical we see is one vbc per account you may want to deviate for that if you want to do some quick development or quick testing a VPC has a longer lifetime a VPC once created has the IP space or your site arranged remains allocated to your V PC the recommendation here is choose a large V PC typically like a slash 16 got lots of room to grow and also choose an IP range which does not overlap with one if your existing order IP ranges so you can easily connect them afterwards same thing applies in certain net design so the subnets be created within your V PC create a limited number of subnets because it allows you maximum flexibility security use access control lists and access control this can act upon the full V PC or on the subnet an access control list is like a stateless firewalls and in reality we see customers use or not use them because most commonly security groups are being used security groups act upon the actual easy two instances that you can group scalable recommendation is use security groups much as possible logging a monitoring will come back to that lot your traffic to get inside and what's happening what in AWS get inside in your overall networking and as we're discussing application migration you want to connect you on-premises environments to your AWS environment you can start a VPN connectivity and over time with traffic grows move to Direct Connect Direct Connect connect your on-premises environment to your AWS environment it's available in 1 or 10 gigabit per second connections as partners available who can offer you slices of that and once the Direct Connect is in place which you can do you create virtual interfaces you create virtual interfaces that connect your on-premises environment to one of your V pcs you can connect it to multiple V pcs and I serve everything in aw recommendation is use a backup use a backup first of all with VPN or cherry on the cake use a secondary Direct Connect location so now we've got multiple V pcs in our accounts and we briefly touched upon the central services so what do we see as best practices have a central service GPC living within the central service accounts that you can use for services that you will be making available to everybody think about security tooling think about Lauren think about entered authentication and then what you're going to do is you're going to have this central V PC and you connect the surrounding V PC is using VPN it's not before launching any of our services or in our network let's look at security let's look at security from two different angles one angle is what is actually happening what in my accounts what's happening what in my network what's happening with my users and the second domain is the access management let's start to the insight into what's happening in my account so if we double click on the inside is happening in my account first one is I want to understand who is doing what what enable yes who is doing what would an AWS and what effect does it have on my services and I perhaps you more importantly what's happening into my services is that compliance with my enterprise security or compliance rules second thing I'd like to do is I'd like to understand what's actually happening in my network what is happening in my network in terms of the traffic flowing in and out and then lastly overall I'm going to collect a large number of locks you know to be able to understand what is happening and I'll show you an example in a second that's available to you in order for you to start looking into your log files and doing the initial analysis so the first one who's doing what in my accounts who's doing what in my account district loud trailer comes in clouds will log through API calls and the API calls can be originating from a person on the console can be originated from CLI or originated from direct API calls these are locked and remember we showed you earlier the central account logging the lot in a central st bucket as a number of partner solutions available that you can use to do the analysis and also you can use this to monitor and troubleshoot what's happening so cloud really gives you insight who is doing what on my head of your services and the second thing I'd like to understand is what was the effect of that action what is the effect of the action or is originating API call or my aid of your services a dubious comfort provides you inside on that it provides you insight in the status of your actual AWS services so it's a resource inventory it's a change lock and also it provides you change notifications or the changes that are happening on my AWS resources on top of configures config rules and config rules is looking as these changes and is assessing those changes against your company rules is assessing those changes do I have a compliance or a non-compliant change here another change is non-compliance is when you automated action I can take as an example I do not want my instances to be open to the white world on for 10-20 tiers of people can SSH into my might into my environment if I detect an instance is open to the well at the white world what I'm going to do is notification being sent and I'm going to remove or 22 access never looking at networking so we just we discussed the AWS and who I am or the API snow let's look at the networking what's happening in my network if you enable VP flow log enable it on a V PC or subnet level and VBP Froelich is going to do is going to lock the metadata of your networking traffic it's going to load the metadata network traffic the source IP address the destination or fear the rest and what is packets accepted or rejected so actually is a good way to check if you configured your security groups in the right way or not you can use CPC flow logs logs are being centralized and can use them to generate alarms for example you can create an alarm when an instance is having an excess amount of traffic on it so now we've discussed a number of services and we have collected and discussed a number of logs so what can we do with all these log files we discuss flour trail whiskers Phoebe flow logs and you probably have log files coming from your ec2 instances we've recently made a solution available it's available AWS answers the link on the slides and what it allows you to deal with the single click it allows you to install this solution and what the solution is doing it's collecting these logs it's transforming these locks and it's making it available to you in Amazon and Amazon Elastic search they can use it to detect any ill irregularities in your raid OBS environment and the last topic we often see with respect to security coming up is how am I going to manage my computer how am I going to manage my computer in a sense what starting point do I use next we there's a variety of options here there's a variety of options in terms of how I'm gonna manage my computer first one being you can import your own virtual machines into the AWS environments you want hardened images you'd like to import second one is you can also use a.m. eyes from the marketplace we have an example of here the CIS image security image the chicken years and used as your starting point for your computer or use any of the a.m. eyes Amazon makes available customize it to your needs and then create your own image and you start from that point onwards so now we discussed the inside and what's happening in my environment by the security let's now move to the access management part as most of the access management part and let's see how we can control who is allowed to do what in my AWS environment and this what identity and access management comes in identity and access management is a service that allows you to control who is doing what's on my AWS environment it's quite similar to what you would have in your on-premises environment in terms of all based access difference maybe this is extremely granular you can have an application manager John and John is allowed to start and stop instances during weekdays 9:00 and 5:00 if the request is coming from my corporate IP range and if the instances are March of development so that's a level of granularity that you can provide using I am and the access policies with respect to access policies we have a set of managed policies manage policies for example access to ec2 or access to Service Catalog you can create your own policies or we have made available a set of policies for specific job functions like a database administrator we see a lot of enterprises view as they connect I am the integrator I am with the run Active Directory and they use this setup in order to manage access to AWS let's first dive into the access policies let's firstly look at the access policies and see what are best practices here best practices are two things one is lease privilege start as low as possible and the second one is segregate duties as much as possible seven gages as much as possible on top of the slides you see an I am master who's allowed to create policies and you see second one I am manager is able to assign policies why would you like to do that well you'd like to do that because now there's not a single person that can assign his or herself admin policy admin rights the different access policies for architects administrators application owners etc and once you create these access policies and creedy's walls in I am what you can do is he can connect your existing Active Directory to AWS and the way it works that you pretty simple the way it works is you create these walls and you map ad groups to these roles so you map ad groups to the worlds and AWS and that allows everybody who's part of the ad group to go to AWS and assume this role and perform the actions that this wall is allowing him or herself to do and we're discussing here multiple accounts and I'd like to show you the solution we've recently made available again on AWS answers which is allowing you to ease the process of Federation with respect to multiple accounts it's a cross account manager and across Account Manager allows you to have a master account create a set of roles and making sure that these policies can be assigned in your accounts which would like to be part of this solution it was a session earlier this week security to your for you can find on YouTube and it provides a deep dive and it's also a demonstration and at the same time you see the link on this slide I can just use the leg and create a Polock create a solution by yourself this the first part of the presentation in terms of really an overview what is my landing zone in terms of the accounts the VP sees and my identity and access management and my security and I would like to get the the were Hank will give the view for Philips Thank You Khun my name is Hank Olson I work for Philips Enterprise IT [Music] I have to put some slides on she yes there we are and I'm going to explain on how we in fact set up our account structures and how we work and why we do it at this moment we have Philips is has about 400 sites worldwide and about on 100 of them 100 plus we still have local computer facilities or storage and still pretty significant some of them are very small my broom closet some of them are very big still so there's still a lot of service in there about 2500 and if the contracts on our incumbent suppliers we still have very high cost of a fixed fee service management fees and all those kind of stuff that's all India is absolutely not consumable also the infrastructure we have over there as we are an old company there are 125 years old now the services are adults because we did not have them at that moment but we have quite some old stuff everywhere so and that is end of life and of support and also the moment you'll get stuck over there and you have a kind of situation which is not really well maintainable and at the end there are no insensitive of incentives in the contracts also we have to increment providers to clean up 2d come to modernize and to make our next steps how are they organized and what we did is we contracted a party to in fact really help us with cleanup because we do it completely out sourced so 30 percent of what we think of all those stuff all stuff will go into decommissioning 42 percent in to AWS Amazon Web Services and 25 percent they'll call in a local compute darkroom operated that's we have standard solution for that I think lost Wednesday we hear that there is also an edifice coming from from is available for AWS maybe we have to use that as well so that's maybe we have to redesign maybe in the program but we will look into that and then it's always a kind of leftover this will go into the data center so we have a hybrid solution over here on how we will think that we can get the whole stuff in fact legacy into the new environments now why we do that because we really want to go into cloud cloud first we have to move in fact from and the picture you see over there is not a Phillip data center - yes to be sure you really want to call into an always-on because the servers are currently not always on they are very often off like if you have for example Facebook LinkedIn Netflix and you have all those kind of service if they are offline then you're in a newspaper but we accept and I think in many companies we accept is that our SP system is out for an hour or that you have to break down those kind of things and that's not acceptable anymore because you must have continues of service as well it's more always-on that's absolutely immersed we will go into self provisioning so Scott will tell a bit more on Service Catalog as well that is what we will do consumer driven and we really want to work with standard products so no customizations any more scalable resources and really pay for what we use no fixed fees and contracts for service management for account teams and all those kind of things please stop there then so we have a completely different model therefore we created a landing zone and it's a landing zone you see here three stacks the one on the left is the legacy that's in fact what we do Kirti that's what we do today then you have in the middle that's our approach for the landing song for the legacy stuff so that we will do a technology refresh in fact from our old data centers it's our everywhere around the world into AWS and then especially on the layers of fertile machines herbs and turrets we will move that into an Amazon or in a datacenter in the box but that's in fact what we will do in fact and we keep the same processes in place for application management am a Spartan stands for application maintenance and support as support improvements in fact our applications for instantly and then we have a menacing partner who is in fact running their IT ruining the infrastructure for AWS that's in fact the column where we would like to land our legacy applications but that's not the end state because you will know nothing in the legacy in the middle column will be optimized we will not optimize applications it's far too expensive but we really wanted those applications is that they move away that they will phase out that the dekum that they die that's in fact what the purpose over there so we're not going to invest in there that we have to cut them off the local sites to in fact clean up get rid of the local data centers and have a quite a youth business case over them this is absolutely significant but the end state is where I really want to have our standard new applications in and this will be differently organized there you also and see that we have less partners now AMS partner one of the system integrators which is also here at the event they've all in fact do more than just AMS they will not only manage the application firm to me but also technically and it will also menace in fact the infrastructure based on AWS es and of course for all three of them we have a network provider in them that's how we will do that to enable that we developed C array cloud reference architecture yep here you see a very high level of the C array it's in fact based on our enterprise contract we have a root account of course so that's one time use and then what we did is we create and that's what we keep on doing as you create multiple payer accounts you have one payer account in fact for IT Global Services does the department I work for that's where we have our huge systems for enterprise users but next to that we have markets we have about 17 markets and we have lots of business units and the rule within Philips is that you have to pay in your own users in fact if you want to use some in AWS or anything in IT you will have to cut your own invoice so that we have separate they'll run up at the end into 3050 payer accounts we will have globally and for every payer account you can spin up your length accounts you can do this for your backups you can do for your resources and other functions which you won't have to indent and essential over here is that you can link in partners so you can link importance like partner one part a tool or even other partners you can have local partners in in a market for champ lemarchal USA or the market in the Benelux or in Germany or in Japan or Australia it's all possible we can also have global partners who do that and those partners create their own account where they have the management tooling in and the only thing they do is their current recurrent them access into that account into the resource account and they are the only one who have access we don't have access because I'm not responsible for managing those systems they are responsible and I want to avoid that any one of Phillips has access into their account you scan morning to morning to offer cost control and then below that their functional accounts in those functional accounts we are set up systems like Authenticator reverse proxy effect for two-factor authentication for access security Active Directory is in there we have a twist built in VF a system what you call is called one this is our authentication layers and of course we have virus scanning intrusion detection all those kind of stuff in there and very essential is central logging so we lock every activity over there so we know always what is happening it will feed that in our security systems as well they have a shared central auditing account over there and what we also want to do is a shared central intellectual property accounts because you see that you have multiple accounts of multiple partners where we work with that we want to share in fact all the scripts they have developed and shared services so that they can add up up in attending a Service Catalog we have to complete this with networking because you can ever create all gtex you can ever create set up an aide of yours but if you are not connected into this then you cannot use it of course but essential here is and that is the Philips started this policy already in 2011 we have an internet centric policy meaning that more than 75% of all our sites are internet facing so there are all internet connected so we moved away a lot from MPLS already but we still have about 25% of all our sites on MPLS the dogs 25% on MPLS is about 60% of our network hosting so that is significant so we want to enforce more internet centric uses we really want to get rid of MPLS that also means that we must have more and more applications in a cloud environment by a user traffic it's mainly Internet patient so we have a direct connect in there for machine to machine traffic for example for into our data centers and we will also have always have some sites on MPLS that we really want to limit that and of course we will connect also an API based in this our SAS crowd where that is required so this is of course a very high level set up on how we do it within Phillips and this is not complete yet we are still building it and one of the things we are called to build over here is cell service catalog Scott will tell you more about service catalog thank you Scott Macy and I am the product manager in charge of Service Catalog and I'll walk you through kind of what we're hearing from customers such as Hank from Philips and others about kind of what they're looking for from that next step on the landing zone and kind of how access management for users should be controlled so next one so I wanted to kind of quickly walk through kind of that what we're hearing from the organization with different levels so at the top of the organization they're looking for standardization control visibility all the different components of kind of IT kind of centralization but then from the bottom level we're looking at kind of hearing from customers looking for kind of that self service that agility they want to go fast but they want essentially also that balance they want that kind of control standardization templating how do we accomplish that and what are we looking for so essentially customers want to define those resources they want to find those landscapes they want to find those patterns and how software and application that have played and they want to employ ploy the kind of the mantra of a you know prove once and deploy many and make sure that they get that kind of reusability of the standardization so they can take those resources and apply them across the organization and kind of get those savings those efficiencies and then they want that self service of deployment but also making sure that it meets their standardization needs meets their kind of encryption needs or their security needs and kind of give that self assurance and that kind of confidence and then there's they kind of the pieces you've got this down standardized catalog of services and templates and pieces in addition to kind of allowing the self service they want to have that automation they want to employ that into their development pipelines or kind of into their processes so what is service catalog and how does that accomplish that so a diverse service catalog allows organizations to manage a private catalog of essentially templates standardized products that they then can give users access to in service catalog and then service catalog itself has a second proxying method to assume another role to call downstream so those users in general don't have access to the rest of the AWS services but the product itself has the ability to launch into those services and call easy to and do the other aspects but only in the methods defined in that template and then that allows organizations to essentially balance on once that standardization but also allow the customers and their internal employees to be able to come in and quickly deploy something on their own and manage that agility so under the covers how does it work area so on the administrator interaction side so what is a product in service catalog a product and service catalog is a version of a cloud formation template so essentially they can define in that you know gonna have CloudFormation template each of the different pieces of the infrastructure that is allowed they can hard-code parameters for where they don't allow changes and then they can parameterize other parameters to allow essentially about valued list of allowable values and allow that essentially to become extensible so on the administrator interaction side what does an administrator do essentially on in Service Catalog administrator you can have separation of roles you have a landscape architect or a DevOps pipeline essentially to develop and author templates and those standardizations get those certified by your central IT or security teams to make sure that they meet your standardization upload those into service catalog as a product then you can start to group those products native a catalog of products and group those into what we call portfolios which is a simple folder construct typically we see from organizations that they like to group these by I mean the functional units application teams environment levels or all the above and then they're assigning the users and roles that have access to those and those are the only role roles that will actually be able to launch from Service Catalog in that portfolio the other aspects is you can actually put constraints on each of these kind of portfolios to determine which use in one team you might want to restrict a little bit more of the aspect or in one environment you want to actually restrict some of those settings and current configurations and then the other powerful aspects of Service Catalog is being able to tag at the portfolio or their product level to ensure that when launches come from that portfolio they have all those standardized tags that govern its level that the central I team's looking for for that you know tagging consistency across the organization then the other aspect is that they can share it across accounts to grab that standardization across from that central IT from that central service catalog account then from the user side cloud consumer comes in deserves catalog they can browse the products that their administrator has given them access to but that's all they can browse they can see those they can then self-service deploy those they can select the version that they want to deploy they can then provision the product by providing the parameters and setting the belt allowable values that they can set and then they kick off that launch on their own and then once that deployment has happened they can have notifications and then they get the outputs back that were defined in the template that the administrator wants them to have access to whether that's kind of the SSH link into the ec2 instance or other aspects so what is kind of been happening in Service Catalog this year so over this year we have developed a full set of ap is that we allow all of the features in service catalogs UI to be available at via API and we've moved our whole console onto that API set so there's consistency between the API set and the UI layer so that no matter how you automate or aspect all of those cloud trail logs all those actions all the supporting features are available for you to integrate into your tool sets whether it's embedding into something along a kind of an ITIL front end or whether that's something from a homegrown front end that you've built and then there's the aspect of orchestration and automation then tooling that you can actually do to actually make your job easier and kind of take pieces out of the pipeline and build a DevOps pipeline for products or to automate into your Jenkins scripts there are other types of kind of orchestration pipelines and I wanted to hand it now back over to Koon Bigler who's gonna kind of walk you through some of the cool things that his team is doing across accounts globally yes oh thank you Scott so I think with respect to Service Catalog we should like three key things that you can do so the first one is like Scott was highlight see user generated products so you probably will have people in your organization the fast forward as a developer as a people that really really understand a to be on a deep level and at what they can do they can start to create a products and these products now are not confined to their own small group what it can do is they can put these products forwards they can go to a process of approval and then it can be made available in their various portfolios so in order your enterprise users can consume those second thing is administrative products administrative products in terms of thing about reporting think about managing your portfolios and think about having people giving people access to the various portfolios but also administrative products in terms of I'd like to give somebody access for two hours like elevated access into the AWS environment because he or she needs to do something which does not belong to the original world a person has assumes so that can be an administrative product and then when the administrator launch of the products this user gets elevated access and after a couple of hours the elevated access can be removed automatically and the last one is and I want to zoom on this one a little bit is you can think of micro services acting on your launch products wonder functions which act upon your launch products and which perform actions in order to reduce your cost increase your agility let's take a specific example here an example is we just recently made available an ec2 instance scheduler starting point is is really easy for you to consume you'll get a link over here and the template will configure all of the services that you see on this slide and what it does it gives you the ability to tak your instances with a schedule and the insert actor schedule and then there's a lambda function which runs every five minutes and based on the tax schedule that perform the action to start or stop your instance let's take an example we've got Becky over here Becky wants to migrate an application and she wants to test a three-tier application stack it's what she's going to do is she's going to use her corporate credentials log into AWS log into aw Service Catalog and then she gets this view presented and this year was showing her portfolio and the products that are made available to hurled in this portfolio Becky does not have any large products you see at the bottom of the slides however she's got a couple of products she can choose from but simple products what you're going to do is you're gonna lounge a three-tier application stack what's happening right now is she starts to lounge as part of the lounge process the first question that Becky is being asked is you need to provide a couple of parameters and the parameters of Becky needs to provide other parameters yet the administrators have made available in the CloudFormation template so the specific parameters were interested over here is the parameters at the top the prevalence at the top are do you want to impose a schedule on your products do you want imposes schedule on your product to have your instances automatically start and stop based on the schedule now Becky is based in Europe it's development she works 86 so she provides the schedule and now the schedule is being added to the product as a tack so once the products have been lounged she'd attacks for the button and a schedule over here and Jaison format the schedule between Monday and Friday between 8 & 6 and I was happening is the lambda function but pick this up and we'll perform these actions when Becky comes in in the early morning 8 o'clock she gets a coffee and the instance started when she goes home with six o'clock everything will be shut down automatically so think about a cost reduction of you so if you look at the entrance flow how does this work so again combining Scott's slides you've got Becky coming in at the beginning she launches serves cattle lot and she browsed the products during the provisioning process she populates the parameters that we made available to her and now the products being lounged this one important point like to highlight to you as well which is you've got the ability to use some dynamic parameters within yourselves catalog how can you do that what you can do you can use custom resources you see the example in the middle inject dynamic parameters for example based on some parameters you define you want to select a specific ami but Becky can lunch lunch products scheduling function I think also about the other function she can automate think about automated backups think about removal of unused EBS volumes etc etc so now what I've tried to do is to give you like really two high-level quick view of a landing zone and I would like to hand over to John and he's are gonna put it in perspective of an application migration journey and see where we go from there thanks again there we go that was everybody last day on this last session almost last presenter hope you're doing well I hope you had a great week it seems it was a fantastic show so what we're gonna try to do here we've talked about creating a landing zone and all the fantastic aspects that can be stood up in an incredibly fast fashion right this is all about getting things rolling it's really just you can't you can't paint the Mona Lisa in a day and so sometimes people have to practice the Mona Lisa a few times before they finally have created it so the the whole landing zone concept is around that right get things moving get things into the cloud learn get some stick time because without it it's all theory and we all know what happens to a bunch of theoretical concepts so we're gonna go to right now are some high-level methodologies and thought processes around migrating apps and also operating and optimizing probably three items into themselves that could take a day's worth of lectures but we're gonna put them into about 12 minutes and 35 seconds and try to give you some concepts and ideas of things to do after you get these leggings that stood up and maybe even get you through some of the existing migration components you're working on so the first thing after you have your technology built your your infrastructure in a cloud infrastructure in a cloud environment is to think about rationalizing your portfolio right this this is even one step above the the six hours or five hours or 12 hours or whatever maybe if you've heard recently we host refactor we architect think about it a much higher level and we've broken it out into commodity table stakes and differentiators the commodity is gonna more than likely make up about 60% of your portfolio these are the apps that you would commonly think about lifting and shifting these are the apps that are going to in the environment that we're gonna be talking about soon that is essentially an extension of your existing data center if you're anything more than a 10 or 15 year old enterprise you're more than likely gonna have a pile of these we talk about table stakes about 25% of the applications you may vary but these are the things that we're gonna do a little more to we're going to potentially pick it up move it into the cloud maybe we're going to put RDS in place instead of our existing databases maybe we're gonna put auto-scaling in place because these are business critical applications maybe we're gonna have load balancers in place probably going to drop it into availability zones instead of just lifting and shifting into one these are very important but they have a low rate of change right they typically tend to stay the same because they're kind of your production applications and finally differentiators the differentiators of the cloud native apps these are the things that you're going to be looking at and saying my developers want to build the next generation of X right they want to revolutionize this industry we need to find a way to accommodate them in addition to this traditional infrastructure that we're gonna have to move older applications into so how do I do all that right it's the interesting perspective here is table six and differentiators tend to make up a much higher percentage of your overall spend portfolio so there is more value in them but they also take more time and they're a little more expensive to do and then finally we're gonna talk about the operating model right because operating models need to change as application migration changes right so the traditional three-tier or I should say red yellow green light type of model for operations doesn't work so well in my next generation application world probably doesn't resonate when they need for it so going into the migration journey itself you know first and foremost we've already spoken about is is rationalizing your portfolio what is in there and how does this start to break out right so we gave you a high-level points for rationalization now we begin to think about what do i riho s' what do i refactor what do I read our context alright so on and so forth what so every what so I get rid of and that kind of breaks into a two-fold journey initially at least right and I we like to refer to it as either the brown field or the green filtering the brown field journey is the classic lift and shift use case right some things that are very important is making sure you have business I almost looking at why this is something that's religion shift and then maybe why it shouldn't be moved into more of a cloud native environment so absolutely absolutely a reason for it but make sure you have an analyst taking a look at that make sure you have pipeline teams working on the candidates the landing zone we've talked about creating and then create patterns once you move something let's say a lamp stack I document it make sure it's in place make sure the next time someone comes upon an application that's similar they're doing the exact same thing make it so that the innate to bring your kid in on bring your kid to school day and they could pick up on these patterns and potentially migrate an application for you and then your existing operations are gonna stay more or less the same right we just basically set up a slash 16 in the cloud that could be a data center in my parking lot it just happens to be you know living in Virginia um so if we're not moving much about the application let's operate it like we did in the past because it gets into a lot of time and money and we can't expect to retrain people that are doing you know NOC work for the last 30 years to suddenly understand cloud native applications know how to how to support them so there's read books in place you know there's run books maybe will stay pretty similar on the great field side however all right we're looking at these new applications that when we put in we're trying to change the way our company is doing business the landing zone is probably gonna be different it might not be a slash 16 or a slash 19 right I might be firing off a bunch of slash 28 release there's all kinds of different ways I may be doing it but the model needs to meet your business requirements and those are probably going to be different for the new applications you're rolling out it doesn't make them any less or more important but make sure you treat them accordingly because treating everything like a big bundle is a mistake right and the operating levers are also going to change a couple slides from I will get into operating levers but most certainly the way I take a look at a self-healing application living on self-healing infrastructure that's distributed across a global footprint is probably going to be a little different than the way I've been looking at my three-tier you know database server and working with in the past and ultimately keep in mind that the Greenfield has greenfield improvements are made as you put innovation into this new world do everything possible to roll it into the brownfield right you're actually building the greenfield of the future in brownfield also so the next time something comes up as an operon fill opportunity maybe there's a capability that's been rolled into it from Greenfield the NAM makes perfect sense right so maybe we can put it into the traditional architecture because the end state is what you know we're referring to here is the future state and it's gonna be combination of both sides of it because it's probably gonna be a while before you get all the legacy out of your environment it's gonna be a while before you read our connect all of your applications this isn't for everybody of course some some folks have done it quite well but a lot of big organizations take a little time to do that right and your future operating model probably needs to account for both of this all right I'm currently referring to this future state we might call it Orange field very Orangeville mostly orange field you got that reference maybe so one thing we've also learned when we're talking to customers and working with them is that waterfall does not work when it comes to migrating applications priorities kick in value goes down the reason you're doing it cost savings goes away because instead of moving something in two weeks or three weeks I'm moving it in two months or three months and that's not how a lift and shift or a basic refactor weari platform should work so this is an example obviously you've got a program running within within your sprint model if you take a look at your traditional engineers and the folks that are running the environment today in on-premise those are probably folks are gonna doing the deploying the landing zone extending integrating and managing the landing zone all right this is central IT these are the folks that have a vested interest in making sure that the company is safe that nothing is being put at risk you know and once they figure that the developers taking off a million miles an hour we have the control arm which is internal IT trying to say hey hey let's be careful so these are the folks that really need to take a look at what the the data center of the future is going to look like but what needs to look like today I spoke briefly about the migration business case if we're trying to cost out we should be moving applications there to save us in this money the fastest right if we're trying to innovate we should be looking at where we can get the most bang bang for the buck and an innovative model there's gonna be an ongoing discovery if you're large or especially you're always going to be discovery mode so there should always be a sprint team doing discovery getting out in front and determining the rationalization for the three components we spoke of earlier as well as what type of migration mod are getting put in place pipeline generation is really important I betcha if I say who in this room has gone through a p2v virtualization effort sometime in the last five years probably everyone would raise the hand and those of you they've been through large-scale ones to know that one of the number one problems is pipeline alright we're ready to move 50 ops this week we have three and it slows everything down so having a small group of team I mean I would argue a sprint team I have a scrum nut that's doing nothing but generating pipeline and keeping that cute fool so once we get optimized and we start moving with these patterns in a repeatable manner we actually have a pipeline we can keep pulling from because otherwise that's again how these things could extend it over years and years instead of months and finally we have the greenfield piece I was referring to earlier it's got his own discovery it's got its own environment which I'm calling innovation alright so the innovation is my new platform this is the thing that's taking advantage of things like lambda and Kinesis and all of the wonderful things that you've heard about released this week and the greenfield migrations is more than likely being done by by application teams and folks that are building the next generation of application so how do we how do we actually run these right it's important to think about the fact that when I'm doing mass migration I'm gonna have certain outcomes right and those outcomes can't be skewed with the the types of outcomes I'm going to have when I'm doing something more advanced so that's migration some folks might say I hate it some folks might say we love it you might have gotten a million different opinions on it but the point is there's probably an opportunity for it in your organization for the right reason if I need to close five data centers next year mass migration is a darn good use case for it right if I need to save a bunch of money this year and we pulled we told the Board of Directors we need to save some money mass migration is awesome if I don't have the funding or the cash tomorrow modify my operating model the future I should be thinking about keeping things more in a mass migration model however when we start thinking about Reap platforming and refactoring right there's a little of maturity involved and our operations model starts to change I mentioned possibly moving to things like RTS well do we manage it like we do on premise so the databases know do we have to account for how we manage that in the cloud yes we did all right so we have to start to change and evolve our operating platform and then ultimately we get to this final stage of maturity as I mention these could all happen simultaneously but which is RER contect and when we architect threats where we get the server's compute that's where we disrupt the technology industry right that's where we get the maximum that we get cloud native applications that can do everything the cloud offers to you in each one of these Heather Heather Merritt but almost keep in mind that increasing effort is going to have increasing return and I'm going to get much faster return on the left and we get much longer-term return on the right these are all factors to be thinking about as you're going to your migration strategy and looking at it as a plumped sum of applications or servers in environment could be a mistake so finally just looking at the operations model itself and you know who does what in these different modes so for example the one thing I want to mention is that especially in the beginning you don't have to tap this DevOps perfect world migration day one all right you probably want to get there but but day one I talked about getting some stick time let's get some stick time right your business goals may be to save money or to close data centers and therefore automation may have to be a bit minimal we want to have some automation where we can we don't just have the time and money right and the final piece which I was referring to earlier as traditional support models can really dilute the value ie red green yellow knock people supporting next generation applications right but that's not to say that they can't get there but their methodology their process their run books are mostly not going to function so what you start to see as you mature as you move to this next generation of cloud as you can have a distribution of responsibilities begin to shift right in the beginning in a lift and shift model and a mass migration traditional ops is still doing a lot of the stuff they've been doing in the past but as you move into replac forming and refactoring in hybrid operations and finally re architecting what you're also going to see is that the level of effort put in by the ops team traditional ops team is going to begin to diminish and the level of responsibility by the application teams in your next generation cloth teams is going to increase and so these are all things to consider as you're looking at your migration journey on your landing platforms because differentiating and segregating is going to be key to success and understanding the value and success that you get from these and so finally you know we've spoken across the entire platform here and we've talked about landing zones having direct connect networking we've discussed service console and all the tools and components around it as well as application migration from a methodology perspective and an Operations and potentially optimization perspective it's a lot of stuff to say and do and in about 59 minutes and 40 seconds but we've got through it and hopefully you've learned content from this and enjoyed what we've presented I wanted to go through just a component of the available resources keep in mind these presentations will be available online the available resources for Lanie's owner in place here there's a lot of great links I want to call out number 3 the networking one talking about PCI landing zones honestly you can go out to the Quick Start website and in about 12 minutes you can deploy a fully PCI compliant VPC with logging yet that's three buckets already created you've got flow logs going into it you have got cloud trail going into it I mean it's a really great way to understand exactly what's going on behind the scenes without you doing all the legwork all these other links are actually beneficial components that will allow you do more and more with the environment that's really worth taking a look at that another group of resources that will be available to you as I mentioned you can go out and pretty easily click a few links and stand this stuff up and it's pretty solid right I mean you're obviously gonna want to change you're gonna get that orange then I talked about orange orange linings in some day but day 1 this is a heck of a good start and it finally just related sessions with with regards to this session probably not too many of those are gonna attend at this point but you may want to go back and review what you get home and take a look at the session so thank you very much for your time thanks for sticking around for an extra day than hear us talk and have a safe and healthy trip home and weekend

Channel: Amazon Web Services

Views: 4,674

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud, AWS re:Invent 2016, aws reinvent, reinvent2016, aws, cloud, amazon web services, aws cloud, re:Invent, Architecture, ARC314, Koen Biggelaar, Advanced (300 Level)

Id: nXdgc1GREiU

Length: 61min 12sec (3672 seconds)

Published: Fri Dec 02 2016