Author: Michael Cade, Global Field CTO Cloud-Native Product Strategy, Veeam
What many developers still need to understand about protecting containers
Despite it still feeling like ‘the new toy’ for many development teams, container technology has been around for some time. But it wasn’t until the rapid evolution of container-based applications in recent years that businesses started deploying these environments en masse. In fact, recent reports suggest that we are approaching a tipping point in container usage.
However, these insights also reveal that the way the majority of businesses are protecting their containers is still unfit for purpose. In fact, recent findings suggest that Kubernetes (K8s) clusters belonging to more than 350 organisations, (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 described the container market as “red hot”. Nearly half (47%) of businesses reported that they are using containers currently, while 35% are planning on doing so in the next 12 months. If those plans all become reality, that’s 82% of organisations using containers by the end of 2024.
It’s a common conflation that containers equal Kubernetes. While this isn’t accurate, as it’s simply a platform for managing containers, the report indicates it is becoming the standard. Currently, 66% of organisations use it to manage and orchestrate their containers. Essentially, it’s a product name that’s become so widely used that it’s now synonymous with the thing itself, like JCB, Kleenex or Frisbee.
But “red hot” is an apt way to describe current container usage in more ways than one. With current practices, far too many businesses risk getting burnt. According to the same report, less than half of companies that have implemented containers made data protection part of the architecture design process. Instead, 19% only considered how to protect their containers after implementation was complete and perhaps worse, 33% just carried on using existing data protection tools and processes. This is symptomatic of the knowledge gap around containers and Kubernetes and, in some cases, data protection in general.
Time to move on
Let’s tackle the worst problem first. According to Enterprise Strategy Group, a third of organisations using containers still use the same data protection tools and processes as they would have on a ‘normal’ application. This is ineffective for several reasons. While traditional backup solutions focus primarily on Virtual Machines (VMs) or file-level backups, Kubernetes demands a more nuanced approach, given its dynamic and cloud-native nature. Backing up a container-based environment with a traditional backup solution is like trying to take a snapshot of a city with a photograph. Sure, you might capture the buildings, but you won’t have a sense of the flow of traffic, or what’s happening inside or underground.
But if that’s the case, why are organisations doing it? In most cases, it’s simply an awareness problem. Businesses think the solution works. After all, they have backups so they don’t see the difference until something bad happens like a cyber-attack. As soon as they try to recover the container-based environment using this backup, they realise that their image-based backup can’t ‘see’ the K8s clusters. A traditional solution will only backup the VM that holds the containerised environment, leading to all kinds of potential issues including incomplete backups, inconsistent states, inefficiency, and security gaps, to name a few.
Data protection from/by design
So, understanding the need to protect containers with a system that understands containers is the first mental hurdle that needs to be overcome. But there’s one more hurdle before the finish line. When implementing Kubernetes, data protection needs to be part of the plan from early design phase on. There’s a long list of reasons for this, but it comes down to the efficiency of resources (in computing and financial terms), the opportunity to test and validate, and most crucially of all – ensuring reliable and fast recovery. In reality, backup is the easy part, it’s the recovery that’s hard. Building with recovery in mind against clear KPIs, namely Recovery Point Objective (RPO) and Recovery Time Objective (RTO), are essential. However, this is infinitely easier to achieve when it’s part of the plan from day one.
With nearly one in five organisations making this mistake, this is an age-old problem for a new technology. If we look back ten or twenty years ago to when organisations were protecting their physical servers, the technical details have changed but the reason for the problem stays the same – backup is ‘tiresome and boring’. It’s like looking at the airbags when building a new sports car – no one’s in it for the airbags although they are often life-savers. As such, there’s a risk no one thinks about them in the early development stages. But if you’ve built that chassis and added a high-tech dashboard, putting that final safety measure in is going to be much more expensive than it needs to be.
That isn’t to say: “If you haven’t thought about it yet, don’t bother.” Organisations need to have proven and tested backup and recovery plans in place. According to the Veeam Data Protection Trends Report 2023, 85% of organisations suffered at least one cyber-attack in the preceding twelve months; an increase from 76% experienced in the prior year. One way or another, you need to be “Left of Bang”. If that work is being done after the design of a containerised environment it may take some redesign and refactoring but that’s better than the alternative of being unprepared during a successful ransomware attack. As the proverb goes: The best time to plant a tree was 20 years ago. The second best time is now.
