Cloud Computing Streak Marks

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.

  • First, the title of this post alone should bring them in by the thousands!

    Second, we are going to have two different sets of adoption/use problems in the cloud. On the "enterprise" side, I'm confident that these will be worked out. The API is not a new concept and while some of the technical problems will be new ones, I think collaboration between development groups will get us through the lion share. There will be problems though, all new things bring them, just like APIs continue to demand that throttling and access being managed thoughtfully.

    On the "consumer" side, problems take one a much bigger issue because users, for the most part, are not going to debug errors being thrown in the browser due to implementation problems. This will be no different than with using web sites. Most people do not going looking through URI encoding or name value pairs in the query string to figure out why there is an issue. I know my mom isn't going to, like most, she is going to say "this isn't working" and then call me.

  • In all the hundreds of issues you ran into, are these really the best two problems you could find to illustrate issues with Cloud Computing? Because honestly neither of them are anything specific to cloud computing at all – the first issue of waiting for services to start applies to any Linux server while this issue is a flat out bug in Java.

    I'm really puzzled by the tone of these posts, which seems to be "we thought cloud would be really easy but we keep running annoying issues that my mother wouldn't understand". Hopefully your mother isn't the lead programmer at this startup. That's why you hire smart technical people – if technology was simple and worked perfectly every time, you wouldn't need so many smart folks to get it working.

    No technology is perfect. Every operating system, application server, database, API and SDK I've ever worked with has had quirks, flaws, odd dependencies, and flat out bugs, and you end up spending 50% of your time mapping out those issues and working around them at the start of the project. Once you understand a platform and all its warts it gets easier the next time around. No one promised that "cloud computing" would be the first perfect technology ever created. It's just a different technology for a different purpose. One more tool for a programmer's bag of tricks, and a really cool one at that.

  • Oh – I’ve got plenty of other good examples and – as we piece this together, a really interesting “lack of abstraction layer across the cloud” starts to come together.  Presumably the goal of cloud computing (as espoused by many providers) is to simplify a big part of the problem so the smart people could focus on higher value added things.  See Gigaom’s article this morning: <a href="… />So far, my guess is that it is “adding a lot of jobs” as people try to get this actually working.

    • Interesting idea for an abstraction API, kinda of like what GNIP is doing for APIs. However, from the posts I've read so far it seems like Standing Cloud is looking at two angles.

      One, is this low level, say, QA/standardization issue across all of cloud computing.

      The other is, "people have forgotten what dBase got right" across not just the current web db people, but even across the web frameworks like RAILS and Google's offerings (based on your post in the fall).

      So, I am willing to pay real money for the second one — the one where you guys just solve all of my low level problems and let me make something for the users.

      I can see a scenario for the earlier one, complete with real time market pricing data for different services.

      I guess what you guys are saying is that you're going to make a 4GL for the web that is highly flexible in that it will allow you to manage and deploy across any available cloud services.

    • I think you're mis-reading Dave Right's point. That Java issue is obviously an issue with the JDK for the OS of that particular cloud instance – it's exactly the same behavior you would get if you were running that OS on a real machine.

      I think you're having an observational bias because you're getting these notices from the cloud provider instead of from the OS provider – but they're exactly the same.

      I don't see any valid critiques of Cloud Computing here.

      Valid critiques are:

      1. Security leaks caused by malware at the hypervisor layer.
      2. Performance bottlenecks caused by too much abstraction.
      3. DoS attacks made possible through anybody sharing the hypervisor.

      There's definitely an attack on Cloud Computing possible, it's just not in this post.

      Disclosure: I love cloud computing and am done with server hardware.

      • Adam, your point is actually the point. Let me explain.

        *Part* of the aggregate cloud computing marketing push is the latest "let someone else solve your problems." Just like the ASPs of the 1990's said they'd run your server apps for you. Just like the custom built ASPs (like of this decade said not to worry about software anymore. Part of cloud computing's industry message is that you no longer have to worry about servers.

        Want a new server? Click a button. There it is.

        No one is telling you that you still have to install an OS. Or that you still have to make backups.

        Brad's example is that the API implementations for controlling cloud computing suffer from the same problems that cloud computing is trying to remove.

        This is a very real problem. Another way to think about it, based off Brad's description of their survey is that there are real concrete observed quality control issues across the board. You simply cannot pickup any API, implement in any programming language or other tool, and just expect it to work. You cannot assume that your only problems will be logic ones with your use of the API. You have to assume there will be all kinds of lower level ones.

        One example from a previous startup I founded in 2004 that talked to 55 different blog platforms is that even a simple "standard" like the metaWeblogAPI can have weird issues across different implementations.

        Case in point: when integrating with a Brazilian blog provider our code was causing total server core dumps. The cause? The provider claimed to use one character set and was actually not following *ANY* character set standard. They were just throwing characters in the air. At the time there was a major issue with the compiled-in support for XML-RPC in the version of PHP we were using such that it became very unhappy when it encountered this situation.

        As in Brad's example, the solution was a custom native-language implementation of XML-RPC that although worked and provided more control was probably at least 10-100 times slower than the C language extension. The productivity gains on this stuff start to erode when you find yourself reimplementing every Internet RFC because no one ever managed to take the time to do it right.

        This issue probably took up 2-4 man days of time debugging. We just did not expect the issue was at such a low level and caused by something seemingly innocuous as character sets.

        In reality, we learned character set implementation is a big pain to debug because it is very hard to figure out what the raw characters being sent/recv'd are as every single layer of software can be fiddling with them, including your SSH terminal, your OS copy-paste, and your text editor. Our view that one or two systems programmers figured out character sets a long time ago and we would never have to understand them was wrong.

        I am giving this long reply because it illustrates how many problems you still have to deal with if you are using cloud computing.

        Guess what happens when you couple vm's in the sky with a 4GL system that handles this layer of stuff. When you can really make a decision to outsource every single piece of every single layer beneath your application logic to a company that will just make it work…

        • I stand corrected. The old adage remains true then, "When somebody says character sets or calendar app, run!!!"

  • Pingback: » Blog Archive » Exploding myths #1: The Cloud is “easy”()

  • Should we be worried about security of the cloud, and in particular when you see detailed bug / bug fixes around the connections for transfer of information – seems ripe with opportunity for bad guy attacks.

  • Martin Brunthaler

    So how exactly are we going to blame cloud technologies for these issues? While I agree that there's a lack of standardization in many (all?) areas of cloud computing both examples stated are applicable in any computing domain. Especially the JDK related issue is not related to cloud computing in any way.

    Such issues have been haunting us ever since – in fact I believe that cloud providers are in a good position to put an end to many of these issues. As the industry matures we'll see a) efforts to standardize APIs (computing control, storage, security, accounting) and b) many cloud related startups and also major vendors to provide services tackling higher level issues (e.g. startup sequence control, monitoring, etc.).

    • To clarify, I’m not “blaming” cloud technologies.  I’m trying to surface a set of problems that are extensive with the current instantiation of the cloud computing deployments.  One of the points – of course – is that “cloud computing is not separate from all of the existing issues that exist with non-cloud tooling and infrastructure!”

  • Oh yeah.  Security is going to be a huge issue.

  • Bingo. Yes to both problems, although we are starting with the lower level one which needs to be dealt with before you can address the higher level one.

  • Martin Brunthaler

    I was just referring to the two examples brought up and hence assumed that the majority of other problems related to tooling are not solely cloud related.

    The three major cloud players are differentiating each other at different abstraction levels, one of which also providing the necessary toolset to use the cloud – assuming they get their act together this will be a convenient solution for most .NET developers around. Bottom up, Amazon is closest to the traditional data center. That's probably where you want to hook into when talking about tooling. Their APIs have a good chance to become the de-facto standard for other cloud providers (see Eucalyptus – I assume that'll be deployed in many private clouds). This in turn will relieve toolchain providers to implement 100s of APIs. Anyway, they're probably trying to make working with clouds easier hence I assume that this will be Standing Cloud's USP, right?

  • Phil Sugar

    It seems that every generation of new technology has somebody proposing that this "new thing" will make it so easy that even "your mother" can use it.

    Object oriented programming, database tools, client server development tools, etc, etc…heck we can go back to punch-cards if you want.

    The end result AFTER really smart developers take the technology and make an app that is user friendly is that the user is much better off.

    In my mind cloud computing is just the latest..

  • On the problems of cloud computing, six general points and a conclusion: (1) One of the keys to success is good problem selection. (2) Another key to success: Exploit your opportunities; don't fight your problems. (3) To put up a tall building, build on bedrock, not soft dirt. (4) One key to 'easy to use' computing: Not that it anticipates your desires and tries to satisfy them for you but just that what it does is easy to understand, well documented, reliable, stable, and useful (and with minimal 'side-effects'!). (5) In computing, make money providing results fairly close to end users; Microsoft can make a lot of money selling infrastructure, but few others can. (6) To estimate how much work it will be to write some software, start with data on how long it took to write similar software before. If there is no such similar software, then usually no good estimate is available. Conclusion: Trying to do a lot with cloud computing now looks like trying to write software where no good time estimate is available to make money selling infrastructure built on a foundation that is not easy to understand, well documented, reliable, stable, or useful, building a tall building on soft dirt, fighting problems instead of exploiting opportunities, and poor problem selection. Maybe there can be good news for cloud computing and a feasible path around all the grim problems, but finding such a path might require some good creativity.

  • Yup to everything you said.

  • Good API's and SDK's are harder to create than most engineers think. There's the standard time estimation buffer of multiplying an engineer's estimate by 2-3 to get a decent estimate. I would say that for a project that includes the creation of a public API, after you do all that individual buffering, add another 2-3 factor for testing and the project as a whole.
    The best company I've seen at making SDK's is MIcrosoft. They are not without their faults, but they have decades of experience creating SDK's, documenting them, maintaining compatibility with them, etc. In my opinion, Google, Amazon, and even Apple are just beginning to learn the lessons that Microsoft learned years ago.

  • Bingo.

    Yes to both problems, although we are starting with the lower level one which needs to be dealt with before you can address the higher level one.

  • Just as a little addendum to my 'I stand corrected':

    Normal people aren't using cloud computing APIs. They're simply installing an OS on the cloud just like they would with a physical server. In that sense, there is very little difference between the two (except the security and reliability of the hypervisor itself (I'm referring to Paravirtualization since that's the flavor of cloud being critiqued here)).

    I think this conversation is on two different levels:

    Brad/Michael saying that cloud computing (when leveraged with their APIs) has it's own problems and isn't a panacea.

    Everybody else is basically saying that if you don't leverage the cloud (apples to apples) any more than you would a normal hardware installation, you get the added advantage of not having to worry about fixed hardware costs/maintenance and the lead time on deploying/retiring hardware. The savings here more than makes up for the increased cost of the cloud (usually).

    Both arguments are correct. I'm going to post this on my blog at right now – it seems to be a hot topic.

    • These are all great thoughts – thanks for putting the time into the discussion.  It’s a really challenging one, especially in the context of the tech industry’s desire for “the next great thing” to just appear and solve everything (which – of course – never happens).  

  • Pingback: Varud - Social Network Predictions » Blog Archive » Cloud Computing()

  • Saying that cloud computing isn't ready for prime time because there's a bug in Java is like saying my mom will never be able to drive a car because somewhere in Kansas there's a tractor with a flat tire.

  • Nice pint of view. Entirely sharing your view.

  • Nik


    Thanks for sharing. We are in the market for running cloud services. We have used EC2 in the past and have been featured on the AWS blog for some of the use cases of EC2 for one of the previous avatars of our service.

    We understand the pain and I think a lot of the cloud deployment solution tools would be helpful. Its kind of like what Opsware/Loudcloud used to do for datacenters but for managing the cloud.

    We are looking at the market place for our own service. StandingCloud based on your blog post is definitely one and seems like another? Are you aware of similar solutions in the same area so that our evaluation becomes easier?


    • Cloudkick is definitely in the zone of stuff I’m talking about.  I haven’t seen many others yet, but they are starting to appear.

  • Pingback: Ladies Prefer()

  • Pingback: affordable car insurance california()

  • Pingback: insurance auto quotes()

  • Pingback: instant online car insurance quote()