Think Outside the Infrastructure

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”.

It’s time to get back to the reason for doing all this in the first place – it’s about the business, and the applications.Which is why you need to think outside the infrastructure when it comes to Cloud more than you need to think about the actual infrastructure itself. By that I mean the Cloud is more about logical concepts like service levels / tiers and features rather than HP or Cisco, EMC or NetApp.

Hang on – didn’t I say this was about thinking _outside_ the infrastructure? Isn’t capacity all about the infrastructure? Well yes and no. When most of us think about capacity, we tend to think in terms of physical constructs – memory, compute, storage, bandwidth etc. Obviously the capacity management of those things should be a given. But just looking at those is not enough – you need to look at other factors that are more on the logical side. Like IP addresses – there’s not much you can do with the 50% spare capacity in Cluster X if the address space presented to it is full. How have you defined the failure domain for your infrastructure? Is it such that any one cluster cannot house more than X number of “critical” applications? If so, better make sure you throw that into the capacity equation too. Same goes for things like backup – is that feature something you define on a cluster basis? It may not be a 1:1 relationship, but if you have defined any kind of fixed relationship between backup servers or backup space and endpoints, you need to track that as well. I’m sure there are many other things you can think that may be more relevant to you. Or not – the point is, don’t just think about the physical stuff when thinking about capacity.

When making placement decisions, determining if capacity is available is just one part of the equation however. First you need to know where to look. In your initial internal Cloud deployment, this may not be too much of an issue – if you’ve followed the path I have outlined so far, you have a fairly simple offering and can likely categorise the potential workloads fairly coarsely. But as your offering becomes more complex, so too will the decisions as to where to optimally place a new workload. And the only way you can make such decisions accurately is to ensure you have good metadata to describe your applications and your infrastructure.

Rather than repeat myself here, I’ll refer you to this post I wrote 6 months ago. How time flies – 6 months down the track I don’t really have anything new to say on the matter. And I still haven’t started development work on a tool to provide this functionality, as much as I would like to!

That’s about all I have on Thinking Outside the Infrastructure. But again, the point of this series isn’t to provide the answers – it’s to get you to thinking about the questions.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: