AWS Nordics Office Hours - Safely deploy application configuration with AWS AppConfig

hi everyone and welcome to this first episode of the new season of aws nordic's office hours my name is jonatha i am a developer advocate at aws and i am based in the nordics so this is our weekly show where i bring on aws experts to let you our viewers learn about aws and get all of your questions answered and of course we want this to be as interactive as possible so ask questions post comments and you do all of that in the chat throughout the show and don't worry if we don't get your questions straight away we'll try to answer the questions where they are relevant in the stream so for each episode we have a specific topic to talk about and this week well it's no difference we are going to talk about application configuration and how to safely deploy application configuration with the help of aws app.config and to do that and to educate you our viewers i have two guests on this time i have vinny satya she's a product manager at the aws app config team and i also have james seward he's a senior solutions architect for public sector at aws so welcome to the show both of you and vinnie please tell us a bit about yourself uh hey everyone hey gunner uh glad to be here uh this is obviously my first time here uh and i was gonna introduce my name is vinnie um and i'm a product manager for uh app config i've been with amazon for a little bit more uh four years and i'm also based out of uh the u.s and i'm based out of the hq2 that's near washington dc so it's a lovely morning here and i'm glad to be here yeah thanks for for waking up early and joining us uh here for the nordic's office hours vinnie the next games so james tell us a bit about yourself hi thanks for having me so my name is james seward i'm a solutions architect i'm based here in the southwest of england um my day job is i work with public sectors in the healthcare vertical but i'm also an applicant an app config specialist uh and that's why i'm here to do uh some other technical stuff today cool and throughout the show we're gonna look at a lot of different examples see how we can use aws app config for for deploying application configuration but let's start from the beginning what is configuration when it comes to applications what what are some examples of how we're seeing customers using configuration so application configuration enables customers to change uh application behavior at runtime so a common example that i love to give customers or you know whoever i'm talking to is that imagine as an application owner you're trying to release a new feature you know when your code is deployed you want to unhide that feature uh and you want to do that along with a marketing announcement or as a devops engineer you're trying to deal with an operational event where you know things are tense and you want to release that fix as soon as possible and there's no time to decode deployments but you want to um you know either change the logging verbosity of your application or collect um logs on a more granular level or the changes that need to be deployed fixed and we can't wait for code performance that's really changes that we would like to uh deploy as application configuration so things that are fast um uh it's dynamic and is consumed by uh your application at run time uh it sort of you know kind of is the basics of you know what app config is sort of built on and we're trying to uh provide some more safety controls and um validation and a lot of you know uh changes that can be consumed by their applications by customers application on runtime was really kind of uh it revolves around and the option well if you're not separating your application configuration that would mean to instead embed it into your code right right so um i'll just quickly go back and you know talk about the legacy ways of you know what are the other ways that um you know customers are not let's say using something like app config which we will dive a little bit uh deep into uh there are two common ways that we've seen customers use application configuration one they would either embed that into the code and this has been like the most common way of storing configuration uh it's been very legacy and obviously uh saving application configuration as code provides you the safety control that i was just talking about uh within the code deployments however uh it's super time consuming so the example that i just gave you know as an operations engineer or a devops engineer uh if you're providing uh if you're trying to uh deploy a fix to your application you obviously can't wait for a code deployment uh or in a feature release use case wherein uh the feature uh is already deployed but you're trying to unhide the feature for all of your consumers and it's a global application if you're doing that as a part of the code deployment it would probably take days um you know for it to flow through your pipelines and have that feature be available to the customers so uh in cases like that it's probably not a very good idea of uh storing that uh configuration into the code and that's one of the common things that we've seen uh across our customers that that's the normal way of doing things it's been that like that for a long time so while this has been time consuming um you know but it comes with a lot of safety controls uh another way that we've seen when the customers want these changes to be fast or they want these changes to be consumed by the applications quickly we've seen them that they store these application configuration values in databases um so what that means is like you know all you do is you change that one entry in your database and you're ready to go when that application configuration value changes um so what happens in that case is while this is really fast obviously that change reflects immediately it can be consumed immediately by your application uh but there are obviously some concerns with that approach as well so uh number one you know it's fast so that means it's uh your application is able to fetch that immediately but imagine that value either let's say had a typo or that was not correct you know it wasn't the expected value that your application expected what would happen so we're looking at like risks of outages um you know and and it happens that we're all humans we could make uh typos or any other errors uh in configuring those values and uh you know that's obviously there's there's more risk you know than anything else there for your application um secondly uh obviously there's uh since values get deployed fast there's also not a way to roll it back um you know unless you make that change again first you catch it you make that change again and then you know your application is able to uh consume it again so uh obviously the lack of rollback mechanisms uh you know there's so many outages uh there's so many risks of outages um and then obviously imagine you know that database is unavailable right so in that case um you know there isn't really that story to fetch that value from and again you know that kind of post poses a risk um to the application you know as an outreach and um i've been talking to several customers and you know whenever i talk to them about these problems um there's been there's always been like a data point that i get that you know we always have like application configuration and misconfigurations are their number one reason uh of why their applications go down so we know that you know this problem is widespread we know that customers face it like you know uh pretty much applications across um all of their domains and uh there's definitely you know we needed to build something to kind of you know just kind of innovate and how we can you know provide customers a new way of uh making sure that there's less risks um of outreaches to their applications and that's where aws app.config comes in then absolutely that's a way to solving that and and tell us a bit about aws app config the the different parts that it actually solves in that well the problem that we're trying to solve with that config right so um i i just talked about a couple problems that you know we've heard from customers uh you know these are pretty much have been the ways of um you know deploying configuration and in general um so with app config there's actually a little story behind how we um you know released app config it's been a service since 2019 but um maybe a few of our customers know that uh this has been a service that's been uh used at amazon by like more than 4 000 teams and it's been you it's been in use for almost half a decade um so werner vogels who's our cto um he's a ceo of amazon he recently also posted a blog and that you know i really like that blog because he talked about you know how uh these configuration best practices were at amazon you know in the early days you know when um to make like any little change to uh our website we had to kind of redeploy the whole website that thing was like a gigabyte um you know in in size and redeploying that would obviously take hours uh you know our engineers would be on call um so that wasn't obviously the best way of you know doing things but that's exactly where technology was at that point in time and you know amazon was no different but uh at the pace that we're releasing software now um configuration or application configuration here plays a very important role so um i would love to share that blog with our customers and as uh when it talks about you know the various issues that amazon faced as well and we wanted to go fast we wanted to ship features fast we wanted to uh you know deal with operations around quickly uh we knew that there needed to be a system where we could uh store and fetch these configuration values um from from that central uh system so we had an internal service that our team started to use as a best practice um it was definitely you know uh it was we were doing great and you know our customers uh obviously we were the ability to ship software um it was the velocity really increased and that's how we sort of you know thought that we should share the same uh best practices uh around application configuration with our customers and that's how really app config was uh released so just to kind of dive a little bit deep into you know what we were looking for when we were building our own internal configuration management system we wanted the ability to store and update configuration data quickly and you know obviously it should be separate from code deployments second we wanted the ability to have applications fetch that configuration value from a service um and you know we should we shouldn't be falling into the same um uh issues with like databases for example we wanted it to be highly available and then obviously third uh the ability to check um and validate those configuration prior configurations prior to uh the deployments so that we want to make sure that whatever value we're deploying one is expected by our application it does not have any errors it makes sense you know just because we uh wanted to make sure that uh it's really it's really uh sensitive right uh it can affect your application it has risks of outages so we wanted to make sure that that those values are correct and those checks are done prior to deployment and you know as soon as we deploy them it's valid and you know we don't fall into we don't have any risks of outages and also we wanted uh to make sure that there's a rollback mechanism that's available and those best practices are sort of baked into app config and we'll you know uh james would probably like to talk a little bit more in detail and give customers uh an overview of the service yeah that's that's great win interesting to hear about how it actually evolved in from from something internal at amazon into something that that customers at aws can use today and and if you just joined us this is the aws nordic's office hours and i'm joined by vinnie and james today to talk about aws app config and application configuration and james i i think you're eager to get started showing off so i don't think waste weight anymore let's dive into that and have a look at the things that vinnie actually talked about how that looks in practice so and hey everyone in the chat nice that you're saying hi and we have a question that i think will save for a bit because i think james will get there pretty quickly as well yes james i'm adding your screen share and and let's start out okay thanks so uh by way of demo um i've used all of my technical ability to create this hello world example application so this is just a little python flask application running on a couple of ec2 instances with a load balancer and it really just renders a hello world page and what i've done is i've hooked up to app config to receive the configuration value for the background color of the page so hopefully that's a nice uh obvious demo that i can show um you know how config is is rolling its configuration out so if i look in in app config itself this is um the app config sort of home page it's part of aws systems manager um you can see that i start by having these uh two applications defined so i've got a lambda application for a future demo and i've got this ec2 application so the the applications the configuration starts by being divided into the application that needs it and then if i click through into there you can see that under my application um i have this concept of environment so at the moment i just have this one demo environment but the the environments are really there to allow you to deploy configuration to different groups of in this case instances um so that you can roll out um i think like the question was asking you know can you push configuration out to a qa environment and a prod environment that kind of thing and so environments is the way that you would do that you would have um a qa environment and a pre-prod and a prod you know whatever matches the way that your environments are deployed and the question here was for serverless applications but it doesn't really matter if it's for for uh a ec2 based application in this case or uh on serverless application right yeah just to kind of add on there like app config is very agnostic to uh the targets so again we define targets as either it could be your ec2 instances or uh your serverless lambda functions um on-prem servers iot devices it's pretty much agnostic to what is at the other the receiving end so um to just to kind of iterate that yes uh for service and basically the same configuration could be used for both as well absolutely yeah uh you could store that um application sorry application configuration centrally um and it could be received by any set of targets and you could have separate environments for those yeah yeah so in this case i've divided my demo applications because they're doing different things into these two different applications in app config but there's no reason why you couldn't sort of mix and match if you wanted um or create you know an environment that represents your ec2 instances and an environment that represents your lambda functions um and i think you know something vinnie said is there there is very important it's that you can deploy um the configuration that you've created you can you know it becomes this redeployable thing um that you can send to different environments and so that means that you can send that configuration to your qa or your test environment and you can validate it and then when you roll it out to your prod environment you know that you're deploying exactly the same configuration that you've already tested to the production environment um so that sort of you know again prevents any typos as you go between environments and these are our practices that i think a lot of people are familiar with when it comes to to the code we deploy using the ci cd practices that that is very familiar to most most developers but in this case for for application configuration instead right and just to kind of add on to what gunner said um you know and i'll point back to the block that our cto wrote recently um you know he kind of talked about continuous configuration so that's sort of you know ci cdcc uh that's what you know we've been trying to tell our customers because essentially cicd helps you with your uh code deployments and you know automate it across and make your delivery software delivery faster however these configuration changes sort of need to happen like in parallel um to the cicd pipelines and uh for any changes that are uh any changes that are deployed at runtime uh continuous configuration is sort of the way to go so uh give that blog post to read definitely really interesting yeah and i posted the link in the chat earlier correct james yep so the the final piece that we haven't really seen here uh is the actual configuration itself and so in appconfig those live inside what are called configuration profiles and you can think of these as being sort of a set of related uh configuration settings uh it's the easiest way to get started thinking about those so inside my application profile i have um a hosted configuration this means that it's the app config service is storing this configuration for me um config supports quite a few different uh back ends to hold the configuration but in this case i'm using the the built-in one and you can see that my configuration document is really just a json document that's defining the background color uh as white uh for my application so this is sort of the the moving parts for app config that you you need set up so if i just jump jump over to my application code i can show how that's then loaded by the application because i think this sort of helps close the loop for sort of how the environments and profiles and application values that we've seen work so this is the application code that's running on my ec2 instance like i said it's a fairly straightforward flask application just giving me really the ability to render this little html template you can see here that i'm pulling in the background color using sort of templating and then what i'm actually doing in the application is i'm supplying the value for that variable to go into the template by reading it from app config so if i just back up a little bit here i've got this app config helper library um so this is a little python library that wraps up the api calls that you need to make to app config in order to receive your configuration um and part of the reason that i'm using this is it sort of helps enforce uh best practices so there's a few values that you need to supply to the api when you're calling it in order to get the best value out of it really um and so this helper library is doing that for me is it the time to to do a shout out to the developer of that library vinnie well it's it's developed by james and uh i'm just super stoked about it uh lots and lots of customers are uh using this uh library it's on github uh i'll definitely post the link to that um but yeah thanks james so much thank you um dog fooding uh in a sense yes i mean so the library itself came out of an internal project that i was working on and i realized i should wrap up the functionality and make it a library so that's that's where it originally came from but the the helper library you can see it's taking these three values that i'm actually reading from the environment and they are supplied into the environment by the um the cdk stack that's deploying this whole demo um so that's sort of how it all gets tied together but those three values are the the app config application uh name the environment name and the profile name and then the 15 is the number of seconds it should cache that configuration so it's not repeatedly fetching the configuration um and hammering the app config api it will sort of cache it for 15 seconds and then see if it needs refreshing and then when the page is loaded that's done by this function here so the first thing i do is check to update the config so this won't update the config if it's been less than 15 seconds since the last time it did it if it has been then it will automatically fetch the config for me and then i'm checking a variable we'll ignore this use new template value for now so what i'm doing is rendering that template that we saw at the top of the file and into that background color i'm just providing the background color variable that i've read from my json configuration and then the the application returns the rendered html and that's what renders on the page and so that's really sort of the the bits you need to get started with using app config in your application right so let's get back to app config then and i think have a look at how to actually make a change and and how to do that um using app configure and a deployment of a new configuration yeah so for the purposes of the demo i'm just going to do this in the console i don't have a continuous configuration pipeline set up so what i'm going to do is i'm going to create a new version of my hosted configuration so it's um these are versions so that you can actually sort of perform rollbacks or you can you know you can go back to a previous version of the configuration if you encounter problems so what i'm going to do is i will change the background color from from white to a sort of gray color and then i will just save that so now i have version 2 of my hosted configuration but this isn't live yet this is just created in the service what i actually need to do is uh run the deployment process to roll this out to the environment and comparing this to the other ways that you talked about earlier for instance storing in in a database or storing in i don't know s3 or something like that it would basically mean that you would be live with this new configuration though absolutely um yep uh so this is you know again one thing uh that's super great about app config is uh you can manage multiple versions so um you can store unlimited versions here um and and just to kind of go back a little bit uh you could still store your configurations in s3 or uh there are certain other configuration stores that we support within app config as well so if you're a customer of uh systems manager parameters and uh you're storing your application configurations as string values uh you can definitely reference those here and you could deploy it with the same safety mechanisms that we talked about using app config similarly um we support a systems manager document store we also support s3 so essentially those version that version control that james just sort of talked about is available for all of those configuration uh stores we also do have um an integration with uh database code pipeline and aws app config is integrated as a deploy action there so that gives customers some other sources that potentially they could use to store their application configuration centrally and deploy them through aws app config um also just to make sure that uh folks know that again app config is very agnostic to the type of data that you're deploying so pretty much text json yaml that's supported uh you know by app config so it's pretty much agnostic to the type of data that you're deploying so i do have an environment i've been working on where what i'm storing in app config is actually a my multi-part document so i've stored multiple things together uh in one configuration um so yeah you can store a lot of stuff in there so to perform my deployment um i'm going to deploy this to my demo environment i'm going to use version 2 of the configuration that i just created and i'm also being prompted for a deployment strategy i think we're going to come back to that in a little bit for a future discussion so for now i'm just going to leave that and hit start deployment and it's now actually started rolling out my configuration to my environment so you can see that it's going to give me a progress bar as it rolls it out i've got some details about what's going on i've got a watch alarm we're going to look at that again in a minute but if i go to my application and uh start refreshing at some point we will start seeing the background color change so this is one of the sort of key things that's important here is that this change is being rolled out slowly um or not too slowly for the purposes of the demo but it's being rolled out across my application fleet so there's a few ec2 instances that are running behind this load balancer so while one of the instances might have already received the updated configuration at this moment that hasn't been the instance that served my request but now we've we've refreshed and we've now hit an instance that has seen the new uh configuration i've got my background color updaters rolled out so looks like that's progressed pretty well and if i go back to app config we can see that we've actually hit 100 complete on the deployment and it's now in this baking phase which is where appconfig waits to make sure that everything is okay with your deployment before it declares that it's finished um but that's rolled out now just to kind of add on here um what james sort of talked about was uh the app config deployment strategy so again going back to the database example um that approach also does not have a way in which you could roll that uh all that change uh to your instances like one by one or you know roll it gradually and obviously there are instances um where you need that change to be available to all of your services all of your servers all at once but app config sort of provides you the best of both worlds like you could do it either ways you could also deploy that change immediately that's obviously not recommended as a best practice but deploying it gradually so that uh you know if there are any errors you could catch them early on and if that me if that configuration change needs to be rolled back it could be done early on again if everything just kind of ties back into mitigating the risks of outages for your applications and which is why you know this feature is super amazing when you know if it's a test environment and you're just deploying it to a small set of targets you're just testing it out testing out something um you could you know probably deploy it quickly across those instances or across those targets uh but you know when it's a production change uh the recommendation there would be to kind of progress slowly so you could either progress by like um availability zones or uh you know depending on however you uh you know you're managing your targets it would only deploy that application configuration change to a small set of targets wait uh to see if there are any errors um and then sort of move on until the deployment is 100 complete so again that kind of gives you that best practice where um a lot of safety that sort of built into our code deployments you know kind of exists here with app config as well and um again just going back it's been an amazon best practice and um that's that's how you know that's been a recommended strategy for customers throughout configuration yeah um that shows why we we use the word safety or safely deploying our application configuration absolutely so there's a question in the chat i think this might be for for you vinny would you recommend using appconfig to replace feature flags using a vendor product yes absolutely um feature flags has been one of the bigger use cases that we have seen across our customers um so they've uh they've seen when customers are storing their future flags as a json uh document um and they've defined all of the flag metadata within that so definitely that's one of the bigger use cases uh for uh storing uh your feature flags with an app config and you could obviously use uh the deployment safety that's built in the deployment strategies that we just talked about um and also you could have um i'll actually like to touch uh on a little bit more about the validation so um there's also a json schema validation that we offers and what that validation does is it makes sure that uh your configuration data is kosher prior to deployment so in this case if let's say your feature flags are in a json document you could verify that against a json schema to make sure that there are no errors and if there are any syntactic errors for example you're missing a comma or you're missing something um or you've made a typo those are caught early on so that when you actually deploy that configuration data uh there are no errors so that value is exactly what you know your application sort of expects yeah sounds like a great segue to what you are about to show so yes i do actually have uh some validators applied to this environment um so what we're looking at here the highlighted section is the json schema for the ec2 applications json validation that was deployed to appconfig so this is a a standard the json schema here and it's really describing what the json configuration document needs to look like in order to be valid and the way to read it is that inside this properties sort of block here i've declared that i want to have a property of background color i've got a human readable description and then i said that i need it to be a string and also i've said down here that this property is required and then the other interesting one here is uh this additional properties value means that i'm allowed to put in other properties into my json document my configuration and the schema will accept that if you wanted to say that this was the only thing that could go into your schema you would say additional properties are false so i can demonstrate how this works with that config so if i go back to my environment and oops go back to my configuration profile rather and i'll try creating a new version of my my configuration document where um i've made some stupid typo uh and i'm setting the background color to zero um so that's not what i want my um my validation said that that needs to be a string so i've saved that configuration version uh and now if i try and run the same deployment that i did before but with this newer version um what's going to happen is um i'm going to get an a exception thrown by the api to tell me um that it's a little um it's a it's a little technical i guess the error message but effectively what it's saying um is that or in this case it's actually my lambda handler i've um uh i've out validated myself uh let me make another change to this uh so yeah the the other piece to this uh puzzle perhaps is that uh uh let me do that um and then what i'm gonna do is let me see if i can i can make an error by using the uk spelling for color let me see if that one will get caught by my validator there we go so this one is telling me no this is also my lambda validator so i've actually uh put two stronger validation on this uh that's a little unfortunate for talking about the json schema but i can neatly segue here to i guess the fact that i've got a lambda function that's performing additional validation on my configuration so this is this is the contents of that lambda function and what happens is whenever i start a deployment app.config is going to call this lambda function with the configuration of the that i'm trying to deploy and so my lambda function um this this line here is just fetching the value of the configuration out of the event that is passed into lambda and then what i'm checking is has the value that i've been passed as the background color property does it match this sort of html color code format so i'm looking for it to be a hexadecimal code of either three or six characters and if it's not any of those then i raise an error so that the validation is failed um so you know this is uh like i said this this accidentally uh out validated my json schema test but you can see here that this is my lambda function saying that it was unable to in this case parse the zero as the string type that i wanted and if i change the configuration profile to have an invalid format so i put the wrong number of characters in it for example then it will also detect that and prevent that from going out to the application so what's happened here is before my application receives this invalid configuration data i'm prevented from rolling it out into the environment so can we say that that the schema validation is for for more syntax validation simpler type of validation of the configuration and the lambda function validation can be more complex validation it could basically check more or less anything with that lambda function that's right yeah the the jenkins schema validation really make sure that in the case of jason at least that your configuration is the right shape so it's got the right properties the properties have the right types you haven't got any extra properties if you're not allowing that for example but the lambda function is where you can can apply whatever logic is necessary to say while the the configuration value for background color is a string is it a string with the right format is it a number in the right range that kind of thing surely that says in the comments that the error is that you spelled color without the u yeah so the error then is that uh my validator code is looking for uh background color without the u and it throws a key uh uh key error on the dictionary that it's received but yes unfortunately html color or css properties don't have the you in um so as a bit of behind the scenes i had all kinds of fun putting this demo together where i was absent-mindedly spelling color with eu in some places and not in others uh it took me a while to straighten all of that out yeah all right vin did you want to add something to the validation yeah i was just gonna say that you know we also don't limit customers uh to probably just attach like you know that either either or uh so you can make sure that your configurations are syntactically correct with that json schema that we were you know talking about and also uh you could attach multiple validators so you can have a lambda validator or multiple roundabout layers uh for your configuration just to make sure that pretty much uh checks against all of the logic that you wanted to check against yeah yeah in this case i think i've got the validators in the wrong order look so it's running the lambda function first yeah probably yeah all right so if you just joined us this is the aws nordic's office hours with miguel negros and today i'm joined by james and vinny to talk about application configuration with aws app config and james is now showing off his amazing ec2 application and we he has made a configuration change and deployed it with so now we have a gray background color and we've also looked at validators to validate the configuration so uh next then talked about safely deploying and we've talked about uh uh well shortly at least about the deep deployment configuration and how to to actually do profiles for for deployment can should we look a bit more into that perhaps absolutely um do we talk a bit about it how to to safely deploy by by doing it in in different ways and can you just show us an example of of how that looks in the console james uh with the uh the monitoring do you mean uh yes yeah yeah so um one of the things that um we sort of glossed over uh when i showed it earlier was this sort of baking phase of the configuration deployment and what's happening there is while app config is rolling the configuration configuration out across the fleet and for a configurable period after it's finished rolling out to everything it waits and it monitors um a cloud watch alarm um to see if your application is performing correctly um and so the way this would work is you create a cloudwatch alarm to say monitor latency for your application or one to say um you know how many errors is it returning out of all the requests that kind of thing and if your application starts misbehaving after this new configuration has been rolled out your cloudwatch alarm goes into the alarm state appconfig will detect that and it will start rolling backward say it starts it uh pretty much immediately rolls back the configuration across everything um back to the previous version the version you were using before you started the rollout so oops if i go into uh this demo environment you can see that i have this cloudwatch alarm configured against this particular environment um and if i just pop over to the cloudwatch console that's this alarm here so you can see at the moment everything is okay um for the purposes of the demo i'm not actually monitoring any cloud watch metrics for this alarm i just have the alarms um sort of exists and i'm going to manually set the status to show what what it can do if something goes wrong so let me start by deploying um whoops by deploying the version of the configuration that makes the background of the page white so that makes it nice and easy for us to tell what's going on and i'm going to roll it out using this linear 50 every 30 seconds deployment strategy again we um the product kind of supports three predefined deployment strategies um that you know we've uh created for different use cases uh but you could always go and create your custom deployment strategies um and let's let's maybe dive deep a little bit uh into that creating your own change actually yeah yeah it's definitely worth mentioning that that deployment strategy does have sort of test dev tagged against it um you know deploying um half of your fleet every 30 seconds is not really a best practice in order to give your application time to detect the problems or the problems to surface i should say so i'm just waiting while the configuration rolls out so you can see that we're now starting to see the background color of the page go white what i'm going to do is pop over to my command prompt and i have a little script that's going to set the status of that cloud watch alarm into the alarm state so this is just to simulate you know having an alarm that might monitor some problem with my application so app config is deploying and baking and what it's going to be doing is monitoring that cloudwatch alarm which should now be showing as being in the alarm status here we go with the little red status here and you can see that it's immediately stopped the deployment and rolled it back due to detecting that that alarm went off and so what it would have done is put my configuration back to the original version which was the one that was loading the page with the grey background and so if i reload the page you can see that that's definitely what my application has gone back to so app config detected the alarm going into that state and immediately wrote my config back to where i was before and this can be used with with any type of cloud watch alarms so so you were just using an example but it could be for instance a canary watching a specific url or it could be well any type of metric that you're that you have alarms against just to monitor to make sure that that the application is still behaving as you want it to be yeah right so should we just have a look at the deployment strategies and how to to create your own yeah let me quickly uh create deployment strategy so i can just put a simple name in there so um there's there's two deployment types there's linear and exponential so this controls how quickly um app config sort of accelerates the deployment if at all while it's going through uh the fleet you can then choose what percentage of the fleet will start or what additional percentage will start receiving the new configuration during each step and then you specify the total deployment time so between them the step percentage and the total deployment time will give you the value for how long it will spend on each step um so um here we would spend a couple of minutes each and then the bake time this is the time that it will wait after it's rolled out to all of the fleet it will then wait an additional 10 minutes monitoring that alarm before it declares that the configuration is successfully rolled out completely so vinnie are there any best practices to think of when when if you're creating your own deployment strategies or is that totally dependent on the application or the the architecture of your application perhaps yeah absolutely that's that's a good question so uh just you know it really depends on uh the use case um that you know we're talking about the recommendation obviously is to roll it out gradually uh rather than you know having that change be uh consumed by the application immediately so um in a case wherein um again you're deploying uh you're allowed listing a user for example um and if you're using app config for that um you could probably have a big time of about a couple minutes uh you know in that case we know that configuration values uh validate against uh a schema or a lambda function we know if that value is correct we could probably um have a shorter wait time as compared to when you know you're rolling out a new feature for your entire uh application in that case we would obviously recommend that um we have a larger wait time and we sort of space that deployment out uh you know across like a few minutes so uh we do have an aws recommended uh deployment strategies uh strategy that we've added in here it's um it's the fourth one so we're in um actually sorry just a minute um yeah uh if you go back uh it's basically the one that progresses slowly and has a higher uh number of bait tanks so i think it's the fourth one so with a growth factor of ten percent uh every it rolls out within that 20 minutes and then you know kind of wakes waits for that 10 minutes for it to bake and monitor for any alarms right and to get this to to actually work as intended you of course need to make sure that you have alarms in place that that are actually monitoring the application correct correct right did you want to add something james i was just going to say that you you can of course manually cancel the the deployment if you know if you happen to notice a problem before your alarms fire um you can also jump in and cancel that yep um manually uh you could always manually roll back uh that configuration uh if you see any anything else that went wrong yeah and of course because you have the versioned configuration stored by app config even if the deployment is completed uh you can start a new deployment that takes you back to your previous version of the configuration anyway absolutely and on rollback it always goes back to the the version that was deployed earlier right to the last available version yep all right so james is the time to look at the the lambda example yeah so let me uh quickly show so the first demo was based on on ec2 instances behind the load balancer but of course as as vinny mentioned it is agnostic basically to what your environment looks like and but there are some differences in how you're using app config based on aws lambda compared to ec2 yes so this is a simple lambda function um that really all it does is it's hooked up to api gateway and when it receives the request via api gateway it returns the text you can see down here at the bottom it says hello demo user you have visited and then just gives you the url that you visited what i'm doing is i've got two feature flags that can transform the the url that you visited into uppercase or can reverse it or of course both if uh both are set to true and those are coming from my app config configuration but the difference here in how i'm receiving that configuration is i'm using a lambda layer provided by app config that actually handles fetching the configuration from the app config service for me so whereas on ec2 i was using that helper helper library that i'd written before in lambda i can actually take advantage of this this layer that's running the app config logic for me and the way that i reach the configuration data inside my lambda environment is i can just make an http request to localhost on a particular port which by default is 2772 and then the url that you request on that localhost server is made up of the again the application id the environment id and the profile id that you have deployed in app config and then it gives you the um the json configuration back that that app config has provided and it's handling all of that caching logic for me instead i don't have to to have to written that in this case and then i just read the values out of the configuration and use them to transform the text so if i pop back over to my terminal i can make a call request to that api gateway and i can just put the string hello on the end and at the moment uh you can see that it's configured to just convert the the text into uppercase but the same as i did for for ec2 oops if i go to app config and then to my lambda application instead we can see that in here i've got the lambda application profile so this is separate to the ec2 application profile and here i've got my two feature flags so if i just set if i create a new version and set it to enable the reversing of the string so now i have a new version of my configuration again and once again i can do a deployment to this so this is out to my environment my demo environment i'm using the same sort of fairly rapid deployment strategy for the purposes of the demo and you can see that from app.config there's no difference between deploying to lambda and deploying to ec2 it's just the combination of application environment and so on that i'm picking um that tells or that matches up with what the application itself is checking so if i come out here and start visiting my uh demo url again as it rolls out um i will eventually start receiving that that text reversed as well so this is where the uh the caching that's being done inside the lambda function for me is a slowing down my demo it should be there in a second this is live demos for your people this is trying to strike the balance between giving yourself enough time in the deployment to show things like uh triggering the cloud watch alarms yeah and making them prompt enough to uh to show that they're working i swear this worked much quicker when i was testing it myself did the deployments did it finish it did [Music] and i should probably check that i uh i do have a validator on this one but what it doesn't validate whoops what it doesn't validate for me is that uh the intent was correct i don't think we've got a way to uh to validate the time i meant what i put i know i did turn it on oh there we go it just took a little while for the cache to expire so we can see that having turned on that feature flag um it's just reversing the string now obviously that's not a super useful demo but this is really just to show that you know i was able to flip on that feature uh fairly quickly uh using um the configuration flag that i rolled out with that config and as you mentioned you use the lambda extension for aws app config which is something that was that was released at the same time as as lambda extensions uh became public right uh it was actually um before that um so along the extension's first release in preview uh and that's when uh app config lambda extension sort of released uh for folks who do not know what uh the app config lambda extension is it it is essentially uh uh it's essentially like a client that runs in parallel uh to a lambda in vacation so uh that makes things a lot more easier with uh for serverless applications because it kind of takes care of um the polling uh the time integral and the caching for you um and james would probably show the implementation a little bit yeah so the uh i should have shown really the the um that's not a built-in thing in lambda i had to add that extension in by by configuring this layer um so you get the the layer name and version is in the documentation it varies slightly per region but once you attach that to your lambda function um the the other thing you need to do is supply um these um this application app config app name environment name profile name values so that it knows which one of your applications and so on uh it should be querying but you can see which is as straightforward as just requesting that particular url uh off localhost um obviously i'm picking up from my uh application environment the the values i need those are populated for me by the um the cloudformation deployment um but but all i've done is use the requests library uh to fetch that and you don't even need to use requests you can use something like url if you want but requests just makes it so much easier right so we're well we're are close to top of the hour so uh time to get your last questions in if you have any around aws app config and and application configuration but vinny i i think is there something uh i think we want to talk a bit about integrations with aws app config tell us a bit about what kind of integrations are there so yeah definitely uh the first one uh you know we sort of just touched on the lambda extension so uh you know where it kind of came from first a lot of our customers obviously had serverless applications and they wanted to kind of simplify how we um how they fetched their configurations uh from app config so land extension i think land extension sort of solves that for our customers uh but essentially we also have an integration with uh aws code pipeline so for customers uh that are probably using code pipeline for the orchestration of their code deployments um we have a similar uh integration with their code pipeline variant acting fig is a deploy action within code pipeline so what that solves for is essentially want to automate deployments or configuration deployments across your environments um so that's where you know you could model different stages within aws code pipeline you could still store your configuration in one of the sources that are supported by aws code pipeline so that includes fitbucket uh github or even s3 uh essentially you fetch it you model your stages and then use actin pick deployment strategies uh for example to deploy with the same best practices that you know we were kind of talking about earlier um and enable rollback in case one of the deployments fail uh what it also gives you is uh essentially a way wherein let's say deployments are uh the application configuration deployments are super critical right and you want to have like a manual review process that that's added between the stages that hey you know if stage one is complete i want somebody to review it and then it moves over to the next stage so uh put pipeline sort of enables you to do that as well and then what it also enables you is to maintain those separate pipelines uh than your code so that you know again going back to that continuous configuration that you know we're talking about um all configuration changes could be deployed through across your environments um from code pipeline um using the orchestration and the automation that that's available there so um essentially we're trying to be well integrated within the developer workflow um and you know kind of so that customers can use us the way the same way that they deploy code yeah and um besides that you said it early on james that you were going to use the console for for the demo purposes but what are other ways that customers are using um app config today and you mentioned that your setup was with cdk as well james i think yeah so that demo environment was built out with cdk you can use that to create new versions of your configuration and then trigger deployments as well if you sort of want the integration there um i think you know part of what we've talked about today though is having your application configuration deployment separate from your sort of your application deployment itself and so you can probably you know probably a good way to do it would be to use cdk to build the deployment pipeline for your application configuration as well but then have that run using code pipeline and the app config integration there i think that's a good way to do it and besides that you can update your configuration using cli or console or cloud formation yeah like like everything else it's all api driven so that you can you know integrate with you know you can either do it directly on the cli or you could start building your own tools if you've got some sort of an internal deployment process that you wanted to integrate app config with you know you can take advantage of of the um the apis and the sdks to integrate that and um one more question vinib we saw the examples that james james gave now that contained one property for the ec2 ones and we had two properties i think for for the other one but how big com of configurations are people using it for um so the limit that we offer to our customers is about one megabyte uh there's also you know when we talk about what is the size of your configuration um we always say that you know it obviously shouldn't be huge uh because you know at that point it's not configuration anymore probably so uh configuration values um generally like we see our customers uh constrained within that one megabyte value that we provide um and uh so far it's it's you know we haven't received any customer feedback that uh that's you know uh that's not enough so generally those values are sort of constrained within that one megabyte there's features in that config you can use to um to sort of um to break it down into more meaningful chunks of configuration as well so those configuration um environments and profiles you know you can you can have a deployment of a a profile that might be an allow list for a bunch of accounts so there's a big long list of account numbers and then you might have another configuration profile that's your feature flags for example um that makes it easier to reason about what it is you're deploying and it also makes it easier to sort of troubleshoot and investigate and diagnose because you haven't got this you know nearly one megabyte of json um that you're trying to work with correct yeah one one megabyte of json is quite a lot of configuration to have all right so any last best practices anything you want to share vinnie or james before we wrap up i mean i would just sort of you know revise like the configuration workflow or the app config workflow workflow like you configure your application configurations you know always make sure they're validated uh and then make sure that you know those uh configurations that are validated obviously are deployed gradually and that's you know what they always recommended um and make sure that there's a rollback mechanism so deploy your configurations the same way as you manage your code and with the same operations for me yeah i i definitely call out having um uh comprehensive monitoring of your application because um you know if you're gonna make your configuration deployment sort of take advantage of all the automated features that we talked about today you need to be able to safely monitor your application or correctly monitor your application so that if anything goes wrong with that deployment appconfig is able to help you out by automatically rolling it back but that means you need to have good alarm coverage or good metric coverage so you can diagnose that right great points so i just want to say as well that i think that aws app config is one of the hidden gems of aws not enough people are using or know about aws app config so far so i think everyone has application configuration and the use case for it so as we normally end these shows just try it out all right and with that i want to thank james and vinnie for joining me today i want to thank everyone for for watching and thanks for the questions and comments throughout the show and next week we're back with another episode of course on monday where we're going to talk about simplifying serverless best practices with aws lambda power tools thank you all very much thank you thank you

Channel: Gunnar Grosch

Views: 81

Keywords:

Id: xGlQUeJQlbY

Length: 60min 3sec (3603 seconds)

Published: Mon Aug 23 2021