Lessons for Procuring Cloud Services at the Enterprise Level: Part 2 | Gaining Altitude in the Cloud

Posted On February 16, 2012

In Part 1 of this blog series on lessons to help you avoid potential challenges and surprises while on the road to the cloud, we looked at procuring cloud services, application and workload analysis, evaluating cloud services, the end-state environment, and making TCO work. Following are our final five lessons

6. Active Management of the Environment – To make their solutions cost effective, cloud service providers (CSPs) have architected their cloud environments to a predetermined set of standard technologies and service levels. The buyer must thoroughly evaluate the technologies and service levels proposed by the CSP to determine whether it can live with these, or otherwise end up paying more. Organizationally, the buyer should also consider a new role – cloud manager –whose purpose is to actively manage the cloud resources made available by the self-provisioning portal, i.e., provision and de-provision virtual machines (VMs) per demand. For example, there is no need to dedicate a physical server (or VM) on a full time basis for the QA or testing of an application that is only rarely changed. In this case, the appropriate course would be to store an image of the specific application, and only spin-up a new VM and download the image when changes are required, this way avoiding a recurring monthly charge for a VM that is available 24×7.

7. Transition – Although a case may be made for the potential savings of utilizing a cloud solution on a recurring basis, the transition costs may make doing so unattractive. Indeed, transition (supplier fees and internal transition expenses) may come close to costing as much as the first year billing of a cloud solution. Given that many times a CSP is expected to transition for a fixed fee and to a specific deadline, risks tend to creep in and overhead may be added to its transition fees. Additionally, these transitions usually occur in waves. The first wave proves the approach and validates the details of the plan via with a workload or group of servers that are not critical to the business. After evaluating the results of the first wave, plan changes and enhancements are made for subsequent waves. To avoid interruption to the business users, the cutovers usually occur over weekends, which make the transition take longer. We recommend jointly developing a detailed plan with the CSP to mitigate risks, clearly assigning responsibilities, and working out the details in areas in which the CSP perceives greater risk.

8. Disaster Recovery (DR) – A CSP may offer a primary site for production and non-production (development, test, and QA) workloads, and a secondary site for DR. Recovery time objectives (RTO) and recovery point objectives (RPO) requirements will drive the cost for DR, especially for data replication when a short RPO is required. A potential cost effective alternative is to dedicate the primary site for production purposes only, and the secondary site for non-production. In case of a declared DR event, production would be switched to the secondary site until the primary site is operational. The drawback to this approach is that the non-production environment would be unavailable until the primary site is again up and running.

9. Cloud Manager – Expanding a bit on the cloud manager role we touched upon briefly above…this individual would be responsible for extracting the greatest use of the cloud environment in the most cost effective way by actively monitoring the utilization levels of the environment, and making decisions whether to scale up or down for any given application or workload. The buyer should note that the skills required for this role may not exist in the organization and may be necessary to obtain outside the organization.  The skills required are not necessarily technical in nature, but rather an IT business management profile would be best suited given that the cloud manager would work directly with the CSP to plan for changes and utilization peaks to ensure it is prepared in advance for increased/decreased demand.

10. Pricing – In most cases, Software as a Service (SaaS) is priced by user, (and possibly by user profile), and thus can be precisely allocated back at the departmental level. Infrastructure as a Service (IaaS) does not identify usage at the end user level, but rather is typically invoiced at the VM level. For applications/workloads that run on a specific VM and belong to a particular department, the allocation is clean. The cost allocation for end users from multiple departments that access the same applications that run on multiple VMs is difficult to achieve at the VM level. Achieving the desired goal of invoicing IaaS services by end user/department would require software that analyzes utilization at the database level (where transactions are stored by end user ID) attached to the application.

As we noted in Part 1 of this blog series, moving from a legacy IT environment to the cloud is not trivial…it’s fraught with expenses, challenges, and making decisions – even trade-offs – in still unchartered waters. We believe these 10 procuring cloud services lessons will help you take the right steps on the path to cloud success.

Everest Group Executive Viewpoints icon Related Articles