Is Your Head Too High up in the Cloud?
There is no doubt that the cloud is here to stay and that it will be a part of every company’s future data and analytics strategy. However, knowing that the cloud is an important piece of the puzzle does not mean that companies aren’t making a lot of mistakes with cloud migrations and implementations. While there are many cloud success stories, there are also a lot of stories of frustration, missed deadlines, cost shocks, and lack of anticipated results. This blog post will discuss some of the common causes, which have nothing to do with technology and everything to do with poor planning.
Lacking an Understanding of Cloud Cost Structures
The cost structure of the cloud is fundamentally different than that of on-premise platforms, and the difference is not always guaranteed to be in favor of the cloud platform. Where any given company falls on that spectrum is tied to how well it understands the difference in cloud cost structure and how well it adapts its practices and protocols to account for it.
Charging for every CPU cycle and every piece of disk storage used is central to cloud models. On the surface, this sounds great. After all, why would you want to pay for resources you aren’t using? The problem is that a lot of on-premise high-volume processing isn’t very efficient. When you own the computers and they are sitting mostly idle at night, the incremental cost to have an inefficient analytical process execute is virtually zero. As a result, the common target for coding efficiency in an on-premise model is to get things efficient enough that they don’t interfere with other needs.
The “efficient enough” model makes sense when you own equipment and it has spare capacity. However, coding to that standard will rapidly consume your budget if it is done in a cloud environment. Therefore, code efficiency is more important than ever in the cloud. Unfortunately, many companies realize this the hard way after seeing huge and unexpected charges caused by simply migrating existing code as-is to a cloud environment.
Expecting New Technology to Fix Broken Processes
Another common error with cloud migrations is for companies to assume that moving to the cloud will in and of itself fix existing process issues. Most process issues aren’t about technology, but about the policies that surround the technology’s usage. For example, many companies struggle to keep an up-to-date inventory of all of the various analytical processes that are in place, what data they utilize, and what their output is used for. If the process for compiling this information isn’t meeting expectations in an on-premise environment, a cloud migration is simply going to shift the problem somewhere new.
It is important that organizations carefully consider which of their problems can be solved by a cloud migration and which can’t. For example, meeting intermittent needs for a massive amount of processing is easily addressed in a cloud environment but documenting the processes involved in that processing is not. There is no way around the hard work to understand what’s working, what isn’t working, and how to fix it. Many of the problems companies have that surround their technology implementations are far more process driven than technology driven. Disappointment is the inevitable result when it is recognized too late that a problem won’t be solved just by moving to a new platform like the cloud.
Allowing Career Goals to Impact Technology Roadmaps
One factor that can lead companies astray is the desire of key employees to accrue certain experiences on their resume. At the start of the big data era in the early 2010’s, implementing Hadoop was considered a prime resume builder. As a result, many technology executives chartered Hadoop projects as much to get one under their belt as to meet a clear corporate need. Today, the same pattern can be seen with cloud migrations. Every technology team member, from entry level to senior executive, wants to be able to say they were a part of a cloud migration.
That is not to say that most companies shouldn’t move to the cloud, nor is it to say that the intentions of those sponsoring the projects are always corrupt. The impact of this issue is typically more along the lines of moving things a little too fast with too little planning in order to get the cloud migration box checked sooner than later. If having a cloud migration on a resume wasn’t so appealing, many organizations might be more methodical and cautious in their approach.
Assuming Fast, Successful Deployments as a Default
Many companies have historically struggled to fully deploy data and analytics processes over the years. While there are tools in the cloud that facilitate deploying processes, it still isn’t a simple matter to deploy complex analytical processes in the cloud. As discussed above, there are technical as well as process barriers to successful deployments. If a team hasn’t been effective with deployments in a traditional environment, don’t assume the cloud will solve that problem just because the cloud has a lot of native tools to help.
A rational approach is to recognize that the tooling available in the cloud can help streamline and standardize deployments. However, it is still necessary to have a process and to maintain discipline when deploying. Realistically, the first deployments done on the cloud will probably go even slower and less smoothly than in the past as teams get to know the new cloud environment and its new protocols. Don’t look past that learning curve.
Change Your Thinking To Succeed
One new technology that can help make a cloud migration successful is to implement a data operating system such as DataOS from The Modern Data Company. A data operating system provides a single, up-to-date view of all systems from one place, whether cloud or otherwise. It inventories all available data, applies security and governance protocols, and routes data requests and queries properly across the underlying systems. As legacy systems move to the cloud, simply redirect the data operating system to the new location and users will see a seamless transition.
A data operating system also helps with the problems outlined previously in this blog post. While a data operating system won’t change the cost structure of the cloud, it will provide additional visibility into what requests are being sent to any given cloud instance and how that data is being combined with other data. This will help an organization understand its cloud usage better. Similarly, a data operating system won’t magically fix broken processes. However, it does make it easier to track, tune, and manage them. It will also ease deployment challenges since new processes can be deployed from a central location. Last, while it can’t stop people from doing things for resume enhancement, implementing a data operating system is itself a positive resume builder. So, for those sensitive to such things, implementing a data operating system will be appealing for that reason even as it provides other benefits.
To learn more about how a data operating system like DataOS can help your organization modernize its systems and end user functionality, download our e-book Maximize Your Data Transformation Investments.
