Oleksiy Mark - Fotolia
5 post cloud migration risks and how CIOs can avoid them
We've covered issues that arise when making the move to the cloud but here we're diving into the challenges CIOs and their IT teams face post cloud migration and how to avoid them.
Work is still flowing from data centers into IaaS environments such as Google Cloud Platform, AWS and Microsoft Azure. Migrating a workload into a cloud environment is only part of the challenge and many risks attend the move. Some can be prevented and others prepared for. The following are five common post cloud migration risks that CIOs must consider today.
Risk 1: Poor architecture leads to exorbitant compute costs
Although on average 40% of an enterprise's IT workloads still run in a private data center, many companies have basically thrown up their hands and said, "move it all to cloud as fast as we can." The reason being that some want to empty a leased data center or shut down and repurpose an owned one -- others make the move because they assume they should be in the cloud and just thought they needed to get it over with. The situation inevitably turns into adopting a "lift-and-shift" strategy for many workloads, which means no attempt to adapt the workload to the cloud. The result: systems running on the same number of virtual machines they did in the data center, instances that mirror the ones they ran on there and running at full capacity, 24/7.
This can translate to the same workload costing several times as much to run in the cloud as it did in the data center, which can easily break an IT budget. CIOs can find themselves having to borrow resources from other critical or strategic projects or with no choice but to request more funds.
The key to reducing costs is adapting workloads to the cloud environments. Even a quick jump to the cloud should avoid an unexamined lift-and-shift approach and should always include right-sizing exercises to reduce over-configuration. Minimal adaptation can sometimes yield enormous savings as well. For example, a financial services company may have a heavy-weight modeling application that runs whenever it's needed. Because it can be available at any time, it can't be limited to specific work hours and idled otherwise. However, it doesn't necessarily have to be available instantly. Instead of running it 24/7, IT can set up a minimal listener instance that waits for someone to request the modelling app and then spins it up. That way, the massive vCPU application with hundreds of GB of vRAM will only run during the hours it is in use.
To avoid this cloud migration risk of significantly increasing costs, CIOs and their IT team should be evaluating workloads for such adaptation opportunities as part of their cloud workload onboarding process.
Risk 2: Poor understanding of workload ecosystem
In a similar vein, if an IT team doesn't understand how data flows out of a system they are moving to the cloud, they can wind up facing the cloud migration risk of unexpectedly driving up costs. It's important to remember that data flowing in is free and data flowing out costs. The same workload onboarding process that can help identify opportunities to adapt a workload to run efficiently in the cloud should also map out what other systems the application runs in to better understand where and how much data will need to leave the cloud environment and how much it will cost.
Once that it sorted, IT can then decide how to mitigate the risk of ballooning costs. Options for eliminating this kind of problem -- whether undertaken as part of the process or after the fact -- include rearchitecting the application to eliminate flows out, implementing compression, migration of the other systems involved to prevent cloud egress and adding a direct cloud connect or cloud exchange to restructure and regularize the cost.
Risk 3: Cloud environments not in sync with security policy
According to Nemertes Research's 2019-2020 Cloud, Network, and Infrastructure Research Study, approximately 66% of organizations have some kind of cloud workload onboarding process to follow when migrating a workload to the cloud. In that, nearly all include security configuration and 50% of those organizations automate that setup. However, having security set up correctly at the time of migration is only the first step. If IT pros fail to robustly incorporate audit and maintenance of each security environment into their regular change management processes and systems, they will inevitably see their various cloud and on-premises environments drift apart. Thus, this leaves the organization at risk of falling out of compliance and increases the risk of compromise.
The cloud onboarding process should include confirmation that each new offering is tied into the change management process, as well as include updating security and audit policies as deemed necessary when entirely new cloud environments are added into the mix. Tools such as Flexera, Scalr and Tufin are also available to help implement security consistently across environments.
Risk 4: Inadequate visibility into performance and use
IT teams can often lose sight of performance and system utilization on cloud systems not because they're unable to get the information but because they have failed to plan for how to get it and how to use it. The focus on migrating to the cloud is more intense than the focus on managing ongoing operations in the cloud. When admins must use a different tool set to acquire the data embedded in a provider portal, that decreases the likelihood of the information being consistently collected and used.
A good onboarding process should drive adequate preparation for cloud operations on each workload migrated. Ideally, it will result in integration of data from the cloud's management apparatus into the existing management tool set. This can also be implemented after the fact but in many cases, it won't be until there is a significant problem with performance or availability.
Risk 5: Inadequate lifecycle management leads to wasted money
Lastly, there is the post cloud migration risk that IT doesn't track the newly implemented systems through their end of life. This is a familiar problem with the cloud -- zombie systems have been an issue since the birth of server virtualization and the cloud amplifies it since it is easier to lose track of a system that has no visible physical reminders -- in other words, no host server sitting in the rack. It isn't uncommon for IT teams to set up new test and development environments without fully decommissioning the old ones or to replace a server with a service -- for example, replacing a DIY SQL database with a DBaaS offering from the cloud provider but only turning off the original database application without shutting down the instance it is running on.
In addition to wasting money, these zombies can create security risks where operating systems go unpatched and configurations are not maintained, among others.
