The Importance of Policy in Cloud Migration

Wave planning policy – this defines the order, priority and grouping of systems that are to be migrated to the cloud.  Also referred to as move groups, these waves are the “chunks” of infrastructure and/or applications that are being targeted.  The policies in this area include whether to migrate by physical criteria (e.g. data centers running out of power) or logical criteria (e.g. app-by-app), and also how to deal with application interconnect.  Latency can be a serious problem when moving to external clouds, making interconnect analysis critical.

Candidate qualification policy – this covers the qualitative and quantitative criteria that indicate whether a specific server workload is suitable for the target cloud environment.  On the qualitative front, considerations like the treatment of sensitive data and required SLA levels will dictate whether a specific application (or component of an application) can be placed in a certain type of cloud capacity.  On the quantitative front, high levels of activity like context switching or I/O can also rule out migration to certain environments, which may not be designed to support high throughput or performance (or where these capabilities may cost more money).

Sizing policy – this governs how existing workloads should be sized into the cloud capacity.  Many clouds are packages into fixed instance sizes (e.g. small, medium, large), which are modeled in the cloud catalog.  The policy on how to map the existing workloads into these containers is critical – the mis-allocation of resources will either cause performance issues or will waste money by over-provisioning the applications.  Policies in this area, for example, may dictate that decisions are based on the peak activity of the last year, trended forward, plus N% buffer, normalized to the cloud capacity using SPEC benchmarks, targeting to use 75% of the cloud container.  Load balancers and other structures that provide an opportunity to use the more “elastic” features of clouds must also be reflected in the overarching policy.

Placement policy – this governs how workloads are placed in the actual back-end infrastructure, and dictates everything from business constraints (e.g. these apps cannot go together) to technical constraints (e.g. cpu and memory overcommit ratios) to performance targets to operational policies.  In many cases, these policies may be owned by the infrastructure groups managing the servers, but they must also be reflected in the migration planning to ensure that any subtleties are accounted for early in the process.

Exception policy – this deals with what to do with the workloads that are not suitable candidates for the cloud being targeted.  Common examples include large database servers, which may be better placed on physical servers or in shared database environments.  This aspect of policy ideally defines an order of precedence, such as trying custom cloud containers, then VMs, then blades, rack mount servers, etc.