The AWS Well-Architected Framework serves as a guide in designing an effective, secure, reliable, efficient and cost effective cloud infrastructure. This consists of design principles specifically discussing the 5 pillars of a well-architected framework. Based on industry best practices it'll help you assess your designs for any gaps or limitations that you may have overlooked and will give you a basis to work on in creating a holistic solution.
When should you use it?
Ideally, you should review this documentation thoroughly and have a clear understanding or the 5 pillars before designing your cloud infrastructure or solution. However, in most cases when the solution might have already been deployed beforehand, you can use it as a guide to assess the solution design implemented and make corrective actions where deemed necessary based on your finding.
What are the 5 Pillars?
The 5 Pillars comprises the following:
When should you use it?
Ideally, you should review this documentation thoroughly and have a clear understanding or the 5 pillars before designing your cloud infrastructure or solution. However, in most cases when the solution might have already been deployed beforehand, you can use it as a guide to assess the solution design implemented and make corrective actions where deemed necessary based on your finding.
What are the 5 Pillars?
The 5 Pillars comprises the following:
- Operational Excellence
- Security
- Reliability
- Performance Efficiency
- Cost Optimization
Operational Excellence defines the ability to run and monitor systems to deliver business value and to continually improve supporting processes and procedures.
Security details the ability to protect information, systems, and assets while delivering business value through risk assessments and mitigation strategies.
Reliability states the ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.
Performance Efficiency encompasses the ability to use computing resources efficiently to meet systems requirements, and to maintain that efficiency as demand changes and technologies evolve.
Cost Optimization details the ability to avoid or eliminate unneeded costs or suboptimal resources.
There may be instances where you may prefer to focus on certain pillars such as Reliability, Performance Efficiency, and Cost Optimization doing somewhat of a trade-off amongst them in order to satisfy certain business decisions that drive your design solution. It is possible to have one over another and is quite common in real world scenarios. However it is highly advised that you DO NOT trade-off on Security and Operational Excellence.
A few words on Architecture
With traditional IT environments there is often a central team which acts as a governing body which ensures that all other teams follow best practices. This team may comprise of the following roles: Technical Architect (infrastructure), Solutions Architect (software), Data Architect, Network Architect, and Security Architect. These teams use TOGAF or the Zachman Framework as part of their enterprise architecture capability.
With AWS, the capabilities are distributed into teams rather than just one centralized team with that capability. This means that other functional teams such as product or feature teams are given the decision making authority to create and deploy architectures following best practices. This may sound as a risk to others since those teams, being functional, may or may not be subject matter experts in enterprise architecture and best practices. However AWS mitigates this risk by implementing best practices and providing access to experts who ensure that those teams meet or exceed the standards defined as best practices. Secondly, AWS employs mechanisms that carry out automated checks to ensure standards are being met.
General Design Principles
Keep in mind these design principles when designing your architecture to facilitate good design in the cloud.
Stop guessing your capacity needs:
Eliminate the guesswork on your infrastructure capacity needs. When you make a capacity decision before you deploy a system, you might end up sitting on expensive idle resources or deal with the performance implications of limited capacity. With cloud computing, these problems go away. You can use as much or as little capacity as you need, and scale up or down automatically to meet demand.
Test systems at production scale:
You can create a production scale test environment on demand in the cloud to complete your testing requirements and then decommission the resources after. Since you only pay for the test environment when it is running, you can simulate your live environment for a fraction of the cost of testing on-premises.
Automate to make architectural experimentation easier:
Automation allows you to create and replicate your system at low cost and avoid the expense of manual effort. You can track changes to your automation, audit the impact, and revert to previous parameters when necessary.
Allow for evolutionary architectures:
In a traditional environment, architectural decisions are often implemented as astatic, one-time events, with few major versions of a system during its lifetime. As a business and its context continue to evolve, these initial decisions might hinder the system's ability to deliver changing business requirements. In the cloud, the capability to automate and test on demand lowers the risk of impact from design changes. This allows systems to evolve over time so that businesses can take advantage of innovations as a standard practice.
Drive architectures using data:
In the cloud you can collect data on how your architectural choices affect the behavior or your workload. This lets you make fact-based decisions on how to improve your workload. Your cloud infrastructure is code, so you can 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. This will help you understand where improvements can be made and can help develop organizational experience in dealing with events.
A few words on Architecture
With traditional IT environments there is often a central team which acts as a governing body which ensures that all other teams follow best practices. This team may comprise of the following roles: Technical Architect (infrastructure), Solutions Architect (software), Data Architect, Network Architect, and Security Architect. These teams use TOGAF or the Zachman Framework as part of their enterprise architecture capability.
With AWS, the capabilities are distributed into teams rather than just one centralized team with that capability. This means that other functional teams such as product or feature teams are given the decision making authority to create and deploy architectures following best practices. This may sound as a risk to others since those teams, being functional, may or may not be subject matter experts in enterprise architecture and best practices. However AWS mitigates this risk by implementing best practices and providing access to experts who ensure that those teams meet or exceed the standards defined as best practices. Secondly, AWS employs mechanisms that carry out automated checks to ensure standards are being met.
General Design Principles
Keep in mind these design principles when designing your architecture to facilitate good design in the cloud.
Stop guessing your capacity needs:
Eliminate the guesswork on your infrastructure capacity needs. When you make a capacity decision before you deploy a system, you might end up sitting on expensive idle resources or deal with the performance implications of limited capacity. With cloud computing, these problems go away. You can use as much or as little capacity as you need, and scale up or down automatically to meet demand.
Test systems at production scale:
You can create a production scale test environment on demand in the cloud to complete your testing requirements and then decommission the resources after. Since you only pay for the test environment when it is running, you can simulate your live environment for a fraction of the cost of testing on-premises.
Automate to make architectural experimentation easier:
Automation allows you to create and replicate your system at low cost and avoid the expense of manual effort. You can track changes to your automation, audit the impact, and revert to previous parameters when necessary.
Allow for evolutionary architectures:
In a traditional environment, architectural decisions are often implemented as astatic, one-time events, with few major versions of a system during its lifetime. As a business and its context continue to evolve, these initial decisions might hinder the system's ability to deliver changing business requirements. In the cloud, the capability to automate and test on demand lowers the risk of impact from design changes. This allows systems to evolve over time so that businesses can take advantage of innovations as a standard practice.
Drive architectures using data:
In the cloud you can collect data on how your architectural choices affect the behavior or your workload. This lets you make fact-based decisions on how to improve your workload. Your cloud infrastructure is code, so you can 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. This will help you understand where improvements can be made and can help develop organizational experience in dealing with events.
Comments
Post a Comment