Storage for Kubernetes — Not a Problem, but an Opportunity
Last week’s KubeCon was special for everyone who has been working on OpenEBS and any related software for the last few years. By introducing OpenEBS to the CNCF and being embraced by various speakers at KubeCon, we seem to have broken through into the consciousness of thousands of Kubernetes users — all of whom at one point seemed to be queuing up to chat with us (or to grab a sticker of the Mule visiting Sagra Familia).
Tweets like this one (thank you Priyanka!) led to many great conversations around our booth.
https://twitter.com/pritianka/status/1130738477853581312
Many of our conversations were with existing OpenEBS users who come meet us in person and perhaps learn about a variety of topics including 0.9, the recently added support for LocalPV, the forthcoming high performance storage engine, on premise deployments of MayaOnline, among others. There was a decent amount of buzz about KubeMove as well — more on that below.
I’d like to give a special thanks to the engineers who stopped by from various car companies and reported that OpenEBS is now a preferred solution under a number of Kafka pipelines and even in the on-line configurator for a public facing web site. Not all states of this configurator (where you design your own car) are being handled by Kubernetes, but a portion is. Now they want to put all of it on Kubernetes itself as opposed to being on external systems only connected via API or otherwise. As their usage points out, APIs check the box for connectivity; however, these and countless other users of Container Attached Storage from OpenEBS and our proprietary friends show that there is something more going on here. These users are not stopping at the API level, whether it be CSI at the storage layer or via Kafka or some other layer of connectivity at the DB and data layers. Instead, they are embracing Kubernetes itself as a substrate for storage and data management.
So, why is that? And how is it that after many years of effort OpenEBS has become only now become a bit of an overnight sensation? I thought a lot about this during the flights back to the US and the long waits while going through customs. The simplest explanation I can give is this:
At MayaData we started OpenEBS because we never believed storage for Kubernetes was simply a problem that needed to be solved — rather we have always seen it as an opportunity to be seized.
When we first set out many years ago, as a group we were very familiar with the promises and challenges of software defined storage. We knew that from what we tried to build at companies like Nexenta, CloudByte, HPE and Dell. And we knew how our feet of clay — the technologies our software itself was written in, deployed in and operated upon — kept us from delivering storage that was truly software defined.
So, we asked ourselves — what if storage FOR cloud native environments was ITSELF cloud native? More importantly, we asked hundreds of users about this.
And we didn’t just ask; we gave them some code to try. We started with a simple, naive storage approach — starting with an orphaned Go project that put storage in containers started by Rancher called Longhorn — and we wrapped it with logic to make it easier to deploy and operate. We put our experiment in the hands of users and watched and listened. We learned a lot very quickly and found that our initial thesis was by and large validated. There were new users with new use cases emerging as Kuberntes and containerization proliferates across on premise and cloud environments, and these use cases promised fundamentally better and even more agile ways of building and running software that includes stateful workloads. The adoption of what we call Jiva taught us a lot and led us to build our next storage engine, cStor, that added many additional capabilities including far superior data integrity and data resilience.
Now, what are these data agility use cases? What can users get done now that they simply could not accomplish with API connected storage or data? Why is it that storage for Kubernetes is more of an opportunity than simply a problem in need of fixing? I won’t go through all of these here, it would be better for you to join the OpenEBS slack channel or ask around about how and why everyone from tier one financials to national defense organizations to large SaaS operators and others are using OpenEBS to accelerate growth and resilience while minimizing costs.
Here are a few reasons we heard many times last week at KubeCon:
What’s Mine is Mine and what’s Yours is Yours: Small Team Autonomy
Distributed Turtles all the Way Down
Freedom from Lock-in: Freedom to Innovate
I hope that one thing we’ve shown with OpenEBS and other open source work at MayaData, such as Litmus for chaos engineering, is that while our Twitter and, of course, mascot and sticker game is strong, so is our code! It’s with that same invigorating spirit that I write this post.
In less than 3 minutes, you too can be running OpenEBS on whatever Kubernetes you have lying around. There are no special settings required; no kernel modules that could violate your RHEL support should you be thinking ahead, although OpenEBS does primarily use iSCSI at the moment. So, enough thought leadership blog stuff — take the code out for a run today.
$ helm install stable/openEBS — name openebs — namespace openebs
And thanks again everyone for validating OpenEBS over the last few years. Together we’re showing the world that storage for Kubernetes doesn’t just solve a problem, it’s an opportunity to do the right stuff faster and with more agility.
If you are interested in what others have said recently about OpenEBS and MayaData, please take a look at the Twitter feed. Some interesting articles include:
You can also check out the press release announcing new investments, joining CNCF and especially OpenEBS 0.9:
This article was first published on May 26, 2019 on MayaData's Medium Account.