The PivotNine Blog

Kasten Launches With K10 and Kanister For Kubernetes

06 December 2017
Justin Warren

Kasten has launched out of stealth at KubeCon in Austin, TX, calling itself “the cloud native data-management company” and has two products ready for you to try. Since Kasten was only founded in January 2017, that's pretty impressive.
Firstly, it has its platform offering, called K10, which takes an application-centric view of data management. K10 uses a policy and workload view to define whether or not a set of data needs to be protected, and how. There's an easy-to-understand interface to show operators if workloads are being protected or not, and it automatically discovers new workloads with the same characteristics, and automatically starts protecting them.

“K10 aims to have an operations focus, but to also be developer friendly,” said Niraj Tolia, Kasten co-founder and CEO.

Unlike more traditional backup tools, with Kasten a restore of a workload involves a rebuild of the container but with its stateful data. It's much more in tune with the CI/CD workflow of container based applications than the more traditional “just restore the data” approach. It also removes the headache of having to manage the stateless app containers separately from a stateful data layer, and the often complex nature of reconnecting ephemeral containers to the persistent data store.

Kasten also has its Kanister framework, which has been open sourced, for defining application specific data management tasks in simple YAML files it calls blueprints. These blueprints can be shared or extended as code while the Kanister framework handles all the background tasks associated with making the blueprint work in a Kubernetes environment. It's a lot like a Terraform setup or Ansible playbook in many ways.

You can take a look at the Kanister code (or should that be kode?) at github.com/kanisterio if you're technically inclined.

After KubeCon last year, I wrote about the challenge of stateful data management and containers and how it was an unsolved problem. Looking around the show so far, there are a few companies attempting to address the issue, including industry stalwart NetApp and startups like Virtuozza.

Oddly enough, I spoke to a startup called Datos last week at AWS re:Invent, who are aiming to tackle the issue of backups of noSQL databases like Mongo, Cassandra, and redis, which have largely been ignored by traditional backup and recovery vendors. The existence of Kasten and Datos means I'm not the only one to have spotted the opportunity presented by the lack of stateful data management options for containers.

So far there doesn't seem to be a consensus on how stateful data should be managed. Should it all be native to the container platform with StatefulSets or similar? Should it be held on traditional storage systems that simply provide data services over standard storage interfaces like iSCSI or NFS? Or should data live at the other end of a database connection, where the datastore is managed as a completely separate entity? How do we decide which solution is the best fit for our need?

It's still very early days for state management in container land, so it'll be fun to track the companies and entrepreneurs who believe they've figured out a good way to solve the problems.

I attended KubeCon US 2017 as a guest of the LinuxFoundation who paid most of my international flight costs. You can watch my interviews at AWS re:Invent on theCUBE in a playlist here.

This article first appeared in Forbes.com here.