The Cloud Tiering Fallacy: Four Key Points to Consider

The Cloud Tiering Fallacy: Four Key Points to Consider

This is part of Solutions Review’s Premium Content Series, a collection of contributed columns written by industry experts in maturing software categories. In this submission, Nasuni Chief Product Officer Russ Kennedy offers commentary on the cloud tiering fallacy through four important points.

SR Premium ContentOftentimes technology gets hyped and doesn’t measure up to all the marketing. That’s the case with tiering to the cloud from on-premises arrays, a common offering among traditional storage vendors.

There’s some innovation missing in this space as vendors aim for relevancy by offering new cloud features on old hardware. It’s an approach we saw long ago in Information Lifecycle Management (ILM).

Although cloud tiering may in fact just be about marketing, it really refers to an effort to manage capacity. Companies may rely on tiering, but when they concentrate on syncing data instead, they’ll become more efficient and build out scale.

Understanding Syncing and Tiering in the Cloud

For decades the tech industry has grappled with the concept of tiering and the plan to move data from the front end to the back end. Turns out that the cloud is considered the target at the back end. Don’t compare the cloud, though, to old-fashioned storage media. We’d like to see technology that uses unlimited, on-demand low-cost capacity revamped for an innovative new storage format. We need a new strategy in the cloud, not one that is decades old. It would not involve tiered cloud infrastructure but syncing data to the cloud.

You might wonder how syncing differs from cloud tiering. Well, think of it as a difference between something that requires close monitoring and something that’s simply a good fit from the start. One option is left over from another cloud era, and the other is built for the unlimited object store available in the cloud.

Either way, both models of working originate from the same strategy. Whether you are tiering or syncing, you still must leverage cloud storage and deal with the capacity limitations that local hardware presents. Volumes on standard NAS devices bring limitations. Although you can thin out volumes and use unlimited, cost-effective capacity when you tier in the cloud, it’s not simple, incremental or granular.

Cloud Tiering Presents Operational Challenges

When you build a tier, you must be prepared for the overhead that’s required and ensure that everything ends up at the back end. In fact, tiering means large, bulky sets—a directory structure or a large file volume. That’s not a sign of robust data protection: The data has likely disappeared or at a minimum becomes inaccessible if the front-end device disintegrates before you tier.

When you build large data sets in the cloud, one vendor, NetApp, notifies you that you can consolidate various back end volumes behind one volume. Again, cloud tiering and namespace aggregation make sense in a marketing brochure, but in reality, it’s a large inconvenience for the person managing the system. The process entails fabricating volumes and filling them up. Then you face a decision on whether to tier or build a new volume while aggregating on the back end.

Expect that accessing data from the tier can disrupt applications. Try maintaining volumes for snapshots, servers, VMs and more due to sensitive applications. Keep in mind that complexity goes along with a capacity increase and complexity scales with growth. And that’s not technology at its best.

Why Syncing to the Cloud Works

You can flip this strategy on its head by syncing to the cloud, where everything is always streamed to and managed on the back end. The cloud is the source of truth, and automated caching keeps the front end full of active data. Syncing is akin to using very large trucks to transfer data from the front to the back. And the trucks don’t deliver to their route until they’re all full. Contrast that with a sync-based file storage system, which operates more like a high-speed conveyer belt. Data is continuously moved to the cloud back end, creating an unlimited cloud volume rather than a continuously growing number of data sets that have been loosely aggregated.

Picture a sync model where data is always required at the edge. The data travels back in real time upon an end user clicking on that file. The granular process occurs automatically whether you’re working with a large CAD model or a sub-file-level asset.

With data already committed to the source of truth, deletion at the edge is convenient and fast. The goal: uniform performance everywhere. And that’s what an operator strives for when managing an infinite volume. No decisions need to be made as far as what’s stored in the edge vs. the back end. The system handles it automatically. And that’s an added plus when it comes to operations.

It’s All About Scale

Semantics come into play when you consider what is cloud and what is not. Traditional storage vendors believe their tiering technology is the cloud. That’s not the case. NetApp gets props for spinning their controllers in the cloud, but their systems cannot take advantage of cloud scale. They were built and optimized for local machines.

Think about what a system truly built for the cloud would entail. It must scale to infinity without added difficulty or requirements of building new volumes or meticulously monitoring regular movement of data from one tier to the next. The beauty of a real cloud system is in automation. It handles all of this for you, so you won’t have to think too hard about data protection or capacity.

It’s all about scale. If scale brings more complexity, a system could fail. With cloud-native file systems built to sync data, you’re able to scale without the usual complexity. And that means operating as smoothly with a single site as you would across an entire global enterprise.

No hype, no magic. It’s just what advanced technology does.

Russ Kennedy
Follow Russ
Latest posts by Russ Kennedy (see all)