Downloaded 15 times
Uploaded byAnton Babenko
Designing for elasticity on AWS
The document discusses designing for elasticity on AWS, emphasizing scalability, flexibility, and the importance of service-oriented architecture (SOA) principles. It outlines strategies for implementing elasticity using AWS services like Elastic Load Balancer, Auto Scaling, and monitoring tools. The document encourages automation and experimentation to fully leverage AWS capabilities for building scalable applications.
More Related Content
Similar to Designing for elasticity on AWS
Designing for elasticity on AWS
- 1. Designing For ElasticityOn AWS May 26th, 2015 - AWS User Group Norway
- 2. Who am I? AntonBabenko Sr. Software Engineer at Telenor Digital Organizer of AWS User Group Norway Before: Web-developer, consultant and tech lead for the last 10 years. Using AWS since 2010. Betajob AS, Zoozoo.com, mCash, imagepush.to, SnappOrder, and many more. E-mail: anton@antonbabenko.com LinkedIn: https://www.linkedin.com/in/antonbabenko Github: http://github.com/antonbabenko
- 3. Agenda: 1) AWS andElasticity 2) Application 3) AWS Services
- 4.
- 5. What is AWS? •Low infrastructure cost • No guesses and planning upfront • Unlimited Scalability • Highly reliable
- 6. What is AWS? Scalability,Security, High-availability, Testability, Fault-tolerance and Elasticity are configurable properties of the AWS platform on which application is running.
- 7. What does elasticitymean?
- 8. How designing forcloud is different? The cloud changes several processes, patterns, practices, philosophies and reinforces some traditional service-oriented architectural principles that you have learnt as they are even more important than before.
- 9. How designing forcloud is different? Reinforce SOA principles: • Service loose coupling • Service abstraction • Service reusability • Service autonomy • Service statelessness • Service discoverability • ...
- 10. How designing forcloud is different? The cloud brings some new philosophies: • Building scalable architectures • Understanding elasticity • Not fearing constraints
- 11. How designing forAWS is different? • Not fearing constraints = “be creative in AWS-way” • “Design for failure and nothing fails” SOA principles reinforced: • Service loose coupling - all • Service reusability - EC2, S3, Route53 • Service discoverability - AS, tagging • ...
- 12. How to makeapp to get most of AWS in term of elasticity?
- 13. App should bescalable to be able to utilize cloud advantages fully.
- 14. What about webapp ? Web applications must be: 1) Stateless 2) Loosely coupled 3) Able to scale horizontally Advices: • Think parallel • Leverage different storage options • Automate everything Read 12factor by Heroku.
- 15. How to implementelasticity on AWS?
- 16. How to implementelasticity on AWS? Use Elastic Load Balancer: • Not free, but cheaper than your managed HAProxy (ELB costs $0.028 pr. hour = $245 pr year) https://aws.amazon.com/elasticloadbalancing/
- 17. How to implementelasticity on AWS? Use Auto Scaling: • Free • Optionally combine with ELB https://aws.amazon.com/autoscaling/
- 18. How to implementelasticity on AWS? Monitor what is going on using standard Cloudwatch metrics or add custom metrics. https://aws.amazon.com/cloudwatch/
- 19. How to implementelasticity on AWS? Use dynamic configuration to bootstrap instances: • SimpleDB or DynamoDB can keep configurations, for example https://aws.amazon.com/simpledb/ https://aws.amazon.com/dynamodb/
- 20. How to implementelasticity on AWS? Automate everything: • Cloudformation • AWS CLI • … https://aws.amazon.com/cloudformation/ https://aws.amazon.com/cli/
- 21. How to getmost of AWS? 1) Use free tier 2) Use Route53 3) Use Cloudfront 4) Experiment with instance types 5) Decide which pricing model fits your needs best 6) Use latest AMI and latest instance types 7) Read A Comprehensive Guide to Building a Scalable Web App on Amazon Web Services 8) Browse Cloud Design Pattern
- 22.
- 23. We are hiring,come and talk to me.
- 24. Thank you! Leave yourfeedback: http://bit.ly/aws-norway
- 25.
Editor's Notes
- #6 Scalability, Security, High-availability, Testability, Fault-tolerance and Elasticity are configurable properties of the platform on which application is running Elasticity is a fundamental property of the Cloud SQS was the first service November 2004
- #7 Scalability, Security, High-availability, Testability, Fault-tolerance and Elasticity are configurable properties of the platform on which application is running Elasticity is a fundamental property of the Cloud
- #8 Elasticity (in the cloud) is the ability of an application to automatically adjust the infrastructure resources it uses to accommodate varied workloads and priorities, while maintaining availability and performance. Elasticity is a key for startups, who used to buy hardware in advance (slashdot effect) Elasticity is a fundamental property of the Cloud
- #9 It reinforces some old concepts of building highly scalable Internet architectures It introduces some new concepts that entirely change the way applications are built and deployed Few SOA principles: Service loose coupling: Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other. Service abstraction: Beyond descriptions in the service contract, services hide logic from the outside world. Service reusability: Logic is divided into services with the intention of promoting reuse. Service autonomy: Services have control over the logic they encapsulate, from a Design-time and a Run-time perspective. Service statelessness: Services minimize resource consumption by deferring the management of state information when necessary[16] Service discoverability: Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted. It is critical to build a scalable architecture in order to take advantage of a scalable infrastructure. Characteristics of a truly scalable application: Increasing resources results in a proportional increase in performance A scalable service is capable of handling heterogeneity A scalable service is operationally efficient A scalable service is resilient A scalable service should become more cost effective when it grows (Cost per unit reduces as the number of units increases) Constraints (bonus: better split of components in SOA): Not enough RAM => use distributed memcached Not enough IOPS for DB => consider other data storage solutions (AWS specific); use sharding; use read-replicas
- #10 Few SOA principles: Service loose coupling: Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other. Service abstraction: Beyond descriptions in the service contract, services hide logic from the outside world. Service reusability: Logic is divided into services with the intention of promoting reuse. Service autonomy: Services have control over the logic they encapsulate, from a Design-time and a Run-time perspective. Service statelessness: Services minimize resource consumption by deferring the management of state information when necessary[16] Service discoverability: Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted. It is critical to build a scalable architecture in order to take advantage of a scalable infrastructure. Characteristics of a truly scalable application: Increasing resources results in a proportional increase in performance A scalable service is capable of handling heterogeneity A scalable service is operationally efficient A scalable service is resilient A scalable service should become more cost effective when it grows (Cost per unit reduces as the number of units increases) Constraints (bonus: better split of components in SOA): Not enough RAM => use distributed memcached Not enough IOPS for DB => consider other data storage solutions (AWS specific); use sharding; use read-replicas
- #11 It is critical to build a scalable architecture in order to take advantage of a scalable infrastructure. Characteristics of a truly scalable application: Increasing resources results in a proportional increase in performance A scalable service is capable of handling heterogeneity A scalable service is operationally efficient A scalable service is resilient A scalable service should become more cost effective when it grows (Cost per unit reduces as the number of units increases) Constraints (bonus: better split of components in SOA): Not enough RAM => use distributed memcached Not enough IOPS for DB => consider other data storage solutions (AWS specific); use sharding; use read-replicas
- #12 KNOW/LEARN AWS SERVICES Amazon has developed several elastic web-services already - EC2, EBS, ELB, EMR, ElastiCache, EFS, Elastic Beanstalk, etc. Even more internal terms like - Elastic Compute Unit, ENI, Elastic IP --- Everything fails all the time (с) Werner Vogels, CTO Amazon. This was very much true back in 2010 when Netflix moved to AWS. AWS is much more stable nowadays, but designing for failure is still important, because it makes you think about available alternatives and follow SOA principles (eg, service loose coupling).
- #13 How to actually make app to get best of AWS in term of elasticity?
- #14 Reminder: Scalability, Security, High-availability, Testability, Fault-tolerance and Elasticity are configurable properties of the AWS platform where application is running
- #15 Loose coupling principle in real life: Avoid SPOF, for example, unnecessary dependencies between zones (eg: 2 zones for apps sharing same db hosted in one zone) Splitting a system into tiers allows managing the availability and scalability of each tier independently. Deploy critical components of your application across multiple AZ and replicate your data appropriately; Loose coupling allow to scale horizontally to higher degree and with less resources Automate everything: Handle dynamic IP addressing when your instance restarts by reassigning it tooling is important --- 12factor was written by Heroku as a marketing material to their PAAS solution. “Execute the app as one or more stateless processes” is often a good starting point.
- #17 Achieving Even Better Fault Tolerance for Your Applications DNS Failover for Elastic Load Balancing (if ELB is not healthy or no instances in it) Auto Scaling with Elastic Load Balancing
- #18 Autoscaling with values: min=max=1 Fixed amount of instances, or scale up/down by cloudwatch metric, or by time schedule
- #22 Use free tier Use Route53 (internal DNS at least. Combinations of latency based and failover strategies) Use Cloudfront to optimize connections Decide which instance family to use for your app Decide which pricing model fits your needs best (spot instances can be up to 10 times cheaper than on-demand even for web tier) Use latest AMI and latest instance types