“First, do no harm” ― Hippocrates
Today’s IT teams have a lot on their plate. Although unstructured data is growing by 35% per year, IT teams responsible for that data are seeing shrinking headcounts, budgets, and data centers (those data centers may not actually be shrinking, but they are definitely not getting any bigger). This is the fourth in a series of posts that have weighed the challenges and opportunities, as well as the benefits and drawbacks, that enterprise strategists, managers, and administrators need to juggle when it comes to moving workloads to the cloud.
In previous posts, we’ve gone through some of the common factors that enterprises must consider when deciding whether and how to integrate cloud services. We also covered the pros and cons of different strategies, and how to weigh those against each other to determine the best path forward for your enterprise.
In the next few posts in the series, we’ll analyze some common strategies for migrating data to the cloud, in the context of how to manage (and minimize) risk.
Before we start, it’s important to note that some enterprises are inherently more risk tolerant than others – and you need to determine what your business deems acceptable vs unacceptable risk.
This is influenced by the nature of your business and associated factors, e.g. whether or not you have regulatory deadlines or personal protected information (PPI) that needs to be safeguarded. In some cases, the consequences of not meeting regulatory deadlines, or of leaking PPI, are massive.
Imagine an insurance company that inadvertently violates HIPAA laws: the downstream effect can involve financial penalties, civil penalties, negative publicity, and possibly even criminal penalties. Financial, healthcare, insurance, and other heavily-regulated businesses will have a much lower tolerance for risk when it comes to systems, software, and architectural changes on par with a cloud migration.
The prospect of cloud compute and storage presents an interesting conundrum for many enterprise system administrators: the competing pressures of supporting the business’ need to innovate for the future, and the need to ensure that existing services and workflows stay online to sustain the business today.
A successful cloud-adoption strategy requires a careful balance: taking calculated risks to adopt new platforms and technology that deliver growth and innovation, while also keeping the lights on and the business running.
Unrealistic strategies
Before we look at what to do, let’s talk about what not to do. First among them: don’t take unnecessary risks when it comes to the apps that keep your business running.
Refactoring large applications
Many organizations will at least consider refactoring their critical file-based workloads to a cloud-native architecture. This entails rewriting the application to leverage object storage rather than file data. There are admittedly some long-term benefits to this approach – such as greater flexibility in cloud operations and tighter integration with some of the provider-specific cloud-native services available on AWS and Azure – but there are a few significant cons to keep in mind as well.
The upfront cost of this strategy is high. Depending on its size and complexity, you may be looking at a conversion cost of anywhere between 3-30 million dollars to rewrite a single app.
That’s right: upwards of 30 million dollars for one app. And that assumes it succeeds.
Which brings us to the flipside: not only is the risk of a large-scale failure very high, but in a worst-case scenario it can bring your entire business to a halt while the problem is diagnosed and corrected. And that’s just one failure: how many of those can your organization tolerate over the 2+ years it might take for the project to complete?
Recognizing risk in context
There are legitimate situations where the above scenario might actually be deemed as an acceptable risk. Consider the following:
Imagine that one of your business-critical, file-dependent apps has been purchased by a new vendor who has announced that it will be phased out and no longer supported as of a certain date. Suddenly, you’re in a position where you have to do something, any of which could end in failure and business disruption.
Maybe your organization relies on a third party app whose vendor has announced that the next version will be cloud native”. Whatever you and your organization feel about that announcement, the risk is there regardless, and it’s on you to minimize and mitigate it rather than try to avoid it.
Some larger business transformations can also offset the risk of moving to the cloud. If you are undergoing a large rebrand, or pivoting business models, then you a) are already at high risk of other failures but b) can maybe salvage some of the previous data that was historically kept on-prem by moving to the cloud.
In these cases, there are enough external factors that outweigh whether cloud migration is considered an acceptable risk to take on.
Those of you old enough to remember the Y2K bug have a perfect example of external factors that change the “acceptable risk” equation: one in which the risk of doing nothing was higher than taking action to re-architect, migrate, or replace even mission-critical legacy apps.
Admittedly though, the above scenarios are not likely to apply to most of you. When it comes to refactoring business-critical apps, a lot of organizations weigh the low likelihood of success against the high cost of failure, and rightly conclude that it makes more sense to leave the app where it is, and wait for the cloud to catch up.
Overdoing it
Another unrealistic strategy across any journey to the cloud is trying to move too fast. Not only will you break the application, you will be dead in the water until you can either revert back to your on-prem deployment or fix it forward in the cloud.
If you don’t slow down and take the necessary time to evaluate and test your applications thoroughly, you risk post-migration latency issues, data errors, and throughput shortcomings. Above a certain threshold, these might add up to a full migration failure. The risk of these errors occurring is significantly decreased when you put forth the time and effort that are necessary for a smooth transition from on-prem to the cloud.
So, what are the realistic strategies for moving workloads to the cloud? Stay tuned for our next installment to see what approaches we recommend.
James Walkenhorst is the Sr. Technical Marketing Engineer on Qumulo’s Product team. He has been working on and around NAS platforms and hands-on demo environments for 15 years, and spent the 10 years before that in IT operations as both an engineer and manager.
