What a week —the Mule DABS — commercial MDAP launches

Last week we saw the culmination of an enormous amount of work by ourselves — and by partners such as IBM and many other users of OpenEBS — culminating in releases across the open source projects we primarily support, OpenEBS and Litmus, and the launch of our commercial offering which we call MDAP.

What a week — the Mule "DABS "— commercial MDAP launches

You can learn more about progress in each area:

https://www.ibm.com/us-en/marketplace/openebs-cloud-native-storage

TL;DR: https://www.ibm.com/us-en/marketplace/openebs-cloud-native-storage/resources

OpenEBS on IBM Cloud PrivateOpenEBS on IBM Cloud Private

A primary topic at the booth last week was “use” cases as in — how the heck are people using OpenEBS? Perhaps the most common “use” case we have encountered has been adding resilience to underlying storage services from AWS and others often while using less expensive attached disks on these services.

You can read a how-to blog here on running OpenEBS on AWS in this way on the OpenEBS blog here: blog.openEBS.io

Stateful applications using OpenEBS and instance stores
Stateful applications using OpenEBS and instance stores

We also had a chat with some users who have started running OpenEBS with NoSql. There seem to be two main reasons these users are using OpenEBS with NoSql — which already has data resilience features built in:

  1. Cloud independence: the first is to add another additional level of abstraction so that when cloud environments are moved there is no impact on engineers. We heard for example from a large governmental user that they had a mandate to be cloud independent, which is why they have moved to Kubernetes and are investigating the use of the open service broker as a way to further abstract cloud-specific calls.
  2. Simplified Local Storage Management for Local PV and storage like OpenEBS using NDM: As OpenEBS depends on Kubernetes as the storage substrate we are always looking at ways to improve Kubernetes itself. To be clear, we are already benefiting tremendously by the upstream work done by the broader community. We also seek to do our part through projects such as node disk manager (NDM) which can enable Kubernetes to treat disks and underlying storage services and so forth as Kubernetes objects. NDM can be used for automating the provisioning and management of local PVs uniformly across different Kubernetes platforms. Beginning with OpenEBS 0.7 it is easy to use OpenEBS for capabilities such as NDM. You can read more about the usage of NDM within OpenEBS in Kiran’s blog here: https://blog.openebs.io/openebs-0-7-release-pushes-cstor-storage-engine-to-field-trials-1c41e6ad8c91

And you can also read about the April beta release of Local Volumes as a capability within Kubernetes here: https://kubernetes.io/blog/2018/04/13/local-persistent-volumes-beta/

We wrote about these and other “use” cases on the jointly created IBM subsite for OpenEBS here: https://www.ibm.com/us-en/marketplace/openebs-cloud-native-storage

In a sense, with OpenEBS 0.7 we are releasing two storage engines — one is enabling Local PV and the other — still in Alpha — is our cStor. cStor is also open source, and unlike Jiva, which is written in Go, cStor is written in — you guessed it — C.

cStor is rapidly accumulating production hours and is already shown to improve upon our existing Jiva in a few ways including better read performance (performance is yet to be optimized by the way) and an end to end data integrity. As cStor reaches beta in 0.8, you’ll see it used to dramatically improve snapshots and clones and related use cases as well.

Well, that’s a quick recap of last week. It was perhaps our most important week as we started to tie together our technologies into a solution, MDAP, that we think is unequaled at least in the breadth of vision, and we are just getting started. We continue to progress towards our vision of data agility — where Kubernetes and related technologies and services including of course OpenEBS are used to dramatically accelerate the building and operating of environments that include stateful workloads in a way that is free from vendor and cloud lock-in.

Please provide any feedback below or via @epowell101. Thanks for reading!

This article was first published on Sep 6, 2018 on MayaData's Medium Account.

Utkarsh Mani Tripathi
Utkarsh is a maintainer of jiva project and has contributed in building both control and data plane of OpenEBS. He loves to learn about file-system, distributed systems and networking. Currently, he is mainly focusing on enhancing jiva and maya-exporter In his free time, he loves to write poems and make lip smacking dishes
Chuck Piercey
Chuck Piercey is a Silicon Valley product manager with experience shipping more than 15 products in several different market segments representing a total of $2.5Bn revenue under both commercial and open source business models. Most recently he has been working for MayaData, Inc. focused on software-defined storage, network, and compute for Kubernetes environments. Chuck occasionally writes articles about the technology industry.
Sagar Kumar
Sagar is a software engineer at Mayadata who loves coding and solving real-world problems. He has been playing with Kubernetes for the last couple of years. Currently, he is focused on building OpenEBS Director as the go-to solution for OpenEBS users. In his free time, he loves playing cricket and traveling.