AWS re:Invent 2016: Cost Optimizing Your Architecture: Practical Design Steps For Savings (ARC310)

good morning everyone how's it run this morning pretty exciting keynote there a few presents for people thanks so much for joining me today Simon Alicia I'm a head of solution architecture for public sector in Australia and New Zealand you might remember me for such podcast as the AWS podcasts if you're a listener thank you if you're not a listener why not sign up come on we're going to be doing a lot today a lot so once this wakes up there we go it's a wake down like most of us we're gonna dive right in this is a more advanced session so I'm not going to explain what different service is doing all that sort of stuff you've looked that up yourself we're going to cover quite a lot in a hurry many different domains and the objective here is to give you things to take away and actually do if you walk out of this session with one or two meaningful cost-saving ideas that you can actually execute in your environment I'll personally be exceptionally happy and I'm hoping you will too that's the intent and we're going to cover three main domains we're going to cover operational optimization infrastructure optimization and architectural optimizations so there's kind of something for everyone here now the idea here is to show you the money I want to show you where the opportunities for savings exist and Verna gave you a whole bunch of new toys today so you can take those cost savings and invest them in other things if you want to as well but the idea is to show you where you can get the money now I've tried to make this a bit easy because there's a lot of maths going on here a lot of numbers there's decimal places it gets a little confusing so using this sort of little star system that will show you the types of cost savings these are real percentages that I'll be showing you today now I'll point out two things firstly all the pricing I'm going to be using is from the Sydney region just because that's where I happen to reside so it's easy for me to calculate apply your own local region pricing but the concepts will be the same and the percentage savings will likely be almost exactly the same the other thing is some of my pricing that I've used will be out of date today that's one of the joys of working at Amazon you do all this work you prepare what do they do they cut the prices and I can't be upset about that that's a great news for you but again the savings will still remain that you'll see there so I did want to do the quick wins the obvious stuff this is not a basic session but this is the do not pass go do not collect your hundred dollars unless you do this already the first thing is you use reserved instances for stable workloads now what is the magic rule of thumb that most customers find successful here run your system for three months get an understanding of what the workload actually looks like spend a little bit of time tuning spend a little bit of time optimizing then make your RI commitment and your commitment could be a one year could be a three it could be the new convertible ones totally your choice doesn't really matter but invest in something for those stable workloads once you understand them well the second thing that you must do is use consolidated billing because you'll receive discounts with doing no effort there are many services that are tiered based EC to s3 cloud front if you could solid eight your spend you automatically get given the discount money for nothing so do it so Thursday morning in Vegas I am now pretty much 100% starbucks Frappuccino powered so I don't feel bad putting this slide up let's talk about some of the sweet good juicy stuff so you know it's 11 o'clock I figure this is Bisset work I like these kinds of donuts myself so we talked a lot about architecture we architect for availability we architect for performance for security for function we spend a great deal of time doing this but I contend there is a new domain for architecture and that is economy when you're building your systems you need to look at the economy of your architecture because you have a great deal of control over it so what I mean by economy of architecture I mean the same or better outcome for a lower cost and I'll show you how we can actually do that today I'm talking about the ability to trial and change the way the system is built during its own lifetime we need to move away from this model of heavy upfront design some finger in the air predictions of what capacities will need and what Pro all the application will run and instead embrace the idea of radical change during its lifecycle funded by cost savings now there's degrees that you can do this depending on whether you built the system yourself or you're using a commercial off-the-shelf system I'll be showing you options that apply to either now radical changes are possible and they're driven by economics and more importantly they're often driven by the appearance of new services like you saw today that dramatically lower the cost of some of the undifferentiated heavy lifting of IT a service you may have invested significant time effort and money in building yourself you could probably consume cheaper from somewhere else replace in your system the other aspect I think is really interesting and this is a growing area of interest in the community is around transactional cost and operational cost so I have a question is the only participation part of the talk today the first two rows will not get wet so it's not that sort of participation but I have a question for you as soon as my little clicker works there we go who knows what their per transaction cost is for their favorite application not many people who here knows what their cost per hour is to operate systems that they're responsible for good okay that's getting better who tracks it in real time and sticks it up on a board in the corner yep couple very representative of my investigations with customers most of us run and operate systems and have no idea what they actually cost from a business centric perspective so here's the challenge I could have gone down this direction for the whole talk I'm not going to but I want to give you a little something just to give a teaser as we go there are some actionable steps that you need to take in this area the beginner one is simply do it by hand sit down with cost Explorer figure out your transaction rates and do some rough calculations and either be pleasantly surprised or really really shocked depends intermediate you gather these transaction volumes in real time from your systems and you still calculate by hand but the advanced one is you monitor in real time you can plug transaction rates into something like Kinesis fire hose and run Kinesis analytics on it and pour really interesting data in real time now what's my average transaction flow versus my average infrastructure cost and put it up in the corner and say hey dev team optimize that that becomes your measure so just think about things in that term as we go through and optimize some stuff because you need to make this relevant to your business stakeholders so let's talk about operational optimization this is an interesting one because people don't really think about this very much because you know your hire people they do stuff for you I pay them they come in they do stuff you know they don't do this stuff gotta do something other stuff well what does this stuff actually cost so I thought I'd have it a bit of an international investigation so what does it cost for a Systems Administrator per hour is just converted to US dollars around the world and you can see that you know life in Brazil as the systems administrators pretty good Japan's pretty high as well but I'm guessing the cost of living is pretty high but this is just the median system administrators and none of us in this room would ever work with just a median system in most roads no we don't do median DBAs are the same interestingly the parity of DBA per hour cost compared to system administrator cost it was much closer than I had thought I don't know how that happened but again you've got a big range there you know kind of sucks to be a DBA in Singapore at the moment but it's really good in Japan I don't know but anyway all these things have a cost so let's think about what the actual meaning of this cost is so let's talk about a database upgrade we should be upgrading our databases on a regular basis to take patches fixes performance enhancements etc if you're gonna do one of these yourself you're doing a lot of work you're gonna back up the primary backup a second row you're gonna back up the operating system you're gonna back up the server you're gonna try and find the binaries to do the upgrade with anyone done that lately yeah that's a fun morning's work right there then you're going to create a change record then you're going to rehearse it in development because you know this thing doesn't always go right then you're gonna do it in staging and make sure it work properly then you do it in production on most secondary then you'll failover then you'll do it on the primary then you'll make sure it's working and then if you're lucky you've just spent eight hours doing something that has no perceivable value except one hour today or you could do something like RDS and say well I'm going to by we know that I want to apply the update in I'm gonna run it in staging make sure it's okay run in production make sure it's okay I'm going to create a notification record just to tell people I'm doing stuff because that's kind of nice it'll take me maybe an hour maybe and the nice thing is when I do it I have complete control I choose when this takes place the nature of it I can also track at great granularity what happened I can watch it happen either in real time or save the logs for afterwards and attach it to the change record for audit ability so I've been really lazy and made myself my life a lot easier and I've saved the company a truckload of cash depending on where I live just that activity is anything from one hundred and thirty three dollars less to three hundred and forty three dollars less that's real money now you might say well Simon we're gonna spend that money anyway I've got a high these people are not going away I said that's great but you could invest that particular chunk of time slash money into something else of more value like maybe tuning your database might be a better use of a DBA style so what about at the infrastructure layer what are we going to do there so one of the big things that people do is invest in storage and I want to give you a way to save money on your storage without any code changes at all so this is really relevant to people who are running systems that they might not have code control over and this is taking advantages of storage tiers particularly infrequent access now you need to understand your usage patterns to take advantage of this but let's work a real example here I'm storing a hundred terabytes of photos because that's what my app does each photo is about ten Meg and it costs me in standard is three three thousand two hundred ninety two dollars and seventy eight cents per month nice and resilient safe pile of history it's doing a great job but you know that's a pretty decent investment in storage cost what if I know a bit about my data and I know that my data has a long tail so you know after 30 days most of the data actually doesn't get access because people get bored with the pictures I put up there I'm 20 percent of it maybe gets returned once a month with the odd exception so I can create a policy few clicks and say hey apply this policy to my s3 bucket and move stuff across am 32 percent saving no code change no effort I'm now spending two thousand two hundred twenty dollars and sixty-five cents per month it's not bad so some want to point out here today's none of what we're talking about here is five percent saving ten percent saving fifty well we're talking big meaningful move the needle savings those folks standing about this heaps of seats around here if you want to sit down to what about this one revisit and right-sizing or ec2 instances this is a bad habit I see people falling into because we grew up in an age or were you buy a server you live with a server so you never look at the server's again do you you're just deploying you get on with your life well that is not the case in ec2 land as you saw this week lots of new instance types to choose from do you check on a regular basis whether your instance types match the reality of your workload who's done it in the last six months good at least every six months if not once a quarter the updates in the ada best blog saying new instance type available is probably a good cue you can also use trusted advisor for some hints on this and I'll share some good news for you about trusted advisor soon but let's work an example let's take a windows were closed I have running and let's compare two instance types so I've got my m4 4x large cost me just over $2 an hour to run in Sydney I've got my m4 x large cost me nearly 30 cents in how to run it see now I'm running my workload and I look and I say well what's notable about that workload well it kind of pegs out at 15% of the CPU that's what it does doesn't go higher than that that's its maximum rate for whatever reason don't know why that's just what it does so I can do a trivial change and change my instance type down to that X large size and test it because you're always going to test to make sure we're doing the right thing and lo and behold where am i sitting I'm sitting about 60% now I'm really happy with that because I'm a conservative kind of guy I don't like running my servers that 90 percent because we stuff happens at 90 percent does gets a bit shady but 60 percent is fine I've can peek up and down I got no trouble before I even start using auto scaling groups so I'm pretty comfortable with this what have I just done I've saved myself 87 percent on my ec2 bill now I would contend that for most customers the ec2 part of the bill is the biggest part if you go to the whoever's paying that bill and say I've just saved you 87% of your ec2 bill you will probably get a hug you might not want a hug but I'm pretty sure 85% and upwards of savings is the hub zone that's what I'm calling it again oh that's a good thing I'm not but you know we'll just call it what it is so you can actually use trusted adviser to help you with some of this stuff it does give you some really good cost optimization hints and one of the nice ones is in low utilization ec2 instances now this is not so much for the example I just gave you this is for the ones that are pretty much someone turned them on and they don't use them at all like really low network utilization really low CPU utilization take advantage of this trusted adviser so let's get a little more fancy shall we spot instances who uses spot instances here they're quite a few they provide great value for your workloads but for many people they're only familiar with using them for maybe dev test some highly scalable and embarrassingly parallel processing type work you know things that are ephemeral but did you know you can use it in a different way and he comes to code so this is an auto scaling group launch configuration in cloud formation so our first taste of Jason for the morning just so I didn't convert it to the yeah Mel version I probably should but I ran out of time so this is the launch configuration part of our auto scaling group so what do we do so we duplicate our auto scaling group so we'll now have two auto scaling groups for our application and we're going to do a hell of a lot of coding this could take a long time till the boss you might not be available for a week because you're gonna do a lot of work you're gonna add one line to a launch configuration and that one line is the spot price and automatically you have turned this launch configuration which is a new one show picture soon into a spot instance driven Auto scale group so you've probably seen some quizzical looks this is how it looks I have one lb and I have two auto scaling groups one auto scaling group is my standard on-demand or could be an RI or a scaling group doing its work happily but it's really small my other auto scaling group though is my spot instance auto scaling group and for that I'm going to bid the higher than the market rate but lower than the on-demand price now one of the benefits of the way the spot market works is even if you bid higher than the spot price you paid the prevailing rate so if I bid $1 and the prevailing rate is $0.50 I pay $0.50 which is good so as long as I'm bidding lower than the on demand rate and higher than a spot rate I'm automatically saving money of some description they may say i harbored simon their spot instances you might not always have them and i don't say yes you're absolutely right which is why we will set a cloud watch alarm on the group in service instances for the spot instances group and make sure we have enough capacity there and if we don't what is that trigger it triggers our other on-demand orders going through balancing workload playing with some stuff technology not too shabby now we need to understand the price history to make sure we make an intelligent approach here luckily we have the handy dandy console she's probably been fancily updated since i made this slide and we can see what the price history is this is a good example of one in the Sydney region 3a Z's you can see for this particular instance type the m3 medium pretty low and steady isn't it doesn't change much there's a little spike in one spot but it's not one of those ones it's bouncing all over the place so I've got pretty good assurance that the price is generally low so let's work the example here so I've got two auto-scaling groups spot and on demand my on-demand price is about nine cents an hour for demand my spot price that I've seen in the market is about 1.3 cents so if I've got a 12 server fleet if I use it using just on demand that's a dollar 17 an hour now many of you know your hourly cost which is good you should all know your hourly cost if I convert it to this model and aggressively use spot in this scenario I'm likely to be spending 30 2 cents an hour or I've saved 72 percent now this is really nifty because firstly it's kept me out of a hug zone which I know some of us are not too comfortable in but we still saved a lot of money how much I mean 72 percent off your bill that's something to be thought about so let me show you another way save a lot of money on your infrastructure without doing any code changes talk about developers we all love developers developers work hard I was once one and we you know developers work on big projects but they never work 24/7 I have worked on projects where it's happened for a short period of time but the quality of code goes down very quick and the coffee increase is just it doesn't work out well so let's think about this our developers are not working 24/7 even if they're working 10 hours a day I've still got 168 hours that nothing is happening shut stuff off please telling you shut it off you will save 70% it's interesting a lot of people put a lot of focus on their IT spend on production most of the IT spend is actually in dev and test isn't it that's the little secret of the industry so how can you make this easy for yourself well you can automate it there are many different ways you can use there is no right way my imploring to you is to do something so one example is you can use tagging to start up and shut down but be careful with this I'll share an example from an australian customer one of my favorite customers rea group they were really advanced in the database used and they tagged everything i said we're gonna write a script it's gonna go through it if it's got the right tag it gets shut down at night awesome only problem there was a little issue with the code is that if it called the api didn't get any tags back i thought ah untagged instance shut it down so it's a bit of an issue with the api at the time and it was getting no tags back and it was just happily going down and shutting off hundreds of instances it was actually called the zombie apocalypse and they really kicker of the story is that these aam be apocalyptic was running the script killed itself boom so you know use something but be careful what you use now i want to give you a list of things to use it is a completely incomplete list but it's a good one to take a snapshot off so you can use lambda you can use data pipeline you can use cloud watch I'm going to name check an Australian company called gorilla stack who also do stuff in this area so there are lots of options you have turn stuff off please now another little infrastructure one is caching now Casey is one of these weird things in our chair don't you guys have found it but people are kind of afraid of caching it's like aw it's a bit scary and we didn't learn about it in University and it's unfamiliar to us and you've got to preload caches on what if the case turns off and all this good stuff anyway it's worth investigating because beyond performance improvements you can get and this white paper the reason I've linked that is that it just gives you so much information way more than I could give you in this session you can save 90% of your spanner in the hug zone again danger so think about it if I've got a database that's a DBM very large and it's doing 30,000 PI ops single Eisley so just one node and I'm driving it hard and I flip it to an elastic ash node it's an order of magnitude cheaper Wow and my customers would probably be happier yes got to do a little bit of work we're getting to the little bit of work zone but it's something to think about the other reason I mention it is for a lot of applications today they do provide a drop in capability for things like Redis and memcache and if you're not using them you should look into it because you could save big so let's move into some meaty stuff the architectural optimization if you are an architect sitting in this room today you are unbelievably lucky you're as lucky as this gentleman here because this gentleman is standing here he's got levers to pull has me you can pull them down you can pull them up but it's actually really cool with intelligent decisions you can pull different levers and get different outcomes it's awesome so what are some of the levers you could pull well you can do code changes you can actually change code it's actually the best way to fix stuff the number of times I talk to customers are like well this application runs terribly and we want to change the infrastructure so well maybe you should just fix the application in the first place um so we can do that you know and there are architectural trade-offs to be made there are way more decisions than you ever had to make before and on the one hand that's challenging because you've gotta kind of learn more but the flip side is it's great because you've got more choice and you can make better more finely honed decisions and you can test them in real time to see if they make sense you're not sitting there twelve months before deployment going I think if I use this kind of approach it'll be ok you can say well I tried that didn't work I'm going to spend a week and change it to something completely different and it's okay and it really is okay so let's talk about some of those levers and some of those tricks you can use luthier has a web tier no one has a web tier all got a web tier to do something so did you know you don't need to have web servers to host your web team because hosting web servers is kind of boring unless you're doing a truckload of mod rewrites and other stuff you're really just spending most of your time patching feeding upgrading and looking after it so one of the approaches a lot of customers are start to take is to use s3 as their whip - because s3 has this capability called static website hosting worst name ever because it's not static you can run JavaScript you could do cos you can host the AWS SDK now you can do a whole bunch of active stuff from that website and you're not patching it there are no service to manage there's no scaling rules to worry about it just works what does that cost me to run Simon well if we take an average page and these days an average page has 150 or more objects on it and the average size per page is exceeded two Meg it's actually rapidly growing which is interesting let's say we've got a popular website 100,000 page views a day 450 million gets nearly 6 terabytes of data transfer I'm paying in Sydney 1139 dollars and 43 cents per month for that all day every day getting that happening for me now remember our example will for about what it cost to administer stuff well what am i saving on well I'm not patching web servers anymore not doing capacity planning not having to worry so much about my security scanning because the pipeline is much easier to scan there's less surface area my rollouts can be much easier I could do better testing saving hours per month so let's get to something really nifty that's our front end what about queues I've been talking about to you since 2011 without obvious customers and they're awesome for decoupling and availability and scaling or what sort of stuff but did you know you can use them to manage cost yes you can let's work an example here let's trigger our auto auto scaling groups based on a revenue totally different model to think about so we're gonna work an example because it's always easy to work an example to get these through so we have an app it's a mobile app I take photos because that's what I do and I take a photo gets stored in s3 and something happens to it and I care not what that might be in our example we've got a single m4 watch and that can process 1,000 images in an hour and I've got an agreement with my customers it's a freemium service if you don't pay for me you get your photo back when you get it back if you do pay for it I'll get it back to you within ten minutes cuz that's kind of how we roll so I have two auto scaling groups here the auto scaling group at the top the free Q so if I'm a free customer my metadata goes on to the free queue to be processed and the auto scaling group only spins up when I have a thousand pieces of work on that cube so I'm maximizing my work load for that out online but I will wait an indeterminate time if though I'm a paid customer my queue uses a completely different metric you may not be familiar with this metric because it only came out a little while ago it's the approximate age of oldest message so it tells you how aged your queue is remember a ten-minute SLA this says if I'm lagging behind my ten minutes spin up instances process away completely different behaviours of two auto scaling groups based on different queue rules same customer base how does this look from a revenue perspective well let's do an example 2,000 transactions come in half of them a free half of our premium so we in the free mode only spin up one instance for an hour or we process those transactions so our cost is and here we start reading the dot the zeros 0.0003 three six per transaction now if I'm processing on the paid queue though I have to spin up ten instances to get the SLA that I want based upon that throughput so I'm paying 0.002 o16 so again ordered maybe two different costs for my paid versus my free people isn't it I now need to understand what am i charging my free people nothing so that's a cost that's burdened on my paid people what am i charging my paid people do I know if I'm making money on any customer what's the question to start bubbling in your head so let's see if we can make this cheaper and better now that we understand what our cost model is well one of the fundamental rules in architecture is the less you have the cheaper it is of a simpler it tends to be to operate the ultimate thing is the thing that has no moving parts it's like a block so what we want to do is want to simplify so I'm going to simplify by moving us to a lambda baseman model and I'm going to show you the cost implication of this versus just the functionality thing so what are we done here you can see there's no Q's here and we've now like two buckets why do we have two buckets well we're going to use s3 events and I'll show you how to configure that surely but if we had the one bucket and we're using s3 events every time we did something to that object what would happen it would spin off and try to do it again so now we have two buckets we receive the image into one bucket do an s3 event that triggers a lambda function to do my work and then we store it to a secondary bucket now for our example I've taken the worst case scenario of how long it takes to process my image I've given it the largest amount of memory I've gone as hard as I could in terms of the badness scale just to give you a realistic example and I'm now processing my per transaction cost lots of zeroes there I'm going to try and translate it for you in the reader 253 percent savings I've had my transaction cost you take that to your business stakeholder and say do you know which art we can now charge our customers 50 percent less and be more competitive or we could take that money and invest it in a marketing campaign or we could give them a 25 percent cost saving yeah it's up to you what you do with the money but you're now processing better the other thing you've done is you've taken the queueing out so not paying for that although it was really negligible as literally dollars for what we're talking about here the other thing I have infected into this cost saving is you get with lambda a free tier forever in this particular model that would do given us seventy one thousand free transactions every month before I even started paying for it that's pretty good what's the other thing I've done here we've now eliminated our 10-minute SLA Emily we now get people to stuff almost instantaneously and they're paying less for it so how do we set up a s3 notification well it's really tough it can take you forever you know you're basically a jump into here you can also do it through the command line etc can you simply say hey I wanna create an image processor function that responds to a put request on a particular bucket and triggers a lambda function wow that was hard I'm liking this new world it's so much easier than it used to be now you may say aha Simon but the pricing you showed me for your paid tier is higher than your spot tier isn't it also yes it is but we can double down on that we can have both so we can have the lambda function for our page here because it gives us that really nifty controllable SLA and we can continue to optimize that if we want and we could also apply all our newfound spot knowledge to our free tier and drive that as low as possible to almost zero so we can have our cake and eat it too so this is how you can start to use queues based on economic performance now you may say well Simon you've used the easy examples it's all stateless just photos come on where's the data well I agree databases make it hard databases are always the trickiest part so here are some rules of thumb that you need to think about firstly let's stop the religious argument of relational versus no sequel the answer is both gotta tell you they suit different patterns different workloads and you'll often find an opportunity to pull out a particular component and put it into a no sequel database and vice-versa use caching liberally it is an awesome pattern if you look at any large-scale software development company that are delivering web scale applications they have caching everywhere it's just normal we need to take advantage of it more do not conflate your transactional database with your analytical database the how not one on the same there is a reason why redshift exists and there's a reason why Postgres exists and they're not for the same reasons and you need to separate the two and also most often there'll be just a few hotspots in your data bases and these are the giveaways to say AHA that's the bit I need to migrate to something more suitable for that particular workload so it's not saying well this database performs terribly I'm just gonna move the whole thing to Cassandra well that's not going to necessarily fix your problem need to pick and choose so when we pick and choose we use a dollar value as well as a performance figure to calculate that so here's an example of a data set it's a big data set three terabytes and it's running at 80 percent read twenty percent right pretty common work load pattern we see if I sit down and say you know I'm paying a lot for my multi a-z ideas for my sequel to do this I'm spending almost five thousand dollars a month on it I can simply move that data set to DynamoDB I have to make some code changes remember these are some levers were pulling but I know I'm getting an almost 40% saving and probably a better performance profile so again I can decide which levers to pull when it's worth it now I'm not getting out of bed for less than 5% quite frankly so you know we're going to have the numbers high here so this is over 30% so what's the point here the point here is that architectures can evolve they can change now what's one of the biggest challenges are talking to anyone about the whole concept of evolution I have young children we talk about evolution so why don't I ever see anything change well because it takes millions of years for something to change you're never gonna see it it's really frustrating we live in a completely different world in IT look at this week for you guys how much has changed for you in this week it's good yeah things change really quickly we as architects and developers need to take advantage of this and evolve our systems really rapidly in response to the stimuli that around in the world so I thought well let's do a worked example of this and see how this can actually play out so I thought let's build a micro service because micro services are cool I don't know yeah we like micro services so let's build on so I thought let's build one to help us find restrooms in Australia we're lucky we have some really good open datasets do you provides one it shows me all the public toilets in Australia by postcode awesome was it good yeah happy Thomas it let me tell ya I was happy when I found it so I thought okay let's build that and you know I thought well let's take a traditional thought process I'm gonna grab just the language I've never used Python before I thought well I want to learn Python I'm a developer so of course I'll choose the new shiny thing so I chose Python Bottle is a framework my sequel because I know how to code in myseaport it's just easy so I'll go ahead and build that so I built a mucker service so you can go ahead and laugh at my code well let's go stuff and basically all these microservice does is something easy it takes in a postcode or a zip code you might call it and validates it they can only be four digits in Australia so it makes it nice and easy and then it runs a query against my RDS database and says hey get me the list and return it as a JSON payload pretty easy so I coded that up felt nice about myself at all we're gonna deploy this particular micro service well we tend to do what's familiar so I'm gonna deploy it onto ec2 and I'm not gonna do it natively I'm just gonna go and use iced tea please doc so spin up elastic Beanstalk and deploy that's gonna give me some awesome stuff it's gonna give me a load balancer get in communion or a scaling group I'm highly available I'm gonna have a redundant RDS cluster running underneath I'm looking pretty good some downside there I don't have any API protection no traveling no credentials and their management still got to roll my service for and do some patch management although elastic Beanstalk helps a lot with that so got kind of a heavy storage layer but you know this does the job so let's see how it actually looks if you've never used elastic Beanstalk before this is where we have color and movement so this is 8 times speed I'm calling it out because I didn't want to have you sitting here for a while because you know it takes time for instances to spin up but this is deploying from my codebase they're doing an EB create and it's speeding up the elastic load balancer spinning up the instances the auto scaling groups of cloud watch rules etc I really like elastic beanstalk because it does all that stuff for me so this will spin up it'll create all the resources and I'm a happy little camper and I'll show you how it works Shirley will just let it spin round you can see why I did at a time speed because I can't tap-dance for as long as this would have taken it takes a few minutes because you know instances take time to spin up but in general it'll do it in a few minutes and away we go and boom we're done great so what does it actually do so if I type in my url and I do a slash postcode and then I do a slash mm that's Sydney CBD there's all the bathrooms I do Melbourne CBD where I'm from 3000 my suburbs 3 or at 5 I'm pretty comfortable this works does the job I'm happy with it right I could stop there but evolution huh things change so how do I evolve well what's cool what's what's useful what do people like now about containers container eyes we should container eyes so I thought well I'm looking to container eyes I'll be lazy I'll get someone in my office to contain their eyes for me so shame bore the channel is one of the essays in our Melbourne office said I'll container eyes and he did he took my code as it was put it into e CS and containerized it is even the docker file for your reference super complicated so it was really good because we got to say docker a lot it's fun playing doctor a lot isn't it everyone feels good I said doctor today and so what we've got here is something that is pretty much the same as what we had before the instances do spin up faster which is nice but I haven't solved any of my other problems really but I've evolved it to something a little more modern perhaps because I'm using a lot of weight container I can tune my container better than maybe I could tune my application instances particularly for such a lightweight micro service but let's evolve let's continue to evolve let's respond to stimuli so let's land eyes and put api gateway on there as well so suddenly I've taken a vast step forward I've said you know what I'm over these servers I'm over these containers I'm only going to use compute when I need to execute my function and of course micro services fit this model perfectly it's an O'Malley spending money when I'm doing stuff I'm not patching servers anymore I'm not having to do maintenance because you know the little secret of docker containers you still have to patch them kind of good to do I've never fully managed API throttling performance all that good stuff but I still got this big storage layer down the bottom so the wise ones amongst you'll be going too hard that's that's where I'd be evolving next because really you just got a big lookup table so I'm alive you got a sequel database there is would be you'd be surprised why people do the things they do often it's because it's what we know it was super easy for me to set that up so of course I did that first so let's take it to the endpoint and no sequel why's it so we introduced dynamodb and now we have no service we have no containers we have no database to manage we have a completely smooth line with full availability completely treatable performance management and control we now is a service a lot which is way cool insane talker a lot isn't it because you can make people angry because this servers there there's really service behind it it's funny well it's funny to me the downside of this side I'll be totally honest with you is that people get a bit concerned cuz like whoa less familiar deployment model let's just ease up there cowboy I don't know what's going on here I'm not used to deploying this way you've got this crazy no sequel database you're deploying these functions as a service are feeling uncomfortable so I want to show you what the code looks like and I want to show you how you can use existing frameworks to deploy it okay so that's where we're going with this evolution so here's what the new code looks like here's the new code much like the old code what have I done I've ripped out the my sequel calls that you could see there the cursor that was there and I've replaced it with the DynamoDB call so all I'm doing is connecting using the adaboost Python SDK also known as boto into my dynamo DB table I'm running a query I'm still iterating through the items and responding to it so my message here is that any component developer can convert from running a relational database to a no sequel database it's not that hard so I've done that here basically well you haven't solved my deployment issue so I thought well that's a good question and you know it would have been easier me to say well using Amazon deployment tool like blah or X or whatever you say well that's your ecosystem you familiar so I said I didn't want to do that as I said never used Python before not familiar with it so I looked for what are the sort of frameworks they get used for deploying this kind of software and I came across this one called Zepa and it appealed to me because it's got such a cool name you know is that moon unit set where is it Frank Zappa Zeppo is a very popular open-source deployment mechanism and I've got to say it is really cool and what they did is I said we've got this deployment framework we're going to just include the ability to deploy to Amazon lambda awesome let's see what that looks like so what we do is we do a deployment is a configuration file behind this with about three lines in it the lines are the credentials I need to use the s3 bucket and which environment I wanted to point to it's not that hard so we go ahead and we deploy and this is the real time video I haven't sped this up so there's a per deploy prod and he goes ahead and packages my project up from my laptop that was in git and sends it up across what was a particularly poor communication line at the time and it starts to create the lambda function it creates a few health check rules for me as well to keep it alive and running for me which is nice it will also create a API gateway for me it does all the plumbing does all the IOM rolls for me everything I didn't have to do anything it was really easy to set up which is why I want to share this with you it also shares one of those beautiful features of many tools which is the progress meter that doesn't get to 100% don't we love those and it moves that are funny so this will finish about he could finish it about 93% something like that but it goes along and the thing I do like is it does say this step will take a bit a bit being an interesting measure of time but this is real time so it's going ahead and deploying deploying the API gateway see 94% it's good done I've deployed my micro service how cool was that so let's go and see what it looks like so again I can make a call but this time I'm curling the API gateway slash prod slash postcode 2000 that Sydney boom let's do Melbourne boom let's do Elston week 3 105 boom nothing changed but everything changed i evolved how i delivered that output i'm doing it way cheaper way simpler way more efficiently less deployment steps I've evolved my architecture along the way can be done so that's all the good what about the bad there are two anti-patterns I want to share with you because these are things you should not do and I will encourage you not to do please the first one is getting confused between high availability and cost optimization and I see this happen all the time particularly driven by product owners who say it's got to be as cheap as possible and then you deploy on one node and the node goes down and there's an edge and they say but it was down and you said well I said it would go but it has to be up all the time so it's a whole different conversation people so what you want to do is model for availability then cost but there is one really interesting trick you could do for the in particular related to protecting yourself against AZ interruption so if we have an application let's say we want to always maintain twelve instances running for our production load we need to deploy it in duplicate across multiple AZ's with full capacity so it we're never affected this is a true h.a architecture but there's a little mathematical trick if you're deployed in a region that has three or more aziz so remember we're protecting against an availability zone level disruption so in the top model we've got to run 24 a Gregory instances to protect ourselves in the bottom model we only have to run 18 why is that because I've only got to run 12 at any one time so if I lose an AZ the bottom one still has enough instances running the top one still has enough instances running but to get there I have to spend 25% more so we can immediately save 25% on a h.a configuration just by spreading across three days if you have them available to you that is a simple configuration change in your auto scaling group go ahead and do it immediately less nodes having to run same aggregate workload the second gotcha who here stores binary large objects in their relational databases not many this happens a lot one of the benefits of my role is I get to meet with a lot of customers and I see a lot of commercial software and a lot of self driven software and this happens surprising amount so I'm just gonna stand here and say do not do this it makes your databases run really bad really slow and they're very very expensive how expensive you may ask well let me show you let's say we're storing our blobs in a table we've got three rows in our table user ID image good and a blob nice lazy programming way to do things and each image is 2 Meg I store it in my database and we're really successful and I'm now got three million rows I've also now got a nearly six terabyte database to manage which is hard and painful and annoying and I'm also spending three thousand two hundred and seventy nine dollars and 56 cents per month to run this in a chained mode with just standard storage so ain't she if I architect this the way it should be detective what would I do with my blobs put them in s3 wouldn't I that's where blobs belong and I simply change my table and say point to where the blob resides and have the cove get it from there and now my database shrinks down to less than six gigabytes my storage cost is far lower just to store that storage is just less than $200 and even with all the gets and puts I could possibly need it's just over $200 so my RDS cost goes down in my every aggregate cost has dropped and I've saved 42 percent just by doing things the right way the first time so make sure you avoid that trap and if you see commercial software that you use doing this have a stern talk with your provider and encourage them to make it more effective to run so we've covered a lots that I have ripped up in the donuts and got to the goodness inside this is a cruel slide before like should I apologize first sorry you know hopefully they've got donors and what I remind you is we're talking about here is a new domain for architecture we're talking about the economy of your architecture think about how to get the best outcome at the lowest possible cost think about how to change it all the time because you can change it based on economics and understand what your transactional cost is there's everyone rushes for the door there is one more thing everyone in this session today gets 30 days free trusted advisor starting on the 6th of December thank you for coming along today this is my gift to you it will automatically activate based upon the email address you sign up to re-invent you if you say to me but Simon I use a different email address give me your card and I'll have it activated on the address that you want thank you so much for coming along today please fill in your evaluation I'm happy to answer any questions that people might have but thank you

Channel: Amazon Web Services

Views: 7,326

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

Id: qYHR_V1lvNU

Length: 46min 20sec (2780 seconds)

Published: Fri Dec 02 2016