Further (Mis) Adventures in Cloud Computing. Like Bob Marley, I’m Still Waiting. #cloud

Yesterday I wrote about my effort to find a cloud provider that I can use to upload an image.

I tried three. Each one is in some state of beta-ninnes, with complex sign up procedures, no clear self-service catalog. You see, I’m pretty sure they’ve done a mahvelous job putting their infrastructure in place, using the best tools, hardware out there.

But no thought to the user experience. So here’s the countdown.

Cloud One, the upload takes 5-6 hours, fails, then gives me a cryptic error message. So every cycle of trial and error is a day. Status: Not working
Cloud Two, after scary, long sign up process, chat sessions, disconnected chat sessions (“I was talking to Randy about…. sigh….”), appeals to product manager (“let me get back to you”). I’m finally provisioned! But it doesn’t work with VMDK. Status: Not working.

Cloud Three, Same as two, but I can’t log in… so I call support and they ask me two questions: account # and domain name. Me: “I don’t have them, this is the only number I got from sign up” Support: “I can’t find you.” Me: “Here’s my name, address,credit card, blah” Support: “I can’t find you.”

Much later… We’ll get back to you soon. That was yesterday. Status: Not working.

So I’m still waiting… Lest you think I wasted the whole day in this foolish quest without gain, it did remind me of how much I love Bob Marley’s “I’m Still Waiting” So enjoy!


“Can I get a price check on this AMI?” Catalog, Order Management, Subscription and Metering

William Vambenepe has a nice post that illustrates some of the challenges in the catalog side of cloud computing. First a quote, then my comments.
Of course, by the time my account usage page was updated (it took a few hours) I had found the price list which in retrospect wasn’t that hard to find (from Amazon, not IBM).

So maybe I am not the brightest droplet in the cloud, but for 20 bucks I consider that at least I bought the right to make a point: these prices should not be just on some web page. They should be accessible at the time of launch, in the console. And also in the EC2 API, so that the various EC2 tools can retrieve them. Whether it’s just for human display or to use as part of some automation logic, this should be available in an authoritative manner, without the need to scrape a page.

The other thing that bothers me is the need to decide upfront whether I want to launch a Tivoli instance to manage 50 virtual cores, 200 virtual cores or 600 virtual cores. That feels very inelastic for an EC2 deployment. I want to be charged for the actual number of virtual cores I am managing at any point in time. I realize the difficulty in metering this way (the need for Tivoli to report this to AWS, the issue of trust…) but hopefully it will eventually get there.

This anecdote shows the disconnect between the flat-static catalog, the order system, and the subscription / metering system that will need to be addressed.

The other issue raised, is that of units of measure. Units of measure vary today depending on where the customer sees value. This needs to be also managed in the cloud catalog/order/subscription manager trinity.

Now can you imagine trying to call your cloud provider to explain that you didn’t mean to launch 1000 servers for a week?

Best Practices