Brad's Books and 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 »

Cloud Computing Streak Marks

Comments (31)

In response to my post The Beginning of the Real Mess in the Clouds I received several emails / twitters / comments saying some variation of “these are easy problems to address” or “the cloud computing providers will quickly fix all this stuff and even my mother will be able to use cloud computing.”

Uh huh.  Here’s another one.  We’ve got hundreds of these already and it has only been 75 days since we started the company.

A heads up to anyone attempting to connect to Slicehost using Java:

There is a subtle bug in the JDK (including 1.6), such that long username/password combinations (like the long username used with the Slicehost API) are encoded improperly in an HttpURLConnection. If you include the username in the URL, you will get a 401 error; if you attempt to use an Authenticator you will get an exception from Java that there is an invalid line. The solution is to override the base64encoder and set the authorization property manually OR potentially use the Apache Http client rather than the built-in JDK client.

Here is the basic code for the solution:

static final String Credential = "my Slicehost API username here"; // the part before the @

class LongLineBase64Encoder extends BASE64Encoder { @Override public int bytesPerLine() { return 1024; } }

URL ServiceURL = new URL("");

HttpsURLConnection Conn = (HttpsURLConnection) ServiceURL.openConnection(); String EncodedUsername = (new LongLineBase64Encoder()).encode(Credential.getBytes());

Conn.setRequestProperty("Authorization", "Basic " + EncodedUsername); Conn.connect();

What part of mess wasn’t I clear about?  Oh, and my mother is really smart, but I’m betting that “The solution is to override the base64encoder and set the authorization property manually OR potentially use the Apache Http client rather than the built-in JDK client” doesn’t mean much to her.

The Beginning of the Real Mess in the Clouds

Comments (13)

We made a seed investment at the end of last year in a company called Standing Cloud.  They are working on a set of application development and deployment tools for cloud computing that build on some of the ideas in the posts What Happened To The 4GL? and Clouditude.  They’ve spent the first quarter of 2009 testing out a series of hypotheses we had concerning issues with Cloud Computing as well as building an first release of their cloud deployment tool.

Things in cloud computing land are much worse than our hypotheses, which were already suitably cloudy.  Following is a simple example of a real issue that even a non-techie will be able to understand.

When starting cloud server instances via an API, it’s important to realize that the instance may become "available" from the perspective of the cloud provider system before all of its standard services are running.  In particular, if your automated process will connect to the instance via ssh or http, it will be at least a few seconds after the instance appears before the applicable service is available. This problem generally does not arise if you start servers manually, because by the time you see that it is running, copy the IP address or domain name, and type the command or browser URL to connect, the services are usually ready.  Possible solutions include:

  • Wait a safe, predetermined amount of time.  This is the simplest, but obviously is not robust.
  • Attempt to open a socket on the applicable port (e.g., 22 or 80), and do so in a loop, with a brief sleep between attempts.  These attempts will fail until the service starts, and you should have the loop time out after some period in case there is a deeper problem with the instance.
  • In a similar loop, directly attempt to connect to the service.  Depending on the SSH API you are using, this may have additional overhead or abstraction that is better avoided, but it is robust and likely to work.

A related, but more insidious issue is that the sshd authentication services are not necessarily available as soon as sshd is available on the port.  Thus it is possible to connect to the service and have authentication fail, even though everything should be in order. A sufficient wait period or a loop is once again the solution.  However, if the loop wait period is not sufficient, you may attempt too many failed authentications and lock yourself out of the system.  Thus this approach has no fully robust solution aside from an empirically safe wait period either prior to authentication or in the loop wait.

Clearly these problems are tricky to diagnose if you are not aware of their idiosyncrasies.

A more robust but also more complex overall solution would be to incorporate a service on-board the instance that starts up at boot and checks the status of sshd from the inside, then makes an otherwise unused port available when the system is fully ready for connection and authentication. Of course, this requires that you can boot from a pre-configured image rather than a stock image, and it also requires that another port be open on the firewall.

The set of things like this is endless.  In addition, each cloud computing environment has different nuances and each stack configuration adds more complexity to the mix.  There are so many fun puns I that apply that I get giddy just thinking about all the storms ahead and the need for umbrellas.

Boulder / Denver Amazon Web Services Developers

Comments (8)

If you are located in the Boulder / Denver area and doing stuff with Amazon Web Services, there is a new group forming called AWS Anonymous.   Per the Colorado Startups blog, they are having their first meeting at The Cup in Boulder on January 20th at 10am.  Just show up if you are interested – it’ll be easy to find them since they’ll be the nerds saying things like EC2 and S3.


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 both are attempts to implement a high degree of clouditude for application developers. 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. 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.

Build something great with me