AWS re:Invent 2019: [REPEAT 1] Introduction to DevOps on AWS (DOP209-R1)

I'm Sebastian born and raised in Brussels speaking French usually maybe you heard that already slight touch of French accent her and I would be John during this session with by Jonathan my side my name is Jonathan I manage some of our idea related teams like cloud 9 and will later give you a nice demo about an interesting capability we launched to help you debug applications a great demo of a new feature that we just released last week so I'm working in software industry since the last 25 years and I so different things when I was working as consulting as consultant I work with with banks in Europe small countries in Europe with lot of banks ISO big public institution where the development team was not talking to the operation team to different teams reporting to different manager even sitting in different buildings never talking to each other and sometimes as a consultant I say hey guys you should talk to together and I organize meetings I start to talk to each other and they start to understand each other programs and after the meeting that the tank me is saying hey thank you finally we met these guys and we understand why it's important to do that for the deployment or we understand the small change to change the souls things we can change in our code to make operation easier I also work as a consultant for Bank and they were deploying into production twice per year every six month and of course it was a big bank weekend where everybody has to come back and work for the huntie for the entire weekend a lot of change going into production in one shot and as a developer if I miss that release window it means my code will be delayed of production by six months so talk about agility in this type of environment today organization wants to be more agile they wants to be more productive and that's why they are merging development and operation to create what we call DevOps and once that's what we are going to talk about for for the next hour so DevOps is not a project I'm not going to sell you a product or service develops it's really a culture here and in this talk we are going to show you how you can grow your team from one person team you and your laptop may be deploying manually to the cloud to a team of hundreds of developer that are deploying thousands of times per day to the cloud so when you start a new project it's day one imagine it's always day one you heard that already and on day one typically you're on your laptop and you're writing code and you prototype in your IDE and it's that work so at some point you want to deploy your application to a production environment and you heard about public cloud you heard about AWS and you choose to deploy on AWS and deploying to the public cloud gives you a couple of advantage one of them is the agility you are confident that if you need more machine to make a test to experiment written UAT for example you will get that extra capacity very easily it would not be necessary to call your favorite hardware vendor and wait for a few weeks to receive additional hardware put the hardware in to relax put the network cables install the operating system install the patch monitoring tools the security package whatever and then finally get your server know in public cloud you can just open the address console start an easy-to instance or start 100 the ec2 instance and start to experiment directly it will also give you the elasticity that you might require if your project is a very successful the elasticity is the ability to give you more compute capacity more storage more memory depending on the workload of your application so you can start very small like one or two server and then grow as your business is growing as your application is growing grow you infrastructure automatically you are also confident that the cloud will allow you to go global in minutes if your project is successful and you start with customer in Europe in Asia you can really claw in your application over there we have a global CDN with more than 200 pounds of presence that can cache your static and content or and your media file close to your customer to reduce the latency between your customer in your case so you can go global very easily and the best of all of using public load of course it's that you only pay for the services that you are using if you are not using anything you we are not going to charge you you are not going to be built if you have only ten kilobyte of file on the Amazon s3 you will pay almost nothing but if you have terabytes you will pay for the value that you get from the services so you choose to deploy your infrastructure to the cloud and you make your research and you found the reference architecture on our website aws.amazon.com slash architecture so your first architecture will be probably something like that single region to availability zone availability zone it's a group of data center that are separate to each other in terms of risk so they cannot be affected by the same risk at the same time a lot of unanswered receives a request to your application your application being deployed on Amazon ec2 instances virtual machines with an auto scaling group that will scale your fleet automatically based on the metrics that you choose and master slave database in the two different availability zone so in case something might happen to one availability zone the database will automatically fail over to the replicas database so that's a reference architecture that's the way most applications are starting inside the cloud and during that first phase you will probably build that infrastructure in the AWS console you are going to use what we call infrastructure has click ISE clicking in the console to create your V PC to create your network to create your instance to configure DNS to configure security groups and everything M infrastructure has click as a couple of advantage actually it's very easy to discover the different service to experiment with the different options but it's very difficult to replicate what if after a few weeks or a few months you need to create the same infrastructure because one is asking you for a test environment for example or what if you need to replicate you infrastructure in another region because you start with customer the region is very difficult because you don't live or recipe to recreate the exact same infrastructure but let's face it almost everybody start to create infrastructure in the console at first during that first phase of your project your choose also in your development tool we do support your favorite IDE we have a plugin for this idea the JetBrains ide so PyCharm for pythons intelligent edj story for Java Visual Studio code and Visual Studio for dotnet node and other programming language we have plugins that helps you to discover resource you have on your AWS account and to deploy code to your account as well very recently this week last week last week we also release the plugin for webstorm and writer from the jet brain family using this plugin you can develop locally for example a lambda function for example here I am in in in Java though in Python and I can debug my code directly from from by charm I can run my lambda function locally from my laptop in a docker container that emulates lambda and I can deploy my function my lambda function to the cloud so you can choose your IDE you can install it with a plug-in and start to interact with AWS services resource directly from your development environment another option for your idea is to use cloud 9 cloud 9 it's an IDE just like the one you are using on your laptop but that one is running in the clouds it's running inside an Amazon ec2 instance so each developer can have its own IDE you can collaborate as well and one of the good thing of using an IDE in the cloud is that you can create separate environment for separate projects these days many developers have full stack developer they're working in JavaScript no GS in the morning Titan in the afternoon and if you provide different IDE different cloud9 instances for different project you can be sure that the artifact from from one or the dependency from one project we're not pollute or break the environment for your other project it's like giving people off apply to your own time machine and not just to a specific directory so you'll learn about cloud 9 and you decide to use cloud 9 and your team is getting bigger your deployment server your production infrastructure got some visibilities or your management team allocate more developer resource so your team the fact that you are using cloud nines helped to boost rap or to to welcome new developer in the team very easily because you can just point them to to a cloud 9 instance and they can start to work very quickly on on your project problem you're not alone as soon as you are - developer you need a way to share the source code between the different developers of your team so you start to investigate different option to get a code repository and of course you can go to one of the managed services available on the internet such as github or bitbucket without word grades they also all come with some limits that are inherent to these services like the number of representation you can have or maybe the maximum file size you can have so you have another option it's to start your Amazon ec2 instance and to install git by yourself great but how are you going to scale that if you have thousands of developer if you have gigabytes of repositories you will be responsible for patching this machine for patching it itself you will be responsible for scaling this you will be responsible for the backup you don't want to lose your source code so having a strong backup strategy for your EBS volume will be very important and you discover another option is to use a fully managed service in the cloud to store your code fully managed means that you don't have to manage ec2 instance we do that for you this is what we call service service means you don't manage the server women a server for you so we do the backup for you we store your code on Amazon s3 it's the code is encrypted at rest you can manage the keys using AWS kms AWS commit it's a fully manageable scalable a git repository in the cloud and it's really good so you can continue to use your client-side git command line or any tools you have that interacts with kids code committees fully compatible with git just like any git repository you need to create an SSH key to get started so you include nine for example you type ssh-keygen to generate the key you upload the key to the code commit console you configure your client-side SSH in the dot SSH directory and then you're ready it's the old stormed out gets that me my dad and my grandfather before me use and love with get adds git commit git push get pull and the joy of merging a code talking about merging you need to choose a branching strategy as well how many branch are you going to have in your repository if you look at the industry right now they are mostly two different approach to two branches one is called feature branch so when you start to create a new feature on your release you create a brand for that and all the developer works on the on that branch and when the feature is finish where the release is done you merge back to to the trunk that's good if you have point in time release software that you need to release with a specific version number at Amazon for example we are using that for firmware for echo device of all Kindle tablets King Kindle reader all tablets for example when you have a mobile application a website something which is updated continuously the other strategy is to use trunk base development trunk base development is that you try to keep the trunk as close as as the production as possible so as a developer we create a branch when I start to work on something a new feature or big fix for example I will do my change on my own branch and I'll try to keep that branch as short lift as possible because long live branch are more difficult to merge back so to three days maximum and after that I branch I merge my code back as a pull request and we can do a lot of photo motion for pull request I will talk about that a bit a bit later on so feature branch is probably the way to go if you have a mobile application or a web application so you have a code repository you have a couple of development developer working on your environment and there is a one in your team that's every couple of days take all the change from from code commits creates its own cloud9 instance merge all the change compiled run the test zip package everything and deploy to your production environment and that's a manual task it's boring developer don't like to do that that's the build master in in one of my previous team nobody wants to be a build master so we create a rule the guy that breaks or the guy or the woman that breaks the the bill becomes the new build master until someone will break the build again and he or she is becoming the new bit master and that was a good competition between developer to be sure that whenever we commit code to the trunk the code will not break the build but there is a better way to do that now you can automate your builds as well so you can start to think about continuous integration and I'm sure you you saw this type of diagram already continuous integration the idea is to automatically build your code whenever there is a change in your source code repository so git hellos to have different types of hooks trigger scripts that can start to build and you can have a server where your package will be compiled on will be built when I say build it's compiled if it is Java or typescript maybe it's just a matter of shipping stuff if it is no GS or Python application that doesn't really require to be compiled but it's also a good place to run a set of tests to ensure that the new code will not break anything so it's the right place to make your integration test to make you need tests maybe to make some some tests on the code quality itself like the level of documentation or limiting your code for example and just like you did for your source code repository you are looking at the different options that you have here and one of the option is to have your Amazon ec2 instance that you need to manage yourself to patch yourself to patch the operating system and install your favorites continuous integration server there that continuous integration server probably has 1,000 different plugins that you need to download configure merge conflicts between these plugins so it's a lot of work probably almost a full-time job in a large team just to manage that build environment how are you going to scale that if you have thousands of bills per day there must be a better option so in the cloud better option would be to use AWS code build and exactly like code commit is a fully managed environment for code code build it's a fully managed environment to run your build so a build environment it's a docker container and you give us a script with a set of commands that we will execute inside the docker container to compile your code to package your code and to run your unit testing or your integration testing code build will scale automatically so you can have one bit per day or 1000 bits per day we will scale that automatically and you only pay for the time of the build for the runtime of of the build so you decide to automate your build with code build you need to give us a script and the script it's in a file called build spec dot yeah Mel it's a Yammer file it has multiple face like a pre-built build a post build and each of these face is just a sequence of operation that you give us or hits a project to build a docker image and you see in the pre-built is just to connect to the docker repository and to prepare some environment variable the build itself it's docker build and the post build is to push my image to the docker repository maybe apply some auto tagging and prepared Program Files for example so that's a very simple spec file you need to give us that in the root of your project and code B it will execute these steps automatically for you you still have both developer joining your team you have one development server right now and one production environment and it doesn't scale all your developer wants to have their own development environment so they can test the ID they can break things without impacting their colleagues so basically you want to go from that architecture to this architecture but of course you don't want your developer to create by themselves their own environment in the console because what is the chance what are the chances that two developers are going to create the exact same environment if you're just using the console it will not scale this environment will be different so you will end up with development test and production environment that will be different there will be different operating system version package dependencies version something will not be aligned so what you are going to create if your user the console it's a snowflake server or a set of snowflake server you know snowflakes from distance they all look the same but if you look closely at the snowflake there are all difference and that's exactly what you don't want for your IT infrastructure you want all the server to be the same so what are you option to have all your server the same it's to automate of course it's to automate the creation of your server of your production environment your development environment inside the clouds and you have a couple of options to do that automation you can use a script I'm going to use a Python and bottle 3 SDK the Python SDK to create a Python script that's great and you can build an environment like that but can you delete the environment with the same script no you will need to write another script to delete the environment because the order of things matter you need to create first a network then the database then the application server and so on what if you want to change something you have your environment there and you just want to apply different settings for example for a security group you cannot just change your script and re-execute the script because it will create another environment it will not apply just the change so for that we propose to solve that problem with AWS CloudFormation and all customers are using a dress code formation since many years to describe their infrastructure as a text file you can describe your data center in a JSON or in the ml file and you give that yell file to cloud formation it will cut code execute that younger file in the cloud for you it can apply a Delta between current environment and just a change or one line change in your ml file and can also delete your environment if you need to turn on your environment for example your development environment should be deleted at night because nobody is working with that and you don't want to pay for resource that you are not going to use cloud formation great hundreds of thousands of customer are using a cloud formation but what we heard from this customer is that sometimes a bit verbose you need a lot of lines of code to create basic infrastructure like two hundred lines of code create a network and it's text-based so you cannot easily reuse or create higher-level construct like this practice that you want apply to your environment you know sharing code through copy/paste it's not the best development practice that's why we created the cloud development kits AWS last year launched the cloud development kit it's GA since a few months now and the idea with the cloud development kit is that you can use familiar programming language such as typescript JavaScript c-sharp Java Python to describe your infrastructure because it's a real programming language typescript JavaScript you can create higher-level construct objects that encapsulate some default behavior that you want all your development to share like the best practice for your architecture for example so construct is just a class an object that you define that encapsulate some some behavior and what does the cdk is actually generating cloud formation so we are not reinventing the will the cdk compiles to Yammer style for cloud formation and then you can use the cdk command line to execute that cloud formation in the cloud for you that's an example of a CDK a script in typescript this one creating a VP see it's two line of code and can be one line of code if you take all the default for example here I limit my my VP c2 to availability zones instead of three so two lines of code that will generate 200 line of Yammer for cloud formation you can define dependencies like an HTML static websites you can create user data and user data it's a small shell script that you give to your Amazon ec2 instance and when it boot the first time it will execute that script to install some package or install your application you can create an auto scaling group remember the service that allows to scale in an OT or your fleet of application specifying the instance type the operating system the size of your auto scaling group the permissions for example or the user data script and when everything compiles you just type cdk deploy and it will deploy that infrastructure for you in the cloud and remember it's a programming language for working inside your IDE cloud 9 or other IDE you can have syntax highlighting you can have code completion you can have refactoring because it's it's plain type script JavaScript or Java Python for example so now you are automating the creation of your environment you have your source code encode commits you have automatic built-in code build and you have cdk script to generate your development environment for each developer your different test environment and your production environment what about the deployment itself after code builds finish and you have the new version of your of your application which is packaged how do you bring that package to show your different test environment and to your production environment so code deploy it's a fully managed service that helps you to deploy code wherever you want to deploy your code code deploy can work with Amazon ec2 instances obviously but it can also deploy go to on-premises you install a small agent on your own promises machine code deploy can orchestrate the deployment between the cloud and on-premises it can deploy to dock your container running in a GCS cluster for example or ETS processor and it can also deploy a lambda function and if you have multiple deployment like that test prod you need an Orchestrator or you need a work flow you need someone that controls the different steps that decide when to go from one step to the other maybe you might have manual steps as well like manual approval before going to production and that's rule of code pipeline called pipeline it's a fully managed workflow that orchestrate your deployment pipeline inside the cloud so we have the whole family there code commit code build code deploy and code pipeline and code deploy can do some some interesting or can apply some some interesting deployment strategy but before talking about deployment strategy remember that with code pipeline and code deploy your your pipeline can be as simple as you want so build deploy that's the example I will show you in a demo in a minute but it can be also extremely complex depending on the need of your organization it can goes across multiple AWS accounts you can trigger a pipeline for grammatically with a lambda function so this is an example taken from from the AWS website if you search for AWS track 10 example you will see that extremely complex pipeline across multiple multiple account what about creating this pipeline automatically as well you don't want to go in the console and for each environment create a pipeline and configure code deploy you can do that with the CD key as well so with the CD key you can create a source action like taking my source on get up in this example you can define a be the project with the type of linux image rather for the build with different policies and where is the source code where is the destination of the build you can define a deployment action in that case I'm deploying my docker container to ECS and once you have these three elements sauce build and deploy you can type them together in a pipeline with three stage get sauce build docker image deploy to ECS so your deployment pipeline you'll development infrastructure to bring code to production can also be created automatically using the the cdk going back to code deploy typically code deploy will deploy your code with a policy that we call rolling upgrade and that's probably what you are doing today in your data center as well when you do rolling upgrade you take one machine at a time outside of the load balancer you update the version of your application on that machine and you bring that machine back into the load balancer game quite easy quite efficient but there is a couple of issues with with that type of of potential issue with that type of deployment and one of them is what if you need to roll back what if in the middle of the deployment you realize that something is not working as expected and you need to roll back and revert back to the previous version it's very difficult to do if you do rolling upgrade in deployed you have another option which is called blue-green deployment with blue-green deployment the idea is to create another infrastructure next to your production on infrastructure and progressively shift the traffic to the new version of your infrastructure so you're not only deploying a new version of your application you're recreating your entire production infrastructure for each single deployment that's something you cannot do on promises right you cannot call your favorite hardware vendor to say hey I need to buy an other data center for to deploy it the next version of my application so with blue green you have production in blue a code Depot will automatically create another prediction environment for you let's call it a green environment it will create infrastructure so in this example it's a couple of docker container it will configure the load balancer to load balance request to the green environment it will create a testing endpoint and send some traffic tests to that endpoint if the test is okay then it will start to progressively move the traffic from the blue on Rheinland to the green environment and if everything goes well eventually all the traffic will end up in on the green environment and while you are doing that you need to create alarms you need to monitor your green environment because if anything goes wrong then code deploy will stop the deployment and stopping the deployment is very easy it's just reconfiguring the load balancer to send one hundred percent of the traffic to the blue environment so it's very quick it's a quick operation so knowing your baseline knowing your alarms is super important because that's why that's what code deploy we'll choose to abort your deployment so it's up to you to monitor technical metrics or business metrics one of the business metrics we do monitor at Amazon it's the number of purchase per second on the retail website if that metric drops during your deployment it's not because customer do not want to buy from amazon.com anymore it's because something prevents them to buy from amazon.com so we don't try to fix anything we first switch back the traffic to the old version of the deployment and then we start to find the root cause and to fix that so let's see that I have a 10 minute demo here where I'm starting from a github application it's a Python flask application that talks to dynamo DB to accept signup that application is deployed into a cluster it's a docker cluster and ECS cluster and I have a pipeline the pipeline that I use that I show you on the slide from the cdk that's the cdk code that create that pipeline with sauce build and deploy the application is a really very simple HTML tie tongue it's running inside a docker container you can go to my github and you will find the sample application there let me show you the application when it is deploying hey the next big thing is coming in a city and what I'm going to do is to make a change ok the user can can can register of course and these data are set into dynamo dB so what I'm going to do here I'm going to make a change in the application and I will make a git push to show you the pipeline in action so I have the HTML file here with the text that you see on the screen I have the Python code just to show you that it's really a regular very simple application it has two roads or road for index and a road for the sign up I have a docker file where I install nginx install the dependencies mostly flask Python a couple of configuration file for for Ingenix so that it can route the traffic to my Python application and then I just start the web server inside the container and I have a build spec file that code build will use to build that container it's the exact same file as the one I show you on the on the slide before so looking to my easy are the docker repository preparing environment variable building my doctor container tagging my docker container pushing my docker container to the repository and then preparing a couple of files that code deploy will use to actually deploy that container inside the ACS cluster and the output of the build is really three file it's the definition of my docker container it will help code code deploy to to know what to deploy and how to deploy that so let's make the change and let's before that yes let's go to the build so I have the build project I have to deploy face and inside the deploy face this is where I configure code deploy to make the blue-green deployment so code deployer has that concept of application and that application is configured in such a way that it will trigger a Bluegreen deployment so in the configuration of code deployed you need to tell us where to deploy which cluster here I have my ETS cluster the name of my cluster and the name of the service inside the cluster and Bluegreen deployment it's heavily dependent of load balancers I explained before so you need to give us the name of the balancer the testing endpoint and the target groups for the blue and for the green environment you also choose how long do you want to keep the test traffic on the testing endpoint its demos or five minutes and once the green deployment will receive prediction traffic how long do you want to keep the blue environment might be days or weeks for example to be able to revert back just in case you notice something is going wrong on your on your deployment and the pipeline and show you the pipeline already it's very simple sauce build and then deploy so let's change the code I'm going to change the name of the city and replace Paris with Las Vegas I'm going to commit that changing it up using the graphical user interface from the visual studio so that's a git add a git commit with a commit message like I learn from my parents to always put a commit message and you should do so and then git push so this is the equivalent of git add git commit get push on the on the command line I can go back to get up and to show you that the change just arrived there if I reload the page you can see that the change has been made 14 seconds ago so let's go back to the pipeline and see the the pipeline in progress the sauce phase it's already done just now you see that's been because it's super quick it's just downloading from github preparing of zip putting that zip on on Amazon s3 and then moving to the next phase next phase is the build so code build is creating a docker container it's my build environment it will take my build spec 30 ml file to execute all the commands there and that bill takes roughly two minutes based on my previous experience it's the time to create the container and then to execute my bill spec file so during these two minutes let's go back to the load balancer and you don't show you the load balancer I have one load balancer with two target groups blue and green currently blue is attached to the load balancer Green is not attached and if we go to the targets you will see that the blue one as the old version the two containers already running and the green one has no container yet a code deploy will register the new container to the green a target group automatically let's go back to code build you can follow all the steps of the build in the code build console this is invaluable when you're debugging because when you're going to create your first builds back that Yammer will not work at the first time to be a couple of times and being able to see the exact error message and what line is failing helps you to to to debug so now it's a people of that start with all the dependencies and via to an environment for python one of the good things also we've got built is that you can see the build history so you can also stop a build if if it is blocked or taking too much time so we are at 1 minute and 52 seconds so it will be almost finished let's go back to the the pipeline and the pipeline will detect that the build is succeeded when the build succeed it will turn green automatically all right if there is an error if there is an arrow it will stop there but here just on green and now we are entering into the blue-green deployment phase with a code deploy and you can also follow the steps from code deployed so you can go to the code deploy console and from there see the different step the first step is to create infrastructure right now code deploy is creating two new containers and registering these two containers to the green target group of my load balancer so it takes also roughly a minute to start to container we can go to the ECS console to see the number of tasks can you see I have two running tasks as my blue environment and two tasks that are currently being provisioned you can see that the version number of the task definition has been incremented by one so it's not the same version of the application on these two tasks if we look at the load balancer you will see that code deploy will register the container to the green target group and we have already one Tokyo container which is registered and the second one will be register in just a minute I know we have the second one so know that we have the Green on random ready code deploy we start to send testing traffic to that environment so testing traffic is on a different listener so it's a different endpoint a different address and you can run script or give that address to some of your customer or QA people to test that so here if I change my url to column 8080 you will see that it's the new version of the application that has been deployed there in production I still have the old version on the poll 80 so the test will stay there as long as you define I define it for five minutes of course I don't want to wait five minutes in front of you here so at any time you can interrupt the test it can also be interrupted if there is an alarm but here I click reroute traffic to reroute 100% of the traffic to my green environment so right now code deploys change the load balancer configuration and since 100% of the traffic to the new green environment so going back to my browser if I go back to the production environment the one on 80 you can see that it's Las Vegas as well so no in production I have the green environment and the blue environment stay there as long as you as you need as long as you configure it to be able to go back to the blue environment just in case and here I will stop it manually and once again if there is an alarm code deploy will will send the traffic back to the blue on vine and that's the end of the deployment phase actually called pipeline will detect that the deployment phase is finished and we'll finish the pipeline and code deploy will terminate my old blue on violin so I'm reloading here in the CS console checking the the green a target group the green target group has the new docker container and the blue target group as no more docker container so if I reload in ECS console you can see that there is only two container left the blue environment has been deleted by code deploy automatically going back to the pipeline you see that the deploy phase is finished and it succeed and it's finished just now so that's an example of Bluegreen deployment using a full pipeline starting from github code deploy code build sorry first code deploy to deploy in Bluegreen creating a new infrastructure for you know you have your production environment running in the clouds how do you do a production environment in the cloud jadynn thank you yes I want to talk to you about kind of the next step like if something goes wrong we saw the the happy path right like what if everything goes through and you can deploy your changes but every now and then you will encounter bugs that you want to debug right now debugging got harder and harder over the last few years because applications are getting more complex and more distributed right if you look at the table application you have a lot of dependencies and it's getting hard to replicate them on your local development machine there are some some cool local development features that we offer for example with a local lambda that you can run or like a emulator DynamoDB version right but at some point the complexity gets so hard the mock-ups of course not perfect they don't emulate the exact setup that you have in production in terms of security groups access controls network and and so forth and with this that that it becomes harder to reproduce it locally we were trying to see how can we actually help you debug things in like a development stage or testing stage that is in the cloud so last week we actually announced a new capability for a bunch of the intellij sorry the jetbrains i des so for IntelliJ for webstorm for Pied remand for Ryder we launched the capability for you to live the bug ECS and Fargate tasks right so you can connect your local ide to a remote environment your development stage for example and do the full step through the bugging set breakpoints evaluate expressions and so a very powerful feature that allows you to debug faster go faster through development cycle reproduce errors and figure out what's wrong and then hopefully fix and and then progress with your with your actual tasks that we're working on so I want to show you a demo about that so what we have here is a simple java application in IntelliJ right pretty simple class file with a few print statements and then here on the left I'm connecting to my ECS cluster enable debugging and then pick a role that should be used and now saw the instrumentation process this is something you have to do once with your EC s plus that's something we also recommend you do not with a production environment right because we're now adding some additional instrumentation we're adding essentially a sidecut proxy to the to the container so that we can pass the traffic through that do the connection to the local IDE this takes like one to two minutes that's what we're speeding this up a little bit like I said this is something you have to do once and once this is complete you can connect your local IDE to it and have a pretty much standard local debugging experience as you used to from IntelliJ from writer from webstorm and python so the instrumentation completed here what we can do now is connect again to the es cluster what you can see here is that now we have this nice debug symbol and we can start enabling debugging this is now pretty much what you would do locally right like I define what is the class that I want to debug what's the all the settings that I need for the for the build stage right like how do you want to run maven and all that these things again pretty simple pretty comparable to what we do locally exactly the same experience I'm configuring here two environments or two I want to have two debugging sessions in order to show you that you have independent isolated environments here that you can manipulate separately so we do the same thing we enable debugging now we would do the Maven built run which takes again a few seconds right and after we completed that we will be able to go through you can see here we have two breakpoint set that we will walk through the live remote ECS environment that I don't have local on my on my machine so now we have here the to debug sessions debug session one debug session two and as you can see we're now getting the same information as you would have in a typical debugging session about my variables right like their state I can manipulate them I can see what all the the valleys are set and so forth and again in two separate executions right so we we see the print statement for both of them that we have here in the first line we stopped at the first breakpoint and now we can introspect the settings we can evaluate expressions we can override values so here for one of the two sessions we're setting a value to 343 and go step over the debugger step right and then the other expression it's still set to the old value so now if I complete this and go to the final print statement you can see the output is different right so there there are two separate isolated debug environments I was able to do all the local evaluation that I am used to for my local debugging experience again the goal is it's pretty much the same thing as you would do local debugging now the trick is we're actually connected to remote easier so far gate container so that I can have everything that I'm used to for my local experience with the remote cloud resources today we support the those four IDs that elicit auto from the JetBrains family we support ECS forget what you could see us do in the future is look into supporting more IDs looking to supporting additional compute targets this is something that is just launched into beta last week so eager to hear your feedback eager to hear what should we add next support for how can we improve we're pretty excited about this capability because we think it allows you to have an easier development environment and development experience on a device on the cloud so we're very excited to hear your feedback for that and with that I'll hand back to to Sebastian Thank You Janelle that's quite impressing put a break bone in the cloud and actually execute steps by step code running in the clouds your deep problem team is growing you have automates your full pipeline so now it's time to think a bit about monitoring and operation how to get the alarms or to act when an alarm is is it's triggered by your value environment and more and more what we are seeing at our customer site is that the development teams the operation teams are using chat systems to to communicate between them and switching contexts between your slack application for example in your AWS console it's not always as easy as you want so using a slack channel or shine channels allows the team to stay in touch on the go or on the office and that's what we called shut up so what the industry is calling a chat ups operation in in a chat we launched AWS chat BOTS back in July chat bot allows you to collect SNS message such as AWS cloud watch alarms or billing alarms and to deliver this message to your favorite chat applications such as Amazon shine or slack last week we improve it with chat board and we add the possibility to directly type an AWS comment as a respond to a chat message you receive an alarm in slack and you want to learn a bit more about the root cause of that alarm what generated that alarm so you can type new wshh CLI command directly inside your chat and get the result and start to investigation inside your slack channel let me show you how it works I've demo slack Channel a lambda function in Python which takes a lot of time to execute five seconds and I have a cloud watch metric cloud watch alarm on the throttle metric so you know the throttle metric it's the number of core that will be throttle if there are too many calls in parallel I have my chat bot configure to post message to the slack channel I have an AM roll attached to that and here's my slack channel so let's generate some load on my function so I'm calling it one two three four five times you can see that the the first call will return 200 that is okay but the others are generating an error or too many requests exception so eventually after one minute cloud watch alarm will will trigger the metric is being catched by by cloud watch and the alarm is defined on one minute so there will be a small delay before the alarm will will raise I didn't mention that of course you cannot type any degress comment in the selection l you associate an IM permission and so you can finally control what type of operations are available in the in the slack channel here the metric appear in my cloud watch console so if I go back to cloud watch alarms we are going to see the alarm switching to from insufficient data to alarm and as soon as the alarm will trigger the message will be posted to slack so now we have the alarm in cloud watch because the data has been received so if we switch back to slack we see that I receive a message on slack and the message gives me the name of the alarm the region the account the specific threshold that was breached and the metric so from there I can called the AWS CLI AWS lambda gate function the name of the function function name demo to know a bit more about that function and why this function has been throttle and immediately I received the answer just like if I was typing the command on my terminal and I see that the reserved of concurrent execution is one and that's why my calls have been throttle and if I go back to the AWS console I can see that indeed the reserved concurrency was was one so I can solve that problem so AWS chatbot allows you to receive crud watch alarms into your slack channel or your Amazon chime channels and you can type comments directly to investigate the root cause of the issue when I'm doing this talk I have a frequently asked question is how Amazon as a large company is doing develops as well we start off the verbs drawn area nor drawn it was micro-service in 2002 so almost 20 years ago already and the way we do it at Amazon is to to say if you build it you run it so if a developer development team is building a service or micro service they are also in charge of running that service so we don't have separate operation team and development team it's a small team because more teams have less over write in terms of communication they are more nimble so we have a large number of small teams that each develop and operate their own service how small is small it depends but at Amazon we say that it's a two Pizza team meaning that if you cannot fit your team with two Pizza American sized pizza then the team is too large and you need to split the team into smaller smaller components we automate everything including the creation of our pipelines we put all those security the tests the intelligence of the tests and the security of the pipeline in the pipeline so you can access the pipeline to check on the code as well to ensure that a mistake can be catch as as soon as possible every time someone commits code there is a series of tests that are run to avoid a human error to arrive into into a production this is what we called with belts and suspenders and of course the infrastructure is run as code as well so let's wrap up with this 100 50 minute session what we build we start with your laptop a new single developer on your project typing code and we progressively build a system where teams of developer can be responsible of their services they can create their own deployment pipeline using code commit code build code deploy code pipeline you automate the creation of this pipeline you automated the creation of the development environment the test environment the production environment using the AWS cloud development kits cdk and you choose code commit which frankly is source control to share the source code across all your development team the message to remember think big you do not need to start with something as complicated as on the previous slide but try to shoot for the moon what would be the perfect deployment process for your project or for your team or for your customer what is the perfect deployment process that will maximize the value for your for you the number of deliveries for your customer and minimize the friction so the rollback the number of time you need to roll back so try to shoot for the moon it might take years to get there start somewhere start small and then iterate based on customer feedback or your developer feedback think about the impact of technology on your team as well I'm talking to AWS customer every week and every week I hear the message saying hey it's much easier to hire people and to retain people when we are using DevOps philosophy but an application modern development tools that's one of the impact of choosing this type of technology as well your team's your tech team will have fun using this type of technology remember that money is not the only motivation for tech people having great technology and fun environment it's it's often a factor of motivation for your development team as well so it's okay to start small start to something small and start there and don't be afraid of automatic deployment remember my bank I talked about at the beginning of this tour that we are deploying twice per year into production when you're shipping a lot of change into production of course it's it might be a traumatic experience because you don't control all the things that you are going to change at once but if you deploy a small unit of change one by one it's very easy to rollback if there is some breaking change and come back and undo your deployment so don't fall into the do not deploy on Friday fallacy I guess many of you have already or maybe apply this type of policy inside companies say now I don't want to deploy on Friday because I don't want to be called back during the weekend a deployment into production it's a non-event in your IT organization it's normal day-to-day life its day-to-day business remember also that if you really want to innovate and to provide added value for your customer you must ship your code as quickly as you can from the developer machine to production because the only place where code is happy is in production code is not meant to be and to stay in the github repository it's a liability for you of you invest time and money to write that code to test that code and it doesn't bring you any added value it doesn't bring any added value to your customer to stay in a git repository so the only place where code should be is in production it's up to you to put in place systems to reduce the time from code to production but to do that in a safe environment where it's actually safe to deploy and to minimize any type of friction to minimize the type of error or don't fall into the deployment trauma so try to make the right thing easy and automatic and make the wrong thing hard writing is to ship code to production the wrong thing is to ship a book to production thank you very much I will take your feedback on on my Twitter stepstool I'm sure Jonathan you will do the same happy to continue the conversation after after distort and don't forget to complete the survey in the mobile app thank you [Applause]

Channel: AWS Events

Views: 10,301

Rating: 4.7538462 out of 5

Keywords: re:Invent 2019, Amazon, AWS re:Invent, DOP209-R1, DevOps, AWS CodeBuild, AWS CodePipeline, AWS CodeCommit

Id: wugkTArXBYo

Length: 56min 57sec (3417 seconds)

Published: Wed Dec 04 2019