Cloud Native Storage: Overview

When thinking of containers, Cloud Native Storage topic shines like an evidence. You have to handle this topic with care as it will carry your workload and configuration. This blog will be the first of a series talking about CNS and usage.
I will try to cover as many aspects as possible and clear up the CNCF situation when you start looking at the landscape. The purpose of this series will not be to a direct comparison of the products one to one. Especially because of the number of products and time consuming testing. Plus you may find many on the internet who did it for different purposes and different products. It will be more a higher level method to choose wisely what will the best fit for your needs and workload.

Before I go further, let me just raise a little warning about what you’ll read below. To understand terminology and the ins and outs concepts, you better be familiar with Kubernetes. For example, holding a CKA (Certified Kubernetes Administrator) may help you better appreciate this series of blogs.

Classic storage, I mean at the OS level, is what we call ephemeral storage from a container view. You may have LVM, nfs shares or any storage managed at the OS level. Many SRE engineers will stay at this level for data protection to secure and avoid the risk of loosing their precious data. For example, we may imagine a database administrator having his database installed in a VM and thinking to backup the dedicated file system where the data are stored.

Now let’s get back to cloud native storage. As the name depict it, it has been built specifically for cloud environments. Stricto sensu, cloud differs from on-premise for hosting, but here, we’re describing the general term for “cloud native”. It means a software approach to develop, build, create and manage modern applications and for that, they require scalable, flexible and resilient capabilities. These applications can leverage on public, private or hybrid cloud infrastructures.

What are these cloud native applications, they are (or should be) most of the time small and independent services allowing a very fast release cycle with more confidence. This can also be part of the efficient time-to-market definition. Again, small doesn’t mean it can’t handle very big loads, scalability and flexibility are part of the cloud native’s main purpose. In fact, it is more designed for efficiency and reliability to handle production environments by reducing cost in a general manner when load is varying.

You may also find big monolithic workloads in containers and I can say that, since I work with containers, I saw a lot of productive environments running applications that are not microservices. It is sometimes not possible due to vendor products or it can be a vendor first move before moving from monolithic to microservices.

Now, let’s talk about the CNCF landscape regarding Cloud Native Storage, it is a sub-topic in the Runtime category.
You can find it by following the link.

If you are not familiar with this view, let me give you some hints

• Some product have a grey background, it’s because their code is proprietary
• Some product have a white background, it’s because their code is open-source
• Projects are graduated regarding vote from the community, it indicate the maturity level of a product
• Graduation can be the following
  • Sandbox: Innovators
  • Incubating: Early adopters
  • Graduated: Majority
  • Archived: Grey logo, Project no longer supported
• Some are in this picture only because they support the community as members
  • Platinum
  • Gold
  • Silver
  • Academic
  • Nonprofit
  • End User supporter

I can imagine now what can be your next question is: Which product should I use for my needs.
Well, this will be the topic of my next blog series regarding Cloud Native Storage.

In the mean time, I encourage you to follow my colleague’s blog on not being afraid to install a database in Openshift here.