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

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.

Don Williams
Don is the CEO of MayaData and leading the company for last one year. He has an exceptional record of accomplishments leading technology teams for organizations ranging from private equity-backed start-ups to large, global corporations. He has deep experience in engineering, operations, and product development in highly technical and competitive marketplaces. His extensive professional network in several industries, large corporations and government agencies is a significant asset to early stage businesses, often essential to achieve product placement, growth and position for potential exit strategies.
Kiran Mova
Kiran evangelizes open culture and open-source execution models and is a lead maintainer and contributor to the OpenEBS project. Passionate about Kubernetes and Storage Orchestration. Contributor and Maintainer OpenEBS projects. Co-founder and Chief Architect at MayaData Inc.
Murat Karslioglu
VP @OpenEBS & @MayaData_Inc. Murat Karslioglu is a serial entrepreneur, technologist, and startup advisor with over 15 years of experience in storage, distributed systems, and enterprise hardware development. Prior to joining MayaData, Murat worked at Hewlett Packard Enterprise / 3PAR Storage in various advanced development projects including storage file stack performance optimization and the storage management stack for HPE’s Hyper-converged solution. Before joining HPE, Murat led virtualization and OpenStack integration projects within the Nexenta CTO Office. Murat holds a Bachelor’s Degree in Industrial Engineering from the Sakarya University, Turkey, as well as a number of IT certifications. When he is not in his lab, he loves to travel, advise startups, and spend time with his family. Lives to innovate! Opinions my own!