BiB 073: HammerSpace Data-as-a-Microservice For Kubernetes - a podcast by Packet Pushers Interactive LLC

The following is a transcript of the audio file you can listen to in the player above.
Welcome to Briefings In Brief, an audio digest of IT news and information from the Packet Pushers, including vendor briefings, industry research, and commentary.
I’m Ethan Banks, it’s March 26, 2019, and here’s what’s happening. I had a briefing with HammerSpace earlier this month. HammerSpace describes themselves as, “a storage and protocol agnostic cloud data control plane, abstracting data from the infrastructure for self-service hybrid cloud data management, driven by machine learning and metadata management to deliver Data-as-a-Service.”
That mouthful does a pretty good job at getting to the heart of HammerSpace, which is to layer policy on top of your existing storage, moving data around to wherever you need it to be automatically. And if that happens to include hybrid cloud, that’s just fine with HammerSpace.
Data-As-A-Microservice
In this briefing, HammerSpace announced the ability to provide a global namespace for persistent storage in Kubernetes environments. As containers were originally conceived to be stateless and ephemeral, that is you should be able to stand them up and tear them down at will with essentially zero application impact, the idea of persistent storage seemed a bit wrong. Why do we need persistent storage for stateless containers?
As container use cases have expanded, stateful containers have become normal, and the need for persistent storage has grown right along side. But presenting that storage to a container in an automated way hasn’t been all that easy.
HammerSpace has tackled this issue with what they are calling data-as-a-microservice. This is not a new type of K8s specific storage, which HammerSpace thinks is about the last thing the Kubernetes world needs. Therefore don’t think of this as being just about getting data to a container. More importantly, HammerSpace is trying to answer the question, “How do we get storage to evolving workloads?”
Data Is Declarative
The answer to this question is to make data declarative. That is, describe what is needed from storage, and it just happens. At least, from a devops perspective, it looks like “it just happens.” In other words, policy drives the automation without admins having to pay too much attention.
Once the policies are in place, snapshots are put where they are needed for access or resilience. You might be accessing storage that’s on prem. You might be accessing storage that was burst to public cloud if policy dictated. You can also turn off HammerSpace in the public cloud when you need to save some dollars in your cloud provider’s bill, although global de-dupe to reduce the amount of data transiting cloud is part of the package.
Of course, nothing here is actual magic. What’s really going on is that K8s is talking to HammerSpace DSX Data Services Nodes as well as the Container Storage Interface as presented by HammerSpace. Kubernetes workloads are getting local file type performance via NVMe-level IOPS even though they are talking to HammerSpace and not storage directly.
Use Cases
HammerSpace cited a couple of key use cases for this technology that will be familiar to folks who have run into stateful containers.
The first use case is databases. For example, noSQL, MySQL, Elastic, Redis, Cassandra, mongoDB, and MS SQL Server. HammerSpace described this scenario as helpful to folks who need low latency access for their builds to go fast.
The second was for transparent dev/test to production. For example, you could take a snapshot of data living on your on-premises NetApp, present it into the cloud read-write, a benefit of a Kubernetes global namespace according to HammerSpace.
For More Information
This is a complex product and announcement, and lots more to the…

Further episodes of Tech Bytes

Further podcasts by Packet Pushers Interactive LLC

Website of Packet Pushers Interactive LLC