Not even a full day after having delivered my presentation about the possibilities of Cloud Computing in the context of Microsoft Dynamics NAV at Decisions 2010 virtual conference by MSDynamicsWorld.com (which by the way you can still access on-demand if you missed it), my friend Steve has forwarded me a Forrester Research article published on ZDNet by James Staten: Could cloud computing get any more confusing?
A great read and a fantastic short analysis of what is and what isn’t the so-much-talked-about Cloud computing.
For me, it was just great to read this article, which thankfully appeared just after I completed my presentation and not any earlier, because I could easily verify my claims and my opinions I expressed at Decisions 2010.
One of the major points I missed about Cloud computing was that I stated that it helps companies turn CAPEX into OPEX, not something that I read somewhere, but something that I believe should be obvious to anyone having spent more than five minutes thinking about Cloud computing. James in his article says that there is an important difference not often mentioned by the “cloudwashers” (that’d be me) is that it’s not just OPEX, but flexible OPEX.
And that’s just right, and also something I missed mentioning in my presentation where I was blabbing about “resource sharing”, but never ever mentioned that the most important trait of resource sharing is actually resource cost sharing, or pay per usage.
What an average listener might have understood from my presentation is that Cloud computing is a rent-an-app over web concept, which it isn’t. It’s closer to renting processing power.
To sum up James’s point there in my own words: if you are paying for your Cloud application per user per month – then it’s not cloud computing, it’s mere hosted-in-the-web option.
Whoa, now Cloud computing DOES get confusing truly. Because all of a sudden, the series of the prime-time Cloud(washing) computing providers just go away. Salesforce? As per James’s argumentation – not cloud computing.
So, if you keep strictly speak about flexible OPEX and cost per resource usage, then the only truly Cloud computing solutions are Cloud computing platforms that charge per resource usage, such as Windows Azure Platform or Amazon Elastic Compute Cloud. Anything built on top of them, which doesn’t charge per clock cycle but per user per month, isn’t cloud computing. Interesting.
Now did I confuse you, or did I confuse you?
Anyway, Steve and I have exchanged a dozen e-mails ranting to one another about Cloud computing, what it’s good for and where it sucks, and I’m sure we’d have drank a gallon of rum and brandy, and at least some beer, if Cloud drinking was at least a bit as feasible as Cloud computing. I hope I turn some of those rants into a series of blog posts – which I definitely intend to do with the content of the presentation.
This Post Has 5 Comments
Pingback: Navigate Into Success
Thanks for the mention, Vjeko. I’m not sure that a gallon of rum or brandy would make the cloud concept any clearer, or its potential NAV application more direct.
@Steve: Actually, Steve, it might have made the concept clearer, because it would have made us smarter: http://hubpages.com/forum/topic/9591 (Why Drinking Beer Makes You Smarter)
Hi Vjekoslav, great thoughts! I also liked “flexible OPEX” as it distinguishes from traditional OPEX, even though many people may dispute that they’re still the same thing. Another aspect of cloud computing that I think most cloudwashers tend to neglect is the ability to design and build “native” cloud applications, as opposed to simply hosting on-premise software and applications in cloud environments. This can be a true differentiator for cloud computing as well, since it represents a significant technical paradigm shift in how applications are implemented, from traditional on-premise software architectures. In a nutshell, native cloud applications can be built to fully leverage the underlying seemingly infinite and elastic scaling infrastructure, by utilizing horizontal-scaling (or scale-out) design techniques, which can be comparatively more challenging to engineer in on-premise environments.
Pingback: Got C/AL?