The transition from datacenter to cloud has not been smooth for IT pros, enterprises, application developers, or product companies. It seems that everyone focuses either on transitioning existing applications to the cloud (the “bridge to the past” approach) or building an entirely new cloud-native application environment (the “blow it all up” approach). This is certainly evident with the storage solutions we are seeing which attempt to bring enterprise-class data services into this cloud world: Most are transplanted legacy systems or truly native cloud storage solutions.
The Problem With Enterprise Applications
That’s why I was intrigued to hear about Kasten’s approach to the problem. Rather than ignoring the decades of storage innovation and inventing something totally new, they focused on the product features that made enterprise storage so compelling. And rather than trying to transplant legacy enterprise technology to the cloud, they reimplemented these features using cloud storage technologies. Then they wrapped the result in APIs and connected it to an open library of application-aware data management primitives. Smart.
Kasten’s K10 platform includes classic data management capabilities like snapshots, replication, and backup but these are re-thought for the cloud-native world. Integrating these features with enterprise applications has always been challenging because both the storage platform and application needed to be aware of any actions performed. You can’t just yank out some data and replace it under a running application! So people like me spent way too much time in decades past scripting applications to pause, restart, or refresh their understanding. And this kept many innovative storage architectures from ever taking root in the data center.
Kasten K10 and Kanister
But this isn’t as much of an issue with cloud-native applications. We’ve moved the demarcation between application and data so far apart that cloud solutions are truly stateless: You can reboot or add containers at will and they’ll pick up with barely a hiccup. Although integration is still needed, there are management frameworks like Kubernetes running the show, and these were created with integration and automation in mind. So Kasten can move data at will and tell Kubernetes to reconfigure the applications appropriately.
But of course automation is still needed. That’s where the Kanister project comes in. People who really know applications can script the particulars in an open framework, allowing Kubernetes to make exactly the right moves. And of course K10 is completely integrated with Kanister, leveraging this knowledge to reconfigure applications as needed as data is moved.
Kasten isn’t trying to fit a square peg into a round hole by porting enterprise storage or applications into the cloud. Instead they’re leveraging the new stateless applications and management frameworks to deliver traditional storage and data management features to cloud-native apps. And they’re leveraging the wisdom of application developers to create a framework of knowledge they can use. Very smart all around!
- Inside-Out vs. Outside-In Hybrid Cloud - January 14, 2019
- Amazon and Database-as-a-Service - January 11, 2019
- Thin Provisioning: The Lies We Tell Our Systems - December 21, 2018
- Why Would Microsoft Buy Mellanox? - December 19, 2018
- Pure Storage Isn’t About All-Flash Anymore (and Never Really Was) - December 13, 2018
- Liqid Takes Composable Infrastructure to a New Level - December 5, 2018
- The fault, dear Brutus, lies not in our machines… - November 26, 2018
- ProtonMail Was Probably Not Hacked - November 16, 2018
- Goodbye X-IO, Hello Axellio and Violin 2.0! - November 12, 2018
- The New iPad Pro Proves That Apple Doesn’t Need Intel or AMD Anymore - November 9, 2018