Are you Well Architected?

so this session is going to be about well architected really trying to answer the question are you well architected because as we see you know failures happen all the time and so how do your systems or your processes respond to those so just to make this a bit more interactive because all I can see is a sea of blue lights from headphones is who here is building technology solutions and fills but their teams are building something that is well architected it's following best practices hopefully most people they've got great teams most people feel reasonably confident ok now when you ask that question people feel a little bit less confident when you ask them well do you feel confident in that when you think about all of these different areas so maybe some of those areas would make you think hey my team is great but we want to dive a little bit deeper into how they thought about security or reliability one thing that can help you feeling more confident about whether you're building well architected systems is to review your architectures is to have a conversation about the systems you've built and work out whether it's been following your best practices of course doing that in a consistent fashion can be difficult the person who's involved when you're viewing the architecture may have had a bad evening with their football team and so they might not be reviewing their all the architecture the same way that they've reviewed other architectures or maybe they've got a focus on security so they'll dive deep on security but maybe don't feel so confident about asking about reliability and when I talk to most customers it's rare that they thought about applying a consistent process across their whole technology portfolio how do you make sure that all of the systems you're building are following some level of best practice and so that's why we created AWS well architected is to help customers understand if they're following best practices and of course then be able to make informed decisions about how you might address anything you see in there that you might want to improve so let's talk about the history of well architected so well architected has been around for a number of years it actually started in 2012 anywhere solutions architects started having conversations with customers asking hey well is this approach to building this architecture well architected and we've evolved that over of years one of the things I'd really like to emphasize is that well architected is about AWS listening to customers and looking at what is working for them and so the best practices that we talk about evolve and change over time so this is not a fixed point in time this is the best way to build a system we are looking at what's working new technologies how things are evolving patterns and practices and building that into well architected and in 2018 we released the AWS well architected tool which you can use in the AWS console to review your architectures for free so as much as possible we try to give you not just a framework for reviewing architectures but also the tooling for doing that process as well so what is the AWS well architected framework I like to think about any kind of system will process in terms of why starting with why and in this case what kind of benefits do customers see from using well architected so when I talk to customers about the benefits they see from carrying out well architected reviews on their architectures they see these kind of benefits so for example they can build and deploy faster and that happens because well architected emphasizes using automation to build systems so you spend less time doing manual processes and have human error and have more time with systems which are repeatable evolvable and hopefully high-quality one way to think about well architected is a mechanism for your cloud journey so as you move from working in an on-premises environment and you're starting your cloud journey well architected helps you to learn what the best practices for building in the cloud are one of the things that well architected gives you which as an engineer I've always looked for is a way to measure architectures is this architecture following best practice is it any good and so that's one of the key value offerings from doing well architect it is it gives you a way of reviewing an architecture and give you some sort of measure of how well it is falling best practices and of course when you've done that measurement you then have the opportunity to improve that architecture so we also provide you with advice on how you can improve the architecture based upon those findings so what is the well architected framework effectively it's a set of questions and design principles across five pillars one way to think about that is to think about when you're building technology solutions it's a lot like constructing physical buildings if you're building any kind of physical constructs such as like the Excel center you really have to think about the foundations of that building because if those foundations are not solid then it's going to be half of that building to be safe and easy to use but also it's going to find it hard to deliver on what it's intended for so if you don't have good foundations you might build that library it won't be safe and it won't be a great place to read books and the similar thing when you're building technology solutions if you neglect the five pillars that we identified the world architecture framework security reliability performance efficiency and cost optimization and importantly how you're going to operate that system one of the things we see is that when people build systems they don't necessarily think about on day one am i designing this for operations so you have to think about how you're going to also operate it so if you think about something like the Excel center it's not just enough to think about its physical construction you also have to think about how is it going to be used and as you'll see with most technology solutions you'll put a lot of time and resource into the design phase but the runtime will actually dominate your costs and the value of that system so you really want to put effort in from day one on thinking about how that system is going to be used so how are people applying well architected one of the things we like to do at a ws is to create ways of doing things that customers can choose how they apply them for themselves and what we've seen as a reoccurring pattern of success are these three things firstly people who are successful using well architected use as a way to have a conversation about how do i improve my architecture they don't use it as an audit process so it's not about blaming someone about the mistakes they've made it's really about a consultation on how do I look at this architecture and how can I make it better secondly the other thing that we do is we make sure that well architected is pragmatic so all of the advising well architected is based upon experiences of real customers running real systems on AWS so this isn't based upon people thinking in ivory towers about the best way to run architectures this is really about have we seen customers be successful with this and so hopefully when you're reading the well architected framework you'll see that the advice is based upon things that you've also seen being successful as well and finally I would say the other thing we see is if you use well architected as a continuous process so if you're thinking about a product lifecycle using it early on in your design phase and as your product matures helps you to continue to look at your architecture and work out how you can improve it what you don't want to have is a static architecture which you have to rebuild every few years because you haven't continued to evolve it and so the well architected framework allows you to turn that into more of a process so how might I go about reviewing an architecture and here you have choice so this has evolved over the years so one of the things you can do today is that you can go into the AWS console and you can review your architecture using the well architected tool and we built that to be an educational experience so as much as possible we've tried to put the learnings of how to build good architectures into that experience so we won't just help you answer the questions but we'll also try and get you and give you advice on how to understand how we think about this question the kind of things are important and the kind of concepts that you might need to understand and so you can use the well architected tool in the console for free to review your architecture and of course the advantage of that is is that you can review which ever workloads you want when you want so a good example of that would be that customers might review an architecture early on in the design phase and then as they're building that system and they make design decisions they can just go back into the tool changed that one question and then carry on and we also give you the ability to create milestones so you can see how your architectures are improving over time your next choice is that you could use a partner so we have select APN partners who we have trained on how to do well architected reviews how AWS solutions architects think about architecture and how we review architectures the advantage of this approach is that obviously everyone's busy who here is not busy put your hand up no one everyone has more work to do they then can possibly do so an APM partner can help you bring in extra resources to work on your systems and critically if you find issues with those systems they can be hands on keyboards and help you fix things so this can be a great way to actually move forward in terms of architecture continue to deliver features but also address some of the issues that might be slowing you down and then finally you could talk to an AWS solutions architect now this is on a best efforts basis so a solutions architect to sit down with you and review your architecture we recommend you use that for your critical architectures or when you want to have a conversation about the thematic issues you might see in across your workloads so imagine you reviewed five or six of your different architectures running on AWS you could then identify that maybe there's some issues you're seeing that are repeating pattern and is there any training or anything that anybody else can do to help you address that more holistically so we're going to be talking today about a real life example about how a customer work with a partner to improve their architecture and I wanted to explain to you how that model works before we dive into the actual example so firstly you can engage with an AWS APN partner there's a list of the current ones on the website up here who can carry out what architecture reviews and they will review your architecture for free so effectively though we view you architecture and work out where there are places where you can make improvements to their architecture and they'll write you a statement of work or things that they would improve and of course that will cost money to have those statement of works implemented so if you're trying to justify making that happen what AWS will do is if you agree to have that partner fix those issues that AWS will give you five thousand US dollars worth of a dubious credits to offset the cost of doing that and that's because AWS wants to see you succeed in building and running systems ultimately if you're successful then you're more likely to be working with AWS and we're more likely to see you continue to exist as an organization and it gives us more opportunities to work with you to make architectures better so I'm going to switch over now to give you a real-life example so I'm going to ask Phil to come up from steam house and he's going to talk about how they worked with one of their customers to improve their architectures okay any sound yet good sound right I'll trial start again so hello everyone Thank You Fitz my name is Phil horn I'm from a an advanced consulting partner based in Manchester we've been a well architected partner for about the last 18 months during that time we have run about 20 reviews with customers some existing customers some new customers and as Fitch said what I wanted to do today was come up and tell you a little bit about how we go about them and a real-world customer story so over the course of those 20 or so reviews that we've done we've established three common reasons three drivers for why people are typically take up a review the first of those is some sort of disaster some sort of security issue or stability or costs running wild and and the business needing to get a bit of control on that others can be sort of tactical sort of short term type reasons for example peak trade or some media of that's about to come up and the business wants to get some confidence in its platform and in the preparations that it's made to get through that particular peak event and the third typical one that we see is something a bit more strategic looking a bit longer term and a business knowing that they're about to embark on a new phase of that business some major change in the business and again one thing to get confidence that the platform that they have in place is going to serve that business as it goes into its next phase so the business that I decided to tell our story about is this business called kanno anyone raise your hands if you've heard of can Oh brilliant okay now I this room is full of people and the people watching their you know the presentation full of people that should feel a great deal of affinity for this business their mission their reason for existing in the world is to teach kids how to code okay as it says on the slide there there are 20 more than 20 billion devices connected devices around the world today and yet there's a tiny tiny percentage of us that actually knows how to understand and influence them my own personal story and this is I've got two little kids 9 and 11 years old I bought them a can o kit I gave them the box and 45 minutes later they were there working with the kit and coding with it if you haven't got a can o cat and I'm not getting commissioned but if you haven't got a can okay you definitely definitely should have one okay so can I were a good story apart from being a really inspiring business to work with can oh are good because they are an example of two of those drivers that I was talking about before they were going to market peak trade so before Christmas last year with a new product that they were doing an association with Harry Potter so they have a coding wand which actually allows kids to cast magic spells and code those spells themselves so very cool but also an exceptionally high profile brand that no one really wants to have any sort of disaster with so they wanted to bring was in to so the engineering team at caño wanted to bring those in so just sense check the preparations that they put himself and put in place themselves for going through that peak trade event and it wasn't just Black Friday their bigger concern or the bigger reason for doing this was kids opening their their gifts on Christmas Day and Boxing Day and then starting to use the application and application in anger the second driver for them was that they were moving from a start-up they've been around six or seven years they've grown very well during that time but they are on the cusp of moving to really quite significant growth globally so this was the more strategic long-term consideration about this platform that we've been building organically and iteratively for the last six or so years how well is it gonna serve as when we actually move to this next phase in our journey and as Russell the principal engineer at caño says here they wanted to pause and put their AWS estate in order and that was the point at which their AWS account manager said what you really need to do is well architected with you and I will introduce you to one of our partners for that and that that's how we started our journey with them so what did we do then so we go in to a review consists of a workshop with technical and business stakeholders we run that on-site with customers takes about half a day and another half a day to prepare some sort of report and presentation back and our recommendations and suggestions for a mediation so we carried that out and we also it was a little more wide reaching this engagement with Calo where we looked at the load testing they done and we found some just a few to be fair a few remediations that we recommended to get through that pete trade event there were some cost optimization things there some additional monitoring recommendations that we made and there were also a few scaling bottlenecks and the single point of failure that was the main engineering remediation that we recommended and so we the guys can oh we then helped them to react attacked a server less platform using lambda API gateway and cloud front and the news was very very good okay I don't think I'd be using this as a case study if it wasn't but they saw a massive increase in traffic across all of their sites across all of their applications including the the Harry Potter launch and it was very successful for everyone within the business now looking at the second driver the where we were looking at how is their platform going to serve them longer term as they go from start up to scale up our recommendations were a bit wider reaching okay and we so our consultants proposed this platform this architecture here which is kubernetes on eks okay this was quite a this was quite a shift for that engineering team there were many people within the engineering team that had already started considering a containers based architecture and really what we were doing was validating a lot of what they were suggesting themselves and and giving the the third-party validation for that and our journey to actually coming up with this with kanno was again to run a workshop involve that engineering team involve area so the technical and business stakeholders not to mandate that this is the right architecture for you going forwards but to get that buy-in and to get that common belief that this was the right platform for the future and what we've pulled out here are again we've got five pillars of the of the framework and we've listed out some of the the benefits the rationale behind and why we would do that if I just pick a few from there so certainly from an operational perspective within Kanno there's a number of different teams working on different workloads different approaches different technologies and bringing the whole organization on to this kubernetes on eks architecture provides a unified approach which then lends itself to greater automation removing risk across the business and and I think the significant one is also for a business that is going to be recruiting a lot more engineering staff going forwards having that single unified approach onboarding new staff and having that common way of doing things is a big benefit for them loads of security benefits from moving to the kubernetes architecture reliability performance and then from the cost optimization perspective the consolidation the greater density of infrastructure within the eks that kubernetes on eks architecture means that we are estimating that there's going to be around a twenty to thirty percent cost reduction on top of the use of our eyes which we're expecting to see around a fifteen percent cost reduction in their bills so that pretty much brings us to the end of this case study we're continuing to work with Kanno as we build out that architecture we provide them with a 24/7 managed service and provide DevOps engineering for that business as well to continue to evolve the platform and that it's me if you're interested in hearing more about the kanno story or if you'd like to speak to us about a well architected review we are there stand b16 and yeah thanks very much for listening thanks Phil for that so as you see from that story you saw that the consultative nature of looking at an architecture working out as a team of partner and custom of how you can improve an architecture we really emphasize that in well architected that we're really trying to help people think about how to improve architectures and we're not trying to look at a way of seeing where people have gone wrong because the reality is is that as we talk about architectures the reality is that you know building good architecture is hard and we as an industry need to help each other get better so what have we learned from doing well architecture reviews I have a few observations there oh so a SS itself as solutions architects we've done over 10,000 we'll architecture reviews so we've looked at over 10,000 different workloads that customers are running on AWS and we viewed those architectures and had conversations with those customers about what's working what's not working and try and understand what the learnings from those reviews have been and of course we use that as part of the process of improving the well architected framework having these conversations helps us to understand best practices or emerging patterns that are working well for customers and so the things that we've learned that work well are that doing reviews earlier in your design process makes a massive difference and one of the reasons without of course is if you think about lean engineering is that often people talk about the earlier you catch a defect that defect the less it costs the reality in technology software especially is trying to introduce something like security towards the end of the the process is going to be pretty painful so by doing a well architected review at the beginning of the design process as you start to think about how you're going to build this architecture asked him some questions around hey have you have you classified the data that's in this system have you thought about how you're going to protect it have you thought about the regulations that might apply to this data and how you're going to look after it afterward having that conversation early on is a lot easier then to think about how you're going to make that system secure reliable etc the other thing that we discovered is generally people don't make bad decisions maybe this is me being slightly positive but generally what we see is not that people have made bad decisions that they decided to do something that was a bad decision you know the the wrong choice it's more that they never made a decision that they neglected to think about something so maybe you often have that conversation where you look at somebody in say and I and are you backing up your systems and they'll have that look in their face where you realize that they've not actually really thought about how that's going to work and that's the kind of thing you see when you do a well architected review is that people forget to do things and by having a consistent review process it's just a way of reminding yourself of how to do that and the other thing that we see from doing reviews is that most architectures are going to have high risk issues in them now this may sound like a sad state of affairs for architectures and the systems you're building but the reality is is that most systems that people build have got latent design decisions in them that are not optimal and by going through a review process you surface those to yourself and you can then make an informed decision about where to invest on what you're going to do about those things so rather than having those things caused you problems at 3 o'clock in the morning you can actually proactively think about hey in the next spin as well as doing these features we're going to pick up this one story where we're going to improve our security or reliability posture or whatever it would be so being able to understand what the latent issues in your architecture is allows you to make informed decisions about how you address that so thinking about how we've seen customers use well architected and there are many different ways to use it but the three primary approaches that we see are firstly learning best practices so when you're moving to the cloud from an on-premises environment some of the ways that you used to build architectures change the constraints have been removed the tools that you have at hand have changed and what are the best practices for building systems in an on-premise environments are not the same best practices remove building in the cloud so as a technology leader if you're thinking hey I've got teams building things on top of AWS for example how do I know if they're following best practices in fact what are those best practices so the well architected framework documents in one place the best practices for building architectures across those five pillars so it helps you at the beginning of that journey know what the best practices are secondly you can use the well architected framework and the tooling as part of your technology governance process so as you start to look at systems and think about moving them into production the well architected review process allows you to look at that architecture and say where are their deficiencies in this architecture as a business do we want to take those into production do we accept those risks or do we need to address them before we go into production so it allows you to make that informed decision about how you're going to do governance in a consistent way because one of the tricky things with most governance processes is doing them in a repeatable way and making sure that you've covered all the same topics making sure that you understand where the risks are and how you're going to address them and then finally is this idea of portfolio management most modern businesses are dependent upon the technology stacks that they are running however as a business you don't always have a viewpoint of what that technology portfolio looks like so how do you know as a business where the risks are in your technology portfolio what is that technology portfolio and consequently well should you be investing time and effort so using well architected to understand and document the workloads that you're running the risks are in them and how you're thinking about improving over over time allows you as a business to think more actively about the things that are actually critical to your everyday success which you may not actually be actively thinking about on a day-to-day basis in the last 15 minutes I'd like to cover off five takeaways it's actually six I don't know why I put five because I started off with one per pillar and then I had an extra one probably something to do the way that I ought to takeaways as well but what I want to do is to you try and give you five or six ideas that make you think differently about architecture so hopefully these are ideas or ways of thinking about architectures that at least one of them is going to be something that you can take away and apply and it will help you so the first one I want to talk about is planes of operation when you're thinking about operational excellence and you're building a back-end system or a service one of the things that's interesting to think about is planes of operations this is a concept that comes from telcos and and networking and really what it says is that when I build a system when I build a service I think about three planes of operations I think about the data plane which is what I used to talk to the service so imagine I was building a database service offering that data plane would be where I talk to the service using something like ODBC so that's the data play and that's the thing that you talk to a resource when you're using the service and then the control plane hopefully you're familiar with it's the API that you would use to request resources from that service so in the case of something like RDS those are the api's you're calling to say give me an RDS database and so the control plane allows you to request resources and to specify how they should be configured and then the third playing which people don't really talk about too much is a management plane and this is the plane that the person running the service or the backend system uses to manage and operate that system so this is the systems that are responsible for making sure that that service is available adding new features capabilities to it etc and the observation I want to make to you is that the code that your operations team are writing today to look after your back-end systems whether that be to do backups to configure to change configurations to do deployments whatever it would be that is actually the top plane then a management plane and that's the plane which you should be treating with very high levels of engineering discipline and unfortunately we haven't always done that we haven't really thought about operations code as being really important and so one thing I'd like you to think about when it comes to operations is to think about your operations code as being actually some of the most important code you have and it's the code that you should be doing to that at least the same level of engineering discipline as the rest of those control planes but security I'd like to introduce you to the ideas of playbooks and lumbergh's i presume some people have heard of these terms anyone put your hand up if you have okay so one of the things I see me play books and rum books is that we all use them to mean different things so these are my definitions you're feel free to use your own the way I try and remember play books and run books is that playbook the pian playbook stands for process and the are in rumburk stands for routine and so play books are more to do with how do we handle situations in a general way what's my my process for handling lists and so for example in the case of instant response you might have a playbook which is something you've written in markdown which tells you when you get a security incident that you should pay to the security team contact they double your support isolate the instances like take away their security groups make see if there's any IM entities on that instance that have got whites to create resources see if there's any like persistence going on so if those iron credentials can create EBS volumes make sure that those you've got understood what's going on there and so the playbook basically documents how to think about that kind of situation and of course you can evoke those play books over time as you see what works and what doesn't work and we have this concept of a game day where you can simulate failures to help you improve things like your playbooks to ensure that they actually work when situations occur now as your playbooks become more mature you'll start to see some of the processes happen a lot or they reoccur and they become more routine and that's when you can start thinking about having a run book and with a run book what you're actually really trying to do is when this situation occurs here is the code that i want to execute and so in this particular example with the instant response you can have something which is listening to cloud watch events are looking for anonomys how do you say that word and you can look at guard duty and cloud watch and cloud show and see if there's anything happening that you don't like and if you don't like that you can trigger a lambda function that does all the things that you were manually doing in the playbook before so you can see how one box effectively allows you to move from a process of trying to do things manually to having something that you can do in code but of course one of the advantages of doing things in code is that you can test it iterate on it improve it see how it's changed and often when people talk about one books and playbooks them there's a there's a sort of gentle push back off we haven't got time to do that what you'll find is that you can apply one ebooks and play books to multiple systems so as you build these these become things that you can use in many different places and many different systems and as I mentioned before they become part of that management plane of your system for reliability I'd like to talk about recovery you wanted oriented computing IOC who's heard of that so this is a bit this is a bit more niche so recovery oriented computing is really about changing our mindset from mean time between failure trying to minimize that to focusing on mean time to recovery how do we allow our systems to cover more quickly and it's kind of like Verna Vogel's would say that everything bells all of the time if you know everything fells all the time then you can put some effort in to try and stop those failures from happening but what's actually more important is how you respond to the failure and how quickly you can recover from it and so when we're building systems we tend to do a form of testing which is testing the happy path the happy path in any system is the code that executes when everything is working fine and when you talk about testing you'll see that most testing strategies will say let's test the system works does it deliver the features that the users want and of course that's an important thing to do you do want to make sure that it delivers on the expectations of your users but of course you will find bugs in there and when your that happens you'll wipe mitigations that will try and fix that so you'll say hey when this error occurs let's do this thing to get us back on the happy path and that's generally how most systems are built and tested as well the issue is that when I read most root causes analysis so when you're looking at what causes most failures when you look at news articles about various organizations whether they've had an outage or some sort of a security incident or whatever would be you find a week reoccurring pattern and the pattern goes like this a failed and then the mitigation for a failing failed as well and it happens constantly and the reason for that is because no one tested that failure pathway so the clicker was now failing on me which is a be helpful so the take away on recovery wanted computing is to think about the untested path will fail so in your system if you don't test those pathways they will fail because the first time you run that piece of code or that process it won't work because no one's ever tested it and so as I mentioned before you can use game days to address this so an idea of a game day would be is that because you've got your systems defined as infrastructure as code you can bring up a duplicate of your application service whatever that would be and then you have somebody who understands that application or service introduce a problem into him but you don't tell your team this you tell them we're having a game day we're going to cause a problem it's going to happen sometime today I'm not telling you when it's happening and I'm not going to tell you what I'm going to do and the idea is is that your team firstly the first thing they normally spot is they haven't got sufficient diagnostics and monitoring to tell them what's working what's not working so it helps your team to understand how they got the right tools then when things go wrong they actually know that they then need to fix those things and they get to work out whether they're there play books and run books actually handle this correctly and what you'll see is that as you execute game days that your systems will become more reliable because the things that we're going to go wrong without testing are being found and being fixed so game days are a way of you not only finding out the errors and the problems in your systems but also building organizational memory of what to do when things go wrong and one of the interesting things about building high quality systems is that the better you get at building these systems the more reliable the more secure they are the less chances you have to learn about what happens when they go wrong so you need game days to offset that in performance Deming cycle is your friend this is the plan do check act process so if you've got a system that you're thinking hey I would like the system to be forming faster it's just not fast enough or it's not reliable enough it's not secure enough whatever that metric is that you're concerned about you can use the Deming cycle to target how you improve that and really the Deming cycle is about saying how do I take a process and how do i improve it but you can apply that exact process to any system and on AWS you can approach it this way so you can first of all pick what you want to fig fix so you're going to say I'm planning to reduce the execution time of this particular system so it's got maybe it's a batch process because you defined your infrastructure as code so you've got a text file such as cloud formation that defines your infrastructure the networking the load balancers the database systems what types of ec2 instances your use of different things how you're using queues sqs this is all defining code you can take that code and you can check it out and you can say let's see what happens if we use one of the new and ec2 instances so you go into that cloud formation you change in the cloud formation where it specifies the instance that's being used there and then you trigger off your build process and of course if you're following well architected then that will be a continuous delivery process so see ICD takes the code creates an environment deploys it onto it once and load tests for you and then you get some metrics back and you can look at those metrics and say what do those metrics tell us do we actually get what we wanted is the system faster now did it do what we want of course we're also thinking about has this introduced any reliability problems or has it changed our security stance or has it changed the cost of the system are we happy with the balance for those things if I am happy with the balance of those things then I could check that change back into mainline and then the next time we do a production to we will have a slightly faster system and of course you can iterate on that you can keep moving forward and one of the things you find when you look at systems where you're trying to improve some sort of KPI is the reason that people generally don't do it is because it's just too hard it's too risky so when you can do it in a separate environment in a risky way it really sets you free and allows you to think about how can I improve that architecture and of course that also makes running game days and things like that much easier cost to me is always a tricky one who here has had some form of technology education like who's done an IQ degree or something like that anyone done one of those okay and in that did it cover security put your hand up a bit covered security okay and now put your hand up if it covered cost did it anyone so one of the problems we have is the vast majority of training courses and education around technology architecture etc does not talk about cost and it's a bit like the Sapphire Whorf hypothesis or if you don't have a name for something you can't think about it because none of us have ever talked about cost we have a blank space in our head when we come to thinking about this when you are on an on-premises environment it's really hard to say hey I don't need these servers anymore can I have that bit of a budget back now of course when you move to the cloud that's actually possible so one thing to think about is firstly most of my team who's building a system don't think about costs or think about mechanisms that you can put in place to make sure that everyone is thinking about costs so if you have a dashboard maybe have a KPI which is what's the dollar cost per request of the system and think about what is the value being delivered so when we talk about cost optimization it's not just thinking about how do I reduce my AWS bill it's also about how do I make sure that I'm delivering good business value and balancing those two things out and so when you're thinking about cost think about firstly that most the team probably aren't thinking about cost and we need to make sure that everyone is thinking about cost because ultimately as AWS we actually want you to spend less on your architecture so that you can use that money to actually have more developers or more people in your team adding are you we don't you spending stuff on resources you don't need and my bonus takeaway is the well architected labs so we have on github put a bunch of source code that tells you how to do various things to be well architected and we did this because you want it to give you some executable content something that you can do in a short period of time you can go into the labs find a concept you want to learn about you can check out that source code play with it work out how it works you can use that source code obviously to implement your own systems but more importantly it gives you a place whereby you can see how the well architected team would go about implementing these types of approaches so the one architected labs is obviously available on github I'd really recommend you go use it and if you've got any feedback you want to give us please submit some pull requests as well so with that if you want to get started with well architected today I would say as with most things on AWS just roll your sleeves up we have online resources that will explain to you what the well architected framework is we actually have free training as well we have white papers and Kindle editions that you can read we also have partners and your account teams who can actually help you thinking about how to get started with well architected but more importantly we built a self-service tool which is free which is an education environment so you can start using it and it will help educate you as you go and with that I'd like to thank you for your time and just ask you firstly if you can use the app to give us some feedback on how this session went and secondly to say that we've got some free swag at the door which is not meant to be influencing the vote that you're given in terms of how well the session went with that thank you [Applause]

Channel: Amazon Web Services

Views: 12,185

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud, AWS Summit

Id: gjNPpjYNiow

Length: 43min 48sec (2628 seconds)

Published: Mon Jun 03 2019