What are some of the keys to success when including public cloud services in provisioning enterprise IT services?
This is a good question because it illuminates a powerful concern that still shadows the public cloud services market: What is the value of the cloud? If the value were totally apparent, there would be wider adoption of such services, but the growth of the market has been gradual.
The cautious adoption of public cloud in the enterprise has been largely due to uncertainty over who exactly controls service delivery when the IT assets are no longer under the direct control of IT. What happens when the IT department is at the mercy of the service delivery channel as much as the end user? How can things like public cloud security and performance be ensured when the resources associated with the service exist in a remote data center, or even several remote data centers that are not under the direct control of the enterprise IT shop?
This control issue defines the primary key to a successful implementation of cloud provisioned services: maintaining control of the process. The cloud works best when the enterprise IT organization is deeply involved in managing the cloud provider. Employing a cloud solution does not divorce the IT organization from responsibility; it actually increases it.
This would seem counterintuitive. After all, isn't the cloud supposed to decrease costs by decreasing IT involvement and capital investment? Well, no. Although using a public cloud has been heavily marketed as a way to decrease IT costs, if done appropriately it can be cost-neutral at best. This is because well-run public cloud provisioning simply shifts costs from Capex to Opex. The cloud increases IT flexibility and allows IT to respond better and faster to the enterprise's demands for computing solutions.
This brings us to a list of dos and don'ts when it comes to integrating the cloud into the IT solution stack.
Public cloud integration dos:
1. Stay engaged. Make sure that IT understands the service contract and especially the remedies available for poor performance.
2. Understand the objective. Is the cloud simply a backup for data storage or is it for having extra computing cycles to backstop strategic applications? Each has different levels of required performance, and each requires different levels of oversight.
3. Pay attention to availability and security. What will happen if your data is compromised? What will happen if the extra computing cycles you need are not available when you need them? Do you have a disaster recovery plan that includes cloud service failure?
4. Make sure you have the tools you need to manage the cloud. Does the cloud vendor provide a management pane of glass that you can use to monitor their services? Do you have the tools you need to verify your service-level agreement (SLA)?
5. Make sure you are staffed to manage cloud services. Don't assume that using the cloud will let you decrease headcount. You may need to increase headcount to adequately manage cloud services. Make sure you know before you implement a cloud solution.
Cloud integration don'ts:
1. Don't assume that the cloud provider understands your business. This mistake put several companies out of business when Amazon's cloud services crashed a few years ago. Only you understand what your business needs: Make sure your contract and SLA reflect what is important to you.
2. Don't assume that the cloud will reduce your expenses. Properly managed clouds require oversight, generally by people qualified to catch problems before they impact your users.
3. Don't trust the cloud vendor's service metrics. Ensure that you have the means to verify their reporting. This may require additional management tools.
Ultimately, the cloud increases IT capabilities, like any good tool or application. But just like the next piece of computing hardware, the cloud requires close management, an understanding of how it impact service and a fallback plan when it fails.
From the editors: Check out this photo story about the top cloud services enterprises want to buy.
This was first published in May 2013