Cloud Encounters: Measuring the computing cloud

Cloud Encounters Measuring the Computing Cloud Dr. Peter van Eijk Independent IT professional Session #616 CMG’09, see www.cmg.org

Clouds
Do they exist?
Do they scale?

Clouds are Real
We made actual measurements of a number of computing clouds, including their progression over time.
This is stuff you need to know when you select a cloud infrastructure.
Note:
Author is not employed by any of the companies mentioned.
No animals were harmed in the conduct of this research

What clouds? Cloud Model Fast deployment of virtual servers Main cost unit Virtual server Examples Amazon

What clouds? Cloud Model Hosted applications Main cost unit User Account / Month Examples Google Sites Google Apps Salesforce.com LinkedIn

What clouds? Cloud Model (Static) Content Distribution Network Main cost unit Delivery of single image, movie Examples Akamai Amazon Cloudfront Rackspace Cloudfiles

What clouds? Cloud Model Distributed, scalable processing Main cost unit API call, Chunk of code Examples Google App Engine Windows Azure (FaceBook API)

Measurement Methodology
More than 30 monitoring stations on all continents
Measurement is typically HTTP Get for a specific URL
WatchMouse.com

Cloud uptime is pretty good, and getting better Each bar represents > 7000 test requests using world-wide monitoring stations by WatchMouse

Where is the cloud?
Google data centers across the world (April ‘08)
http://www.techcrunch.com/2008/04/11/where-are-all-the-google-data-centers/ Proximity Matters 290 milliseconds roundtrip delay

Clouds can be really close
Cloud proximity =
average distance of cloud to 35 monitoring stations (in milliseconds roundtrip)
Akamai is pretty much everywhere Cloud operator Apr 09 Sep 09 Myspace Akamai 30 30 Google AppEngine 57 54 Amazon Cloudfront 51 53 Mosso CDN 54 58 Google Site 62 63 CNN CDN 81 56 EC2 Ireland 121 116 Regular NY site 127 127

Connect times from NY to Amazon Cloudfront
Better peering and/or better routing?
0 5 10 15 20 25 30 35 40 45 50 24-8- 2009 27-8- 2009 29-8- 2009 30-8- 2009 1-9- 2009 3-9- 2009 5-9- 2009 7-9- 2009 9-9- 2009 11-9- 2009 13-9- 2009 15-9- 2009 17-9- 2009 Milliseconds to connect

Connect time to a single hosted site increases with distance. Clouds can be everywhere 0 50 100 150 200 250 300 350 nl2 nl4 de fr dk uk fr2 us-ny us-fl us-sf sg hk nz Monitoring station Milliseconds to connect app engine09 flat site .nl Cloud has Asian presence Cloud has European presence New Zealand is really far away from Europe Connect time to the Google App Engine cloud does not.

Clouds evolve over time 0 50 100 150 200 250 Brazil Chicago Florida New York San Francisco Danmark France Germany Netherlands UK India Hong Kong Melbourne Sydney Monitoring station Milliseconds to connect dec-08 apr-09 sep-09 Google’s coverage has increased in ‘09 Missed real location of Denmark in ‘08 Suboptimal routing in Australia Europe has good Internet Hong Kong had a routing issue in Sept San Francisco. Puzzling? 0 20 40 60 80 100 120 140 160

Routing the Cloud
DNS lookups for helloworld.appspot.com are location and time dependent
helloworld.appspot.com. IN CNAME appspot.l.google.com. appspot.l.google.com. IN A 209.85.129.141 appspot.l.google.com. IN A 209.85.135.141 In addition, the DNS addresses are anycast (not multicast) Location IP address Antwerp, Belgium 209.85.129.141 Odessa, Ukraine Oslo, Norway Amsterdam2, Netherlands 209.85.135.141 Haifa, Israel Krakow, Poland Mumbai, India 209.85.153.141 Chicago, U.S.A. 209.85.225.141 Amsterdam, Netherlands 216.239.59.141 Copenhagen, Denmark Dublin, Ireland Groningen, Netherlands Johannesburg, South Africa München, Germany Stockholm, Sweden Zurich, Switzerland Melbourne, Australia: 66.102.11.141 Auckland, New Zealand 72.14.203.141 Hong Kong, China Nagano, Japan San Francisco, U.S.A. Shanghai, China Singapore, Singapore Sydney, Australia Amsterdam3, Netherlands 74.125.39.141 Paris, France Cologne, Germany 74.125.43.141 Lille, France London, United Kingdom Moscow, Russia Padua, Italy Austin, U.S.A. 74.125.45.141 Florida, U.S.A. 74.125.47.141 Santa Clara, U.S.A. 74.125.65.141

Clouds are scaleable infrastructure
Amazon EC2, 3 locations, limited migration
Akamai: replication of static data
Google has solved the hard part of scalable application infrastructure: duplication over a large distance. If you can do that, you can deploy any number of servers.
Google App Engine, although fundamentally more powerful and still in beta, is pretty impressive. It is in the same league as most other CDNs.

Need more servers?

Conclusion
Clouds are viable infrastructures for internet based services that
Are globally distributed
Need substantial scaling
There is a wide range of services
Type of content served
Geographical reach

Session #616 Thank you for your attention Any Questions? (see next slides) @petersgriddle www.petersgriddle.net

Question:
What about security?
What about legacy data?

Question:
What happens with response time if your cloud provider moves?
What guarantees do you have?

Question:
What kind of financial type applications are hosted in the cloud? SOx aware and compliant

Question:
Where is a list of companies that are using the cloud?

Question:
What about health care information exchange? E.g. CAT scan analysis.
How are we going to be effective in using the cloud for improving health care?
Patients and doctors can be all over the world

Question:
How do you guarantee privacy?

Comment:
You click the wrong button and your data is published to the whole world

Question:
What about reputation of suppliers?

(session chair announcement)

Cloud Encounters: Measuring the computing cloud

by Peter HJ van Eijk on Jan 22, 2010

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 27

Statistics

Cloud Encounters: Measuring the computing cloud Webinar Transcript

http://www.slideshare.net	24
http://www.linkedin.com	3