Architecting Multi-Cloud Environments

Think Multi-Cloud!
Josep M. Blanquer
Sr. Systems Architect

Outline
What do I 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
Conclusions

What do I mean by cloud?
Services vs. Cloud Types vs. Clouds
A cloud is a physical entity behind an API endpoint
Amazon Web Services is not a cloud
It is a set of services: S3, CloudFront, SQS, SNS, EC2, …
EC2 is not a cloud
It is a type of cloud, defined by a public API
Eucalyptus, Cloud.com are not a cloud
They are the tools that allows to create them, following a cloud type
EC2 East, EC2 AsiaPacific, my private cloud… are clouds
They are instantiations of a cloud, providing a service API of a given type
An availability zone is not a cloud, it’s part of one

Where is my cloud in the wild?

Where is my cloud in the wild?
There might be just a few big cloud players
…but there will be a myriad of clouds

Where are my clouds in RightScale?
Dashboard example:
AWS, Rackspace and several private clouds in one account
A cloud is first registered with RightScale
Public clouds like AWS, Rackspace are automatically added
Private clouds are registered by admins.
Once a cloud is registered, a user can start using it
By providing its credentials to it.
AWS uses same creds for all its clouds, that’s why this is only done once

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 not about choosing one cloud provider, but multiple
Current focus: cloud portability

Multi-cloud: benefits
Redundancy, disaster recovery and geo-presence
Leverage unique cloud-specific services when needed
Leverage public cloud cost benefits (cheaper and/or infinite)
Leverage existing investments: private cloud
Move services with bursty, unpredictable apps to public cloud
Private cloud for red-tape bound apps
Support varying levels of security concerns

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, ACLs, …
Storage architectures differ: local/attachable disks, backup, snapshots, …
Hypervisors and machine images differ
Supported features differ
Not just by cloud type, but by cloud instantiation or version
…cost models, billing, reporting…etc
They are truly different applications, with different semantics

How to think multi-cloud?
“Akin to designing your application using several programming languages”
Deploy using cloud-specifics, design using generic concepts
Utilize unique features when needed, but don’t lock yourself in
Have tools that translate your concepts to cloud-specific ones.
Not just the API calls, but higher level concepts like backups, etc.
Design for geographic dispersity
Communicating and moving data across clouds can be expensive, slow
Think of how to share data across
Global storage, periodic backups, live replication, etc
Know if you’re designing for HA or simply for portability
Tightly coupled HA setups look much different than isolated subsystems

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

(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
Backed by the same mirror service to provide frozen repositories
They coexist in mixed deployment listings, same filters, columns…
They can be tagged, and configured in the same way
Can be very different beasts, but they are seamlessly integrated
ServerTemplate
Server
1:N
I
1:1
I
I
I
I
MCI
software config
runtime config
cloud resources

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
…

Parenthesis: What are ServerTemplates?
Anatomy of a
Server Template
Example Server Template:
MySQL 5.0
RightScript/Recipe 6
Initialize slave
…
…
operations
operations
Perform backup
RightScript/Recipe N
Start all services
…
…
Setup DNS and IPs
Restore last backup
boot sequence
boot sequence
Configure/tune MySQL
Install MySQL Server
Install monitoring
Base Image
Right Image

(Multi-Cloud) Server Templates
They are software configuration abstractions
Bridging the gap between the starting point (a base Image) and a fully configured machine
Abstract Cloud and Operating System differences
Chef helps in that regard
Gather a set of user defined, high-level Input values
Can partially help in the sharing of data
Allow configuring servers always in the same or equivalent way
ServerTemplate
Server
1:N
I
1:1
I
I
I
I
MCI
software config
runtime config
cloud resources

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
Equivalent images don’t have to be identical
They are versionable and publishable
Are associated to ServerTemplate
A Server launch will pick the right image based on its cloud mapping
MCIs also define other cloud variances like Instance types, kernel, etc…
ServerTemplate
Server
1:N
I
1:1
I
I
I
I
MCI
software config
runtime config
cloud resources

Multi-Cloud Images: RightImages
RightScale maintains such maps (MCI’s) for all public clouds
Wait, what about images in my private cloud?

Demo: Servers, Templates and MCI’s
Quick demo using the Rightscale Dashboard

Data locality and mobility
A topic a bit further down the road
A big hurdle to overcome
Because clouds don’t share data: they are isolated
How can our app share data across its clouds then?
External globally accessible services:
S3, CloudFiles, Akamai, Dropbox…
Transferring data snapshots across.
Big data = Long time. Can be unpractical, not good for fast failover scenarios.
Maintaining online data replication across clouds.
Good for local reads, difficult for multi-writes. Good for fast failover scenarios.
Using an inherently replicated service, that is distributed
It is possible to achieve multimaster and replication, but at the cost of more complex tech
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

Multi-Cloud Use Case: portability
Test & dev
US customers(production)
EU customers(production)
…
US customers(beta)

Multi-Cloud Use Case: portability
Scalable, powerful
and redundant
All-in-Ones
Test & dev
US customers(production)
EU customers(production)
…
Rails
MySQL
Load balancer
Scripts
and recipes
US customers(beta)
Rails
Front-End
Rails
All-in-One
Rails
App Server
MySQL
Templates
Ubuntu 8.04
Multi-Cloud
Image
Less power
and redundancy
Servers

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.
Think different, again!
Designing/deploying/managing in multi-cloud is different than single-cloud
Multi-cloud is a step further towards fulfilling the cloud paradigm

Using these abstractions: Server
A Server has a ServerTemplate

Using the abstractions: ServerTemplate
A ServerTemplate has a list of suportedMCIs

Using these abstractions: MCI’s
Each MCI will have mappings to several clouds

http://blog.ahems.co.kr	419
http://www.sattvaq.com	9
http://www.hanrss.com	2

Architecting Multi-Cloud Environments

by RightScale

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 430

Statistics