Beware These 6 Pitfalls Of Cloud Assessments

Raju Chekuri (pictured) is president and CEO at NetEnrich, an IT services provider based in San Jose, Calif.

Any cloud migration project begins with an assessment of the current state of an organization's technology environment, plus goals and requirements. But a cloud migration is less a project than it is a transformation of running IT. This makes doing a proper and well-planned assessment even more important if your customer is planning a partial or complete migration.

Yet no two assessments are exactly alike. This is a specialized effort, which most IT departments aren’t prepared to do on their own.

I like to think of assessments as the start of a journey, delivering a roadmap for milestones, costs and ROI. So, don’t be fooled by experts who will tell you that an assessment is the same thing as capacity planning.

There’s much more to preparing for a bulletproof cloud environment than mapping your on-premises environment to cloud infrastructure. You have to understand the differences between the two environments, and plan accordingly.

A glaring difference between on-premises infrastructure and running in the cloud is latency. Applications hosted in the cloud will require sufficient bandwidth and compute resources to make up for the longer distance the data must travel to get to employees, as well as the effect of shared resources. Of course, cloud platforms also will vary.

Here are six common pitfalls IT organizations encounter in assessments, leading to performance issues and cost overruns.

1. Lack of existing performance data. It’s challenging to design a new environment without benchmarks. You may think that whatever infrastructure that has been deployed internally will translate seamlessly to the cloud. That’s not usually the case.

To avoid under-provisioning or over-provisioning the new cloud environment, gather adequate performance metrics over a few weeks rather than just a few hours. That will allow you to understand user patterns and system requirements under different conditions and scenarios.

2. Not enough bandwidth. Your client must have the right pipes to run in the cloud. To determine its needs, first analyze how much network bandwidth applications use or plan to use.

Next, consider the architecture. If, for instance, your client will have a hybrid environment straddling your on-premise and public cloud environments, you might want to consider a dedicated line through a service.

3. Lack of planning for cloud storage. Transitioning from on-premise to cloud storage comes with many options. Public cloud options include block storage (ideal for high-performance applications), file storage and NAS, as well as object and tape storage.

The latter two choices are best for archiving. Another decision your client must make is whether the systems require local or global redundancy. The latter is more resilient for high uptime needs of critical systems, but also more expensive.

4. Overlooking app dependencies. Applications rarely run in isolation. They connect to databases and other applications, which may run on different servers and the VMs. If you fail to consider those dependencies and move an application to the cloud without its “partners,” the application won’t work well, if at all.

Therefore, move applications and their dependent systems together. Dependency mapping is no small feat; it takes time and a certain amount of expertise. So, be willing and able to perform this extremely important task. You can use automated tools to do it cost effectively.