1 / 25

Leveraging Cloud Architectures in the Enterprise

Leveraging Cloud Architectures in the Enterprise. Tim M ackey. Citrix Systems Cloud Evangelist. Enterprise Objectives for Cloud. Remove IT as a service delivery critical path. Self Service. Management Automation. Reduce IT operational costs. Workforce Leverage.

frieda
Télécharger la présentation

Leveraging Cloud Architectures in the Enterprise

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Leveraging Cloud Architectures in the Enterprise Tim Mackey • Citrix Systems Cloud Evangelist

  2. Enterprise Objectives for Cloud Remove IT as a service delivery critical path Self Service Management Automation Reduce IT operational costs Workforce Leverage Consistent application and service deployment Workload Standardization Usage Metering Visibility into user and line of business usage Centralized Management Manage complete infrastructure, regardless of scale Capital Leverage Smarter Virtualization Drive reduced capital requirements

  3. Server Virtualization++ Cloud • More scalable • Lower cost • More open • Built for traditional enterprise apps and client-server compute • Architected for 100s of hosts • Scale-up (server clusters) • Applications assume reliability • IT Management-centric [1:Dozens] • Proprietary vendor stack • Designed around big data, massive scale and next-gen applications • Cloud architecture for 1000s of hosts • Scale-out (multi-site server farms) • Applications assume failure • Autonomic [1:1,000’s] • Open, value-added stack Think: vCloud Director Think: AWS, RAX, zCloud, eBay, etc. …but adoption of new cloud architecture is the future Enterprises should, and will, become more cloud-like…

  4. Key Features for Successful Clouds

  5. A Cloud Role Model: AWS

  6. Amazon Web Services Architecture • Availability Zone • Location engineered for failure isolation • Contains compute, network and storage • Region • Geographically dispersed data centers • Contains one or more Zones • Instance • Predefined compute element with template • Local storage destroyed with instance • Elastic Design • Predictable costing model • On demand provisioning

  7. Availability and Implementation Assumptions US West (California) US East (Virginia) • No zone uptime guarantee • SLA: Region has uptime of 99.95% in last year • Customer owns application • Infrastructure is Amazon’s problem • Zone implementation hidden • Compute unit based  “early-2006 1.7Ghz Xeon” • Hypervisor is heavily customized Xen • Network details fully abstracted • Instance configuration pre-defined • Supports custom templates within instance type

  8. Enterprise Applications and AWS VM VM VM VM VM VM VM VM • Instance location is unknown • Which host is running the instance? • Are multiple nodes on the same host? • Storage and Network are unknown • Performance optimizations limited • IO control limited • Compliance • Limited capability to audit and monitor • No visibility into network segmentation • Security groups a proven model

  9. Cloud Builder Lessons from Amazon • Customizing the hypervisor made sense …. In 2006 • Hypervisor is a commodity. Go with proven solution for best supportability • Infrastructure should be abstracted, but core architecture needs to make sense • Design with the expectation that a core component may need to be replaced • Traditional packaged enterprise applications not designed for agility • Assume outages, not availability • Assume stateless, not statefull • Assume dynamic scale, not static capacity planning • IaaS model do work, but you need to plan for them • Start with new projects, don’t try and migrate as the first cut

  10. Learning from Amazon

  11. Case Study: Zynga • Online gaming studio based in CA • Believes internet should be for fun • FarmVille reached 25 million daily users in 5 months • Started with traditional colo model • Couldn't scale fast enough and outgrew data center • No agility, and agility is key for games • Leverages Amazon AWS • Low cost development platform • Provides fixed cost services during rollout • zCloud is internal private cloud • Looks and feels like AWS, only more control • Favorable cost model at game scale

  12. Anatomy of zCloud • Agility is the core requirement • zCloud tuned for the needs of Zynga • In memory databases • Single digit latency between nodes • Very quick provisioning • AWS Large Instance  zCloud host • Can provision 1000 hosts in < 24 hours • Key solution elements: CloudStack, RightScale and XenServer • Jan 2011 80% of workloads in AWS • Jan 2012 80% in zCloud

  13. Manage What You Own • Profile applications in AWS, then move in house • Built game monitoring tools • Games are the assets • “All-In” monitoring of external infrastructure • Service providers show 4-5 9s, but users say different • Redundant providers at each level • Direct fiber to multiple AWS regions • Implemented data replication • Fully automated provisioning at each level

  14. Cloud Builder Lessons from Zynga vs. • Public clouds are minivans • zCloud is a race car • zCloud is optimized for social gaming • Know your application requirements • Don’t rent what you can own cheaper • Cloud operator doesn’t care about your success • Optimized applications might be key • Ensure you have backup plans • Usage can and does spike • Outages can and do happen

  15. Case Study: Korea Telecom uCloud • South Korean telecom giant • Largest landline, and second largest mobile provider • uCloud provides Enterprise and Consumer Services • Compute, Storage, Backup and virtual desktop services • Core requirements were performance and agility • Delivers services for 40% less than AWS

  16. Case Study: TATA InstaCompute Largest Indian telco, and provider of global IT services InstaCompute designed for DevOps and IT outsourcing Pilot to production in under 9 months Delivers compute costs 50% below AWS

  17. Cloud Builder Lessons From Telcos • Utility computing fits business model • Traditionally operate a low margin business model • Understand tiered service offerings • Have a history with instant provisioning • Tiered service demands infrastructure flexibility • “Cost per instance” is paramount • Charge extra for premium features • Instance doesn’t imply virtualization • Be prepared to change vendors if better model appears • Provisioning agility expected • Customers expect instant self service access and detailed billing

  18. Designing Your Enterprise Cloud

  19. Service Offerings • Clearly define what you want to offer • What types of applications • Who has access, and who owns them • What type of access • Define how templates need to be managed • Operating system support • Patching requirements • Define expectations around compliance and availability • Who owns backup and monitoring

  20. Enterprise Tenancy Requirements • Department data local to department • Where is the application data stored • Data and service isolation • VM migration and host HA • Network services • Encryption of PII/PCI • Where do keys live when data location unknown • Need encryption designed for the cloud • Showback to stakeholders • More than just usage, compliance and audits

  21. Virtualization Infrastructure • Hypervisor defined by service offerings • Don’t select hypervisor based on “standards” • Understand true costs of virtualization • Multiple hypervisors are “OK” • To “Pool” resources or not • Is there a real requirement for pooled resources • Can the cloud management solution do better? • Real cost of shared storage • Primary storage defined by hypervisor • Template storage defined by solution • Typically low cost options like NFS

  22. Cloud Operations If your cloud has maintenance windows, you’re doing it wrong. • Design for maintainability • Monitor critical components • Management servers and system support VMs • Hypervisor hosts, and critical infrastructure • End user deployment environments

  23. Candidate Cloud Deployment Model Zone 1 Load Balancer Firewall L3 switch Pod 1 Pod N L2 switch …. Cluster N …. Cluster 1 Host 1 Primary Storage Secondary Storage Host 2 A Host is the basic unit of scale. A Cluster groups compatible hosts All hosts in a cluster have access to shared (primary) storage A Pod is one or more clusters, usually with a L2 switch. Typically a pod is a rack. Zones contain one or more pods, and have access to secondary storage for templates Firewall and Load balancers separate public and private networks

  24. Cloud Architectures are the Key to Success Worlds largest public cloud environment Delivering video on demand via the cloud Uses the cloud to sell more pigs Transformed their hosting business with the cloud Uses the cloud to disrupt the way we communicate Built one of the fastest growing and most innovative companies on the planet

More Related