Citrix Systems Cloud EvangelistTim Mackey

Leveraging Cloud Architectures in the Enterprise

Enterprise Objectives for Cloud

Remove IT as a service delivery critical pathSelf ServiceSelf Service

Reduce IT operational costsManagement Automation

Management Automation

Consistent application and service deploymentWorkload Standardization

Workload Standardization

Manage complete infrastructure, regardless of scaleCentralized ManagementCentralized

Management

Drive reduced capital requirementsSmarter

VirtualizationSmarter

VirtualizationCa

pita

l Lev

era

geW

ork

forc

e L

eve

rage

Visibility into user and line of business usageUsage MeteringUsage Metering

Server Virtualization++ Cloud

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

Think: vCloud Director

Enterprises should, and will, become more cloud-like…

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: AWS, RAX, zCloud, eBay, etc.

…but adoption of new cloud architecture is the future

• More scalable• Lower cost• More open

Key Features for Successful Clouds

• Select the correct hypervisor to best match workload needs• Seamlessly manage provisioning process across hypervisors

Multi-Hypervisor Support

• Provide optimal workload performance and availability• Management of multiple availability zones from a single consoleAvailability Zones

• Define virtual and physical network isolation rules• Support load balancing and VPN access rules

Flexible Network Management

• Flexible user, network and provisioning isolation rules• Ability to delegate tenancy for departments and divisionsTenant Isolation

• Freedom to define capacity with no per-VM licensesNo per-VM Licensing

A Cloud Role Model: AWS

• 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

Amazon Web Services Architecture

• 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

Availability and Implementation Assumptions

US East (Virginia)

US West (California)

• 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

Enterprise Applications and AWS

VMVM

VMVM

VMVM

VMVM

• 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

Cloud Builder Lessons from Amazon

Learning from Amazon

• 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

Case Study: Zynga

• 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

Anatomy of zCloud

• 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

Manage What You Own

• 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

Cloud Builder Lessons from Zynga

vs.

• 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

Case Study: Korea Telecom uCloud

• 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

Case Study: TATA InstaCompute

• 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

Cloud Builder Lessons From Telcos

Designing Your Enterprise Cloud

• 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

Service Offerings

• 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

Enterprise Tenancy Requirements

• 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

Virtualization Infrastructure

• Design for maintainability

• Monitor critical components◦ Management servers and system support VMs◦ Hypervisor hosts, and critical infrastructure◦ End user deployment environments

Cloud Operations

If your cloud has maintenance windows, you’re doing it wrong.

Pod 1

Cluster 1

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

Candidate Cloud Deployment Model

Host 1

….

L3 switch

SecondaryStorage

Pod N

Zone 1

FirewallLoad Balancer

PrimaryStorage

L2 switch

….

Cluster N

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

Cloud Architectures are the Key to Success