Jinesh Varia Technology Evangelist Architectural Design Patterns in Cloud Computing

Transcription

1 Jinesh Varia Technology Evangelist Architectural Design Patterns in Cloud Computing

2 They sent me here to talk But I am here to listen Please Send Feedback jvaria@amazon.com

3 Cloud Best Practices Whitepaper Prescriptive guidance to Cloud Architects Just Google for Cloud Best Practices to find the link

4 Cloud Computing Attributes What makes the Cloud so attractive Abstract Resources On-Demand Provisioning Focus on your needs, not on hardware specs. As your needs change, so should your resources. Ask for what you need, exactly when you need it. Get rid of it when you don t need Scalability Scale out or in depending on usage needs. No Up-Front Costs No contracts or long-term commitments. Pay only for what you use. Efficiency of Experts Utilize the skills, knowledge and resources of experts.

5 The Living and Evolving The Cloud Cloud AWS services and features Most Applications Need: 1. Compute 2. Storage 3. Messaging 4. Payment 5. Distribution 6. Scale 7. Analytics

6 The Living and Evolving Cloud At Amazon, Every Day is a Launch Day New Features and Services» Reserved Instances in EU Region» Elastic MapReduce» SQS in EU Region» New SimpleDB Features» FPS General Availability» AWS Security Center» AWS Multi-Factor Authentication» Virtual Private Cloud» Lower Reserved Instance Pricing» Amazon RDS» High-Memory Instances» Lower EC2 Pricing» Amazon EC2 with Windows Server 2008, Spot Instances, Boot from Amazon EBS» Amazon CloudFront Streaming» Amazon VPC enters Unlimited Beta» AWS Region in Northern California» International Support for AWS Import/Export» Amazon EC2 with Windows» Amazon EC2 in EU Region» AWS Toolkit for Eclipse» Amazon EC2 Reserved Instances» AWS Import/Export» Lower pricing tiers for Amazon CloudFront» AWS Management Console» New CloudFront Feature» Monitoring, Auto Scaling & Elastic Load Balancing» Amazon Elastic MapReduce in Europe» EBS Shared Snapshots» SimpleDB in EU Region» Monitoring, Auto Scaling & Elastic Load Balancing in EU» Amazon CloudFront Private Content» SAS70 Type II Audit» AWS SDK for.net» Amazon EC2 Reserved Instances with Windows, Extra Large High Memory Instances» Amazon S3 Versioning Feature» Consolidated Billing for AWS» Lower pricing for Outbound Data Transfer

7 Scalability Build Scalable Architecture on AWS A scalable architecture is critical to take advantage of a scalable infrastructure Characteristics of Truly Scalable Service 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 becomes more cost effective when it grows

8 Cloud Architecture Lessons using Amazon Web Services 1. Design for failure and nothing fails 2. Loose coupling sets you free 3. Implement Elasticity 4. Build Security in every layer 5. Don't fear constraints 6. Think Parallel 7. Leverage different storage options

9 1. Design for Failure and nothing will really fail "Everything fails, all the time" Werner Vogels, CTO Amazon.com Avoid single points of failure Assume everything fails, and design backwards Goal: Applications should continue to function even if the underlying physical hardware fails or is removed or replaced.

10 Design for Failure with AWS Tools to make your life easier Use Elastic IP addresses for consistent and re-mappable routes Use multiple Amazon EC2 Availability Zones (AZs) Create multiple database slaves across AZs Use real-time monitoring (Amazon CloudWatch) Use Amazon Elastic Block Store (EBS) for persistent file systems

11 YourWebTwoDotZeroName.com EC2 Instance A EC2 Instance B

12 Availability Zone 1 YourWebTwoDotZeroName.com EC2 Instance A EC2 Instance B Availability Zone 2 DATA Volume LOG Volume LOG Volume DATA Volume Amazon S3

13 2. Build Loosely Coupled Systems The looser they're coupled, the bigger they scale Independent components Design everything as a Black Box De-coupling for Hybrid models Load-balance clusters Use Amazon SQS as Buffers Tight Coupling Controller A Controller B Controller C Loose Coupling using Queues Q Q Q Controller A Controller B Controller C

14 MyWebSite.com Exterior Firewall Hardware or Software Solution to open standard Ports (80, 443) Web Load Balancer Hardware or Software solution to distribute traffic over web servers Web Tier Fleet of machines handling HTTP requests. Web Server LB Web Server Backend Firewall Limits access to application tier from web tier App Load Balancer Hardware or Software solution to spread traffic over app servers LB App Server Tier Fleet of machines handling Application specific workloads Caching server machines can be implemented at this layer Data Tier Database Server machines with master and local running separately, Network storage for Static objects App Server App Server MySQL Master App server MySQL (Slave) Backups on Tapes Periodic backups stored on Tapes usually managed by 3 rd party at their site Tapes

15 Elastic Load Balancer ELB to spread traffic to Web Server Auto-scaling groups MyWebSite.com DNS ELB: Web Tier LB Exterior Firewall no longer needed because EC2 instances are controlled with Security Groups Auto-scaling Web Tier Group of EC2 instances handling HTTP requests. Backend Firewall no longer needed App Server Load Balancer Software LB (e.g. HAProxy) on EC2 instance to spread traffic over app server cluster Auto-scaling App Tier Group of EC2 instances running the actual app. Instances belong to Auto-scaling group. Caching servers instances can be implemented at this layer Auto-scaling group : Web Tier Web Server App Server SLB Web Server App Server Tomcat Auto-scaling group : App Tier Auto-scaling group : Web Tier Web Server App Server SLB Web Server App Server Tomcat Auto-scaling group : App Tier Edge Caching High Volume Static Content is edge cached using CloudFront Cloud Front DB Tier MySQL RDS DB Instances (master, local slave, x-az slave for failover), Automated backups to S3 all managed by AWS Availability Zone #1 RDS Master RDS Slave RDS Slave Availability Zone 2 Availability Zone #n Amazon S3 Backups Amazon S3 used for storing Static Objects and Backups

16 3. Implement Elasticity Elasticity is fundamental property of the Cloud Don t assume health or fixed location of components Use designs that are resilient to reboot and re-launch Bootstrap your instances: Instances on boot will ask a question Who am I & what is my role? Enable dynamic configuration Use Auto-scaling (Free) Use Elastic Load Balancing on multiple layers Use configurations in SimpleDB to bootstrap instance

17 Managed 3. Implement Development Elasticity 3 Usecases Environment Dev/Test Apps Prod SaaS Paid AMI Web 2.0 Product Managed Development Environment AWS Cloud Automated Deployment Environment AWS Cloud Cloud-powered Software Lifecycle management AWS Cloud Enterprise IT ISV Startup

18 Standardized Technology Stacks 3. Implement Elasticity Standardized Application Stacks Web Apache Server App Mongrel ASP.NET Tomcat Server Struts MVC Rails ASP.NET MVC Your Code Libraries Log4Net logger Log4J Spring.NET RubyGems Packages memcached nhibernate DB Caching Framework.NET JEE Ruby Runtime Windows Centos Linux OS Java Stack.NET Stack RoR stack

19 3. Implement Elasticity 3 Approaches to design MDE 3 approaches to designing your AMIs Inventory of fully baked AMIs (Frozen/Ready made) Easier to Setup Golden AMIs with fetch on boot (Take N Bake) AMIs with JeOS and Chef Agent (Made to Order) More Control Easier to maintain

20 3 Approaches to design MDE 3. Implement Elasticity 1. Frozen Pizza Model ASP.NET ASP.NET MVC ASP.NET MVC Your Code Your Code Log4Net Spring.NET nhibernate.net Windows.NET Stack Log4Net Spring.NET nhibernate.net Windows.NET AMI ASP.NET MVC ASP.NET MVC Your Code Your Code ASP.NET MVC Log4Net Log4Net Your Code ASP.NET MVC Spring.NET Spring.NET Log4Net Your Code nhibernate nhibernate Spring.NET Log4Net.NET.NET nhibernate Spring.NET Windows Windows.NET nhibernate Windows.NET Windows Amazon EC2

21 3. Implement Elasticity Golden AMIs with fetch on boot 3 Approaches to design MDE 2. Papa Murphy Pizza Model ASP.NET MVC Source Control Your Code ASP.NET MVC Log4Net nhibernate Fetch on boot time Your Code Log4Net Spring.NET Spring.NET Amazon S3.NET Windo.NET ws Windo.NET ws Windo ws.net Windo ws nhibernate.net Windows.NET Stack.NET Windows.NET AMI Amazon EC2

22 3 Approaches to design MDE 3. Implement Elasticity 3. Made to Order Pizza Model Apache Mongrel Source Control Your Code Cookbooks Recipes Rails Your Code logger RubyGems memcached Ruby Runtime Centos RoR Stack ASP.NET MVC Log4Net.NET nhibernate Spring.NET Amazon S3 CHEF Agent Windows AMI (JeOS) Chef Server CHEF Agent Windows Amazon EC2

23 3. Implement Elasticity 3 Approaches to design MDE 3 approaches to designing your AMIs Inventory of fully baked AMIs (Frozen/Ready made) Easier to Setup Golden AMIs with fetch on boot (Take N Bake) AMIs with JeOS and Chef Agent (Made to Order) More Control Easier to maintain

24 4. Build Security in every layer Design with Security in mind With cloud, you lose a little bit of physical control but not your ownership Create distinct Security Groups for each Amazon EC2 cluster Use group-based rules for controlling access between layers Restrict external access to specific IP ranges Encrypt data at-rest in Amazon S3 Encrypt data in-transit (SSL) Consider encrypted file systems in EC2 for sensitive data Rotate your AWS Credentials, Pass in as arguments encrypted Use MultiFactor Authentication

25

26 5. Don't fear constraints Re-think architectural constraints Better IOPS on my database? Multiple read-only / sharding / DB clustering More RAM? Distribute load across machines Shared distributed cache Your hardware failed or messed up config? simply throw it away and switch to new hardware with no additional cost Hardware Config does not match? Implement Elasticity Performance Caching at different levels (Page, Render, DB)

27 6. Think Parallel Serial and Sequential is now history Experiment different architectures in parallel Multi-treading and Concurrent requests to cloud services Run parallel MapReduce Jobs Decompose a Job into its simplest form

28 6. Leverage many storage options One size DOES NOT fit all Amazon S3: large static objects Amazon Cloudfront: content distribution Amazon SimpleDB: simple data indexing/querying Amazon EC2 local disc drive : transient data Amazon EBS: persistent storage for any RDBMS + Snapshots on S3 Amazon RDS: RDBMS service - Automated and Managed MySQL

29 6. Leverage many storage options Which storage option to use when? Amazon S3 + CF Amazon EC2 Ephemeral Store Amazon EBS Amazon SimpleDB Amazon RDS Ideal for Ideal examples Not recommended for Not recommended examples Storing Large write-once, read-many types of objects, Static Content Distribution Media files, audio, video, images, Backups, archives, versioning Querying, Searching Database, File Systems Storing nonpersistent transient updates Config Data, scratch files, TempDB Storing Database logs or backups, customer data Sensitive data Off-instance persistent storage for any kind of data, Clusters, boot data, Log or data of commercial RDBMS like Oracle, DB2 Content Distribution Querying lightweight attribute data Querying, Mapping, tagging, clickstream logs, metadata, shared-state management, indexing Relational (joins) query OLTP, DW cube rollups Storing and querying structured Relational and referential Data Complex transactional systems, inventory management and order fulfillment systems Simple lookups

30 Cloud Architecture Lessons Best Practices 1. Design for failure and nothing fails 2. Loose coupling sets you free 3. Design for dynamism 4. Build Security in every layer 5. Don't fear constraints 6. Think Parallel 7. Leverage many storage options

31 AWS community and Ecosystem Find help, guidance, assistance when you need it AWS Ecosystem AWS Community

32 Migrating a Web Application to AWS Photo: La Pedrera - Casa Milà, Barcelona - Antonio Gaudi

33 Migrating your Web Application Step by Step towards AWS A typical Web App needs: Compute Power Storage capacity Content Distribution Database storage Messaging Load balancing Monitoring

34 Migrating your Web Application - 1/8 Typical Web App Architecture Database Client Browser Web Server / Presentation Layer Application Server / Business Logic

35 Migrating your Web Application - 2/8 Amazon S3 for Storage Client Browser Store persistent files in Amazon S3 for lower costs, higher reliability

36 Migrating your Web Application - 3/8 Use Amazon CloudFront CloudFront for distribution Client Browser Amazon CloudFront is a content delivery network that caches data stored in Amazon S3 across a network of 14 edge locations around the world

37 Migrating your Web Application - 4/8 Amazon EC2 for your choice of web servers Client Browser Configure Amazon EC2 running your choice of web server to handle all incoming web requests.

38 Migrating your Web Application - 4/8 Scale out App servers on Amazon EC2 Configure multiple Amazon EC2 instances running your choice of application server to process requests. Client Browser Use Availability Zones and Elastic IPs for greater reliability and resiliency. Utilize Auto-scaling and Elastic LB service

39 Migrating your Web Application - 5/8 Use EBS Amazon for Persistent Storage EBS and for S3 for Database Snapshots Client Browser Configure an Amazon EBS device to host your existing relational database. Snapshots can be automatically backed up to Amazon S3.

40 Migrating your Web Application - 6/8 Use Amazon Amazon SQS for queuing requests SQS SQS Client Browser Amazon SQS makes it easy to coordinate between the web server and application servers.

41 Migrating your Web Application - 7/8 Use Amazon Amazon SimpleDB for log SimpleDB files, metadata SQS SimpleDB Client Browser Amazon SimpleDB can be used to store metadata, logfiles, and other information for your site.

42 Migrating your Web Application - 8/8 Use Amazon SimpleDB Monitor your Amazon EC2 instances using CloudWatch SQS SimpleDB Client Browser Amazon CloudWatch to monitoring your Amazon EC2 instances

43 Migrating your Web Application Step by Step towards AWS A typical Web App needs: With AWS: Compute Power Storage capacity Content Distribution Database storage Messaging Load balancing Monitoring Amazon EC2 Amazon S3 Amazon CloudFront Amazon EBS Amazon SQS Amazon EC2 Amazon CloudWatch

44 Conclusions Most Important Lesson From Our Customers: Start small with a well-defined proof of concept Build support and awareness in your organization Once one application is launched others will follow P h o t o : G r a n d C a n y o n H o p i P o i n t S u n S e t

45 The day is not too far when applications will cease to be aware of physical hardware. Much like plugging in a microwave in order to power it doesn t require any knowledge of electricity, one should be able to plug in an application to the cloud in order to receive the power it needs to run, just like a utility. As an architect, you will manage abstract compute, storage and network resources instead of physical servers. Applications will continue to function even if the underlying physical hardware fails or is removed or replaced. Applications will adapt themselves to fluctuating demand patterns by deploying resources instantaneously and automatically, thereby achieving highest utilization levels at all times. Scalability, Security, High availability, Fault-tolerance, Testability and Elasticity will be configurable properties of the application architecture and will be an automated and intrinsic part of the platform on which they are built. The day is not too far. Scalability, Security, High availability, Fault-tolerance, Testability and Elasticity will be configurable properties of the application architecture and will be an automated and intrinsic part of the platform on which they are built.

46 Thank you! Presentation idea and template

47