Architecting Multi-Cloud Environments
 

Like this? Share it with your network

Share

Architecting Multi-Cloud Environments

on

  • 4,987 views

Josep Blanquer, Sr. Systems Architect at RightScale, led this session at the RightScale User Conference 2010 in Santa Clara. ...

Josep Blanquer, Sr. Systems Architect at RightScale, led this session at the RightScale User Conference 2010 in Santa Clara.

Session Abstract: Deploying in multi-cloud environments involves much more than just choosing which cloud provider to use. It requires seamlessly deploying parts of a company's infrastructure across multiple clouds that function in concert while spanning infrastructure providers. In this session, you'll learn about the abstractions necessary to deliver portability and ease of management in a multi-cloud environment. Some important concepts to address include image management, template management, mixed deployments and data portability. We'll 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.

Statistics

Views

Total Views
4,987
Views on SlideShare
4,555
Embed Views
432

Actions

Likes
4
Downloads
126
Comments
0

3 Embeds 432

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

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Sharing considerations/insights about going multi-cloud
  • Will start by defining a cloud, so we all are in the same starting pointThen I’m going to go into describing what multi-cloud means (the holy grail, future looking thoughts)Then I’ll explain how RightScale helps in the road towards that holy grail
  • 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…

Architecting Multi-Cloud Environments Presentation Transcript

  • 1. Think Multi-Cloud!
    Josep M. Blanquer
    Sr. Systems Architect
  • 2. 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
  • 3. 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
  • 4. Where is my cloud in the wild?
  • 5. Where is my cloud in the wild?
    There might be just a few big cloud players
    …but there will be a myriad of clouds
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. (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
    runnable abstraction
    software config
    runtime config
    cloud resources
  • 13. 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

  • 14. 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
  • 15. (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
    runnable abstraction
    software config
    runtime config
    cloud resources
  • 16. 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
    runnable abstraction
    software config
    runtime config
    cloud resources
  • 17. Multi-Cloud Images: RightImages
    RightScale maintains such maps (MCI’s) for all public clouds
    Wait, what about images in my private cloud?
  • 18. Demo: Servers, Templates and MCI’s
    Quick demo using the Rightscale Dashboard
  • 19. 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
  • 20. Multi-Cloud Use Case: portability
    Test & dev
    US customers(production)
    EU customers(production)

    US customers(beta)
  • 21. 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
  • 22. 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
  • 23.
  • 24. 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