Community collaborators vs partners: Part I

As OpenEBS grows in popularity and is used increasingly for production workloads, we are collaborating more with others in the broader cloud native and Kubernetes community. Most of this collaboration happens naturally — users point out that they are using OpenEBS with technology A or B.

We also learn a lot from surveying the OpenEBS community which only takes 2–3 minutes to complete:

https://www.surveymonkey.com/r/BRDCCWY

As OpenEBS is a storage solution taking care of the annoying tasks such as writing data to disk that enable stateful workloads to survive — we inevitably work w/ fundamental layers of the stack such as Kubernetes distributions as well as stateful workloads such as databases or logging and related solutions such as stateful workload operators, monitoring and testing solutions. We also work with our fellow Container Attached Storage solutions such as PortWorx and StorageOS— don’t call them competitors — in open source and also in explaining patterns to the tidal wave of Kubernetes users.

In this blog I try to lay out our approach to partnering, starting with Kubernetes based solution providers and widely used stateful workloads. My goal is to get feedback from current and potential partners and to set some expectations as well.

Kubernetes based solutions:

Kubernetes, of course, has won as the fundamental abstraction layer for microservices and container orchestration. This means that everyone from Mesosphere to Cloud Foundry along with AWS and Rancher and others have adopted Kubernetes. And since OpenEBS is upstream in stable Helm Charts — (see for example: https://hub.kubeapps.com/charts/stable/openebs) it works within seconds on all of these platforms.

Except — there are often additional steps to the integration, steps that users may wish to see to be comfortable with the complete solution. Some of these have a technical basis, and some of them help with joint support and frankly marketing as well.

For example with Red Hat OpenShift, we wanted to make sure that users believed in OpenEBS as a part of an easier per workload and per workgroup storage solution. So we have done the additional work to make sure that it supported the OpenShift RBAC policies and passed Red Hat security testing. As a result, OpenEBS is OpenShift Certified.

Similarly, if you look at Rancher’s newly rewritten management framework — which as of Rancher 2.0 is based on Kubernetes — you can easily find OpenEBS by enabling the use of stable charts in Rancher; you can see the step by step instructions in OpenEBS documentation here:

https://docs.openebs.io/docs/next/rancher.html.

Recently we also submitted a PR to the team at Rancher to make OpenEBS even more comfortable to use on top of Rancher to provide cross AZ protection, snapshots, and other capabilities to Rancher users.

Earlier this summer the Kubernetes based solution provider Kontena Pharos built OpenEBS into their offerings. https://kontena.io/pharos/ And just this morning I chatted with a happy joint user from the cool SaaS app for auto dealers ActiveEngage. So these kinds of partnerships are helping users get up and running and operating at scale more easily.

You can expect more of this type of partnership launching soon — and increasingly with more behind it than technology integrations. What I’m getting at is that while technologies that are working together are great and maybe all that the earliest of early adopters require — most users are not so keen on forging new ground. They would like to know that the particular workloads they are using and the problems they are solving has already been addressed.

Workloads:

And it is by working with workloads that we see the most benefit to those end users that are interesting in common patterns for the deployment and operations of stateful workloads. By increasingly sharing the best practices or patterns for different workloads we think we can contribute to the even broader acceptance of Kubernetes and so use of all its power for stateful workloads.

Recently we have been working with community members that are running MySql, PostgreSQL, Spark, HBase, Redis,and other stateful workloads. Many of these workloads we support in a few ways including:

• Sharing what we learn from the community about joint usage
• Possible Litmus testing support
• Possible E to E support

For example, every OpenEBS release is tested with Red Hat OpenShift, Rancher, AWS, GCP, and other platforms. We have some ideas on how to make this level of end to end testing more useful so stay tuned for some announcements around the OpenSource Summit North America in a couple of weeks.

Commercial support

• Of course, for customers, we contractually agreed to make them successful based on the terms of a license agreement which refers back to that test matrix as well and can have additional certified integrations in some cases.

And of course, in all cases, we welcome the opportunity to co-author blogs and so forth with community members. You will see us extending our global hackathons to support this kind of activity as well and of course jointly presenting at meetups and so forth with interesting projects that are being used widely in the OpenEBS community.

In the next couple of blog, I’ll talk about how we are working with DevOps experts — system integrators that help enterprises architect, build and operate more agile environments — as well as our relationship with Prometheus and Weave Scope and other monitoring related projects — before concluding with a discussion of how we collaborate with existing system providers such as server and storage providers.

How about you? What would you like to see from an open source project like OpenEBS in terms of working well w/ others? What can we do better to help the natural alignment process?

This article was first published on Aug 15, 2018 on MayaData's Medium Account.