Looking for some solid guidance to help build your private or hybrid cloud? Want to turn your existing data center into a private cloud? Or perhaps you want to integrate your private cloud with a public cloud, but you’re not sure where to get started. In this webinar you'll learn the key considerations for building a private or hybrid cloud, presented by the pros at RightScale who help our customers do this every single day. We’ll discuss: - Selecting hardware: How to decide which compute, networking and storage options to select. - Private cloud considerations such as workload and infrastructure interaction, security, latency, user experience, and cost. -Reference architectures and design considerations such as the location of physical hardware and configuration for availability and redundancy. - Use cases and real-life scenarios: Private and hybrid clouds are especially well-suited for scalable applications with uncertain demand, disaster recovery and self-service IT portals. - How to select the cloud solution provider that’s right for you, and how to manage your cloud resources effectively. You’ll leave this webinar with a thorough understanding of building blocks for private and hybrid clouds.

1. Building Blocks for
Private and Hybrid Clouds
August 8, 2012
Watch the video of this webinar
#rightscale

2. 2#
Your Panel Today
Presenting
• Brian Adler, Sr. Professional Services Architect, RightScale
• Ryan Geyer, Sales Engineer, RightScale
Q&A
• Noel Cohen, Account Manager, RightScale
Please use the “Questions” window to ask questions any time!
#rightscale

3. 3#
Agenda
• Definitions and Terminology
• Infrastructure Evolution
• Private Cloud Key Considerations
• Hybrid Clouds – Different things to different people
• Use Cases for Private and Hybrid Clouds
• Best Practices for Private/Hybrid Cloud Design and Implementation
• Design Considerations
• Hardware Consideration
• Software Considerations
• Implementation
• Management
• Conclusion/Q&A
#rightscale

4. 4#
Definitions and Terminology
• Virtualization (server)
• Division of one physical server into multiple isolated virtual environments
• Private Cloud
• A collection of compute, storage, and network resources for a single tenant
that are accessed programmatically via an API endpoint.
• Public Cloud
• A similar set of resources that is multi-tenant and is provided by a cloud vendor
with access via an API endpoint.
• Multi-Cloud
• An environment that spans two or more separate clouds, be they both public,
both private, or one (or more) of each.
• Hybrid Cloud
• An environment that spans one or more public clouds as well as one or more
private clouds.
#rightscale

5. 5#
Infrastructure Evolution
• Old school Datacenters
• Racks of physical nodes, one application per node
• It’s all we knew, it worked, and it was fine.
• Virtualization – The Early Years
• Capability of a node outgrew the needs of any single application
• Lots of idle resources on each node
• Virtualization provided the ability to have a many-to-one (servers per
node) relationship
• This was better
• Cloudification (Virtualization grows up)
• Automated provisioning and management via an API appears
• This is much, much better
#rightscale

6. 6#
Private Cloud Key Considerations
• Workload and Infrastructure Interaction
• Applications have different resource needs
• Choose the right fit for your application and your infrastructure
• Security
• Data may be contained within the private cloud, thus allowing for stricter
security compliance
• Latency
• Consumers of the private cloud resources are generally “closer” to the private
cloud, which reduces latency
• User Experience
• Related to latency, end user experience is enhanced due to proximity to
resources.
• Cost
• OPEX is generally reduced. (CAPEX is another story )
#rightscale

7. 7#
Hybrid Clouds
• What if application outgrows the private cloud?
• Common desire is for “cloud-bursting”
• When private cloud resources are exhausted, a server tier expands into the
public cloud to tap into the “infinite” resources
• Considerations:
• Security – public Internet is traversed
• Latency – traversal of public Internet involves the Great Unknown
• Cost – bandwidth charges for public Internet traversal
• Complexity – setting up a secure environment is not a trivial task
• More common use case is multiple clouds in an organization, with
multiple applications, and with each application contained entirely
within a single cloud.
#rightscale

8. 8#
Hybrid Cloud Bursting
PUBLIC
INTERNET
LOAD BALANCERS
APP SERVERS APP SERVERS
MASTER DATABASE
SLAVE DATABASE
OBJECT STORAGE
PRIVATE CLOUD PUBLIC OR PRIVATE CLOUD
Cloud Bursting
#rightscale

9. 9#
Use Cases
• Self-Service IT Portal (“IT Vending Machine”)
• Test/Dev environment
• Users select one of several preconfigured tech stacks
• “Siloed” environments
#rightscale

10. 10#
Use Cases
• Self-Service IT Portal (“IT Vending Machine”)
• Demo
#rightscale

11. 11#
Use Cases
• Scalable Applications with Uncertain Demand
• Public cloud used as “proving ground” for new applications
• If applications fail, they are allowed to run their course in the public cloud until
they are end-of-lifed
• If an application gains traction, it remains in the public cloud during its growth
phase
• When stability of workload is reached, the application is transitioned into the
private cloud
#rightscale

12. 12#
Use Cases
• Disaster Recovery (DR)
• Production environment in one cloud
• DR environment in a second cloud
• Most common configuration is the “Warm DR” scenario
• Replicating slave in a second cloud
• All other servers in non-operational state
• Failure of production environment requires promotion of slave to master, launching of “standby”
servers, and DNS reassignment
#rightscale

13. 13#
Design Considerations
• Location of Physical Hardware
• On-premise
• Availability considerations (power, cooling, networking, etc.)
• Hosted or Colocation facility
• Accessibility of hardware for additions and/or modification
• Latency to end users
• Security
• Availability and Redundancy Configuration
• Easiest configuration (single zone, single region, single API endpoint) does not
promote high availability
• Outage of API endpoint renders entire cloud unavailable
• Power issues affect entire pool of resources
• High Availability of cloud resources requires more complex configurations
• Multiple zones, multiple regions (if possible/practical)
• Multiple API endpoints
• Redundant and segregated power and networking
#rightscale

14. 14#
Design Considerations/Options
Simple Configuration
HA Configuration
No HA or Redundancy
#rightscale

15. 15#
Design Considerations
• Intended Workloads and Use Cases
• Does the application require high availability or is it tolerant of interruptions of
service?
• User-facing will most likely require HA.
• Batch processing tasks may not.
• Is flexibility of the infrastructure required for test-beds and/or proof-of-
concepts?
• Potential topologies and hardware options will be affected/limited
• Does the application require (or greatly benefit from) high performance CPUs?
• Does the application have high IOPS demands?
• Are low-latency interconnects required?
#rightscale

16. 16#
Hardware Considerations
• Compute
• Commodity
• Allows for easy addition of capacity
• Easy swap-out of failed components
• High end/specialized
• May be required for intended workloads
• Limits available options
• Increases costs
• Complicates maintenance
• Networking
• Driven by topology, latency demands, and price
• Some cloud infrastructure software offerings have support for network hardware
devices (load balancers in particular)
• Storage
• Cost vs. Performance (commodity? SSD?, etc.)
#rightscale

17. 17#
Software Considerations
• Cloud Infrastructure Software
• CloudStack, OpenStack, Eucalyptus, etc.
• Open source vs. commercial
• Dictates/influences other decisions regarding cloud implementation
• Access to resources
• Web interface
• API
• Cloud Management Software
• Abstracts underlying details of the cloud infrastructure offerings
• Presents consistent interface to the available resources regardless of the
underlying infrastructure provider
• Provides a cloud-portable solution
• Provides orchestration tools for provisioning and management
#rightscale

18. 18#
Implementation Process
• Hardware Procurement
• Pre-existing or new?
• Pre-existing limits ability to tailor infrastructure to workloads
• Cloud Infrastructure Software
• This decision will dictate/limit many future decisions
• Research options, and choose wisely!
• Cloud Topology
• Zones, regions, storage allocation, HA considerations, etc.
• Build or Buy
• Use in-house resources if expertise exists
• Third-party resources
• Build using existing resources
• Build using new preconfigured hardware
#rightscale

19. 19#
Management Process
• Compatibility
• Avoid vendor lock-in at IaaS level, hypervisor level, cloud infrastructure software
level
• Unified Control/Security
• “Single pane of glass” for user access, keys and credentials, etc.
• On-Demand, Self-Service Provisioning
• Allow users to access resources without administrative intervention
• Focus on Applications
• Core competency is in application development, so remove yourself from image
management, automation, provisioning, etc.
#rightscale

20. 20#
Summary/Conclusions
• Private (and therefore hybrid) clouds were originally thought of as an
academic exercise or science project
• Recent advances (particularly in cloud infrastructure software) have
shown private and hybrid clouds to be viable IT delivery models
• Many considerations come into play
• Design
• Hardware
• Software
• Implementation Details Contact RightScale
• No “one size fits all” (866) 720-0208
sales@rightscale.com
• Do your research. Find the right fit.
www.rightscale.com
#rightscale