DUBAI — Despite still feeling like “the new toy” for many development teams, container technology has been around for a while. However, it wasn’t until the rapid evolution of container-based applications in recent years that businesses began deploying these environments on a large scale. In fact, recent reports suggest that we are nearing a tipping point in container usage.
Yet, these insights also reveal that the methods the majority of businesses use to protect their containers remain inadequate. Recent findings indicate that Kubernetes (K8s) clusters belonging to more than 350 organizations, including several Fortune 500 companies, are currently “openly accessible and unprotected.” So, what are businesses still getting wrong here?
Two steps forward and one step back: A 2023 report from Enterprise Strategy Group characterized the container market as “red hot.” Nearly half (47 percent) of businesses reported that they are currently using containers, while 35 percent plan to do so in the next 12 months. If those plans materialize, that’s 82 percent of organizations using containers by the end of 2024.
It’s a common misconception that containers are equivalent to Kubernetes. While Kubernetes is merely a platform for managing containers, the report suggests it is becoming the de facto standard. Currently, 66 percent of organizations use it to manage and orchestrate their containers. Essentially, Kubernetes has become a brand name so widely recognized that it’s now synonymous with the product itself, much like JCB, Kleenex, or Frisbee.
But “red hot” aptly describes the current state of container usage in more ways than one. With prevailing practices, far too many businesses are at risk of getting burned. According to the same report, less than half of the companies that have implemented containers included data protection in the architecture design process. Worse yet, 19 percent only considered how to protect their containers after implementation was complete, and a concerning 33 percent continued using existing data protection tools and processes. This reflects a significant knowledge gap around containers, Kubernetes, and, in some cases, data protection at large.
Time to move on
Let’s address the most significant issue first. According to the Enterprise Strategy Group, a third of organizations using containers still rely on the same data protection tools and processes they would use for a ‘normal’ application. This approach is ineffective for several reasons. While traditional backup solutions are primarily designed for Virtual Machines (VMs) or file-level backups, Kubernetes requires a more nuanced approach due to its dynamic and cloud-native nature. Using a traditional backup solution to protect a container-based environment is akin to trying to capture the essence of a bustling city with a single photograph. Sure, you might capture the buildings, but you won’t get a sense of the traffic flow, or what’s happening inside or beneath the surface.
But if that’s the case, why do organizations persist with this method? In most instances, it boils down to a lack of awareness. Businesses assume their solution is effective because they have backups, so they don’t recognize the deficiency until a disaster occurs, such as a cyber-attack. Only when they attempt to restore the container-based environment using these backups do they realize that their image-based backup can’t ‘see’ the K8s clusters. A traditional solution will only back up the VM hosting the containerized environment, which can lead to a host of problems, including incomplete backups, inconsistent states, inefficiency, and security vulnerabilities, just to name a few.
Data protection by design
Understanding the necessity of protecting containers with a system that is container-aware is the first mental hurdle to clear. But there’s another hurdle before reaching the finish line. When implementing Kubernetes, data protection must be integrated into the plan from the early design phase. There are numerous reasons for this, but it essentially boils down to resource efficiency (both computational and financial), the opportunity for testing and validation, and most importantly, ensuring reliable and swift recovery. In practice, backup is the straightforward part; it’s the recovery that’s challenging. Designing with recovery in mind, with clear KPIs such as Recovery Point Objective (RPO) and Recovery Time Objective (RTO), is crucial. However, this is infinitely more manageable when it’s incorporated into the strategy from the outset.
With nearly one in five organizations making this oversight, we’re seeing an age-old problem reemerge with new technology. Looking back ten or twenty years, when organizations were safeguarding their physical servers, the technical details have evolved, but the underlying issue remains the same—backup is often seen as ‘tedious and dull.’ It’s akin to considering the airbags when designing a new sports car—no one is enthusiastic about the airbags, even though they can be lifesavers. Consequently, there’s a risk that they’re overlooked in the early stages of development. However, if you’ve already built the chassis and installed a high-tech dashboard, retrofitting that crucial safety feature will be much more costly than if it had been included from the start.
This isn’t to say, “If you haven’t thought about it yet, it’s too late.” Organizations must have proven and tested backup and recovery plans in place. According to the Veeam Data Protection Trends Report 2023, 85 percent of organizations experienced at least one cyber-attack in the previous twelve months, an increase from 76 percent the year before. One way or another, you need to be “Left of Bang”—that is, prepared before an incident occurs. If the necessary work is done after the design of a containerized environment, it may require some redesign and refactoring, but that’s preferable to being unprepared in the face of a successful ransomware attack. As the saying goes: The best time to plant a tree was 20 years ago. The second-best time is now.
Michael Cade is Global Field CTO Cloud-Native Product Strategy at Veeam.
The opinions expressed are those of the author and may not reflect the editorial policy or an official position held by TRENDS.