Designing for elasticity on AWS

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