Cloud Computing: How important is "data locality" from a costing perspective?

Nicholas Carr wrote an excellent article about cloud computing "The new economics of computing".

"In late 2007, the New York Times faced a challenge. It wanted to make available over the web its entire archive of articles, 11 million in all, dating back to 1851. It had already scanned all the articles, producing a huge, four-terabyte pile of images in TIFF format. But because TIFFs are poorly suited to online distribution, and because a single article often comprised many TIFFs, the Times needed to translate that four-terabyte pile of TIFFs into more web-friendly PDF files.

Working alone, he uploaded the four terabytes of TIFF data into Amazon's Simple Storage Service (S3) utility, and he hacked together some code for EC2 that would, as he later described in a blog post, "pull all the parts that make up an article out of S3, generate a PDF from them and store the PDF back in S3." He then rented 100 virtual computers through EC2 and ran the data through them. In less than 24 hours, he had his 11 million PDFs, all stored neatly in S3 and ready to be served up to visitors to the Times site.

The total cost for the computing job? Gottfrid told me that the entire EC2 bill came to $240. (That's 10 cents per computer-hour times 100 computers times 24 hours; there were no bandwidth charges since all the data transfers took place within Amazon's system - from S3 to EC2 and back.)"

One thing missed in the "NYT TIFF to PDF conversion computational task" is the mention of data transfer cost of uploading 4TB TIFF images into S3.

Doing some simple computations – Amazon would charge about $409.60 for uploading 4TB data into S3, and would charge an additional $261.12 for downloading the processed PDF files, which were 1.5TB in size. That is about $670.72. In addition there will be bandwidth charges of this 5.5TB data transfer from the NYT datacenter, 4TB out and 1.5TB in, I am sure that will be of the order of $400-$600. That could take the data transfer costs to $1000-$1200 range.

In addition to that – consider the amount of time it would take to transfer such a data. At 10Mbps, it would take 53.4 days to transfer this data.

Using Hadoop on EC2 is definitely a great idea, and is very helpful, however the locality of data also matters a lot. Moving data, in my opinion costs a lot, and sometimes undermines the computational costs ($240 here).

Let me know your thoughts.

Cloud Availability

Cloud Computing has become very widespread with startups as well as divisions of banks, pharmaceuticals companies and other large corporations using them for computing and storage.
Amazon Web Services has led the pack with it's innovation and execution, with services such S3 storage service, EC2 compute cloud, and SimpleDB online database.

Many options exist today for cloud services, for hosting, storage and application hosting. Some examples are below:

Hosting	Storage	Applications
Amazon EC2	Amazon S3	opSource
MOSSO	Nirvanix	Google Apps
GoGrid	Microsoft Mesh	Salesforce.com
AppNexus	EMC Mozy
Google AppEngine	MOSSO CloudFS
flexiscale

[A good compilation of cloud computing is here, with a nice list of providers here. Also worth checking out is this post.]

The high availability of these cloud services becomes more important with some of these companies relying on these services for their critical infrastructure. Recent outages of Amazon S3 (here and here) have raised some important questions such as this - S3 Outage Highlights Fragility of Web Services and this.

[A simple search on search.twitter.com can tell you things that you won't find on web pages. Check it out with this search, this and this.]

There has been some discussion on the high availability of cloud services and some possible solutions. For example the following posts - "Strategy: Front S3 with a Caching Proxy" and "Responding to Amazon's S3 outage".

Here I am writing of some thoughts on how these cloud services can be made highly available, by following the traditional path of redundancy.

The traditional way of using AWS S3 is to use it with AWS EC2 (config #0). Configurations such as on the left can be made to make your computing and storage not dependent on the same service provider. Config #1, config #2 and config #3 mix and match some of the more flexible computing services with storage services. In theory the compute and the storage can be separately replaced by a colo service.

The configurations on the right are examples of providing high availability by making a "hot-standby". Config #4 makes the storage service hot-standby and config #5 separates the web-service layer from the application layer, and makes the whole application+storage layer as hot-standby. A hot-standby requires three things to be configured - rsync, monitoring and switchover. rsync needs to be configured between hot-standby servers, to make sure that most of the application and data components are up to date on the online-server. So for example in config #4 one has to rsync 'Amazon S3' to 'Nirvanix' - that's pretty easy to setup. In fact, if we add more automation, we can "turn-off" a standby server after making sure that the data-source is synced up. Though that assumes that the server provisioning time is an acceptable downtime, i.e. the RTO (Recovery time objective) is within acceptable limits.

This also requires that you are monitoring each of the web services. One might have to do service-heartbeating - this has to be designed for the application, this has to be designed differently for monitoring Tomcat, MySQL, Apache or their sub-components. In theory it would be nice if a cloud computing service would export APIs, for example an API for http://status.aws.amazon.com/ , http://status.mosso.com/ or http://heartbeat.skype.com/. However, most of the times the status page is updated much later after the service goes down. So, that wouldn't help much.

Switchover from the online-server/service to the hot-standby would probably have to be done by hand. This requires a handshake with the upper layer so that requests stop and start going to the new service when you trigger the switchover. This might become interesting with stateful-services and also where you cannot drop any packets, so quiscing may have to be done for the requests before the switchover takes place.

Above are two configurations of multi-tiered web-services, where each service is built on a different cloud service. This is a theoretical configuration, since I don't know of many good cloud services, there are only a few. But this may represent a possible future, where the space becomes fragmented, with many service providers.

Config #7 is config #6 with hot-standby for each of the service layers. Again this is a theoretical configuration.

Cost Impact
Any of the hot-standby configurations would have cost impact - adding any extra layer of high-availability immediately adds to the cost, at least doubling the cost of the infrastructure. This cost increase can be reduced by making only those parts of your infrastructure highly-available that affect your business the most. It depends on how much business impact does a downtime cause, and therefore how much money can be spent on the infrastructure.

One of the ways to make the configurations more cost effective is to make them active-active configuration also called a load balanced configuration - these configurations would make use of all the allocated resources and would send traffic to both the servers. This configuration is much more difficult to design - for example if you put the hot-standby-storage in active-active configuration then every "write" (DB insert) must go to both the storage-servers, writes (DB insert) must not complete on any replicas (also called mirrored write consistency).

Cloud Computing becoming mainstream
As cloud computing becomes more mainstream - larger web companies may start using these services, they may put a part of their infrastructure on a compute cloud. For example, I can imagine a cloud dedicated for "data mining" being used by several companies, these may have servers with large HDDs and memory and may specialize in cluster software such as Hadoop.

Lastly I would like to cover my favorite topic -why would I still use services that cost more for my core services instead of using cloud computing?

1. The most important reason would be 24x7 support. Hosting providers such as servepath and rackspace provide support. When I give a call to the support at 2PM India time, they have a support guy picking up my calls – that’s a great thing. Believe me 24x7 support is a very difficult thing to do.
2. These hosting providers give me more configurability for RAM/disk/CPU
3. I can have more control over the network and storage topology of my infrastructure
4. Point #2 above can give me consistent throughput and latency for I/O access, and network access
5. These services give me better SLAs
6. Security

MOSSO is good - but where is my SSH and how much memory do you support?

TechCrunch reported - "Hosting provider Rackspace is offering a new cloud computing service through its subsidiary Mosso. The service competes with Amazon’s Elastic Compute Cloud (EC2), although it doesn’t require any load balancing or other administration. It also competes with Joyent and Media Temple’s Grid Service. Pricing starts at $100 a month for - 50 GB of storage, 500 GB of bandwidth for transferring data and 3 million HTTP requests. From there additional capacity per month costs: $0.50/GB of storage, $0.25/GB of bandwidth and $0.10/1,000 HTTP requests."

All this is good, but where is my ssh? Dude, how will I install my custom built software? How will I manage my Apache expire headers, how will I implement my mod_rewrite rules?

Also, it's not clear how much memory does the $100 get me?