Rightscale Webinar: Building Blocks for Private and Hybrid Clouds


Published on

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.

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Rightscale Webinar: Building Blocks for Private and Hybrid Clouds

  1. 1. Building Blocks forPrivate and Hybrid Clouds August 8, 2012 Watch the video of this webinar #rightscale
  2. 2. 2#Your Panel TodayPresenting• Brian Adler, Sr. Professional Services Architect, RightScale• Ryan Geyer, Sales Engineer, RightScaleQ&A• Noel Cohen, Account Manager, RightScale Please use the “Questions” window to ask questions any time! #rightscale
  3. 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. 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. 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. 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. 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
  9. 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. 10#Use Cases• Self-Service IT Portal (“IT Vending Machine”) • Demo #rightscale
  11. 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. 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. 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. 14#Design Considerations/Options Simple Configuration HA Configuration No HA or Redundancy #rightscale
  15. 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. 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. 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. 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. 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. 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