5 Ways Data Protection for Kubernetes Is Different


What are the differences between Kubernetes Data Protection and the more traditional data protection offerings, even though such products address virtualization and cloud scenarios as well as traditional on-premises data protection?

Here are five notable differences between such products – differences that go beyond privacy and highlight some of the fundamental strengths of cloud native computing in general.

Difference #1: Metadata-centric privacy vs. data-centric privacy

At the heart of data protection is the backup and restore feature. Data protection is more than these two functions, but without backup and restore there is no protection at all.

In traditional environments, which for the purposes of this article encompass virtualization and cloud as well as various on-premises environments, backup and recovery focuses on persistent data and the storage that contains it.

Kubernetes data protection, on the other hand, focuses on metadata and the underlying data.

Kubernetes is essentially a declarative, configuration-based container orchestration platform. Providing privacy for these configurations and other metadata, including resource definitions, Helm charts, and other files, is central to the Kubernetes privacy challenge.

Difference #2: Dynamic policies for auto-discovered applications vs. static policies for predefined applications

Setting up a traditional data protection application consists of setting up a set of backup and recovery policies that apply to the various assets that the organization wants to protect. Such policies generally focus on snapshots and backup schedules.

Also Read :  Privacy-enhancing tech eyes tapping financial, healthcare firms in Philippines for stronger data privacy, protection

In Kubernetes, applications and their microservices components are inherently ephemeral—they scale up and down all the time, appear occasionally, and disappear altogether.

A Kubernetes data protection product such as must therefore automatically discover applications on the fly in order to know which data and metadata need to be protected. The policies that drive such protection must be suitably dynamic.

Dynamic policies exist on an abstraction layer over static ones, and the underlying technology must interpret them in real time to apply them correctly in every situation.

Difference #3: Dynamic, policy-driven automation vs. static, manually configured automation

When the Kubernetes environment interprets and applies policies, it is actually automating workflows that set those policies.

Traditional data protection technologies also offer policy-driven automation, but those automations are as static as the policies themselves.

Kubernetes therefore requires a rethinking of what automation means — instead of a simple flowchart of “do this, make a decision, and do that” logic, cloud-native automation is inherently dynamic, with logic that changes from moment to moment can.

This revised automation term applies to both data protection and other Kubernetes automation scenarios.

Difference #4: Application-Specific vs. Volume-Specific Data Protection

Since traditional data protection focuses on data and storage, operators logically focus on backing up and restoring databases and storage volumes.

Also Read :  US chip ban to hurt TSMC, Korean plants in China

In fact, volumes are the common denominator for all traditional data protection, since backing them up and restoring them means backing up and restoring everything stored or installed on them, including databases, files or application components.

Kubernetes, on the other hand, maintains a comprehensive, declarative abstraction of the entire persistence layer.

Kubernetes applications are inherently stateless due to the ephemeral nature of their components and the stringent performance requirements that apply to such applications.

Still, Kubernetes applications typically need to maintain state without impacting these core characteristics. The platform overcomes this challenge through configuration-based abstractions.

This abstraction-based state management means that Kubernetes data protection cannot happen at the volume layer. Instead, it must take place at the application level, since only applications know what data they need and when. Storage details have been completely abstracted.

Difference #5: Application Recovery vs. Data Recovery

The most important principle of data protection is that your backups are only as good as you can restore them.

While data recovery represents most of the traditional data security recovery story, Kubernetes recovery involves a complicated combination of recovering the data, resources, and configuration components that make up a running application.

Also Read :  Test beds, workforce critical to U.S. technology leadership

Such recovery involves the automated orchestration of multiple dynamic, policy-driven tasks—a tricky endeavor, as the goal of such recovery is not just to avoid data loss, but rather to keep applications running in production while minimizing the disruptive impact to users of these applications.

Once you understand the full complexity of such automations, it becomes clear why Veeam took over Kasten. Delivering the full value proposition of Kubernetes for data protection like the Kasten K10 data management platform does is no easy task.

The Intellyx recording

Highlighting the differences between traditional and Kubernetes data protection inevitably highlights the differences between traditional and cloud-native computing.

Cloud-native infrastructure requires a rich declarative abstraction layer that abstracts storage and data and enables stateless application behavior while managing state.

A key benefit of this cloud-native approach is a clear distinction between the control plane and the data plane—the configurations that govern application behavior versus those that affect the movement of data.

Data protection must work at both levels: first, when data is moved as part of the backup and restore processes, and second, in the broader data protection history that occurs as part of the automated orchestration that drives application behavior.

group Created with Sketch.



Source link