Cloud computing isn’t going to be vapor much longer, Gartner said Tuesday.

By Nick Hortovanyi

Gartner's top 10 Strategy Technology Areas for 2010

Via Annie Shum's blog entry at MIT CIO Symposium blog.

This is very interesting and reinforces the strong interest I've been observing with cloud computing.  In addition, when you have access to computing resources that you can rent for the period that you require it, it opens up the potential for crunching large data volumes and numbers. Before cloud computing, you had to purchase all your own infrastructure and amortize it, over say a period of three years. This is now no longer the case.

It will be interesting to see what applications evolve!

McKinsey Cloud Report - further analysis

By Nick Hortovanyi

A little while back McKinsey published a report on clearing the air on cloud computing. It created quite a lot of buzz on the internet. 

Nicholas Carr on his blog  entry here "the big company and the cloud", suggested that he looked forward to further analysis. Yet I have not seen much.

What I have observed is the relative size of the IT departments here in Australia are significantly smaller then the 1704 FTE count sized organisation mentioned in the report. I'm looking to see how IT department's FTE groupings relate to the one in the McKinsey report.

Thus I'm seeking your help and have put together a google form (it does not ask for your company name or email address). Please fill in the details on the below form, the summary will be available so you can see how your IT department's FTE grouping compares to others.

If your browser doesn't support iframes please click here for the form. Thanking you in advance.

Some further analysis supplied via my twitter friends by:

• Vinnie Mirchandani
• Anshu Sharma (Salesforce, ex Oracle)
  

The End of an Architectural Era - It's Time for a Complete Rewrite

By Nick Hortovanyi

For years, it had been drummed into me, to use a relational database system (RDBMS). It was something that was just accepted, there wasn't any point arguing against it, as it appeared to just work. Data, the lifeblood of any system, could even be recovered in the event of some unfortunate hardware failure, if it was installed properly.

I worked on a few projects, at the end of the .com era, where we ran into difficulties with using relational databases. The issues primarily related to the volumes of data and types of transactions(large number of small inserts and updates) being used. On one project, when the vendor was approached with the issue, they acknowledged it, and said that it was an inherent issue with their product and that they had no plans to address it (so much for paid support, huh?).

Yes, my time honoured faith in the RDBMS had been eroded. But what were the alternatives? It was commercial suicide to not put a proposal forward that didn't use a RDBMS as the main data store.

A little while ago, I came across an interesting paper "The End of an Architecural Era (It's Time for a Complete Rewrite)" (PDF here). Now this paper, had the thought processes going. In it, they present reasons and strong evidence that the "one size fits all" commercial RDBMS paradigm is coming to an end. A key point that stood out for me is that they are 25 year old legacy code lines, written originally for 1970s architected hardware. The hardware has been retired, so should that code line in my humble opinion as well. Its well worth the time to read the paper.

"What are the alternatives?", I hear you still asking. Well I came across an excellent blog post by Richard Jones, "Anti-RDBMS: A list of distributed key-value stores".

I've been experimenting on a prototype, very successfully with Project Voldemort instead of a RDBMS. So next time, you are looking for a persistance store, don't assume you are best served with a RDBMS. It may no longer be the case!