Upload
john-georgiadis
View
208
Download
2
Embed Size (px)
DESCRIPTION
Hybrid clouds provide a good balance between the privacy offered by private clouds and the elasticity and reliability of public clouds. The presentation offers an introduction to the decision criteria when switching from a private to a hybrid cloud architecture and where to start from.
Citation preview
HYBRID CLOUDAdoption roadmap
THE CASE FOR HYBRID CLOUD
• Large resource allocation variance. E.g. Netflix reaches peak traffic in evenings, weekends & Christmas.
• Disaster Recovery: a replica environment in stand-by mode in the public cloud.
• Added-value services expensive to implement in-house at scale.
WHICH SERVICES BELONG TO THE PUBLIC CLOUD?
• Services that exhibit large usage variance:
1. Provision entirely in the public cloud.
2. Overflow to the public cloud(not practical with frequent updates and strict synchronization requirements unless collocated).
• Services that are expensive to implement in-house and difficult to scale or provide 99.9% uptime.
• Services with heavy interaction should stick together whether in public or private cloud.
Client
Fixed Resource Cloud
Elastic Cloud
ClientLB
WHICH SERVICES BELONG TO THE PRIVATE CLOUD?
• Services with unique security requirements.
• Services with unique privacy requirements.
• Cost: very complicated to evaluate upfront. It drops 20% / year.
SERVICES LIKELY TO EXHIBIT USAGE VARIANCE
• Media streaming.
• Analytics usually running at the EoD.
• All services during a corporate event such as the launch of a new product line.
SERVICES EXPENSIVE TO MAINTAIN IN-HOUSE
• Geographically distributed private clouds
• Content Delivery Networks (CDNs)
• Media Transcoding
• GPU cloud: very high cost upfront
DISASTER RECOVERY• Define recovery time (RTO - how much
downtime) and recovery point (RPO - how much data lost) objectives.
• Replicate VMs to cloud storage.
• Replicate DBs to cloud DBs.
• Create a deployment configuration ready to launch when disaster hits (cold-standby) or a small set of VMs that are always live (warm-standby).
• Avoid early fail-over to DR environment as it will aggravate the damage:RPO+RTO < Recovery Time of Master.
DESIGN FOR THE CLOUD• Loose coupling:
• Use publish/subscribe for service interactions.
• Adopt share-nothing architectures, they scale better.
• Fail fast: show an error immediately rather than a spinning wheel for 10 mins and then an error.
• Favor monolithic app designs rather than a network of interconnected micro-services.
• Favor automatic recovery rather than focus on diagnostics and logging.
• Get familiar with cloud automation tools (puppet, chef, pallet, AWS CloudFormation, etc.).
DEPLOY FOR THE CLOUD• The Docker revolution: no more “works
on my PC” statements.
• Clear release path:
• QA certifies Docker containers and pushes them to the repository.
• DevOps perform rolling updates of the published containers.
• Amazon, Google & Redhat have all jumped into it. It will probably affect everybody by mid next year.
$ / G
B
0.075
0.15
0.225
0.3
2006 2012 2014
AWS Google Microsoft
HISTORIC PRICES• Storage cost dropped
84% in 5 years.• VM cost dropped 56% in 3
years.
$ / H
our
0
0.175
0.35
0.525
0.7
2012 2013 2014 Sep 2014
AWS - m3.xlarge (15GB, 4 cores)
CASE STUDY MAPMYFITNESS.COM
• Allows users to map, record and share their exercise routes and workouts online (400,000 activities logged daily).
• 17 million users. Peak traffic during weekends and sport events (Tour de France, etc.).
• Both private & public cloud hosted with Rackspace.
• Hybrid cloud used for :
• Overflow traffic.
• Testing and development.
• Hosting event-type websites that are shorter lived.
NEXT STEPS• Move your public content to a CDN.
• Build a DR environment in Amazon or Google and maintain it.
• Use AWS Route 53 (DNS) to redirect traffic to geo-local data centers.
• Deploy to more than one cloud provider : Amazon failed on the Christmas Eve of 2012 reflecting downtime to Netflix.