RightScale Webinar: December 8, 2010 – In this Webinar, we discuss the benefits and pain points of multi-cloud as well as key considerations to have in mind when going multi-cloud. We present examples of multi-cloud scenarios and describe the design principles to consider when architecting deployments that must span and migrate across different clouds and providers.
4. Agenda What do we mean by a cloud? What is multi-cloud and what’s different? How does RightScale help? Servers and ServerArrays Multi-Cloud Server Templates Multi-Cloud Images Data locality and mobility A multi-cloud example and demo Conclusions / Q&A Please use the questions window to ask questions anytime!
5. What do we mean by cloud? A cloud is a physical data center entity behind an API endpoint What do you mean by that? Amazon Web Services is not a cloud EC2 is not a cloud Eucalyptus, Cloud.com are not a cloud EC2 East, EC2 AsiaPacific, my private cloud… are clouds An availability zone is not a cloud, it’s part of one Think of a cloud as a “resource pool” accessed via API
7. Where is my cloud in the wild? There might be just a few big cloud players …but there will be a myriad of clouds
8. Where are my clouds in RightScale? Dashboard example: AWS, Rackspace and several private clouds in one account A cloud is first registered with RightScale Once a cloud is registered, a user can start using it
9. What does multi-cloud mean? It’s about deploying your application: Across different clouds Spanning cloud providers (most likely with different API’s) Utilizing private and public ones It’s about evolving your application to: Incorporate new clouds as they appear Or quickly moving servers to utilize leftover or new cloud capacity All seamlessly: Without having to learn a new interface every time Working together in an integrated manner It’s about using multiple cloud providers, not choosing one Current focus: cloud portability
10. Multi-cloud: benefits Redundancyfor disaster recovery and business continuity Geo-location for latency and/or policy compliance Leverage unique cloud-specific services when needed Leverage public cloud cost benefits (cheaper and/or infinite) Leverage existing data centers: private cloud Move services with bursty, unpredictable apps to public cloud Private cloud for apps with regulatory compliance reqs Support varying levels of security concerns
11. Multi-cloud: pain points APIs differ Different sets of resources Different formats and encodings Several simultaneous versions for a single cloud Abstractions differ Network architectures differ: VLANs, security groups, NAT, IPs, ACLs, … Storage architectures differ: local/attachable disks, backup, snapshots, … Hypervisors and machine images differ Supported features differ …cost models, billing, reporting…etc They are truly different applications, with different semantics
12. How to think multi-cloud? “Akin to designing your application using several programming languages” Deploy using cloud-specifics, design using generic concepts Have tools that translate your concepts to cloud-specific ones. Design for geographic dispersion Think of how to share data across Know if you’re designing for HA or simply for portability
13. How does RightScale help? Unified Multi-Cloud UI and new API (in progress) Multi-Cloud Servers/Arrays Multi-Cloud Server Templates Multi-Cloud Images Others in the pipeline ServerTemplate Image Server 1:N I 1:1 I I I I runnable abstraction software config runtime config cloud resources
14. (Multi-Cloud) Servers and Arrays Servers and Arrays are runtime abstractions All Servers look and smell similar, regardless of cloud: Can be started, stopped or run operational actions in the same way Show monitoring data, and can configure alerts in the same way They coexist in mixed deployment listings, same filters, columns… They can support abstractions that some clouds don’t support … Can be very different beasts, but they are seamlessly integrated ServerTemplate Server 1:N I 1:1 I I I I MCI runnable abstraction software config runtime config cloud resources
15. Parenthesis: What are ServerTemplates? Configuring servers through bundling Images: Configuring servers with ServerTemplates: Custom MySQL 5.0.24 (CentOS 5.2) Custom MySQL 5.0.24 (CentOS 5.4) A set of configuration directives that will install and configure software on top of the base image MySQL 5.0.36 (CentOS 5.4) MySQL 5.0.36 (Ubuntu 8.10) MySQL 5.0.36 (Ubuntu 8.10) 64bit Frontend Apache 1.3 (Ubuntu 8.10) Frontend Apache 2.0 (Ubuntu 9.10) - patched CMS v1.0 (CentOS 5.4) CMS v1.1 (CentOS 5.4) My ASP appserver (windows 2008) My ASP.net (windows 2008) – security update 1 Base Image Very few and basic My ASP.net (windows 2008) – security update 8 SharePoint v4 (windows 2003) – 32bit SharePoint v4 (windows 2003) –64bit Win 2003 CentOS 5.2 Ubuntu 8.10 SharePoint v4.5 (windows 2003) –64bit CentOS 5.4 Win 2007 Ubuntu 9.10 …
16. Parenthesis: What are ServerTemplates? Anatomy of a Server Template Example Server Template: MySQL 5.0 RightScript/Recipe 6 Initialize slave … … operations operations RightScript/Recipe 6 Perform backup RightScript/Recipe N Start all services … … RightScript/Recipe 5 Setup DNS and IPs RightScript/Recipe 4 Restore last backup boot sequence boot sequence RightScript/Recipe 3 Configure/tune MySQL RightScript/Recipe 2 Install MySQL Server RightScript/Recipe 1 Install monitoring Base Image Right Image
17. (Multi-Cloud) Server Templates They are software configuration abstractions Bridge the gap between the starting point (a base Image) and a fully configured machine Abstract Cloud and Operating System differences Gather a set of user defined, high-level Input values Can partially help in the sharing of data Are versionable and publishable Allow configuring servers always in the same or equivalent way ServerTemplate Server 1:N I 1:1 I I I I MCI runnable abstraction software config runtime config cloud resources
18. Multi-Cloud Images (MCI) MCI’s abstract a set of requirements in a cloud image Example: A CentOS 5.4 Image Provide an equivalency map of base images across clouds CentOS 5.4 Image is ‘ami-feff’ in EC2 East, and ‘1234’ in Rackspace They are versionable and publishable Are associated to ServerTemplates ServerTemplate Server 1:N I 1:1 I I I I MCI runnable abstraction software config runtime config cloud resources
20. Data locality and mobility A topic a bit further down the road A big hurdle to overcome: clouds are isolated How can our app share data across its clouds then? External globally accessible services. Transferring data snapshots across. Maintaining online data replication across clouds. Using an inherently replicated service, that is distributed. Keeping track of your moving data Where’s the latest? What’s my lineage? how do I manage my datasets?... We’re thinking about useful multi-cloud abstractions to help with all that
21. Multi-Cloud Use Case: portability Test & dev US customers(production) EU customers(production) … US customers(beta)
22. Multi-Cloud Use Case: portability Scalable, powerful and redundant All-in-Ones Test & dev US customers(production) EU customers(production) … PHP MySQL Load balancer Scripts and recipes US customers(beta) PHP Front-End Rails All-in-One PHP App Server MySQL Templates CentOS 5.4 Multi-Cloud Image Less power and redundancy Servers
24. Thinking multi-cloud: summary Work with generic abstractions (deploy using cloud-specifics) Take advantage of each specific cloud’s strengths Avoid lock in. Use or build generic templates: support multiple OSes, and cloud types (not just clouds) Keep a good and clean mapping of Images Maintain just a few and use them across your server templates Know your data: Where is it, and what access patterns you’re using Keep track of where it is, and how it moves. Start with portability, then move to HA-distributed setups Think different, again!
25. Q&A / Getting Started Have a project, but need some help? Contact us: sales@rightscale.com or (866) 720-0208 Ready to get started? Sign up for our Free Edition:www.RightScale.com/Free Call us for a VIP trial of our paid editions Need to learn more? TCO calculator:www.RightScale.com/tco-calculator TCO white paper: www.RightScale.com/tco Webinar archive: www.RightScale.com/webinars White papers: www.RightScale.com/whitepapers
So here’s a graphical representation of existing clouds
So here’s a graphical representation of existing clouds
So…this sounds like a pretty onerous goal…quite a challenging…so how do we approach such a thing? What is different from working in single-cloud mode?
The punchline here is that one needs to step back, and look at the challenges a bit like an integration problem. That is, one needs to work with “portable abstractions” and be able to integrate them across.I think it is very similar to what one would do in building an application or service, consisting of several sub-applications written in different languages.So let me share some considerations to be had in mind when going multi-cloud [POINTS]So it is a fairly different way to think about stuff…it’s all about higher-level abstractions.But not all is lost, RightScale helps with these a lot….let me tell you how…
RightScale already provides several abstractions that are cloud-agnostic. In fact you’re already using probably all of them (despite you might only be deployed in 1 cloud)..We have the concept of a server (something that can be launched/running on any cloud)The concept of a ServerTemplate, which specifies the configuration we want on a serverAnd the concept of an MCI which specifies which image configuration we want (lower-level stuff)And all these things are RS concepts…the cloud is not really involved in all this…
Right not we focus on the ability to migrate applications…the next steps will be to run concurrentlyWE use some of these techniques…but are not packaged …let me finish with a multi-cloud deployment use case that can be realized today. We and others are using. Note it’s not about the more future looking scenario of having you production app runnig simultaneously in multiple clouds….it’s about being able to migration applications/deployments from cloud to cloud, much like in a cookie cutter type of way…