Andrew Hillier is CTO and co-founder of CiRBA, Inc., a data center intelligence analytics software provider that determines optimal workload placements and resource allocations required to safely maximize the efficiency of cloud, virtual and physical infrastructure.
ANDREW HILLIERCiRBA
Many organizations are aggressive in their plans to leverage cloud technologies. The fundamental benefits these technologies bring, as well as the hype surrounding them, often create a call-to-action that is sweeping many IT departments. But taking action before properly thinking through when, how and why these technologies should be used can be dangerous, and can lead to a “ready, shoot, aim” approach to cloud migration.
The key to avoiding this is to think of cloud migrations in terms of policies. IT infrastructure is complex, and the rules of what can and cannot be done may not always be well documented (or even well understood). Combine this with the ever-changing needs of the applications and their data, and it becomes very difficult to properly match application requirements with infrastructure capabilities. To make things worse, one wrong move can cause significant damage, both to the application and the migration project, where a loss of confidence can spell disaster. All this can be avoided, however, if migration policies are formalized and agreed upon ahead of time.
Thinking Through Cloud Migration
Many find the notion of policy daunting, and don’t want to get embroiled in a lengthy up-front analysis of all the minute details of a migration. Fortunately, this does not need to be the case, as the art of virtualization and cloud migration is becoming more of a science all the time, and there are patterns and best practices that can be applied. There are several major areas of policy that should be thought through. And if these can be embedded in the tools and processes used to plan transformations, then cloud migrations will happen much faster, and more importantly, be much safer. These are:
- 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.
Giving some thought to these areas ahead of time, and using them to reach a common ground with application owners and other stakeholders, is extremely important to the success of cloud migration initiatives. Better yet, modeling these policies in such a way as to enable the automation of cloud migration decisions can greatly acceleration migration projects, and prevent costly mistakes along the way.
Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.
