Are your cloud and application stack well architected? Probably not. And that’s OK.
Cloud architects inside Amazon originated the AWS Well-Architected Framework (aka "Well-Architected"), and announced it in 2015. It aspired to set guidelines and best practices to help migrate, manage, and optimize running on the AWS cloud. It was driven by learning inside of the Amazon commerce infrastructure and has since added three additional years of real-world input from AWS customers.
Are your cloud and application stack well architected? Probably not. And that’s OK.
Well-Architected helps you understand how well your environment is architected. Most importantly, it helps show what you can do to make your environment better architected.
Beyond “Cloud is Awesome”
"Isn't cloud awesome?" Of course it is. Just ask any cloud vendor. They said it was awesome last year, and two years before that.
The point is not to roll your eyes at IT vendor hyperbole (that's what The Register does). Cloud architecture has exactly one job: closing the gap between what a business needs and what it gets – with reliable, cost-effective, secure and high-performance infrastructure and applications. When change is the only constant, that gap demands continuous attention.
Well-Architected does this exceptionally well. It helps business leaders and technology leaders work together, to choose their architectural options strategically, and build effective applications that can be changed as business requirements change. Change is the natural state of business requirements.
Contrast this with the way IT used to work. Vendors shipped hardware and software; customers bought it, or rented it in hosting environments. Sometimes the business got the requirements wrong, and sometimes the vendors did (usually in combination). AWS and the model of cloud services have changed this forever. Now, requirements change constantly (AWS alone introduced about 2000 product features in 2018, at a rate of about five every day). Which ones matter? That’s hard to keep up with.
Well-Architected leads you to ask how effectively architectural choices meet business requirements, and how much it is worth to meet them more effectively. It puts you in a position to judge, by delivering a well-organized set of recommendations for you to choose from to maximize cloud business value. That is even more useful than awesome.
5 Pillars, 34 Design Principles, ~46 best practices areas, 256 Assessment Criteria
Well-Architected is based on five pillars, which together comprise five distinct foundations of really having your cloud act together, highly aligned with your business objectives: Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization:
- Operational excellence: Running and monitoring the systems in order to deliver business value, with continuous improvement of supporting processes and procedures.
- Security: Protecting the information, system and other assets while delivering business value via risk management audits and mitigation strategies.
- Reliability: Recover from infrastructure or service fails, dynamically acquire required resources to meet business demands.
- Performance efficiency: Use resources efficiently in order to meet business requirements, and to maintain that efficiency as demand changes and technologies evolve
- Cost optimization: Run a well-architected system that meets all business expectations at the lowest price, track and analyze expenditure trends, and manage them correctly over time
Nothing to object to so far; any IT professional would gladly take credit for these virtues.
But Well-Architected raises the bar significantly with a set of six global design principles. These imperatives are an excellent example of its prescriptive, opinionated nature:
- Stop guessing your capacity needs. Eliminate guessing about your infrastructure capacity needs. When you make a capacity decision before you deploy a system, use as much or as little capacity as you need, and scale up and down automatically.
- Test systems at production scale. Create a production-scale test environment on demand, complete your testing, and then decommission the resources.
- Automate to make architectural experimentation easier. Create and replicate your systems at low cost and avoid the expense of manual effort. Track changes to your automation, audit the impact and revert to previous parameters when necessary.
- Allow for evolutionary architectures. As a business and its context continue to change, initial architectural decisions can hinder delivering on changing business requirements. Evolve over time so that businesses can take advantage of innovations as a standard practice.
- Drive architectures using data. Collect data on how your architectural choices affect the behavior of your workload. Make fact-based decisions on how to improve your workload. When cloud infrastructure is code, use that data to inform your architecture choices and improvements over time.
- Improve through game days. Test how your architecture and processes perform by regularly scheduling game days to simulate events in production. Understand where improvements can be made and can help develop organizational experience in dealing with events.
There are another 28 design principles, 5-7 of them per pillar. Suddenly, making sure that cloud infrastructure is technically and economically effective at solving business problems gets a lot more challenging. Well-Architected then enumerates 256 criteria to characterize what it includes. That includes the questions, not the answers.
How good are best practices in the real world?
Well, let's take an example: your environment. AWS offers a Well-Architected assessment tool, and it tabulates your responses to give you a score. Try it.
If your organization is like most, all those interesting white papers and thought leadership have not translated to the universal flawless adoption of AWS consistent with these architectural best practices. In fact, in most cases, we have found almost all organizations running on or considering AWS are even not entirely aware of the full range of possibilities AWS can deliver.
With the speed of innovation and the intensity of competition in the marketplace, that's not surprising. But when various AWS tools are not used properly, it can result in security flaws, deprecated system reliability, performance gaps and weak financial controls leading to extra fees. And there's more, as further consequences can lead to unanticipated business downtime and data leaks.
Whether or not you tried the assessment tool above, we invite you to work with us to take a closer look at your business requirements and existing infrastructures. Our goal is not to flip a switch and make your Cloud architecture a perfect fit for your business needs, once and forever. (That's not really possible.) Instead, what we help with is navigating the many compromises between Well-Architected best practices and solving those business problems that matter to you most, adapting over time.
Solving technical problems: good. Solving business problems: Better.
As a full-stack software development organization, we are all about engineering. Engineering is most valuable when it serves business decisions. Our goal is to work together to ensure business decisions drive your engineering priorities.
Some examples: for development environments, we optimize costs at the expense of reliability, so you can try changes faster at lower cost. In production environment, we optimize reliability with possible acceptance of increased costs. For e-commerce, the priority is performance and sticky customer satisfaction to drive to increased revenue.
On the other hand, security and operation excellence are a constant business requirement; it's rarely a good idea to settle for mediocre security. Even seemingly straightforward decisions involve trade-offs: a serverless architecture may work better with RDS along with S3 object storage than a relational database, even if the original application is a PHP stack on an open-source database hosted on EC2.
Whether you're building a data pipeline, extending a mobile application across platforms, or re-engineering for multi-tenancy and compliance, building these best practices into your architecture will help to produce a stable and efficient system. Even more importantly, it sets you up to adapt to changes and newly discovered business opportunities, which you need your architecture to metabolize.
Implementing Well-Architected lets you stay focused on the functional and business problems you can solve better than any of your competitors. When you discover new things about your customers or your markets we help you adapt. Well architected is good – but better architected is better.
