Apps need data. Apps on Kubernetes are no exception, which is why we at MayaData and the OpenEBS community have been working for years to become the most popular solution for running data on Kubernetes (according to last year’s survey from the Cloud Native Computing Foundation). What’s the secret to state on Kubernetes? Container Attached Storage, or CAS.

In this article, I’d like to explain what is possible now in terms of using Kubernetes as a data layer, with the help of the Container Attached Storage (CAS) pattern as embodied by OpenEBS.

Don’t Break Your DevOps. Small Teams Rule!

One of the central tenants of DevOps and the shift to microservices is that small teams should be able to select the tools they need and should also be autonomous and accountable. Shared storage or the use of a centralized “database to rule them all” breaks this pattern. Container attached storage from OpenEBS puts these small teams back in control. They can pick whether they need a data engine that replicates their database or other workloads — or if they trust their Kafka or Cassandra or other workloads to handle resilience itself. Or if they have NVMe systems, they can — for the first time — deploy extremely high-performance PVCs with the help of MayaData’s MayaStor (just reaching beta).

Your Mistakes or Operational Debt Don’t Trend on Hacker News

In the last few weeks, Garmin and Red Hat (via Quay.io) have made the news. Garmin’s data was held hostage and Quay seems to have had a number of cascading outages of its MySQL and other data management, as explained in its root cause analysis blog.

Using CAS solutions such as OpenEBS minimizes your blast radius. Yes, you can and often will run it on top of an old shared storage system from core IT — or even a storage service from your favorite big cloud. However, a) you don’t need to and b) whatever you do, your blast radius will inevitably be much much smaller.

#containers #data #kubernetes #contributed #sponsored #data analysis