Enter a search term such as “mobile analytics” or browse our content using the filters above.
That’s not only a poor Scrabble score but we also couldn’t find any results matching
Check your spelling or try broadening your search.
Sorry about this, there is a problem with our search at the moment.
Please try again later.
When resources are scarce, you grab them and hold onto them. This has been true throughout history, and it's currently how most organisations manage servers. It’s probably why most data centres are built like fortresses. An expensive strategy but, conceptually, a pretty simple one.
The Cloud changes all this. By pooling and sharing resources, the Cloud makes it possible for us to treat servers as if they are abundant. This in turn means we must change our management style.
When resources are abundant, you only take what you need right now. You allocate and free up resources in response to demand. You pay only for what you use. You compete not through ownership of scarce resources, but through intelligent use of abundant resources.
This is what the Cloud does, it makes cheap, commoditised resources available in abundance, for you to allocate and free up in response to demand.
That has big implications for the way you specify infrastructure. Specifications are no longer about technology; they’re about creating a framework that lets you match capacity to demand. So the core of your specification needs to address three factors:
How much computational capacity do you need, and when do you need it? How does this demand shift over time? Are there daily, monthly or annual patterns? Are there underlying trends? How much uncertainty is associated with those patterns?
To get at these factors, your specification will probably draw scenarios illustrating what your demand might look like across different timescales.
These scenarios will also show the range of likely demand at any point – minimum, most likely and maximum. (And note that a large range isn’t necessarily bad: the Cloud might help you exploit such variation. For traditional systems, a large range is definitely bad: it means you need to grab more resources, even though you won’t use them most of the time.)
How critical is it that this capacity is there when you need it? High availability costs more, so you need to be rigorous here. Look at each piece of functionality in your systems and think about the consequences of an outage.
Will customers be affected, or is it only seen by internal staff? Does it drive revenue? Are other functions dependent on it?
Classify your functionality against the level of availability it really needs, then map this back to your demand scenarios to draw out what proportion of your capacity needs the highest level of availability, and what proportion can live with lower levels. This is the second key factor in any specification.
You will need the capability to match available capacity to demand as the situation changes. How will you monitor resource utilisation? How will you identify unexpected events – demand peaks or resource failures, for example? How will you respond to these events?
How will you reallocate capacity in response to predictable trends, say due to seasonal variations? What aspects of this can be automated, and what aspects need human oversight? What will you manage yourself, and what will the service provider manage for you?
Manageability is the Achilles heel of the Cloud: tools for managing cloud resources are only just beginning to emerge. So you need to be very clear about just what you need. You may also need to be prepared to spend some time developing the necessary tools.
A good specification is therefore going to identify the classes of demand that your systems must satisfy. It will define a set of scenarios illustrating how much computational capacity you are likely to need in each demand class, and the level of availability you need against that capacity. And it will identify what facilities must be available to allocate, monitor and manage this capacity. Simple really.
The problem is standards. The market for cloud services lacks consistent standards. This means that each vendor measures and prices for capacity in different ways. It means they all define availability differently. It means that management tools are generally patchy and weakly integrated. Finally, it means that application licensing models may constrain the infrastructure options which are available to you.
In the absence of well-defined and accepted standards, it takes a lot more work to set out your requirements. You’ll need to define your own measures for capacity and availability. You’ll almost certainly need to find ways to compare one vendor’s apples with another vendor’s oranges when it comes to pricing and service levels. Allocate plenty of time for such work if you want to run a successful procurement.
This work is worth doing. It will help you build a clear picture in your own mind of just what you need. That’s invaluable while the hype is strong and the standards are weak.