ClusterHQ Customers Are Not Wrong

One of the early innovators in the container ecosystem, ClusterHQ, just announced that they are shutting down. They were justifiably proud of their role as an early proponent of stateful containers. We agree. As containerization became a key consideration for enterprises, it was inevitable that stateful applications would be containerized. Challenging problems of providing data persistence and data availability appeared. ClusterHQ was one of the first companies to address this via Flocker, connecting Docker containers natively to legacy storage.

So what went wrong? ClusterHQ customers are not wrong. Infrastructure software needs to support stateful containers. And the problems of managing data state and availability are not insurmountable. ClusterHQ’s Flocker was a good first step, just not the last step.

The problem was that Flocker was connecting to the wrong storage. Legacy storage arrays are fundamentally siloed, not cloud-native, and require manual provisioning. LUNs were designed to provide storage to servers, not applications running in containers. For example, they cannot plug-andplay with container orchestration and scheduling software. Tools like Flocker and RexRay try to connect traditional LUNs to containers. There are worse and better architectures for managing stateful containers. Here’s our view.

We applaud ClusterHQ’s efforts over the years. They set the industry on the path of stateful containers. The good news is that stateful containers are here and being deployed successfully.  Follow our blog and Twitter feed to see how Portworx is leading the charge.