AWS re:Invent 2016: Achieving Agility by Following Well-Architected Framework Principles on AWS (ARC203)


Published on

The AWS Well-Architected Framework enables customers to understand best practices around security, reliability, performance, and cost optimization when building systems on AWS. This approach helps customers make informed decisions and weigh the pros and cons of application design patterns for the cloud. In this session, you'll learn how National Instruments used the Well-Architected Framework to follow AWS guidelines and best practices. By developing a strategy based on the AWS Well-Architected Framework, National Instruments was able to triple the number of applications running in the cloud without additional head count, significantly increase the frequency of code deployments, and reduce deployment times from two weeks to a single day. As a result, National Instruments was able to deliver a more scalable, dynamic, and resilient LabVIEW platform with agility.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

AWS re:Invent 2016: Achieving Agility by Following Well-Architected Framework Principles on AWS (ARC203)

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Timothy DiLauro, Solutions Architect, AWS Joe Gardner, Principal Cloud Architect, National Instruments November 30, 2016 Achieving Agility by Following Well-Architected Framework Principles ARC203
  2. 2. What to expect from the session What is the AWS well-architected framework? What are core tenets to being well architected? Customer use case: National Instruments getting to well architected
  3. 3. AWS Well-Architected Framework
  4. 4. AWS well-architected framework Stop guessing capacity needs Test systems at scale Data-driven architectures Automate to enable experimentation Allow for evolution General design principles to facilitate good design in the cloud
  5. 5. AWS well-architected framework Security Reliability Performance efficiency Cost optimization Set of questions you can use to evaluate how well an architecture is aligned to AWS best practices Operational excellence
  6. 6. Security pillar Security at all layers Enable traceability Implement a principle of least privilege Focus on securing system Automate security best practices Protect information, systems, and assets while delivering business value through risk assessments and mitigation strategies
  7. 7. Reliability pillar Test recovery procedures Automatically recover from failure Scale horizontally to increase availability Stop guessing capacity 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
  8. 8. Performance efficiency pillar Democratize advanced technologies Go global in minutes Use server-less architectures Experiment more often Efficiently use of computing resources to meet requirements, and maintaining that efficiency as demand changes and technologies evolve
  9. 9. Cost optimization pillar Analyze and attribute expenditure Managed services to reduce TCO Adopt a consumption model Benefits from economies of scale Stop spending money on data center operations Assess your ability to avoid or eliminate unneeded costs or suboptimal resources, and use those savings on differentiated benefits for your business
  10. 10. Operational excellence pillar Perform operations with code Align operations processes to business objectives Make regular, small, incremental changes Test for responses to unexpected events Learn from operational events and failures Keep operations procedures current Operational practices and procedures used to manage production workloads
  11. 11. Well-architected framework example issues Security Reliability Managing keys and credentials – No MFA or rotation policy is in place Analyzing AWS-specific logs – Logs are not analyzed Encrypting and protecting data at rest – Data at rest encryption is not required Planning for recovery – Unplanned Seeking help with AWS infrastructure problems – Ad hoc System adapts to changes in workload – Ad hoc
  12. 12. Well-architected framework example issues Performance Cost optimization Storage solution matches demand – Reactive Evaluate new storage options – Ad hoc Evaluate new instance options – Ad hoc Meet demand cost effectively – Fixed amount of resources Govern AWS usage – No policies or mechanisms
  13. 13. National Instruments: Achieving Agility
  14. 14. NI equips engineers and scientists with systems that accelerate productivity, innovation, and discovery “Products used from toys to supercolliders” 40-year-old company headquartered in Austin, TX; annual sales greater than $1.25 B
  15. 15. Cloud journey 2013 – Introduced well-architected design 2014 – Launched well-architected product 2015 – All products followed well-architected framework Started developing on platform in 2008 FPGA Compile Cloud - August 2010 LabVIEW Web UI Builder - November 2010
  16. 16. National Instruments: Cloud Infrastructure 2012
  17. 17. Cloud infrastructure 2012 EC2-Classic, Elastic Load Balancing, Amazon S3, Amazon SimpleDB MySQL on EC2 “Root” credentials Single-AZ Internally developed tooling Backups sent to data center Manual AMI creation
  18. 18. Cloud infrastructure 2012: Challenges Software deployment took 5–30 minutes Lack of infrastructure automation Scaling took 10–30 minutes to meet demand Deployment of infrastructure was manual, resource intensive, and prone to error Image used under Creative Commons:
  19. 19. FPGA Compile Cloud: Scaling for Growth
  20. 20. FPGA Compile Cloud
  21. 21. FPGA Compile Cloud: Original scaling design
  22. 22. FPGA Compile Cloud: Challenges Increased demand causing scaling issues Delayed results Alert fatigue Manual intervention
  23. 23. FPGA Compile Cloud: Improvement What can be made faster? How to reduce alerts? How to automate it?How can we better match demand?
  24. 24. FPGA Compile Cloud: Original scaling design
  25. 25. FPGA Compile Cloud: Improved scaling design Scaling to meet demand Autonomous instances Intelligent monitoring Automated deployment
  26. 26. Benefits from well-architected framework Increased developer efficiency Decreased scaling latency from 30 minutes to 5 Optimized cost from overprovisioning Removed data center dependency
  27. 27. Adopting Well-Architected Framework from Product Inception
  28. 28. Cloud infrastructure 2014 Cloud native services: VPC, Auto Scaling, Amazon Route 53, Amazon CloudFront RDS-MySQL Least-privileged access: IAM Multi-AZ Cloud native tooling: AWS CloudFormation Automated AMI process: Ansible Adopted DevOps principles: Created CI/CD pipelines
  29. 29. Cloud infrastructure 2014: Priority VPC, Amazon RDS, Elastic Load Balancing, Auto Scaling CI/CD pipeline Increased security CloudFormation Automated AMI creation
  30. 30. Security groups Load balancer IAM role Auto Scaling group Scaling metrics Cloud infrastructure 2014: Units of deployment
  31. 31. Cloud infrastructure 2014: Creating the VPC
  32. 32. Cloud infrastructure 2014: CloudFormation
  33. 33. Wiki pages Cloud infrastructure 2014: Automating AMI creation Ansible
  34. 34. Benefits from well-architected framework Faster updates; decreased time to market Load tested above production capacity Reduced attack surface Cost optimized
  35. 35. Migrate Existing Products to Well-Architected Framework
  36. 36. Existing products: Desired changes Area 2012 2015 – Well architected EC2 Classic VPC Relational database MySQL on EC2 RDS-MySQL Auto Scaling Zero Everything Elastic Load Balancing External only Everything CloudFormation Zero 95% AMI creation Manual Automated: Ansible Application deployment Manual AWS CodeDeploy
  37. 37. Existing products: Different priority New product development (2014) Existing product migration (2015) VPC, RDS, Elastic Load Balancing, Auto Scaling Increased security CI/CD pipeline VPC, RDS, Elastic Load Balancing, Auto Scaling Increased security CloudFormation Automated AMI creation Automated AMI creation CloudFormation CI/CD pipeline
  38. 38. Existing Products: Measured Improvements Area 2012 2015 – Well architected Security Root API key IAM, Network ACL, Egress filtering Single point of failure 10+ 1 Time to create separate environment 1 month < 2 hours Longest code deployment time 2 weeks < 4 hours Typical code deployment time 15 minutes < 1 minute
  39. 39. Continuous Improvement from Well-Architected Framework
  40. 40. Continuous improvement: Road map Multiregion disaster recovery Global applications Greater automation Simpler, more efficient Additional security
  41. 41. Road map: Additional security
  42. 42. Road map: Multiregion disaster recovery Region specific Region agnostic
  43. 43. Road map: Simpler, more efficient
  44. 44. Road map: Simpler, more efficient
  45. 45. Road map: Simpler, more efficient
  46. 46. Cloud infrastructure 2016: Benefits realized Increased monitoring Disaster recovery to another region Grew from 3 applications to over 11 Automated turning off unused environments
  47. 47. Lessons Learned Utilizing Well-Architected Framework
  48. 48. Most valuable lessons learned Don’t reinvent the wheel Be willing to make change Know when architecture is nearing its limits Take appropriately sized steps
  49. 49. Most valuable lessons learned It’s a journey, not a destination Invest time to save time Automation empowers faster change and improvement Need qualified people to accomplish
  50. 50. Resources
  51. 51. Thank you!
  52. 52. Remember to complete your evaluations!