Cloud computing revolutionized application design, and changed the way people think about infrastructure. The rise of cloud computing coincided with a new generation of applications and services that required scale. New architecture and design had to take into account low latency network connectivity, geographic distribution, large real-time data stores, the ability to meet demand (while not knowing exactly how much demand to handle), and so much more. We refer to this as Internet Scale. Yet most discussion of scale and cloud revolves around compute as virtualized instances, which have defined configurations and constrained options. Delivering on the promise of Internet Scale involves substantial upfront design, and a comprehensive understanding of the entire architecture - from the underlying hardware, to the operating system, the application stack, services, and deployment. And, it involves choice - choices you should make based on your requirements. Join us for a discussion on the many facets of Internet Scale, and how it can apply to your applications and services.

1. Deliver on the Promise of Internet Scale
Design and Architecture
Marc Jones, VP of Product Innovation

3. 100k servers
24k customers
23million domains

6. Enterprise apps
Defined user base Relative predictability Cost
Internet scale apps
Global potential Relative chaos Revenue

7. Defining
Cloud Computing
Marketing term
Reference Architecture
Operations Model
Capacity on demand
Consumption-based pricing
Self-service provisioning
Accessible via API

8. On-demand, elastic resources with
Internet 24×7 reliability.
Scale? Scale is resource availability and
capacity.
Scale does not directly correlate to
“faster” performance.
Scale can help provide predictable
performance.

9. 51 million blogs
57 million daily posts
21 billion blog posts

10. 50million downloads
30hrs drawings / sec
200 million dollars

11. Online Retail
seasonality
$13,000.00
$9,750.00
$6,500.00
$3,250.00
$0
Q1 08 Q2 08 Q3 08 Q4 08 Q1 09 Q2 09 Q3 09 Q4 09 Q1 10 Q2 10 Q3 10 Q4 10
Net Sales (1,000,000’s)

12. Does an SMB need Internet scale?

13. SMB
promotional activity, social buzz
100,000
75,000
50,000
25,000
0
JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC
Monthly Unique Visitors

14. Built for
Internet Scale
Unpredictable traffic patterns
Unconstrained user base
Global potential
Network-sensitive
Leading-edge technology stack

15. Choice
Applications dictate infrastructure
Workload characteristics
Performance targets
Control requirements
Availability mandates

16. Design +
Architecture

17. Design + Architecture
Why is scalability so hard? It can’t be an after-thought. It requires applications
and platforms designed with scaling in mind.
Is achieving good scalability possible? Absolutely, but only if we architect and
engineer our systems to take scalability into account.
Simply throwing additional CPU cycles or storage at an application is not going to
deliver linear scalability unless the application was designed to scale in such a
manner.

18. Simplicity Over Complexity
Think simple. If it is a complex problem, reduce to a simpler form. Iterate.
Simple is actually hard. You have to work to simplify.
Eliminate multi-step processes. Reduce each step of every process to its
atoms. They perform their work in complete isolation, and communicate
among one another with messages.
“A system can be so simple that there are obviously no bugs,
or it can be so complex that there are no obvious bugs.”

19. Design + Architecture
Choose tools that can grow. The cloud makes it easy to add nodes. Does your
software?
Choose tools that can shrink. The cloud makes it easy to remove nodes. Most
software does not.
Leverage the best available to meet your requirements.

20. Design + Architecture
Stateless and async. One of the guiding principles for linear scalability is to have
lightweight, independent, stateless operations that can be executed anywhere and
run on newly deployed threads/processes/cores/machines transparently as
needed in order to service an increasing number of requests. Share nothing.
Testing async code can be non-trivial. Test coverage should be pursued early (as in
at the start). Test early, test often.

21. Bottlenecks
Eliminate choke points. Everything that has to be coordinated by a single
machine, or even a single cluster, is a failure waiting to happen.
I/O
- Network
- Storage
Architecture, design, and/or implementation flaws. Try to find them
intentionally, not accidentally.

22. Design + Architecture
Expect failure. Hosting infrastructure and the cloud are comprised of a lot of
moving parts, each of which are prone to fail in their own way. Understand the
potential failure points and architect your mission critical resources to survive.

23. IPv6
Connectivity
< 40ms 10Gb

24. 13 data centers
Reach 16 network POPs
20Gb fiber interconnects

25. Distributed
Singapore Dallas Amsterdam

26. Local Storage

27. Network Storage

29. Inventory
(You can’t deploy what doesn’t exist)

30. Hybrid architectures
Common network
API

31. Scale Up

32. Scale Out

33. Scale Down

34. Unified image-based provisioning system
Move between virtual, physical
Clone/reload/snapshot physical servers

35. Time
Provisioning speed
API feature set
Contract length

36. Control

37. Better living through programming
Increase agility
Reduce human error
Enable application autoscaling
Evaluate on scope, documentation, support & community
Control

38. Global deployments ! No capital expenditure ! Significant scale
Consumptive billing ! Complete control

39. Why CloudPlatform?!
Mature
Easy-to-use GUI
Citrix-backed
RightScale compatible
Flexible network architecture
Internet scale
Open source platform

40. Zones!
One Management node supports one or more zones
Private VLAN! VLAN ! Private VLAN!
Spanning
Management Server!
ZONE 1! MULTIPLE OTHER ZONES!
DATA CENTER 1! MULTIPLE DATA CENTERS!

41. Clusters & Hosts!
One or more clusters per zone, one or more hosts per cluster
Cluster defined by storage
Local storage == single-server cluster
Cluster Cluster
Guest VMs! Guest VMs! Guest VMs!
Physical Host! Physical Host! Physical Host!
Management Server!
ZONE 1!
DATA CENTER 1!

42. Hardware Options!
Management Node
Single Proc Quad Core Westmere, 6 GB DDR3
2x2TB SATA
Host Node Options
Smallest: Dual Proc Quad Core Nehalem, 6-192GB DDR3
Biggest: Quad Processor 10 Core Westmere EX, 32-512GB DDR3
Storage: SATA, SA SCSI SSD
Network: 100Mb-10Gb line speed
Guest VMs! Guest VMs!
Management Server! Host Node! Host Node!

43. COMMAND & CONTROL!
Dallas! San Jose! Singapore!
PUBLIC CLOUD WEB SERVERS!
Guest VMs! Guest VMs!
Physical Hosts! Physical Hosts!
Management Server! Object Storage! Object Storage!
PRIVATE CLOUD! PRIVATE CLOUD! DEDICATED!
ZONE 1: DALLAS! ZONE 2: SINGAPORE! HADOOP CLUSTER: DALLAS!