Ever since Docker popularized the concept of containers, there has been all manner of organizations whose stated aims have been to reinvent a particular part of infrastructure for the new, container-centric world. In Weaveworks case, it’s a case of reinventing networking for containers. For Portworx it’s about storage. For Twistlock it’s about security. These companies, depending on which way you look at it, have either identified a very real hole or jumped onto a bandwagon.
Given that Kubernetes is now the choice of the new, new generation (didn’t get the memo? Suffice it to say that all the cool kids have decided that Kubernetes is the ship to jump on) it should come as no surprise to hear that, similar to the way the three examples above came to fruition for the new Docker-centric world, a host of organizations are doing the same for Kubernetes today.
And so it is with Kasten, a new company emerging from stealth that aims to manage stateful containerized applications at scale. If that sounds familiar, it is because Portworx (and, prior to its demise, ClusterHQ) wanted to do the same thing. But before diving into just why Kasten thinks that managing data for Kubernetes applications is in any way different to managing it for regular containerized applications, it’s worth taking a look at what Kasten is.
The company is behind two things, the K10 commercial platform, and the Kanister open source project. Kanister is an extensible framework for application-level data management while K10 is a broad-based platform for the management of stateful container-based applications. According to the company, despite only emerging from stealth today, Kasten K10 and Kanister are used by enterprises, including a top 10 retailer in Europe and a leading global telecommunications provider.
Kasten was founded by Niraj Tolia (CEO) and Vaibhav Kamra (VP of Engineering), who bring experience in the areas of containers, Kubernetes, storage, and distributed systems from their previous experience at Maginatics (acquired by EMC), Dell EMC, HPE, and Microsoft. Tolia speaks to the rationale for Kasten when he says that:
Kasten was founded to solve the data management pain we experienced firsthand in working with stateful applications in containerized environments. Kasten’s mission is to eliminate the friction and adoption roadblocks observed with enterprises when working with persistent state in container orchestration platforms such as Kubernetes. Our application-centric K10 platform has been purpose built to bridge both the tools and DevOps gap and reinvent cloud-native data management for the enterprise.
So, what does it actually do?
Key capabilities of Kasten, according to Tolia, include:
- Policy-driven Automation – In a cloud-native environment, applications come and go rapidly and scale dynamically. Even though IT operators may not be involved in some of these transitions, Kasten K10 makes it possible to proactively define policies and data management workflows that will be triggered automatically for both existing and future applications.
- Compliance Monitoring – Kasten K10 provides a unified view of data management operations across applications in a cloud-native environment. More specifically, it enables operators to monitor the compliance metrics they are responsible for and easily identify applications that need attention.
- Data Protection – Kasten K10 offers facilities for application-centric data protection. The platform captures and orchestrates lifecycle management operations for both application configuration and persistent data. The Kanister framework allows for deep integration with specific applications.
- Data Mobility and Manipulation – To truly harness the power of cloud-native environments, stateful applications need to be fully portable, including the persistent data component. Kasten K10 delivers foundational mechanisms for moving datasets and performing customer-defined transformations.
In positioning the “why” around the requirements for stateful, container-based applications, Kasten tells the same story that Portworx and ClusterHQ before it did, namely that data management is the real hurdle for stateful workloads. While it is fair to say that enterprises have derived real value from cloud-native platforms, there are still the barriers to using those patterns for stateful applications. While Kasten suggests that users have largely overcome the initial hurdles around storage provisioning in containerized environments, they still experience pain points related to ongoing data management and satisfying business continuity and compliance requirements. The company posits that:
While the challenges partly stem from the fact that existing data management tools are very infrastructure and VM-focused and do not effectively translate to a cloud-native world, the primary issue is that proper data lifecycle management is at odds with most implementations of the DevOps model in the enterprise. Operators do not have the visibility and tools to do data management at scale, while relying on developers to address these requirements with sufficient depth is sub-optimal and insufficient. The result is ad-hoc and error prone processes without clear ownership which inevitably crumble at scale, impede business agility, and often lead to severe production issues including data loss.
Which I get, but which is the same message that I’ve heard from many vendors over the past few years – what makes Kubernetes-based data management fundamentally different to regular old container-based data management. I put this question to Tolia who responded that:
In the last 18 months, the pain points around stateful container based workloads have shifted away from initial storage provisioning, as the volume plugin framework has matured and solutions from a number of vendors have become available. What we see with enterprises are challenges around ongoing data management to meet business continuity and compliance requirements in cloud-native environments. Kasten’s K10 platform provides application-centric data management. We are complementary to software-defined solutions and our application-first approach allows us to deliver substantial value that isn’t always possible when starting from lower-level storage infrastructure. Kasten is not a storage provider, and is in fact storage provider agnostic, focusing on higher level data management on Kubernetes to enable data operations at scale.
Whether you believe that differentiation or not largely depends on which angle you come to the container world from. I’m not entirely getting a massive uniqueness here, which doesn’t invalidate their product at all – after all, stateful applications in a container world are still a problem that needs solving – but perhaps reduces the justification for claiming differentiation.
Either way, it’s going to be interesting to see how Kasten develops its product, market, and story over time.
