A few months ago, Tim O'Reilly wrote an excellent post entitled Web 2.0 and Cloud Computing where provides some definitions of two key cloud computing paradigms, Utility Computing and Platform as a Service. His descriptions of these models can be paraphrased as

  1. Utility Computing: In this approach, a vendor provides access to virtual server instances where each instance runs a traditional server operating system such as Linux or Windows Server. Computation and storage resources are metered and the customer can "scale infinitely" by simply creating new server instances. The most popular example of this approach is Amazon EC2.
  2. Platform as a Service: In this approach, a vendor abstracts away the notion of accessing traditional LAMP or WISC stacks from their customers and instead provides an environment for running programs written using a particular platform. In addition, data storage is provided via a custom storage layer and API instead of traditional relational database access. The most popular example of this approach is Google App Engine.

The more I interact with platform as a service offerings, the more I realize that although they are more easily approachable for getting started there is a cost because you often can't reuse your existing skills and technologies when utilizing such services. A great example of this is Don Park's post about developing on Google's App Engine entitled So GAE where he writes

What I found frustrating while coding for GAE are the usual constraints of sandboxing but, for languages with rich third-party library support like Python, it gets really bad because many of those libraries have to be rewritten or replaced to varying degrees. For example, I couldn’t use existing crop of Twitter client libraries so I had to code the necessary calls myself. Each such incident is no big deal but the difference between hastily handcrafted code and libraries polished over time piles up.

I expect that the inability of developers to simply use the existing libraries and tools that they are familiar with on services like Google App Engine is going to be an adoption blocker. However I expect that the lack of of a "SQL database in the cloud" will actually be an even bigger red flag than the fact that some APIs or libraries from your favorite programming language are missing.

A friend of mine who runs his own software company recently mentioned that one of the biggest problems he has delivering server-based software to his customers is that eventually the database requires tuning (e.g. creating indexes) and there is no expertise on-site at the customer to perform these tasks.  He wanted to explore whether a cloud based offering like the Azure Services Platform could help. My response was that it would if he was willing to rewrite his application to use a table based storage system instead of a relational database. In addition, aside from using a new set of APIs for interacting with the service he'd also have to give up relational database features like foreign keys, joins, triggers and stored procedures. He thought I was crazy to even suggest that as an option.  

This reminds me of an earlier post from Dave Winer entitled Microsoft's cloud strategy? 

No one seems to hit the sweet spot, the no-brainer cloud platform that could take our software as-is, and just run it -- and run by a company that stands a chance of surviving the coming recession (which everyone really thinks may be a depression).

Of all the offerings Amazon comes the closest.

As it stands today  platform as a service offerings currently do not satisfy the needs of people who have existing apps that want to "port them to the cloud". Instead this looks like it will remain the domain of utility computing services which just give you a VM and the ability to run any software you damn well please on the your operating system of choice.

However for brand new product development the restrictions of platform as a service offerings seem attractive given the ability to "scale infinitely" without having to get your hands dirty. Developers on platform as a service offerings don't have to worry about database management and the ensuing complexitiies like sharding, replication and database tuning.

What are your thoughts on the strengths and weaknesses of both classes of offerings?

Note Now Playing: The Pussycat Dolls - I Hate This Part Note


Monday, January 26, 2009 4:52:00 PM (GMT Standard Time, UTC+00:00)
As you said - "you often can't reuse your existing skills and technologies when utilizing such services". So even if you are starting a new project, you are going to hit the same roadblocks with GAE or Azure. And i state this after our experience with Bungeelabs for over an year, where we ended up spending more time solving basic issues(that had been solved years back in other programming languages), instead of focusing on the real code.

In my opinion, if you are a startup, scalability should not be even on your mind, since there is no guarantee you are going to succeed. And if you are an established company, it would be too much of an overhead for your employees to learn a new programming paradigm, and code the basic libs, before you even start churning out the real code.

In future, the only reason we are going to consider GAE or Azure is they solve parts of our problems, not the complete problem, since it is beyond a single company to deliver the true OnDemand Scalable Platform(in the next 2 years, at least). As far as the ideas on parts of the OnDemand Platform from which real money and customers can be made or are needed - 1. MailServer Hosting. 2.Image Resizing. 3. Memcache server bundles. 4. Load balanced MYSQL. 5. Pluggable URL Fetch service(like GAE) 6. Video Encoding..........

In my opinion developers will use the above components if each of them are available standalone, not bundled together as in GAE, 'cause if you bundle them too tight, you might end up providing a stack that might seem perfect for certain set of customers, but not all. If the same components are standalone, like what Amazon does, developers try out one of them(like S3) and later on adopt more products as they seem fit or need arises(like cloundfront from Amazon)
Monday, January 26, 2009 7:50:25 PM (GMT Standard Time, UTC+00:00)
Sie suchen ein Tachojustiergerät?
Wir vertreiben professionelle Tachojustiergeräte.
OBD und Programmer.

Comments are closed.