We’ve been using Scalr for a couple of years and the UI has often been a sore point. The UI and UX don’t seem to match up to the capabilities of the scalr platform.

Here’s hoping the new UI solves that.

Hybrid cloud computing is something Rackspace bang on about all the time. To them, there are 3 types of cloud: public, private and hybrid.

Public cloud is what most people I speak to understand cloud to be. Multi-tenant, remotely hosted and managed services. (Ok – there’s more to it than that… but let’s move on.)

Private cloud is virtualised, private infrastructure giving the benefit of dynamic provisioning and the knock-on benefits that brings of dynamic scaling, recovery and the like.

Hybrid is a mix of those and to do it you need to move seamlessly between the public cloud services you plan to employ and the private cloud servers, perhaps even some dedicated hosting services.

Rackspace is geared towards this a lot. While Amazon provides some tools such VPC, Rackspace’s offering seems to include this at a much lower level – even in the load balancer’s ability to balance between a dedicated server and cloud instances.

Visiting San Francisco this year made me realise the stark difference between what the start-up world and the rest of the world. Anything is possible in start-up world. Ideas aren’t gold, they’re like seeing a new place where gold might be. In the rest of the world, ideas are amusing but there is less impetus to do something about them. Someone else will always do it first.

I haven’t read this book, but it’s on my list now… Maintaining your own momentum when you don’t have competition, people as sounding-boards and the enthusiasm and drive of others is hard.

Have a look at it at their secret project blog post.

Rackspace have put it tones of effort to keep the quality of their customer service – i.e. their USP – extremely high. I was surprised that when Rackspace launched their managed cloud if support and management was on a par with the support for dedicated hosting. That level of support takes a certain kind of person and training.

As cloud becomes mainstream, with companies slowly moving from their dedicated and co-lo infrastructure to cloud, support will matter but the question is whether Rackspace can keep their high-quality support model as they scale.

Not all cloud hosting needs that kind of support. I can cope perfectly well with S3 and zero support because it’s so simple. If Rackspace provide the option of support on such simple services, which might become the expectation, surely they’ll end up more expensive.

And how can complex services be supported without Rackspace ending up building solutions based on the technology. Rackspace provides a significantly trimmed down cloud offering, which I’ve always thought gears itself towards use-cases which are in the real world of hosting rather than the general computing problems that Amazon seem out to solve.

With a trimmed down offering, Rackspace can offer support for common use-cases in hosting rather than the huge number of use-cases that anyone on Amazon might be solving. By keeping their offering simple, they can provide high quality support without the risk of customers expecting more than they can get.

Scalr providers you with a kind of meta-level over what Rackspace, AWS and other cloud providers offer. Instead of using AWS’s scaling rules or manually dealing with scaling and config, Scalr puts all the effort in for you.

Here’s how we’ve used it:

- We built some custom AMIs on Amazon (this was a couple of years ago)

- We built into these the ability to run a script at launch time. This has since been replaced with Ubuntu’s cloud init system in our recent setups.

- We wrote a series of bash scripts to setup the instance for us.

There’s a short article by Scalr’s founder on Rackspace blog on using Scalr for scaling Rackspace cloud.

So I wasn’t sure, when I started working whether other people had the same learning curve in debugging as I did but I think they did. I think this because they seem to make the same mistakes. Trying stupid ideas before writing down what the causes might be. Not keeping an audit of your changes.

I’ve pooled together what I read in many debugging books in a debugging-danfrost2010. Enjoy.