Tuesday, December 08, 2009
#sn09 Zittrain's tale of 3 clouds
At the recent Supernova conference (link), thought leaders discussed the network age, and what happens when “control moves to the edge”. But does it move to the edge? At Supernova, Harvard Law School professor Jonathan Zittrain dissected the ‘computing cloud”. His ‘tale of three clouds’ presents a critical view of these ephemeral structures.
The most prevailing cloud notion is the computing cloud, as exemplified by Google’s and Amazon’s offerings. This is the cloud that solves reliability and scalability problems. Putting your application in the cloud instead of on your own servers is like moving from your own answering machine to voicemail. This is generally a good solution, as long as we can figure out a good exit strategy.
The second cloud we’ll have to deal with creeps up from behind, so to speak. It is the cloud of services that is, not so openly, attached to devices like the iPhone and the Kindle. You think you own these devices, which in a legal sense you do. Yet, you do not control what software is on it. If you write an application for your iPhone, you cannot share it directly with your friend. It has to go through Apple’s AppStore, which has a track record of arbitrarily refusing applications. Similarly, you think you may own the e-books on your Kindle, but there is a documented case where Amazon pulled such a book away from all existing Kindle’s. So from an asset management perspective, Apple and Amazon ‘own’ your devices.
Finally, the third cloud Zittrain identifies is not a computer cloud at all, even though it is facilitated by computers. It is the world of services like Amazon’s Mechanical Turk, where human information processing jobs such as pattern recognition are parceled out into very small chunks. There are great and positive examples of it, but it also lends itself to various sorts of misuse. The simplest of these is that this human computing cloud can be a kind of sweat shop, where very repetitive low-pay jobs are being done. There is also evidence that this cloud is used for deceptive purposes, such as writing lots of fictitious reviews on forums and circumventing anti-spam measures.
Is there something we should do about it? I doubt if we can. Technological development oftentimes is like opening Pandora’s box. We’ll have to learn to live with it, and keep hoping.
The most prevailing cloud notion is the computing cloud, as exemplified by Google’s and Amazon’s offerings. This is the cloud that solves reliability and scalability problems. Putting your application in the cloud instead of on your own servers is like moving from your own answering machine to voicemail. This is generally a good solution, as long as we can figure out a good exit strategy.
The second cloud we’ll have to deal with creeps up from behind, so to speak. It is the cloud of services that is, not so openly, attached to devices like the iPhone and the Kindle. You think you own these devices, which in a legal sense you do. Yet, you do not control what software is on it. If you write an application for your iPhone, you cannot share it directly with your friend. It has to go through Apple’s AppStore, which has a track record of arbitrarily refusing applications. Similarly, you think you may own the e-books on your Kindle, but there is a documented case where Amazon pulled such a book away from all existing Kindle’s. So from an asset management perspective, Apple and Amazon ‘own’ your devices.
Finally, the third cloud Zittrain identifies is not a computer cloud at all, even though it is facilitated by computers. It is the world of services like Amazon’s Mechanical Turk, where human information processing jobs such as pattern recognition are parceled out into very small chunks. There are great and positive examples of it, but it also lends itself to various sorts of misuse. The simplest of these is that this human computing cloud can be a kind of sweat shop, where very repetitive low-pay jobs are being done. There is also evidence that this cloud is used for deceptive purposes, such as writing lots of fictitious reviews on forums and circumventing anti-spam measures.
Is there something we should do about it? I doubt if we can. Technological development oftentimes is like opening Pandora’s box. We’ll have to learn to live with it, and keep hoping.
Labels: clouds
Wednesday, December 24, 2008
Which computing cloud is closer?
The ‘cloud’ stands for a worldwide infrastructure of computers that can deliver applications and content to any place on the Internet. Early examples of clouds are content distribution networks (CDN), which can serve web content from a worldwide distributed network of servers. Because the servers are closer to the user the user will see quicker response. Because there are multiple servers, larger numbers of users can be served.
I have done some measurements on the proximity of a number of content distribution networks to monitoring stations around the world. Earlier I reported on the distance that the Google Application Engine (GAE) has to the cloud. Here we do the same for more content distribution networks. Note that GAE actually allows to run applications on the cloud, and we are using here only its capacity to serve content.
The monitoring stations by Watchmouse are situated in 35 locations on all continents of the world. The minimum connect time to a provider as measured from a particular location is a good indicator of the distance to that provider.
There are other qualities a good CDN should have. It should start serving content quickly, and it should serve it with adequate speed (bandwidth). I’ll report on those measurements later.
Our Cloud Proximity Indicator is an aggregate measure, and is computing by averaging the distances to all monitoring stations.
Remarks and observations
• The round trip delay between Spain and New-Zealand (opposite on the globe) is around 290 milliseconds
• Akamai is really everywhere
• Google Applications Eengine, although fundamentally more powerful and still in beta, is pretty impressive. It is in the same league as most other CDNs.
I have done some measurements on the proximity of a number of content distribution networks to monitoring stations around the world. Earlier I reported on the distance that the Google Application Engine (GAE) has to the cloud. Here we do the same for more content distribution networks. Note that GAE actually allows to run applications on the cloud, and we are using here only its capacity to serve content.
The monitoring stations by Watchmouse are situated in 35 locations on all continents of the world. The minimum connect time to a provider as measured from a particular location is a good indicator of the distance to that provider.
There are other qualities a good CDN should have. It should start serving content quickly, and it should serve it with adequate speed (bandwidth). I’ll report on those measurements later.
Our Cloud Proximity Indicator is an aggregate measure, and is computing by averaging the distances to all monitoring stations.
Remarks and observations
• The round trip delay between Spain and New-Zealand (opposite on the globe) is around 290 milliseconds
• Akamai is really everywhere
• Google Applications Eengine, although fundamentally more powerful and still in beta, is pretty impressive. It is in the same league as most other CDNs.
Labels: clouds
Saturday, November 22, 2008
Watching the cloud
Google App Engine is an infrastructure to deliver applications through Google’s cloud. You can drop applications written in Python in it, and let Google do the hosting. I am setting up a business based on this (GriddleJuiz).
So the first obvious questions are: where is the cloud, and does it perform? With the help of my friends from Watchmouse I ran a test on one of my Google App Engine sites and compared it with a regularly hosted website. In the chart you can see some of the results: the time it takes to connect to the site from various places in the world.
The interesting observations are:
So the first obvious questions are: where is the cloud, and does it perform? With the help of my friends from Watchmouse I ran a test on one of my Google App Engine sites and compared it with a regularly hosted website. In the chart you can see some of the results: the time it takes to connect to the site from various places in the world.
The interesting observations are:
- Time to connect to the regular site increase with distance. We are measuring the speed of light here, sort of.
- The Google cloud is in more than one place. For example, it is close to the Netherlands, but it also has a presence in East Asia, near Hong Kong.
- The cloud is probably also close to North America, but it puzzles me why it is not nearer.
- The regular site is closer to monitoring station NL2, where the cloud is closer to NL4.
- Google does not guess correctly the location of some WM monitoring stations. E.g. DK (Danmark) is way off, and might as well be in North America. This is a common misconception among Americans :-)
These results are pretty reproducible by the way. We have done measurements over several 24 hour cycles. The next interesting thing of course is raw performance: how many hits/second can it pull? Stay tuned for more results.
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. Yet, there appears to be a lot of work left, the cloud does not always guess correctly where the user is.
Labels: clouds
