An enterprising approach to cloud management

Any disruptive business technology needs managing as well, if not better, than the established systems that it supplants.

But one of the ironies of new technology in general is that management is frequently an afterthought, to be developed and added after the technology has been used and its behaviours, good and bad, have been experienced.

That approach is counterproductive, if not actively dangerous, in business. However, the economics of cloud computing are undeniable, for the basic reason that the cloud provider has an enormous economy of scale in running its systems. This leads to a much smaller per-user cost to its clients than if they ran the equivalent amount of IT themselves. And the practical benefits of vastly reduced complexity and day-to-day running concerns should convince any company that has sufficiently well-defined IT needs to find a good match in the cloud.

You cannot ignore cloud, but you cannot afford to mismanage it. Therefore analysis of your management needs and how they are met by any putative cloud service has to be a primary consideration when planning any adoption strategy.

Management tools

Many cloud services have limited management tools that do not integrate well with existing systems, either because they are primarily a consumer or small business product engineered as a stand-alone system, or because the services are new and being developed.

A case in point is Google's Chromebook approach, where an attractive pure cloud play of Google Apps business services is married to an operating system entirely hidden behind a browser. As a stand-alone system it is quick and easy to deploy, and with Google's two-part authorisation system, it can be configured to enterprise levels of security. However, integration with other systems is limited.

Active Directory is supported through LDAP, but without full group support, while other centralised hardware management options are missing. At least, that's the case at the time of writing; what Google adds and when is never disclosed until it appears. The only sane approach to assessing its suitability for a particular use is to have a solid checklist of essential features at hand before making a commitment.

Integrating private clouds

Another example of the rapid development and current incompleteness of cloud management is Microsoft's Concero. As Microsoft's business model is far more heavily dependent than Google's on enterprises buying and maintaining their own systems, it puts much greater emphasis on integrating private clouds — ones where the enterprise itself runs the systems that run the cloud that runs the enterprise applications — and the public cloud; in this case, Microsoft's Azure.

Private clouds have less of a pressing economic case for adoption, but are a convenient and very secure way for companies to experiment with and develop their own cloud applications, prior to giving them the scalability that comes with public clouds.

Concero is a management tool that monitors and controls this mixture of private and public cloud, providing self-service portals so that users can mix and match applications and services from a managed environment. It'll be part of System Center, but it isn't available yet; again, from a purely management perspective, this model of cloud computing is less likely to be appropriate, simply because with the tools still under development. The burden of ensuring secure, high-performing, user-ready services will remain with local IT. That's not quite the point of cloud.

Assessing vendor proposals

In this respect, cloud management for any vendor is amenable to the same approach as any IT: an analytical, evidence-based approach to assessing vendor proposals does away with the hype. However, other areas, such as performance, security and reliability, are harder to manage — simply because these are the very aspects of IT management that cloud promises to remove.

Here, the onus on the customer is to trust and verify: research historical performance, obtain a strong and unambiguous service-level agreement (SLA) from the vendor, choose and perform adequate, appropriate metrics to assure the SLA is being met, and realise that "it's in the cloud" is not in itself an adequate disaster recovery policy.

No major cloud vendor is outage-proof — Amazon's four-day outage of EC2 in April took many high-profile third-party services off the air, as well as hitting internal corporate IT. Here, the ability to switch to another cloud provider (or, in this case, to move to another area of Amazon's EC2 services that was not affected) would provide robustness; some companies had implemented that ability and could recover swiftly.

Cloud management's core task remains the same as any IT management: to configure, control, protect and enable. Understand the nature of that task, and the right questions will follow — whether the right answers are forthcoming is up to the vendors.