What is the AWS Well-Architected Framework
This is the first in a three part series on the AWS Well-Architected Framework. It is based on my presentation at the AWS Thames Valley user group "How to design well when there is no rule book". This first part looks at what the Well-Architected Framework is.
On the AWS website they describe the framework as:
The AWS Well-Architected Framework describes the key concepts, design principles, and architectural best practices for designing and running workloads in the cloud. By answering a set of foundational questions, you learn how well your architecture aligns with cloud best practices and are provided guidance for making improvements.
It is split into 5 pillars each covering a different aspect that should be considered in designing solutions.
For me using the framework can be split into 3 categories; Cloud Roadmap, Design Principle, and Cloud Assessment. Each of these come together to produce workloads that are designed correctly and will perform well in each of the 5 pillars.
Cloud Roadmap
To me the worst mistake to make is to treat the Well-Architected Framework and Well-Architected Review as a rule book to be audited against. This is not what AWS intended it to be and definitely not how you will gain most from it.
I believe that the framework and review process are guides to embed processes and knowledge across an organization. Architecture is not just a technical skill for design but a broader skill needed to ensure solutions are designed to meet business challenges and requirements. If used correctly, the Well-Architected Framework allows people to understand the trade-offs that need to be made between different areas and impacts that design decisions have on each area. This is as important for both technical and business roles to understand and by using the framework to show how the various levers work I think the gap between business and technical knowledge can be narrowed.
The other advantage of using the framework and review process as a roadmap is that it allows you to plan you journey. It may be that in early phases performance is more important than reliability. Understanding the different areas and components allows you to map out when each should be considered, and more importantly measure against each of the areas.
Learn - Measure - Improve
For me the framework and review is a cyclic process. Firstly, use it to learn where you should be and where you want to go. Once you have agreed what is important and relevant to your organization and solution, you can then measure your solution against the framework. Finally you will then be able to highlight the areas you now want to focus on changing.
And why cyclic? Well AWS releases so many services, features and improvements that you have to continue to learn and improve. New EC2 instance types might be more beneficial for your workload or a lower cost, a new RDS database type might mean moving off EC2, or a new service might mean moving to a completely different architectural model.
Design Principles
To me the design principles help drive a mind set that many architects and engineers still lack even with certification.
Stop guessing your capacity needs, build solutions that can scale to meet the demands of the workloads. Whether this is fancy microservices with queueing and container, or just an EC2 workload in an auto-scaling group, elastic workloads when done correctly are more likely to be reliable, performant and cost effective.
Test systems at production scale, so that you know it will work at scale. With on demand and scaling there is no longer any reason not to test at scale.
Automate to make architectural experimentation easier. The biggest challenge with experimentation is time. As i put in my AWS Basic post, do everything by code and automate it using pipelines. When you get good enough testing, functional and non-functional, should also be automated.
Allow for evolutionary architectures, so that you are not bound by technical debt. This will mean as new services come along from AWS or new requirements from the business you can adapt with out fear of breaking things.
Drive architectures using data! Design decisions no longer need to be based on a hunch. While experience and knowledge plays a big part, a good architect will look at the data to make a decision. Whether this is cost data, requirements data or test data, all designs need to be driven by what is happening in reality in your AWS account, not just what should happen based on a pristine AWS demo.
Improve through game days. AWS offers great game days, immersion days and Jams. If you can attend on, or get one for your company, I encourage you to do so. If not, create your own! Shut-down a node in test and see how people and systems respond.
Cloud Assessment
The final piece of the Well-Architected Framework is the assessment or Well-Architected Review.
Typically this is the only piece that many people use, normally as an audit, and then get disheartened at the outcome.
For me the review is just a point in time snapshot of where your solution is. When used properly it should show you areas that should be focused on next, almost like a compass. It shows you where you are and the direction you should be taking.
I also think that people compare themselves to others which again I believe is wrong. For me its about where you are and what has improved over time. This why I believe it should be a regular process, more often in a fast changing solution, where you analyze the health of your solution and work out what you want to change. It should almost like your annual health check. Have areas improved or gotten worse, have new solutions or ways of working come out you should consider, has the business needs changed. This way its about how you improve your solution not about where you rank compared to others.
Full details of the AWS Well-Architected Framework can be found on the AWS website.
