In a cross-industry survey of over 350 IT decision-makers at small, medium, and large U.S. businesses, more than half of the respondents said costs of running workloads in the cloud were higher than estimated – sometimes triple than what was expected.
For example, just this March, NASA discovered that as part of a “Cloud First” policy, migrating their Earth Science Data and Information System (ESDIS) to AWS would cost approximately $30M MORE than budgeted as they did not factor in costly egress charges for every time a scientist downloads its data.
It’s a common story: IT departments globally want to migrate applications to the cloud under a preconceived notion of cost saving, to be free from infrastructure management, and to place legacy relics on a modern system. Moving applications and their associated data from physical infrastructure to limitless, accessible cloud servers has the potential to solve many challenges.
However, as NASA and many others have found, cloud migration was not the panacea they had hoped for.
Moving applications into the cloud doesn’t magically enable efficiency or lead to a reduction in spending. It is simply just transferring the application with all its existing inefficiencies to a new location. Without careful characterization of the application and an audit of usage and technology improvements, lift and shift could lead to higher bills, slower applications, more risk, and increased costs.
For applications with significant data storage, data egress charges can be particularly tricky. While cloud storage can appear to be a very cost effective choice, pulling it back out with any frequency is very costly and is a new cost that teams typically have not modeled accurately as it doesn’t exist within the confines of private infrastructure. Under the initial charter to reduce costs, NASA fortunately discovered this oversight before they expanded their archive from 32PB to 247PB that would have potentially exhausted their budget.
While a “lift and shift” approach offers a potentially valuable tool in the modernization and migration process, it has clearly not always served as the best solution for every application. Enterprises must carefully consider all of their cloud migration options for each application individually.
WHY DO ENTERPRISES CHOOSE TO LIFT AND SHIFT TO THE CLOUD?
Migrating applications and data to the cloud appears appealing for agility that the elasticity and scale of cloud can provide, simplifying capacity planning. There may also be motivations to shift expenses to a purely OpEx model. This can be a good fit for applications or data that are on average lowly utilized or may be bursty with exceptionally high peaks that must be serviced. For such applications, lift and shift may offer the potential benefits of:
· Increased agility
· Less resource and labor-intensive
· Cheaper
Many applications can benefit from these promised advantages, at least to a degree. However, lift and shift of applications has other considerations that can impact an organization’s decisions.
WHAT SHOULD ENTERPRISES CONSIDER BEFORE DECIDING ON A LIFT AND SHIFT PROCESS?
A lift and shift decision might seem straightforward at first glance. The reality is that a successful shift to a cloud-based or hybrid environment requires a plan that answers crucial questions, for example:
How mission critical is the application and the data to the organization?
Mission critical applications in the enterprise already have a well defined set of implementation practices to secure, ensure integrity and have sufficient distribution. Equivalent policies must be applied in the cloud. What would the ramifications be of losing the data, or having application/data compromised or unavailable?
Are the applications bursty in nature or constant?
While bursty applications should be a good fit for the cloud, the utilization threshold for getting meaningful savings may vary depending on the current platform hosting the application, the extent of usage burstiness, the amount of overprovisioning that has been done and the cloud services used. There is no cookie-cutter answer.
How frequently and how much data needs to be accessed?
Cloud storage can be a great option for preservation, retention, and temporary storage where egress charges are minimal. Over time, storage needs are monotonically increasing, making it incrementally more difficult to move elsewhere due to data gravity. Ultimately the economics depend on the application architecture. If data gravity is heavy, cloud storage can be analogous to a perpetual lease where payments continue forever and the price increases every month and egress charges present a surprise expense on top of that.
Who will administer the applications in the cloud (i.e. evaluate local/cloud workloads, monitor usage, optimize workflows, validate policies, etc.)?
The cloud, like any other tool, must be well understood and optimized for the advantages it brings. This requires ongoing monitoring of how applications operate, how cloud resources should be optimally configured and how cloud services are charged.
Applications that may not be a good fit for the cloud include:
- Active Archives: unlike archives strictly for retention and preservation which are considered “cold” data, active archives are multi-petabytes in size requiring fast access and cost-efficient retrieval (i.e. egress charges can be enormous in the cloud.)
- Applications that generate large amounts of data outside of the cloud.
- Applications that have stringent performance requirements for systems control.
- Applications where compliance or other business requirements are high-priority.
Also in the process of considering cloud migration and assessing the true amount of storage and compute it might need, many organizations uncover complicated fragmentation, duplication, incomplete or outdated records, and zombie servers. Creating a domino-effect of issues that need to be solved before lift and shift even begins.
Lastly, does an organization have the opportunity to “test” out an environment to see if their organization can even support it?
It may make sense for teams to try out environments and develop in the cloud where they can take advantage of elasticity for something that hasn’t been quantified or benchmarked. Once the environment and apps are benchmarked, organizations can see if they want to “rent vs. buy”. At the end of the day, migrating to the cloud is just running your stuff on someone else’s infrastructure, so it comes down to how much trouble you save by doing so.
It’s not enough to simply migrate to the cloud and check off a box that says, “We’ve migrated.” The NASA example demonstrates that without a thoughtful approach in place, organizations run the risk of trading their current infrastructure for the cloud’s infrastructure. In the end, they could miss out on the most promising cloud computing benefit: more efficiency.
WHAT ARE SOME COMMON MISCONCEPTIONS ABOUT LIFT AND SHIFT?
Some common misconceptions about lift and shift and cloud computing in general include:
APPLICATIONS WILL WORK THE SAME, OR BETTER IN THE CLOUD.
Lift and shift is a practical, pragmatic approach. Cloud is as much an operating model as it is a technology. Organizations that find success with cloud adapt their operating process to fully leverage cloud principles.
But lifting and shifting will not magically fix poor architecture.
Sometimes, organizations expect a cloud migration to inherently improve efficiency and functionality across the board. The truth is that any issues that existed on-prem will continue on the cloud. You can’t just move complex applications to the cloud and expect to be done.
Once a workload has migrated, the work is really just beginning.
“Lifting and shifting an application to cloud exposes all the gaps in understanding, links, security, and performance issues in ways that are difficult to understand prior to the move. The very term lift-and-shift denotes a failure to plan or a reactionary move. You can’t expect regular success from reactionary modifications to complex systems,” Mark Thiele, Technical Standards Chairman for the International Data Center Authority.
LIFT AND SHIFT MIGRATION WILL COST LESS.
“Unless clear cost savings can be realized, moving a legacy application is generally not a good use case [for cloud migration],” Gartner.
It is unlikely an IT team managing proprietary legacy applications will quickly shift to running an entirely new environment in a heartbeat. An investment in your workforce, third party services, training, and additional hardware and/or software may become a necessity even with a move to the cloud.
In one example from IBM, a company budgeted $10 million for a one-year migration from a mainframe to a distributed environment. Eighteen months into the project, the company had spent $25 million and only managed to shift 10 percent of the workload. In addition, it had to:
• Increase staff to cover the over-run
• Replace existing automation tools with cloud based automation tools
• Acquire additional distributed capacity over the initial prediction, even though only 10 percent had been moved so far, and
• Extend the dual-running period at even more cost due to the schedule overrun
Many applications, especially those processing big data and image rendering, are not good candidates for lift and shift – for the reasons we highlighted above. The lift and shift approach is more appropriate for commercial, off-the-shelf applications with easily defined patterns.
Lastly, as we have already mentioned, there can be expensive data transfer costs into and out of the cloud. This is the leading stealth expense for IT teams who have migrated to the cloud and could not accurately forecast changes in pricing models or just how much they would incur in egress charges as this never was a consideration before with their on-prem architecture.
LIFT AND SHIFT TO THE CLOUD MAY NOT BE ALL IT’S CRACKED UP TO BE
More and more organizations have found their cloud migration experience to be similar to the NASA or IBM examples provided above. As a result, organizations are considering how to bring these workloads back home.
Private cloud has advantages the public cloud can’t match when it comes to controlling spiralling costs, the ability to leverage your choice of hardware without vendor lock-in, and reduced operating expenses.
In response, cloud operators are now offering on-premise solutions that could address small scale workload deployments, but are not cost-effective at scale and do not address customer concerns that have been raised as a result of their experiences.
When you have ticked through the considerations we’ve shared and come to the conclusion that a private cloud, on-prem infrastructure is better suited for your application, Platina’s turnkey services help you realize the value of a private cloud by:
- Enabling intelligent decoupling of your physical infrastructure without fear of vendor lock-in or hidden costs, handling the networking, and then converting your infrastructure stack into a workload-ready cluster of resources.
- Simplifying and automating application deployment operations, auto-configuration, and monitoring.
- Providing cost-effective infrastructure orchestration and management that enables quick access, retrieval, and unification of large amounts of data from across multiple storage technologies for easier application management.
- Simplifying troubleshooting via a single pane of glass for an application cluster.
- Centralized management for policy management, visibility, and insight across all of your clustered pools of compute, storage, and networking resources.
Learn more about how we are empowering organizations to realize the promise of private cloud computing.
.svg)
.svg)
