I am currently attending Cloud Field Day 6 in Silicon Valley. We are in the thick of it, just about to start the third day of presentations. Before I wander into the maelstrom of presentations and conversations that will leave my brain feeling like it’s been through a Vitamix, I thought I would jot down some initial thoughts about Hammerspace, one of the presenters from Wednesday.
In the lead up to CFD6, I wrote about Hammerspace, and I had some real questions about where their product fit within the marketplace. If you’ll forgive me for quoting myself from that post.
During their CFD presentation, I would like to focus on the use cases for the technology and why I would choose to use their solution over something like Azure Files or Amazon S3, both of which have a global namespace concept.
Did Hammerspace address these concerns during the course of their presentation. Here is the first video of their session if you’d like to see for yourself.
You can find the rest of the videos on their Tech Field Day page.
In a nutshell, I don’t think they provided ample differentiation to make me choose their solution over options that exist in the marketplace. Before I dive into the reasons why, I want to say something about the technology.
Much of the presentation was spent talking about how their solution works from a technical perspective, and I have to say that this is some pretty impressive technology. There is no doubt that David and Douglas are whip-smart dudes who have some serious technical chops. They have built a platform that sits in front of multiple NFS systems and decouples the metadata layer and the data layer from each other. The Anvil and DSX components seem to do an admirable job of providing an abstraction layer between the storage backend and the clients that consume that storage. The real questions is this:
Is there sufficient value being delivered by their solution to justify the additional layer of abstraction and administrative overhead?
We are talking about adding a layer of abstraction to existing storage, which in most of their use cases was an NFS filer. Applications that are already happily using the NFS mounts would need to be updated. New infrastructure would need to be provisioned, managed, and monitored. The storage team would need to learn a new product. And the IT Ops team would need to support it. So again, is the benefit derived from their solution worth all that additional fuss?
Let me make a comparison to another abstraction layer that adds complexity, but also provides significant benefits. Virtualization and vCenter. vCenter takes a collection of virtualization hosts and provides a common abstraction layer to simplify the consumption and management of virtualized resources. Managing vCenter and the ESXi is a non-trivial amount of work - as many a VI admin would tell you, but the benefits of virtualization and vCenter cannot be denied.
Hammerspace adds the capability to have a global namespace for NFS and they are pinning their solution to Linux and the use of pNFS. I am not convinced that a global namespace is a massive benefit. They also mentioned the ability to apply security policies, deduplication, and replication. Those are nice features to have, but many solutions you might consume in the cloud or on-premises already have these features and it appears in many cases that Hammerspace is leveraging those native capabilities.
They also had a portion of the presentation dedicated to tapping into Kubernetes. While that is an impressive feat of technical engineering, again I am not convinced that their CSI plug-in provides a net benefit over other off-tree solutions from native storage in the cloud or on-prem.
There is a lot of potential in the technology, but I am not sure that Hammerspace has found the proper market fit for what they do. I think there are a few different paths for them:
Time will tell which direction Hammerspace goes, but I have no doubt that the folks at Hammerspace will be successful.
Resourcely Guardrails and Blueprints
November 15, 2024
Deploying Azure Landing Zones with Terraform
November 12, 2024
October 18, 2024
What's New in the AzureRM Provider Version 4?
August 27, 2024