Brad's Books and Organizations

Books

Books

Organizations

Organizations

Hi, I’m Brad Feld, a managing director at the Foundry Group who lives in Boulder, Colorado. I invest in software and Internet companies around the US, run marathons and read a lot.

« swipe left for tags/categories

swipe right to go back »

Clouditude

Comments (4)

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.

  • http://www.tareandshare.com Sheraz Mahmood

    Interesting post, I like where this going.

    Having developed some applications in the cloud, I don't know if the statement “know anything about the underlying infrastructure, including whether there is an application server at all” holds true. There are limitations to all clouds and developer have to be mindful of costs associated to what they are building.

    Building efficient programs is true, regardless of where the application lives. Since the cloud is supposed to lower costs, especially for startups, the way an application is built changes when you take into consideration how many CPU cycles you will be using for any line of code. This is good since most programmers these days throw efficiency out the window until it bites them. Therefore knowing about the infrastructure is very important; all clouds are not homogeneous.

    • http://johngannonblog.com John Gannon

      You make a good point. There are numerous vendors who address cloud management at the VM instance level (e.g. deploying new VMs based on administrator or user load) but is anyone looking at a layer to sit between the app and the infrastructure to do very fine-grained auto-scaling, failover, etc? Seems the EngineYards, Joyents, and 10gen's of the world might be well suited to solve that problem given they are engaging at the app server versus the VM/AMI management level? Thoughts?

      • http://www.feld.com Brad Feld

        I don’t really know. I’m having a little trouble determining the appropriate line between the app and the infrastructure for these types of functions. I know Microsoft is creating a much more extensive framework for this intermediate layer with some of the pieces of Azure – it’ll be interesting to see what is actually implemented.

  • http://elasticserver.blogspot.com Patrick Kerpan

    And I think at Elastic Server we *might* have a capability that increases “clouditude” even further. You can import the application you want to run in your canonical “application server” listed above either into the Community Repo or into a personal repo if using our Personal Edition. Now you have your whole application described in a “bill of materials” which you can target to VMware, Xen, Parallels, EC2 AMI, with more clouds and VM formats coming online all the time. A matter of a few clicks to master your virtual server to any available format.

  • Sheraz Mahmood

    Interesting post, I like where this going.

    Having developed some applications in the cloud, I don't know if the statement "know anything about the underlying infrastructure, including whether there is an application server at all" holds true. There are limitations to all clouds and developer have to be mindful of costs associated to what they are building.

    Building efficient programs is true, regardless of where the application lives. Since the cloud is supposed to lower costs, especially for startups, the way an application is built changes when you take into consideration how many CPU cycles you will be using for any line of code. This is good since most programmers these days throw efficiency out the window until it bites them. Therefore knowing about the infrastructure is very important; all clouds are not homogeneous.

  • Patrick Kerpan

    And I think at Elastic Server we *might* have a capability that increases "clouditude" even further. You can import the application you want to run in your canonical "application server" listed above either into the Community Repo or into a personal repo if using our Personal Edition. Now you have your whole application described in a "bill of materials" which you can target to VMware, Xen, Parallels, EC2 AMI, with more clouds and VM formats coming online all the time. A matter of a few clicks to master your virtual server to any available format.

  • http://intensedebate.com/people/bfeld bfeld

    I don’t really know. I’m having a little trouble determining the appropriate line between the app and the infrastructure for these types of functions. I know Microsoft is creating a much more extensive framework for this intermediate layer with some of the pieces of Azure – it’ll be interesting to see what is actually implemented.

  • John Gannon

    You make a good point. There are numerous vendors who address cloud management at the VM instance level (e.g. deploying new VMs based on administrator or user load) but is anyone looking at a layer to sit between the app and the infrastructure to do very fine-grained auto-scaling, failover, etc? Seems the EngineYards, Joyents, and 10gen's of the world might be well suited to solve that problem given they are engaging at the app server versus the VM/AMI management level? Thoughts?

Build something great with me