Start Simple

This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.

With all the hype surrounding Cloud, it’s easy to lose your head when planning what your first release is going to offer. Well maybe not you, but other people around you who aren’t as grounded will almost certainly lose theirs. “ZOMG we’ll have vMotion to Amazon and single click clone-to-new-VM for production workloads BOOM! HEADSHOT!!!”. Calm down, Doug. You should always remember Gall’s Law, which in a nutshell says any complex system that works is bound to have evolved from a simple system that worked. Amen to that. It’s also worth remembering that simple does not necessarily mean easy, of course as Einstein said “It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.” (ie make it as simple as possible, but no simpler).

The Atomic Unit of Compute

This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.

Bonus content When I first started putting together my VMUG presentation, it was actually solely focused on this particular topic. I’ll link to the original presentation at the end, as I think it’s better if you read the post first.

Another of the challenges you’ll face along the way of Cloud is that of how to measure exactly what it is you are offering. But having a look at what the industry is doing won’t give you much help… as with so many things in IT, there is no standard. Amazon have their EC2 unit, and state that it is roughly the equivalent of 1.0-1.2GHz of a 2007 Opteron or Xeon CPU. With Azure, Microsoft haven’t gone down the same path – their indicative pricing/sizing shows a base compute unit of 1.6GHz with no indication as to what is underneath. Rackspace flip the whole thing on it’s head by deciding that memory is the primary resource constraint, therefore they’ll just charge for that and presumably give you as much CPU as you want (but with no indication as to the characteristics of the underlying CPU). Which way should you go? IMHO, none of the above.

Engage Support Early

This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.

Last post I talked about challenging convention, but you can go too far in doing so. Depending on the depth of your operational knowledge of the environment you work in, it’s easy to do just that and if you don’t consult with the ops teams until the last minute you could be in for a nasty surprise. And so the best thing to do, even if you think you know how things run, is to get operational representation onboard early. Like day one of the project early.

Challenge Convention

This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.

In the previous post, I talked about some of the things that you should think about before going ahead with an internal Cloud project. And I ended saying you should challenge the way things are done currently if they are impossible or very difficult to automate. But there are other things you should also challenge that aren’t directly related to automation, and I’ll cover some of those now.

Garbage In / Garbage Out

This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.

The notion of GIGO is of course much older than I am, but it’s one of those concepts that is timeless. In relation to Cloud, it’s more pertinent than ever. The marketing hype would have you believe that Cloud is a panacea, and many people hawking their wares artfully dodge the subject of your existing tools and processes. But ignore these at your own peril. The COO of the company I work for has a great quote, which goes something like “God made the earth in 6 days, because he started with a clean slate.”. The same is true of internal Cloud (or whatever you want to call it – I’m going to call it that for the sake of convenience) – you could probably nail down the platform code and functionality that you want to launch with in a few weeks, but making the requisite changes to existing processes and integrating with existing tools in your environment is what will take the lion’s share of time to address.