Over the last few days, we've discussed a number of topics in the serverless space, covering storage, APIs, compute, and everything in between. We've got all the components to build a fully functional, robust application in place, but before you run off and create The Next Big Thing, we have to cover one more crucial topic: Well Architected. The Well Architected Framework is a set of guidelines or best practices that AWS introduced a few years ago. The six "pillars" of Well Architected are Security, Cost, Operational Excellence, Reliability, Performance Efficiency, and Sustainability. These concepts are not new, but by defining them in this way, AWS has established a reference that is easy to use and understand when evaluating your applications for best practices. In fact, AWS has created a Well Architected Tool & Review process centered around the six pillars, asking you questions about your application to review yourself or with your team. Before you start building your application, I would highly recommend you go through a formal Well Architected Review. You don't need to answer every single question, in fact some might not be applicable, but going through this exercise gets you thinking about how you want to architect your application, even highlighting key decision trade-offs, or potential issues that you haven't thought of just yet. In the subsections that follow, we'll talk about each of the pillars in a little more detail, and I'll briefly cover Well Architected Lenses.
Security
Simply put, how are you securing your app? Are you using authorization and authentication with IAM users, roles, and policies to limit access to your resources? Setting up permission boundaries and using KMS keys for encryption? This can look like any number of measures, but the important idea here is, are you thinking about how to secure your app? Some of the questions in this space may not be applicable. This could be an app just for you, or one that isn't storing any data to worry about, or it could be wide open to the public and have no personal information to worry about. You don't need to have every single security measure in place for your application, but you do need to think about these things, and make conscious, defendable decisions about your application security.
Cost
This one is pretty straightforward - I don't know anyone who gets excited when their cost or bills go up in price. Obviously, we all want to optimize for a low-cost application solution, whether this is for personal use, your business, or the company you work for (you may not care about that one personally, but I can tell you THEY certainly care about the bottom line). Look at the pricing model and see if there are any ways to cut costs. Some easy ones could be to minimize the number of API calls you're making, or utilize Lambda Powertools to optimize your lambda function for memory & performance. If you've exhausted every option here, that's okay. Cost is typically a trade-off; you may be ok spending more money to make sure your application is secure, reliable, and not hindered in performance. Again, the idea here is that you're actively aware of where your money is going, and you've reviewed your optimization options thoroughly.
Operational Excellence
One of my favorite topics to talk about is 'Clean Code', or better known as best practices within your code. Although this could cover many of these pillars, it arguably fits squarely within Operational Excellence. This pillar is all about building robust applications, code that is easy to understand, read, and maintainable, and having effective development processes in place. Creating small, logical code blocks, making small & frequent code changes, reviewing code periodically, having ample error handling, logging, and monitoring, and so much more fall into this category. For me, this one is sort of like a "catch all" pillar; not because it isn't well defined, but because it encompasses so many parts of the application development cycle. Many of the pillars overlap, but it is very likely that this one in particular will have overlap with one or more of the other pillars at any given time.
Reliability
Is your application stable? Do you backup your data regularly? Do you have failovers or other fail-safe measures in place? Can your application handle a large influx of traffic, or will any changes to the 'average' case break your current functionality? The key question this pillar asks is - are you prepared? Outages are never fun, especially when they significantly impact your customers, but they can (and they do) happen to the best of us. By reviewing the questions in the reliability pillar, you are thinking about your application's disaster recovery plans, backing up your data, and having processes in place for the 'worst-case scenario'. Hopefully by completing a reliability review, these things don't occur as often, or aren't as widespread as they might've been before a review.
Performance Efficiency
Closely related to the Operational Excellence and Reliability pillars, the Performance Efficiency pillar is, you guessed it, all about how well your application is performing. What I enjoy most about this pillar is if you're taking advantage of serverless architectures, you're already well on your way to having this one covered, as it's one of the five design principles to adhere to. This is about your application running smoothly, scaling effectively, and taking advantage of only the resources you need. This is another big "trade-off" pillar, since you may compromise your performance in some cases to comply with security or save on cost.
Sustainability
Sustainability is a recent addition to the Well Architected pillars, and I think it's a good one. It was introduced at the end of 2021, and even though it's a focus I love to see, it also means there has not been a ton of guidance shared to optimize for sustainability. If you're invested in areas involving hardware, AI/ML, large sets of data, IoT, etc., this is a bit more obvious to contend to - simply put, you want to use less resources, and more sustainable (or at least recyclable) hardware. WIth serverless, you are already scaling automatically, only paying for what you use, and optimizing for your event driven architecture, which makes it more difficult to find areas to cut down on usage. My best advice is to review your architecture early & often, and continually try to find ways to lower your carbon footprint with optimal architectural design, and if you haven't made the jump to serverless yet, maybe that's the first step!
Serverless Lens
In addition to the six pillars, AWS Well Architected has this concept of Well Architected Lenses. Much like a pair of reading glasses, you can apply a specific Lens to your application to 'see' your application in a bit more detail. There are Lenses for Machine Learning, Data Analytics, Financial Services, and, of course, Serverless Applications. These Lenses are simply a set of extra guidelines and questions for each of these six pillars relating specifically to the type of application you are building. They are 'optional', as is the entire Well Architected Review process, but again, if you are building a serverless application, I would highly recommend you complete a Well Architected Review with the Serverless Lens, as it will only strengthen your application posture in the context of these six pillars.
If you'd like to learn more about Well Architected or hear about it in practice, I have actually given a recent talk on the subject with Build On at AWS Re:Invent. This is an area of technology I have been very passionate about, and I truly believe these pillars and Well Architected Reviews are well worth the time and effort. We're coming up to end of our team together this week (I know, already?!) so for our last day tomorrow, I'm excited to summarize what we've learned so far, and present you with some next steps for going beyond the serverless basics.*
*This is part of a series that will be covered here, but I also encourage you to follow along with the rest of the series on 90DaysOfDevOps.
Top comments (0)