68. Are you well architected?
If you've been using AWS for a while, you might have heard the term "well-architected". But what does it really mean? Don't worry if you're not quite sure, because we are here to help!
In this episode of AWS Bites, we will be diving into the world of well-architected and explaining what it means, both in general and in the specific context of AWS. We will be covering the well-architected framework, the different tools, and facets that come with it, and answering some practical questions like "should you care about building well-architected workloads?" and "how do you know if your workloads are well-architected?".
Whether you're a startup or a mature organization, learn why building well-architected systems is crucial for the long-term success of your business.
By the end of this episode, you'll have a solid understanding of the world of well-architected and why it's so important. Let's dive in!
AWS Bites is sponsored by fourTheorem, an AWS Consulting Partner offering training, cloud migration, and modern application architecture.
In this episode, we mentioned the following resources:
If you have been using AWS for a while, chances are that you have already heard the term well-architected. It might seem like something obvious at first, but do you really know what this term actually means? Would you be able to provide your own definition if somebody asks you what well-architected actually means? Now, if you're hesitant to try to give an answer to this question, this episode is for you. Today, we are going to cover what does it mean to be well-architected in general and in the context of AWS. We will discuss the Well-Architected Framework and all the different tools and facets that revolve around this particular framework. Finally, and that's probably the most important part of this episode, we will try to answer some very practical questions such as should you care about building well-architected workloads? And if you care, how do you even know if your workloads are well-architected? What if you find out that your workloads are not well-architected? What do you even do? Where do you even start? How can you make them better?
So let's dive in. My name is Luciiano. Today I'm joined by Eoin and we are happy to present you another episode of AWS Bites podcast. AWS Bytes is sponsored by fourTheorem. fourTheorem is an AWS consulting partner offering training, cloud migration, and modern application architecture. Find out more at fourtheorem.com and you will find this link in the show notes. So we said well-architected is a very loaded term. Let's start by trying to give a generic definition of what we mean with that particular term. I think in general when we say well-architected we refer to the quality of a system of being well designed in regards to certain things like security, reliability, performance, costs, etc.
A well-architected system should follow modern best practices and we should make sure that it can deliver the value that is supposed to be delivered to the users in the more consistent way. And at the same time it should be easy to operate for the company, should be cost effective, and so on. So saying that something is well-architected can also be a little bit subjective because if you ask different people they can give you very different definitions of what it means to be well-architected. Probably something based on their own experiences, something based on what they've done in the past, the solutions that they know, the cloud providers, all the tools that they've been using the most. And if you get people with very different backgrounds chances are that their answer will be very very different. So there might be a little bit of source of confusion when we talk about this terminology in general sense but even more when we talk about this particular term in the context of AWS. So where does that confusion come from, Eoin, Do you have an opinion?
Yeah, well it's definitely subjective but at least I would say in the context of AWS they have used the term well-architected for a whole umbrella of tooling and documentation to try and enforce a little bit more of an opinionated view on what well-architected means to people building on AWS. And I think we welcome that because we always want AWS to be a little bit more opinionated. So it identifies a set of concepts that fall under this umbrella and the framework presents a number of these concepts in different categories so that you can kind of evaluate your approach to building and architecting AWS applications. So the parts to this are, well the original one is the paper. So about seven or eight years ago they published a well-architected white paper and this was the first document that tried to define what it means for a cloud workload to be well-architected. And they've kept that up to date. So I think the last update was last October and this is the general set of principles and the principles are divided into what are known as the Well-Architected Pillars. So if you're going to be looking at well-architected on AWS you'll probably become familiar with the six pillars. There used to be five and there are operational pillars.
Operational excellence which is like using infrastructure as code, deployment practices, predicting and handling failures, etc. Then you have security. You also have reliability which includes high availability and scalability. And then you have performance and efficiency. So ensuring that you're using the optimal resources and adopting newer technologies and not wasting resources. Related to that then you have cost optimization which is a pillar of its own.
And related to that again is sustainability which is the latest newly introduced pillar of the Well-Architected Framework. So those are the six pillars. So there are basically six categories within well-architected when you're evaluating a workload. Then you also hear about this term called the Well-Architected Lenses. So with Well-Architected Lenses you still have your six pillars but it's basically like looking at it from the perspective of different types of applications or applications in different industries. So you have a lens for machine learning, a lens for data analytics, there's a serverless lens which we've mentioned a couple of times before in previous episodes, high performance computing, IoT, games and you can actually create your own lenses. So there's an ability for you to define your own I suppose rules and apply those pillars to a specific type of application. So you've got your pillars and the lenses and then there's the actual process of evaluating workloads on AWS. So that's the well-architected review and it's essentially a formal process that allows you to go through these lenses, ask specific questions that really you kind of have to honestly answer and figure out how well you are meeting this idea of a well-architected workload according to AWS's principles. And to help with that they give you a tool. So that's the well-architected tool which you can find in the AWS console and that's a service that you can use to conduct these well-architected reviews and score yourself and monitor any risks that have been identified and track your remediation of those risks. You might also come across the well-architected labs which are essentially training resources, an online workshop split into several labs that allows you to learn the methodology required to conduct these well-architected reviews. So all of these things would provide links for in the show notes. So that's the rundown of all the different products if you like in the well-architected ecosystem on AWS. In general, Luciano, would you say who should care, should you care at all about building well-architected workloads?
Yeah, my first aesthetic answer would be of course you should care because nobody wants to build systems that are suboptimal and maintainable, insecure, expensive and so on. At least not intentionally. Maybe you don't know any better but of course you always want to do the best work you can possibly do in any field, right? I think that this is just a general statement. But at the same time, we always need to be pragmatic because if you are a startup, probably your first concern, your main priority is to just ship something in the hands of your customer so that you can actually validate if you are providing value to them and if your business makes sense or if you need to pivot into something else. So in that particular case, of course I wouldn't suggest startups to be extremely methodical and focused on trying to deliver the best possible architecture because your focus should be somewhere else and maybe more on the product side, maybe more on the validation side. Of course if your idea makes sense and your business starts to get positive feedback, you want to start growing that business, you want to start to deliver to more customers and at a certain point this architectural concern becomes more and more relevant because of course if you have a good architecture you are increasing your chances of providing value consistently to your customers. So I think as a general statement you should care. There might be a point in the history of your organization where this becomes more and more important so it makes also a lot of sense to try to identify at which phase of your company are you in and whether it starts to make sense for you to explore this particular topic or not. So I suppose if you are at that phase where you say okay I actually have a business, I'm making money, I have paying customers and I want this customer to be served as best as possible continuously and of course I want to operate all of that service in the best possible way for my own sake, like cost effective, easy to change and so on. Where do I even start? How do I even know if my workloads are well architected? And another question that I generally hear is like should they do that before or after I go to production? Because maybe you just did a private beta or you have some prototypes that you have been using, you are not really considering your product production yet so should you do a review anyway or maybe should you wait before you are already in production and maybe reconsider your architecture later?
Yeah well I guess the framework is there to help you answer all of those questions so maybe it's important to mention first the framework isn't meant to be used to evaluate a whole organization, it's actually meant to evaluate a specific workload. So you can have multiple workloads with your business and they can all be at different levels of well architected and you can conduct well architected reviews for one or multiple workloads and they don't have to be synchronized in any way.
So I guess the first thing you would need to do then is just identify which workloads are the most business critical and focus on those first and is it probably a good idea to do one and get into the groove of using the well architected review process and then apply it more broadly. So you can use the framework and the tool to convert to conduct that review and that review is a guided process that helps you to explore all of the topics that are important to the framework and make sure that you don't miss anything and there's a set of questions there that are kind of designed to make sure that you have to kind of really think about it and answer it and in some cases you can say okay well this question or this particular topic does not apply to my workload but in general you have to really bear all when you're conducting that review. And when it comes to the question about whether you can use this for development workloads or production you can actually use it for both. You can flag your workload as pre-production and conduct a review. It's a pretty good way to get a sense of where you're at before you launch into production and maybe you can evaluate which of the risks you need to identify and remediate before you go live in production. And it's also important to note that you can repeat it multiple times so you can take multiple passes through it and you can schedule that you do it every three months or six months or whatever makes sense to you as you keep improving the architecture of your workloads and stay on par with the new best practices and cloud capabilities. So once you've done that review it will highlight any weaknesses in your architectures and give you pointers that you need and can start to take action on. So if you've done this, Luciano, and you've been through the process where do you even start when you've got something that you identify and unfortunately you've got a set of risks you realize that you're not as well architected as maybe you hoped you were, what do you even do or where do you start to make them better?
Yeah, so as you said you get some kind of feedback out of this process and that basically means that when you do the process using the tool at the end of this process you will end up with a report and that report contains a number of items and these items are classified by high risk and medium risk which of course is just an indication that AWS, the tool specifically, is trying to give you but it doesn't really know anything about your business it just uses whatever information you provided through the process so it's still up to you to then take this kind of feedback from the report analyze it and decide what really is a priority for you and what maybe something that can wait. So I suppose the next step will be understand the report, understand every single item in that report, prioritize what's more important to you and maybe start to create some actions in your backlog to try to address some of these points. You definitely don't need to address them all as Eoin said it's something that you can repeat over time and get it better at it and of course every time you repeat it maybe there are new recommendations maybe your business has changed maybe you have implemented certain improvements in your architecture so your posture will always be a little bit different. By repeating this over time you will always get new feedback and new opportunities to improve your architecture and just to make a practical example just by looking at the latest pillar that was introduced only recently that particular pillar is something that if you did a review a couple of years ago you didn't even have so if you redo the review today probably there would be a number of very good pieces of advice that you can apply on that specific sustainability pillar that maybe you haven't explored before and it's something you might want to start to address. So since we I think it's useful to do maybe some more practical examples just to to give a real feeling of what kind of questions do you get when you when you do the review should we maybe try to list some of the most interesting questions do you think?
Yeah sure so if you look into the well-architected tool in the console I suppose maybe it's important to clarify the tool isn't doing any kind of analysis of your workload it's not reaching out into your resources on AWS and identifying weak spots it's essentially a questionnaire type tool a guided process that you go through with you know experts on well-architected we can go through it yourself and it asks it asks questions in a way that you kind of have to honestly answer.
So let's take an example so when you do that use this tool you can select like the you will always answer questions about the foundational white paper and then you can also select lenses that you want to apply on top of it as well the tool only supports two at the moment the serverless lens and the SaaS lens but you can also add your own custom lenses as I've already mentioned so you can add your own questions that are specific to your industry or workload so one question that pops up when it comes to operational excellence is just to give an example that it's not all about the technology one question is how does your organizational culture support your business outcomes.
And there's a selection of things that you kind of have to take here really so you have to make sure that you've got like executive sponsorship for your cloud workload that team members are empowered to take action when outcomes are at risk and all of the questions have this format, right. A set of check boxes, you can just check them you can add notes and details to it if you want but you can also say if one of these doesn't apply to you for whatever reason so if you need if and that will happen it will happen from time to time the questions just don't apply to you.
Then on a more technical sense in the performance efficiency pillar it will ask how do you monitor your resources to ensure that they're performing so you will have to confirm that you're collecting performance related metrics and that you're analyzing those when incidents occur and that you're generating alarms and monitoring those alarms proactively. So that all that all makes sense and then if take an example from the serverless lens, it doesn't have a lot of questions in it but it'll ask you how do you evaluate your serverless applications health. The serverless lens is actually a lot more opinionated in having its recommendations than the base, foundational white paper so it will want to make sure that you've got distributed tracing involved in your application and that you've got structured centralized logging as well. So there's specific things you'll need in there so there's a whole set of questions there and when you go through a review you can skip over questions you can go back and fill them in later. So it's quite flexible in that sense. What do you think, Luciano, would you recommend that people do this alone that they just go in and try it out themselves? Should they get AWS or a partner to come along and help them with the process?
Yeah, I think you can definitely do it by yourself because as you said you can just open the well architecture tool from the AWS console and it's pretty much a guided process you just need to make sure you keep an open mindset and try to give the most honest answers to every single question. Even when there are things that of course you wanted them to be different there is no point in trying to hide and maybe give an answer that is not really describing the reality of things because if you do that and you pretend things are better than they are then you are going to be missing out on opportunities for making your architecture better and improving the company the company on its own. And I think it's important to remember that this is not an audit this is something that you do to try to get better it's not something that you do because you're going to get some kind of certification or you're going to get, I don't know, the ability to trade in a specific market.
It's just something that you do because you generally want to be better as an organization at delivering the produce that you are delivering and of course there are also other nice side effects to the business. Because, if you do this process you're probably gonna be able to save money in terms of your cloud expenditure, you might be able to make your organization a little bit more flexible in introducing new features, recovering from incidents and all these kind of things that definitely will give you more leverage in the market to be more effective with your product.
And that's another segue that I think it's important to do this process with different stakeholders in your business so you shouldn't just get your own architect in the company and tell them, "okay, go off and do this exercise". It's something that you should actually do by involving a bunch of different people in your organization because definitely there are questions that require the perspective of people that are not technical, like people that are maybe more in finance or product or people that, if they are technical, they are in specific areas like security.
Maybe your architect doesn't have all these answers so it's really important that you bring the right people for the right questions and they also need to try to give the most honest answer that they could give for the particular question now with that being said you can do all of this alone. But if you if you want another opportunity to try to keep the entire process as honest as possible and maybe have even more guidance, I think it's useful to bring in a partner or to ask AWS itself if they would be able to provide a guided review. A partner or AWS itself of course they have less of an interest in the inner workings of your organization and they can try to keep the process more honest, they can also bring their own expertise, they probably have seen different companies in different industries going through the process and that probably helps to avoid some of the common mistakes that you might be end up doing by yourself. If this is something that interests you, keep in mind that we at fourTheorem do this kind of activity. If it's something that you are considering to do, give us a shout we, can probably help you to start and do your first well-architected review. So with that being said I think this is all we have for today. Thank you very much for being with us. We are really curious as always to get your feedback on any of these episodes. If the well-architected review is something that you have done already, we'd love to hear your feedback on it. Was it useful? Did you discover something important? Did it actually make your company and your operations better or if it's something you did and you were not satisfied with it, we are even more curious to know what did go wrong and if we can learn something from it. I think it's amazing that we will be sharing this learning with everyone interested so definitely give us a comment here or reach out on Twitter and we'd love to talk with you more. Until then, thanks again and we'll see you in the next episode.
Use the arrow keys to move between transcript segments, Home or End to jump to the first or last segment, and Enter to seek in the video.
Help us to make this transcription better! If you find an error, please submit a PR with your corrections.