Cloud: Good for large number of small problems or small number of large problems?

First, to all my fans out there (hello, anyone really there, or you all have given up?):  Ok, Ok, I get it -- I cannot call myself a blogger and be absent for two months.  Sorry!  But Mr. Regularity is back on the scene (I know, this regularity term has been hijacked by some over the counter medicine folks, but so be it).

So what's been keeping me busy?  Clouds and Mashups, my twin passions.  I will try to alternate the two in my postings this year.  Let me first begin with cloud. 

I want to run a hypothesis by you all.  I see two sets of workloads in the cloud.  A large number of small problems (example, salesforce.com, where all queries/transactions come with a tenant-id attached) or a small number of large problems (example, google with its bigtable usage).  Sometimes we tend to get over excited about the latter -- infinite scalability, 1000's of nodes, a computer science student's dream.  But as salesforce.com has shown, one can make a handy billion dollars by efficiently solving a large number of small problems too.  The nice thing about managing a large number of small problems is that one does not, up and down in the stack, need to manage everything as one large server, one large storage or one large database.  Right "scaleout" models can be built at different layers of the stack, giving one a lot of flexibility.  That is why salesforce.com can run on Oracle, whereas google is custom top to bottom.

If we think this way, then we immediately understand infrastructural needs, which is (the size of the problem)*(number of {concurrent} problems).  It is clear that for google, this translates to multiple hundreds of thousands.  One reason why the size of the problem for google is large is because of the #of bits (~PB) and another is because the amount of computation needed for analytics is elastic and the larger, the better, and therefore can be easily ~1000/problem. 

For salesforce, my suspicion is that the total infrastructural need is considerably less.  Now you might say, salesforce is about transactional apps, and transactional apps are not very "infrastructure" intensive.  Whatever the merits of that argument, I find this way of looking at cloud workloads to be quite worthwhile.

Comments

[Don Campbell]

So, just for fun, let's complete the cross product...

Small number of small problems: Clearly this falls into the 'who cares' category. On a good day, I can solve a small number of small problems by myself...before lunch...without a cloud.

Large number of large problems: What would the cloud look like if it could do this? Perhaps this is the cloud of the future. A single cloud with globally connected hardware AND information. The sum of human intelligence and possible analytics providing at-your-finger-tips access to the most complex problems of humanity. Cancer, global warming, energy, SETI, etc. Nothing could stump it. And it would only get smarter. If the cloud initiatives of today can lead to that kind of tomorrow...sign me up!

Don

[Niraj]

Don -
"Small number of small problems" really comes into the tools space. No one is going to small your problem specifically but generic tools like eclipse will help you solve them. So it is an important market for tool vendors OR I think Google App Engine is targeted towards that.

Large number of Large problems - By definition ,there should be tons of people already working on these.Today this bucket is clearly Enterprise IT where people like IBM , oracle , SAP make money.

[Tariq Rauf]

I think this is an interesting way of looking at cloud space.

I wonder, though, whether it would be more useful / appropriate to look at the cloud as a resource you can use either of these two ways and evaluate the appropriate use of the this resource on a problem by problem basis.

So, for a particular problem that is more conducive to a small number of large problems model you would set up that structure for your system and the other way around for other problems.

So, I would say, both ways of looking at a problem are valid and one needs to decide which one, or combination thereof, makes sense for a given problem.

It might be useful to think of providing support at the IDE-level for modeling an application along these lines and observing how that translates to an API at a code level - internal to the application - and what kinds of composability it buys you. At an external level, e.g. at the REST level, the API would be much more coarse grained and might even look the same in both cases.

... just some initial thoughts.

- Tariq

[Chandra Tekwani]

I like the explanation of solving many small problems vs few large problems.

One such forum put together to realize the potential of mobilizing the cloud to solve problems of millions of sales professionals on the street and thousands of physicians. Now that is 2 different market segments but can same solution to the problem.

See more details at,
http://mobilize-the-cloud.iitroorkee.us

[dissertation writing help]

Excellent Blog every one can get lots of information for any topics from this blog nice work keep it up.

thanks