Most of us have built our management systems to cope with scarce resources. We define budgets because there’s never enough money do everything we want. We have expense policies for the same reason. We ration access to machinery and meeting rooms and computers through devices like queues and plans.
Resources are scarce. Protect them. If possible, grab more and hold onto them. That’s what history’s about: wars are fought to grab and hold onto valuable resources. Land. Trade routes. Minerals. Customers.
The Cloud changes this, at least so far as computers are concerned. By pooling and sharing resources, it enables us to treat computational resources as if they are abundant. That means we have to change our management systems.
When resources are abundant, it makes sense to only take what you need when you need it. You can always get more if demand changes, so you should only pay for what you need right now. You no longer compete through ownership of scarce resources. Instead, you compete through intelligent use of abundant resources.
How do you do this?
Let’s start with the way you specify infrastructure. Specifications no longer need to focus on technology. Instead they should focus on demand: you need to create a management framework that lets you match computational capacity to your customers’ demands. So your specification needs to address three core factors:
- Demand. How much computational capacity do you need, and when do you need it? Does this demand change over time – are there regular daily or weekly patterns, for example? What does the underlying growth trend look like? How variable are these patterns? (Variability is bad on a conventional infrastructure: it means you need to over-specify and hence pay for idle resources. But the Cloud relies on variability: vendors exploit it to help share resources.) To define these factors, you’ll probably need to draw out scenarios illustrating how your demand might change over time.
- Availability. How critical is it that computational capacity is there when you want it? This is important: high availability costs more. Consider each piece of functionality in your systems and think about what happens if it’s down. Are customers affected? Does it drive revenue directly? If an outage is highly visible and affects revenue, then the function needs high availability. Otherwise, you might be able give it a slightly lower level. Map your demand scenarios onto availability, identifying the proportion of capacity that needs the highest possible level of availability and the proportion that can live with less. This is your second core factor.
- Manageability. Demand patterns will change. You need to be able to adjust your capacity in response. How will you monitor resource utilisation and recognise such changes? How will you respond to trends, peaks and troughs in demand? How will you reallocate capacity in response to unexpected events? Can this be automated, or will it need human oversight? What will you manage yourself, and what will the vendor manage for you? Manageability is the Cloud’s Achilles heel: tools for monitoring and managing demand are still emerging. So be very clear about what you need, and be prepared to spend some time developing bespoke tools if you have special requirements.
That’s it. The basis of a good Infrastructure-as-a-Service specification is a clear identification of the classes of demand which your systems must meet. It will define how much computational capacity you are likely to need in each demand class, and what proportion of that capacity needs high availability. And it will specify the facilities you need to monitor, allocate and manage capacity as demand patterns change. Simple really.
The problem is standards. There are no consistent standards for specifying this stuff. Each vendor measures capacity in different ways. Likewise for availability. Management tools vary widely, both in their capabilities and in their degree of integration. All of which makes it very difficult to compare pricing and service levels across the vendors.
In the absence of widely accepted standards, you’ll need to do more work to define your terms and set out your requirements. You’ll need to define your own measures. And you’ll almost certainly need to find ways to compare one vendor’s apples with another vendor’s oranges when it comes to price and SLAs. Allocate plenty of time for this work if you’re moving to the Cloud.
But the work is worth doing. It will help you build a clear picture of just what you need. That’s essential when the hype is strong and the standards are weak.
