Portworx sponsored this post.
The number of available options for application deployments and maintenance, whether on-premise or in cloud environments, spells great opportunities. But as microservices, Kubernetes serverless platforms and other options are thrown into the mix, issues of how to manage the enormous complexity involved obviously emerges. A key concern for DevOps, among others, is creating best practices and processes for backups and disaster recovery (DR) in this context.
“People are still more in learning mode. Now, people have deployed their applications and they’re dealing with real-world problems operationally, and not necessarily issues, but best practices about ‘how do I do this?’” Rao said.
DR is not a new concept but is a topic that is being revisited in the context of cloud native applications and Kubernetes, as applications become more complex and are inherently distributed in nature, Rao said.
The first example of this new complexity and added challenge for DR involves how application stacks are often no longer monolithic packaged in one machine, Rao said. “So, right there, if your backup strategy is to back up one machine then that goes out the window. So, the notion that these applications are inherently distributed, service-oriented and have interdependencies with other components running on other systems represent one pillar of complexity.”
Applications are also potentially running in different clouds. In this case, part of an application may need to access specific parts of cloud services that a cloud provider provides, Rao said. A machine learning application, for example, may have a segment of an application that needs to access GPUs in a public cloud provider.
“The entire application does not need to use that. So, your application is [using] different parts of infrastructure,” Rao said. “That adds a second pillar of complexity.”
The third “pillar of complexity” typically involves “what people do when they build a cloud native path” as infrastructure for multiple tenants, Rao said. “In other words, you are not setting aside a particular Kubernetes cluster for a business department or a specific user — you are typically hosting many different applications for many different users who may have different DR practices or requirements,” Rao said.
The fourth and final layer of complexity involves “this notion of self service,” which is “becoming really important,” Rao said. “As an application owner, you do not want to rely on somebody else or have this ticket in the process to trigger a data recovery or an application-continuity request,” Rao said. “You want to be able to manage that yourself.”
Most of the time, the user in this case is not trying to recover data during a disaster but is, instead, “probably just iterating to an application development rapidly and you want to rollback certain components,” Rao said. “And so, this notion of self service is becoming real — which was not really the case when you think of traditional machine-centric DR,” Rao said. “So, these four things, in my opinion, are starting to crystallize certain common requests that I see customers asking vendors, for ecosystems about how to handle this.”
Consequently, new types of service models are emerging for DR and backups. The platform operator might “say ‘here is a Kubernetes platform and your user interface and how you can logon to launch your application — and I will make sure your application can run and will manage the infrastructure,’” Rao said. “And along the same lines, backups and DR are provided.”
At the same time, many users today have multiple Kubernetes clusters running for continuous asynchronous DR purposes, for example. “If a cluster does go down, you can cut over to a second cluster,” Rao said. “That has been a big topic and we’re a lot of multicloud discussion has been about recently.”
In this Edition:
2:09: What are the data recovery issues that you need to start to be thinking about, and how are you making sense of them from a people perspective?
5:46: How are you seeing teams starting to adapt?
12:23: Data security, backup, recovery, and how CSI fits with that story.
17:33: What are the tools that are emerging in the open source ecosystem and what are the initial use cases you’re seeing?
20:29: What is that necessary grammar?
25:20: How do you view your participation in the community if these issues are so critical they should not be taken lightly?
Feature image via Pixabay.
The New Stack is a wholly owned subsidiary of Insight Partners. TNS owner Insight Partners is an investor in the following companies: Real.