Being Well-Architected in the Cloud
•
2 gefällt mir•628 views
by Ric Harvey, AWS Technical Evangelist, UK & Ireland The AWS Well-Architected Framework enables customers to understand best practices around security, reliability, performance, cost optimization and operational excellence. In this session, you'll learn how to architect your applications based on Amazon Web Services' Well-Architected Framework principles.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Being Well-Architected in the Cloud
Ähnlich wie Being Well-Architected in the Cloud (20)
Mehr von Amazon Web Services
Mehr von Amazon Web Services (20)
Being Well-Architected in the Cloud
- 1. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. https://aws.amazon.com/well-architected/
- 2. What is the AWS Well-Architected Framework? Pillars Design Principles Questions
- 3. Why would I want to apply the AWS Well-Architected Framework? Build and deploy faster Lower or mitigate risks Make informed decisions Learn AWS best practices
- 4. A Mechanism for your Cloud Journey Learn Measure Improve
- 5. Pillars of AWS Well-Architected Security Reliability Performance Efficiency Cost Optimization Operational Excellence
- 6. Pillar- Specific Design Principles General Design Principles Design Principles Automate responses to security events: Monitor and automatically trigger responses to event-driven, or condition-driven, alerts.
- 7. General Design Principles Stop guessing your capacity needs Test systems at production scale Automate to make architectural experimentation easier Allow for evolutionary architectures Drive architectures using data Improve through game days
- 8. Design Principles for Operational Excellence Perform operations as code Annotate documentation Make frequent, small, reversible changes Refine operations procedures frequently Anticipate failure Learn from all operational failures
- 9. Design Principles for Security Implement a strong identity foundation Enable traceability Apply security at all layers Automate security best practices Protect data in transit and at rest Prepare for security events
- 10. Design Principles for Reliability Test recovery procedures Automatically recover from failure Scale horizontally to increase aggregate system availability Stop guessing capacity Manage change in automation
- 11. Design Principles for Performance Efficiency Democratize advanced technologies Go global in minutes Use serverless architectures Experiment more often Mechanical sympathy
- 12. Design Principles for Cost Optimization Adopt a consumption model Measure overall efficiency Stop spending money on data center operations Analyze and attribute expenditure Use managed services to reduce cost of ownership
- 13. Pillar Area Question Text Question Context Best Practices Questions
- 14. Benefits of AWS Well-Architected Think Cloud-Natively Consistent Approach to Reviewing Architecture Understand Potential Impact Visibility of Risks
- 15. For More Information… https://aws.amazon.com/well-architected/ AWS Well-Architected Framework Whitepaper Pillar Specific Whitepapers, Lens Free Online Training November 2017 November 2017
Hinweis der Redaktion
- The AWS Well-Architected Framework provides you with prescriptive advice on how to build and operate cloud native architectures.
- The Well-Architected Framework provides a set of questions and design principles across five pillars: Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization.
- Why would I want to apply the AWS Well-Architected Framework? Because you want to: Build and deploy faster: By reducing firefighting, capacity management and by using automation, you can experiment and release value more often. Lower or mitigate risks: Understand where you have risks in your architecture, and address them before they impact your business and distract your team. Make informed decisions: Ensure you have made active architectural decisions that highlight how they might impact your business outcomes. Learn AWS Best Practices: Make sure your teams are aware of best practices that we have learned through reviewing thousands of customers’ architectures on AWS. We have seen customers use the AWS Well-Architected Framework to successfully achieve all of these.
- Well-Architected is a mechanism that helps you be successful in your cloud journey [optionally good intention vs mechanism here – things go wrong, get everyone in the room ask them to do better next time, “good intentions”… but GD does not work, you need mechanisms] Learn the Strategies & best practices for architecting in the cloud Measure your architecture against best practices Improve your architecture by addressing any issues
- The pillars cover fundamental areas that are often overlooked: Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization. Creating technology solutions is a lot like constructing a physical building. If the foundation is not solid, it may cause structural problems that undermine the integrity and function of the building. If you neglect the five pillars of security, reliability, performance efficiency, cost optimization, and operational excellence when architecting technology solutions, it can become a challenge to build a system that delivers functional requirements and meets your expectations. When you incorporate these pillars, it will help you produce stable and efficient systems, allowing you to focus on functional requirements.
- Design Principles help you adopt the appropriate mental model when building for the cloud, ensuring you take advantage of the capabilities of AWS and free yourself from the constraints of traditional approaches. [Optional Lets do a deep dive on the General Design Principles and Pillar Specific ones. ]
- Cloud computing has opened up the technology space to a whole new world of thinking where constraints we used to have in the traditional environment no longer exist. When thinking about general design principles, it’s interesting to contrast with how you would think about this in a traditional environment: You had to guess how much infrastructure you needed, often based on very high-level business requirements and demand – often before a line of code is written. You could not afford to test at scale (a complete duplicate of production costs is hard to justify, especially with low utilization), so when you went into production you normally found a whole new class of issues at high scale Any proof of concepts or architectural experimentation was done by hand and was generally only done at the start of the project. You generally had static architectures and it was difficult to even think about making a change. You generally couldn’t generate data sets that would allow you to make informed decisions, so you probably used models and assumptions to size your architecture Finally in a traditional environment, you would only exercise your runbook when something bad happened in production. In the cloud constraints have been removed, so you can use these principles to take advantage of that.
- Most changes were made by human beings following runbooks that were often out of date It was easy to become very focused on the technology metrics rather than business outcomes Because making change was difficult and risky, we tended not to want to do it often and therefore tended to batch changes into large releases We rarely simulated failures or events as we were too busy fighting fires from real failures We were so busy reacting to situations it was hard to take the time to extract learnings It was hard to keep information current as we were making changes to everything to fight fires, every server was a snowflake. In the cloud, constraints of a traditional environment are removed, and you can use the design principles of the Operational Excellence pillar to make all changes by code with business metrics that you can measure your success against. By automating change and using code, you can move to making incremental changes and reduce risk. You can build organizational muscle memory by running game-days that simulate failures to test your recovery processes, and learn from these and other operational events to improve your responses. Finally, because infrastructure is now code, you can detect when documentation is out of date and even generate documentation.
- Let’s cast our minds back to how we would think about security in a on-premises environment You often only had security at the surface of the architecture, an egg shell model where you harden the edges but once past these protections attackers can go anywhere Logging and audits are sporadic, some devices would not even offer the ability to do it – and they all did it differently. It is very hard to get a holistic view of the whole environment It was hard to have tight controls on who could do what, security was often seen as a blocker, overly permissive security was common You had to have people or manage contracts around how you or your provider would physically secure the DC For security there was a lot of manual processes, and therefore hard to be consistent or drive improvement over time In the cloud these constraints have been removed, that allows us to adopt these design principles to build and operate cloud native architectures - with security across layers, tracing across usage and changes, you can trigger code to respond to events or combinations of events. You can use fine grained access controls to say who can do what, and focus your time using the shared responsibility model and you can turn all of this into code – so it can be automatic, error free, version controlled and scalable.
- Let’s think about how we might think about reliability in a traditional environment: We often test if things work normally – we check if it meets expectations. But, we rarely test what happens after things fail, so the first time we test our recover process is in the middle of a live reliability failure (not a great learning experience!). This is why you used to see lots of systemic failures – X failed and then Y failed (Y being the thing we never got to test) When a failure occurs, we manually fix it – if it happens a lot we write down the procedures for fixing – a very manual process And, we had to guess how much we needed, so we if we got that wrong we had long provisioning times, which could lead to outages. And we made changes to our environments manually, which introduced the opportunity for human error and snowflake servers (perfectly individual) In the cloud constraints have been removed, that allows us to adopt these design principles to build and operate cloud native architectures - to test beyond destruction to make sure recovery procedures are automatic and successful, we can have multiple resources answering requests – such that a failure in any single component always has siblings who can step in and absorb the load we can use the horizontal scaling to meet demand and when we make changes to our environment we can do that through code – and apply the same best practices we would apply to application code.
- As we did before, let’s think about the kinds of constraints we had in a traditional environment when thinking about PE: We tended to use the same tech for everything, when the only tool you had is a hammer – every problem looks like a nail. Generally, this is why you saw so many RDBMS We stayed local, as global was too hard and too expensive – even the thought of negotiating a contract with a supplier in a different country, legal framework and language was enough to stop most conversations here We used lots of servers, that did one thing – and we had to have people to manage all those servers. It’s hard to get the resources to do experiment, it takes a lot of time to set up, and it’s not very common We tended to force technologies to do what we need, and then hope we could get the performance we needed In the cloud constraints have been removed, that allows us to adopt these design principles to build and operate cloud native architectures - skills such as machine learning and media transcoding are not evenly distributed across technologists, so having AWS setup and configure those services for you, it makes adoption easier. deploying to global locations is a click of a button and not a legal process, we can create solutions that are fully managed so we can focus on the code that add values and experimentation is something we can do continuously and we have a bigger toolbox of techniques, and select the one that works best for what we are trying to do. For example, if you have relational information then you would use a relational database while if you needed internet scale lookups you would use a No SQL solution such as DynamoDB.
- Again, let’s think about how we would approach CO in a traditional environment: You had to invest CAPEX upfront for new infrastructure before you needed it Most companies are not large enough to benefit from economies of scale You spent time and money on the undifferentiated heavy lifting of building, maintaining and stacking and racking datacenters Often there is only centralized costs that couldn’t be attributed back to others, so no one is incentivized to review costs and you had orphan systems You purchased and ran servers to provide services, often with low utilization as they were hard to share In the cloud constraints have been removed, that allows us to adopt these design principles to build and operate cloud native architectures - you pay for computing resource as you consume them AWS can use its economies of scale to drive down infrastructure costs, and pass them on to its customers we do the heavy lifting of managing the physical bits for your, so you can focus on the value adding bytes you can attribute costs back to business units and product owners, so they can drive these down and use managed services that have a lower cost and eliminate the time and cost of managing servers.
- As I said before the Framework consists of Questions across Five Pillars Questions are intentionally phrased to be open-ended; to start a conversation about your approach: In this example, we have a security question from the Incident Response area: Contains the Question Text Some Context to help you understand the question And a set of best practices that we have seen customers be successful with You can find all of the Well-Architected questions in the Well-Architected Framework whitepaper.
- Most architectures contain risks. The Well-Architected review process allows you to understand these risks and improve your architecture by addressing any issues.
- The AWS Well-Architected Framework whitepaper positions our perspectives on how to think about architecture in the cloud. We also created a series of whitepapers that include prescriptive advice for each pillar These whitepapers and free training can be found at the home for Well-Architected, where you can always find our most current thinking.