Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Dallas Breakfast Seminar

414 views

Published on

During the “Architecting for the Cloud” breakfast seminar where we discussed the requirements of modern cloud-based applications and how to overcome the confinement of traditional on-premises infrastructure.

We heard from data management practitioners and cloud strategists from Amazon Web Services and NuoDB about how organizations are meeting the challenges associated with building new or migrating existing applications to the cloud.

Finally, we discussed how the right cloud-based architecture can:
- Handle rapid user growth by adding new servers on demand
- Provide high performance even in the face of heavy application usage
- Offer around-the-clock resiliency and uptime
- Provide easy and fast access across multiple geographies
- Deliver cloud-enabled apps in public, private, or hybrid cloud environments

Published in: Software
  • Be the first to comment

  • Be the first to like this

Dallas Breakfast Seminar

  1. 1. Architec(ng  for  the  Cloud   Larry  Gilreath  II,  Enterprise  Solu5on  Architect  
  2. 2. Why  Cloud?
  3. 3. On  Demand   }  Uniform   Pay  As  You  Go   Available   What  is  Cloud?
  4. 4. On  Demand   }  Uniform   Pay  As  You  Go   Available   What  is  Cloud?
  5. 5. Compute   Storage   Security   Scaling   Database   Networking   Monitoring   Messaging   Workflow   DNS   Load  Balancing   Backup  CDN  On  Demand   }  Uniform   Pay  As  You  Go   Available   What  is  Cloud?
  6. 6. From one compute instance…
  7. 7. … to thousands
  8. 8. …and back to one
  9. 9. Loose  coupling  sets  you  free   •  Load  balance  clusters     Web  Servers   App  Servers   Loosely  coupled   with  a  load   balancer   How  do  I  leverage  AWS?
  10. 10. Loose  coupling  sets  you  free     •  Use  a  queue  to  pass  messages  between  components   Web  Servers   App  Servers   Video   Processing   Servers   Queue   Decouple  (ers   with  a  queue   How  do  I  leverage  AWS?
  11. 11. How  do  I  leverage  AWS? Ver5cal  scaling  (more  CPU,  memory,  and  so  on)  will  eventually  run  out   of  room.  
  12. 12. How  do  I  leverage  AWS? Ver5cal  scaling  (more  CPU,  memory,  and  so  on)  will  eventually  run  out   of  room.  
  13. 13. How  do  I  leverage  AWS? Add  and  remove  instances  as  needed  
  14. 14. How  do  I  leverage  AWS? Add  and  remove  instances  as  needed  
  15. 15. How  do  I  leverage  AWS? Base  OS  AMI     An AMI with minimal components (OS, J2EE, and Chef/Puppet) is launched. All configuration occurs via Chef/Puppet after instance launch                                   OS  AMI  and  library  of  recipes   (install  scripts)   Amazon  EC2   Linux   JEE       Your   Code           S3   Hibernate   Tomcat   Log4J   Spring   Struts   Apache   Linux   JEE   Linux   JEE   Chef/ Puppet   Chef/puppet   scripts   OS  AMI   Fetch  on  boot  
  16. 16. How  do  I  leverage  AWS? Auto  Scaling  Group     Result Availability Zone A Availability Zone B
  17. 17. How  do  I  leverage  AWS? Auto  Scaling  Group     Availability Zone A Availability Zone B
  18. 18. How  do  I  leverage  AWS? Auto  Scaling  Group     Availability Zone A Availability Zone B
  19. 19. How  do  I  leverage  AWS? Auto  Scaling  Group     Availability Zone A Availability Zone B
  20. 20. How  do  I  leverage  AWS? Auto  Scaling  Group     Availability Zone A Availability Zone B
  21. 21. Foundation Services Compute Storage Database Network AWS Global Infrastructure Regions Availability Zones Edge Locations Client-side Data Encryption & Data Integrity Authentication Server-side Encryption (File System and/or Data) Network Traffic Protection (Encryption/Integrity/Identity) Platform, Applications, Identity & Access Management Operating System, Network & Firewall Configuration Customer Data AWSCustomer Scale  without  Compromising  Security
  22. 22. Virtual Private Cloud (VPC)
  23. 23. A  Scalable  Web  Architecture  on  AWS Availability Zone 1 Web Server Web Server App Server App Server Auto Scaling Group (Web Tier) Auto Scaling Group (App Tier) SLB Master   Availability Zone 2 Web Server Web Server App Server App Server Auto Scaling Group (Web Tier) Auto Scaling Group (App Tier) Slave   Availability Zone n Backups Static Content www.mywebsite.com Build  security  in  every  layer   SLB Legend    EC2  Instance  +   CloudWatch   Security  Group   Elas5c  Load   Balancer   Route  53  Hosted   Zone   CloudFront   S3  Bucket   RDS   Instance   SSL  @  ELB   Security  Group:   TCP  80  “amazon-­‐elb-­‐sg”     Security  Group:   TCP  8080  “web”     Security  Group:   TCP  8080  “slb”     DB  connec(on  over   SSL       DB  Security  Group:   TCP  3306  “app”     Encrypted  file   system  over  EBS     Bucket  policy    limi(ng  access     Legend    AmazonEC2   Instance  +   CloudWatch   Security  Group   Elas5c  Load   Balancer   Route  53  Hosted   Zone   CloudFront   Amazon  S3   Bucket   Amazon  RDS   Instance  
  24. 24. Amazon CloudFormation Deployment and Management …  and  then  reuse! Use AWS CloudFormation’s sample templates or create your own templates to describe the AWS resources, and any associated dependencies or runtime parameters, required to run your application. Deploy and update a template and its associated collection of resources “called a stack” via the AWS Management Console, AWS CloudFormation command line tools or APIs. CloudFormation is available at no additional charge, and you pay only for the AWS resources needed. Template   AWS  CloudForma5on   Stack  
  25. 25. What  about  scaling  the  Data  Tier? This  is  where  NuoDB  delivers  HUGE  value  …  
  26. 26. Here  are  some  addiBonal  resources:  AWS CloudFormation Sample Templates: https://aws.amazon.com/cloudformation/aws-cloudformation-templates/  AWS User Groups: http://aws.amazon.com/usergroups/  Introduction to AWS IAM Training Video: https://us-east-1-aws-training.s3.amazonaws.com/intro/iam.html  Service Documentation: http://aws.amazon.com/documentation  Pricing Calculator: http://aws.amazon.com/calculator/  Economics: http://aws.amazon.com/economics/  Pricing details for all services: http://aws.amazon.com/pricing/  Solutions Case Studies: http://aws.amazon.com/solutions/case-studies  Marketing Overview Materials: http://aws.amazon.com  Videos & Webinars: http://www.youtube.com/AmazonWebServices  AWS Blog: http://aws.typepad.com/
  27. 27. Architecting for the Cloud Seth Proctor, CTO @technicallyseth
  28. 28. What’s unique about “cloud”?
  29. 29. Cloud architecture   On-demand   Scale-out for capacity & availability   Public infrastructure; dynamic provisioning   Flexible   Commodity   Hybrid (public & private)   Simple   Monitoring & management   Platform APIs and automation   Resilient
  30. 30. Why a different architecture?   Greater capacity   Cost-effectiveness   Higher availability and better failure- handling   Lower latencies for global deployment
  31. 31. Challenges   Distribution brings challenges   Lots of failures happen with frequency   More difficult to get a global view   Security & data lifecycle is harder   Everything else about “distributed computing”   Still, we can scale most layers   Load-balancers & name services at the top   Horizontally-scaled app servers   Caches & CDNs for content   Redundant disks and object stores
  32. 32. Scaling the database is the real challenge
  33. 33. Traditional database design   RDBMS architectures start at the disk   Vertical scale follows   Caching helps, but often breaks consistency   HA systems become very expensive   Schema & operation is hard to evolve   Hard to harness commodity infrastructure   Not designed to scale-out
  34. 34. Common options   Replication   Active-passive or (gulp) multi-master   Replicated data but visible delays & conflict Sharding   Split one database into many sub-sets   More capacity but hard to evolve and relate   Abandon consistency   Push correctness & conflict to the application   Simpler core architecture but painful for applications and hard to reconcile failures
  35. 35. Side-effects   Applications are tied to deployment   Hence, dev-ops   Complex for on-demand changes, failures   More, independent pieces   Harder to interpret failures   Complexity
  36. 36. Global deployment   Many motivations   Disaster Recovery   Lower-latency for distributed users   Data access & storage residency rules   Trade-offs between latencies and safety   Storage may be a separate concern from interaction
  37. 37. Approach Shared Disk Shared-Nothing/ Sharded Durable Distributed Cache Key Idea Sharing a file system. Independent databases for disjoint subsets of data. Replicating data in memory on- demand. Topology Example Oracle RAC DB2 Pure Scale MySQL Cluster and most NoSQL/NewSQL solutions Distributed Database Designs *Note: Most major web properties include custom-sharded MySQL or sharded PostgreSQL, including Facebook, GOOGLE, Wikipedia, Amazon, Flickr, Box.net, and Heroku.   12
  38. 38. Peer to Peer Architecture P P P S3Disk , ... P P NuoDB Database Peer Process Provisioned, Manageable Resources Peer to Peer Communications SQL Client Management Client SQL Front-End SQL Optimizer Transaction Handling Object Caching Object Coordination Durability P
  39. 39. Magic Quadrant 2013 About NuoDB Magic Quadrant 2013 & 2014 NuoDB delivers a distributed SQL database management system specifically designed for the cloud and the modern datacenter. Magic Quadrant 2013
  40. 40. Summary   When architecting for the cloud..   Look for distributed architectures with on- demand capabilities   Layer & abstract to support evolution and react gracefully to failures   Assume your needs will evolve; plan with scale in mind   Please try out NuoDB!   http://dev.nuodb.com
  41. 41. Thank you!

×