Software containers are at the heart of cloud-native business transformation initiatives. Containers are a natural evolution from virtual machines to a more granular and portable application environment in clouds. They are designed to support rapid development and deployment of cloud-native applications in what is called a DevOps model, a set of practices that combines software development and IT operations.
DevOps teams use container orchestration platforms to automate the lifecycle of scheduling, deploying, networking, scaling, monitoring, and managing containers. Kubernetes and variants like Red Hat OpenShift have become the de facto standard for container orchestration, with most leading commercial vendors providing a public cloud service or a multi-cloud management platform based on Kubernetes. In many companies, IT organizations are just starting to catch up with the DevOps teams to support the initial deployment and management of container-based, cloud-native business applications.
And as with any new technology platform, Kubernetes has its strengths and weaknesses, the latter in the areas of data protection and disaster recovery. IT leaders will need additional data management tools such as a Kubernetes backup service to provide the same level of application-consistent data protection and disaster recovery for their serverless databases that they provide for their server-based database applications today.
This blog series will walk you through most, if not all, aspects of Kubernetes and cloud native application data protection, beginning with…
1.0 The need for Data Protection for Containerized Applications
Kubernetes lets us run containerized applications at scale while saving us from getting bogged down in the maddening complexities of infrastructure management, application deployment, and scalability of applications. It allows us to focus on building our applications and have “infrastructure as code” dictate the specifics of their deployment and operation. However, this newfound flexibility doesn’t come without its own set of potential risks, pitfalls, and headaches
While Kubernetes is designed to provide a zero-downtime deployment environment, certain service interruptions, be they catastrophic events or other, less disastrous, eventualities may be totally out of its control or ability to protect against. To protect the application from certain failures, we must rely on traditional data protection methods including snapshots, replication, and backup copies. The snapshots and backup copies act as a form of “insurance” when disaster strikes, but they can be useful in other situations as well.
Now, let’s explain some of the scenarios where backups, and more importantly recovery, can come in handy:
- Human error
…such as unintentional and accidental deletion or overwriting of the namespace where your deployments reside, leaving you unable to recover the environment.
…can result in the deletion or modification of configuration and application data. Unlike problems caused by failures or human error, changes caused by security breaches can be subtle and difficult to detect, leaving you the unenviable task of trying to figure out what changed and when.
Backups can help you replicate your existing Production environment to development, test, or staging environment for QA, builds and updates, etc.
Kubernetes Cluster Migration
Backups are critical from a migration preparedness perspective. Whether moving physical equipment or only bits, before moving your K8s cluster from one environment/location to another, you will want to make sure you have comprehensive backups of your current environment. Even if your old environment is left in place, don’t rely on it being the “source of truth” for the new one. It wouldn’t be the first time that an ops person with too much work and too little sleep made a change to the old environment instead of the new. It might even be you!
Natural disaster and Hardware Failure
Natural calamities such as hurricanes, flooding, wildfires, and earthquakes can destroy built-in redundancy and protection against isolated hardware failures, and backups are required to bring back the lost data and, in turn, the application to the original state.
- Where maintaining backups of the applications are necessary not just for tactical purposes, but for regulatory guidelines and compliance reasons such as PCI DSS, HIPPA, SOX.
All in all, containers are a more efficient way of architecting your application to, using doesn’t obviate the need for backups. Container orchestration systems like Kubernetes and OpenShift have progressed to support data persistence, synonymous with importance – and data protection. Nevertheless, it is important to know ‘what to back-up’.