The Emerging Cloud Service Architecture

I'm going to go out on a limb today and try to paint a picture of where some of this cool and crazy cloud-based infrastructure may be going. While none of what I will write about is idle speculation, it is based on just a few data points, and may be totally off base. However, I do get to talk to plenty of entrepreneurs and developers on a daily basis, and I am starting to see a very interesting pattern emerge.

The existing state of the art in cloud-based architectures takes the shape of an application running in the cloud, calling upon services running within and provided by the operator of the cloud. There are any number of great examples of this type of architecture. Doug Kaye at IT Conversations built and documented his implementation over a year ago. Earlier today, Don MacAskill of SmugMug send me a link to his new post, SkyNet Lives (aka EC2 @ SmugMug). In that article, Don provides a detailed review of SmugMug's use of Amazon EC2 and S3 to implement a dynamic, highly scalable system which simultaneously minimizes response time and cost by optimizing the number of EC2 instances.

As I said, I am starting to see something which goes beyond this in a subtle yet important way. Developers are now building services in the cloud for other developers, with the understanding that important (and perhaps primary) consumers of the service will also be resident within the same cloud.

I'm going to call this the CSA, or Cloud Service Architecture.

Applications communicating with each other inside of the Amazon cloud enjoy some important benefits. They get high-bandwidth, low-latency communication, at little or no cost. They inherit all of the other attributes of cloud-based applications such as on-demand scalability, fault tolerance, cloud-wide network security, and cost efficiency. Applications running in loosely coupled fashion within the cloud can share data using SQS, S3, or other communication protocols of their choosing.

Right now, I see that forward-looking companies are starting to build components which fit into the CSA. On the database side, we have Vertica for the Cloud and MySQL Enterprise for EC2. On the media side, there's Cruxy's MuxCloud, IntrIdea's MediaPlug, and Wowza Media Server Pro for Amazon EC2. I'm sure that there are others that I don't know about.

So who's calling these services from other EC2 instances within the cloud? Here are my first two data points (that's enough to draw a trend line, right?):

1. I had breakfast with the CEO of Sonian yesterday. He told me that they are now using the Vertica product to help them store, index, and retrieve massive amounts of data (more info can be found in their case study).
2. Earlier this year I paid a visit to VisualCV in Reston, Virginia. They use MediaPlug to support uploading and processing of a variety of types of images and videos.

My sense is that this is the start of something big. Web services made it possible to cross organizational boundaries with a simple HTTP request. Now, running within the cloud makes it possible to do this with minimal network latency.

As individual developers learn more about cloud computing, they will naturally look for some very high-level components up and running within the cloud. Over time I am sure that there will be a need for more sophisticated tracking and billing mechanisms, key management, a catalog of services, and other facilities that we can't even envision just yet. As always, we love to get this feedback from you, so let us know what you need.

I'm sure that there are some other CSA-style applications running in the Amazon cloud now. If you've built one, post a comment!

-- Jeff;

Comments

[Peyman]

Can you provide some rough numbers for intra-cloud bandwidth and latency vesus inter-cloud? Maybe intra-cloud services would make a better name for this.

[Mr Jones]

This is future speculation, but I have a question: Do amazon always plan to charge when their cloud compute service access another cloud compute service (for instance Google App Engine).

It seems to me that via strategic location of servers (in common data centers) and other measures these costs could be reduced (if not eliminated).

Perhaps this an unfair (or over simplistic) re-phrasing of the question but does amazon see cross provider cloud compute working like IP protocol or like a walled garden (where every time an application migrates data/processing between a provider it incurs a cost for doing so?)

[Jared]

One thing I'd love to see is the option to provide a service in the cloud that I don't get charged for per se - rather, the user of the service pays for it. Ideally, the service provider can indicate something like 5 cents per invocation, and the service user gets charged 5 cents + the cost to the cloud owner to actually run the service. That way both the cloud owner and I would get paid.

The advantages to a service provider is pretty clear. For one, the service provider wouldn't be spending money running a service that doesn't get used (outside costs to develop and test it initially). Additionally, billing becomes the job of the cloud, which greatly simplifies things.

I'm not sure it works out so well for a cloud owner. One could argue that the cloud provider shouldn't make a distinction between "applications" and "services", as both are code running in the cloud, and it makes more financial sense to charge both. I believe it would ultimately be beneficial from the point of view that given the benefits of scaling (cloud owner with largest infrastructure ultimately can provide lowest cost) it makes sense for cloud owners to get the largest and best set of cloud services. And the best way to do that would be to make the cloud the best one for service providers to work with.