eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
In the past year, we’ve seen a rapid increase in the number of enterprise applications that IT teams are moving into the public cloud. Most recently, many are migrating even their most mission-critical applications, databases and ERP, such as SQL Server, SAP, HANA and Oracle.
As IT teams under pressure to meet stringent service-level agreements look to migrate apps to the public cloud, many are running into unexpected challenges.
In this edition of eWEEK Data Points, Cassius Rhue, vice president of customer experience at SIOS Technology, offers industry information on how to identify some of these challenges and avoid them.
Data Point No. 1: Ensure cloud migration plans include high availability.
It’s no secret that thorough planning is essential to the success of any significant IT project. However, cloud migration plans often omit a significant factor: high availability protection. A detailed cloud plan brings all of the stakeholder teams, technology requirements and end-user expectations in a coordinated effort that progresses through defined milestones or project phases.
By factoring in the end-user expectations and business objectives for recovery time and recovery point, a well-designed plan ensures that deadlines are met and unnecessary risks are avoided. Without a thorough HA component, IT teams often identify crucial information, such as key dependencies, compatibility issues, or hardware requirements late in the project when adjustments and remediation steps are expensive and time-consuming. For example, an unexpected reboot of a server may reveal an application monitoring and HA hole. Ensure that your cloud migration plan considers all of the steps and dependencies involved in your high availability and disaster recovery at the application level.
Data Point No. 2: On-premises configurations may be overkill in the cloud.
Simply copying your on-premises high-availability configuration in the cloud can be an expensive mistake. Instead, start from a full definition of what functions and service levels your on-premises configuration deliver, then design a cloud environment that meets those requirements. Look closely at networking and storage –as well as virtual server resources in the cloud–with an eye to reducing over-engineered components and designs carried forward from your legacy on-premises environment.
Data Point No. 3: Avoid penny-wise, pound-foolish cloud provisioning.
Cloud utilization-based charges can be unsettling for IT teams used to the predictability of operating expense driven on-premises environments. However, controlling cloud costs by under-provisioning can cost you money in the long run. The savings you may squeeze out of cloud fees when you use undersized or lower-performance disks, under-provisioned CPU or memory resources, create clusters with too few nodes and can be quickly offset by the cost of troubleshooting the issues it causes. When User Acceptance Test (UAT) begins and workloads overtax undersized resources or cost optimization of a target node causes unexpected consequences during a failover. Virtual machines are easy to resize, but sizing issues can be subtle, triggering issues that create delays while architects troubleshoot them. Under-provisioning can also mean unrealistic budgeting and unexpected bills.
Data Point No. 4: Outdated procurement processes
Cloud adoption has increased the speed of change in IT—often faster than the procurement processes IT uses to facilitate cloud migrations. Lengthy processes typically included formal steps for requisition, acquisition requiring bidding, instance sizing, formal approvals, server preparation configuration, testing and deployment to production. Storage, networking and compute resources are procured in the cloud in faster, more flexible ways that do not fit easily into traditional procurement processes. Outdated procurement processes can mean unnecessary delays in cloud migration.
Data Point No. 5: Late HA/DR planning
Planning a cloud migration plan often starts with the application that is being migrated. Often, the need for high availability and disaster recovery is left until last. Efficient, cost-effective HA/DR planning requires more than buying an enterprise license for the application. Thoughtful system design can improve the speed, efficiency and cost-effectiveness of a cloud migration process. Capacity, criticality, RTO/RPO, redundancy and the requirements for correction need to be included. Planning should also consider vulnerability to risks, potential single points of failure, and missing layers and levels of application recovery and resilience.
Data Point No. 6: Test thoroughly and often.
In a typical migration plan, the last decision point for “go/no-go” is a batch of user acceptance testing on the staging servers. If the first test fails subsequent test cases are often skipped to make up time in the schedule. Skipped tests are typically related to integrating backup and security software with the latest OS and supporting patches. The project can become delayed and complicated if the simulated load in the test trips any common issues including a kernel bug, a CPU or memory provisioning, and storage layout and capacity issues. The late-in-the-game testing now has to back track to improve customer confidence, work through a more thorough testing and validation plan, incorporate possible resizing and architecture changes, and apply software and OS fixes.
The benefits of cloud are compelling, but to reap these benefits, you need a well-planned cloud-migration strategy.
If you have a suggestion for an eWEEK Data Points article, email cpreimesberger@eweek.com.