Noisy neighbours, a governance issue?

“Everybody knows” that whatever issues one may have with Cloud, it’s always cheap and effective. Well, with my governance hat on, good governance is, in part, about making fact-based decisions concerning technology and about not wasting your technology budget on decisions based on (often PR-led) assumptions. And, what “everyone knows” may not be right in all circumstances.

In the context of Cloud choices, the issue is around shared Cloud resources. If your Cloud is supported on a mainframe, with rock-solid tried-and tested virtualisation, and (probably more important) strong isolation of different users and reliable prioritisation mechanisms, you may not have a problem with sharing the underlying physical infrastructure (if everything is implemented correctly) but on most commodity platforms, if your neighbour in the cloud is badly behaved or “noisy” (running a badly designed system that generates more traffic than is “polite” in a shared environment, perhaps), then you may have problems – according to Rackspace and Netflix, anyway.

The effect is real and if, say, a 1% performance hit worries you (and I’m assuming that you’ll have metrics to show that it does really matter to the business; optimisation for its own sake is usually a waste of money and an unnecessary maintenance overhead), then you’ll do something about it: “Netflix concluded from minute measures of response times and other metrics that a neighbor engaged in heavy I/O and other resource use would slow the Netflix server each minute by fractions of a second. They often caused a server performance hit of 1% or less of what was expected, but Netflix, depending heavily on Amazon for its infrastructure, detected such problems and moved its servers away from the noisy neighbors”. See this article in Computer Weekly.

What this might also mean is that, even in the Cloud, there could still be a place for bare-metal servers (available with IBM’s SoftLayer, for instance; and from Rackspace; and supported by OpenStack) that aren’t shared with other applications. And if you are developing large, performance-critical systems, perhaps you should look at Containers (see Docker) as a lower-overhead alternative to a VM.

These aren’t just simplistic fashion-led recommendations for everyone, by the way; you need to know whether your specific applications can actually benefit from bare-metal. If a well-governed development shop is developing an automated business service, it needs to look at the whole system (at some point, at least) and consider all potential alternatives, not just the most fashionable ones, that “everyone knows” are the right choices. Of course, if you build up a picture of your organisation’s real needs, you may be able to reject some options fairly quickly – but revisit these decisions occasionally, what is actually (and cost effectively) on offer from technology changes quite rapidly these days…