A friend of mine has been going deep on the entire cloud computing ecosystem as he works through some ideas for a new company. He coined a term "clouditude" a few days ago and send me his thoughts about it. I found his term / definition fascinating and very relevant (look for me to start using the word "clouditude". I asked if I could republish his thoughts directly to see if anyone had any comments to add; here they are.
I have been exploring so-called "cloud" computing recently and had a few thoughts that might be interesting to you and possibly to share with readers, who undoubtedly would have some ideas to add.
The "cloud" could be viewed as the Internet cloud or the Web cloud – I am particularly focused on the Web. In particular, I would say that a system operates in the web cloud if it can be used via a standard web browser (possibly including common plug-ins such as Flash/Flex) from anywhere with Internet connectivity. Restricted systems, such as internal corporate "clouds," are not excluded from this definition as long as they are accessible (with appropriate permissions/credentials) from anywhere.
I’ve coined the term "clouditude" as a measure of both the extent to which a system leverages the cloud and the ease with which it can be used and managed in the cloud. I prefer this term rather than "cloudiness," partly because the latter has other connotations, but also because there is an "attitude" component: is the system at home in the cloud, or has it been shoehorned to work there?
To clarify this idea, consider a J2EE application server:
– It can be used to support applications in the cloud, but to do so it requires appropriate computer systems and underlying software and configuration to operate properly; a browser-based configuration interface increases its clouditude.
– An AMI or similar virtual machine instance (created manually or using tools like JumpBox, rPath, CohesiveFT, or AppLogic) makes it easier to set up in the cloud, subsequently needing only custom configuration, so this has higher clouditude than the application server software alone.
Building the machine instances with a browser interfaces has higher clouditude than using the command line.
– Tools like Scalr, WeoGeo, and Elastra make it easier to manage the resources, including scalability, redundancy, and failover issues. This has a lot of clouditude, because here the application begins to have independence from the infrastructure architecture.
– Seamless redundancy and rate-management across different cloud infrastructure vendors is an obvious area to improve clouditude, and is in the process of getting built out. It appears that RightScale and Kaavo are aiming for this, although it does not seem to be available yet.
Now our "application server" is pretty much completely virtual. We load it onto the service, and it is available for an application to use. If volume increases, or servers go down, or prices change, we don’t really care or know – it all happens automagically.
From an application developer’s perspective, there is a next step, where I don’t need to know anything about the underlying infrastructure, including whether there is an application server at all. I just build the application and click a button to deploy it. Google’s AppEngine and Force.com both are attempts to implement a high degree of clouditude for application developers. Force.com actually has higher clouditude, because the application is developed, tested, and run in the cloud, while AppEngine has a local sandbox environment for development, then you upload/deploy to Google.
Of course, with both of these solutions, one trades off flexibility and control for clouditude. Force.com applications only operate there, and AppEngine applications, though written in Python, have to use the proprietary BigTable as a datastore. It doesn’t seem like this sort of lock-in is essential to the practical implementation of a high clouditude environment, but I don’t really know.
It will be extremely interesting to apply this idea of clouditude to whatever Microsoft announces next week at the PDC.