I was interested to see that Red Hat recently decided to acquire NooBaa, a start-up developing an object storage platform.  What makes this story interesting is not the NooBaa technology itself, but rather that Red Hat is acquiring yet another storage platform to complement those it already owns.  Why add another to the list?

NooBaa

NooBaa Installation Process

Let’s look at the NooBaa technology for a moment.  The platform is a software-defined storage object store that can be deployed on any Linux platform (or Windows) and consume either dedicated or spare resources on that system.

This means it can be used on bare metal, virtual machines or in the public cloud.  Installation is relatively simple, with an entire cluster managed via a web GUI (and I’m sure there’s an API/CLI too).

Most servers in a NooBaa cluster act as storage nodes, while two or more servers act to store metadata and manage the storage components.

Data Dispersal across multiple logical disks

Installing NooBaa is really simple.  In fact, most of the installation sequence operates off a single URL that pulls data from one of the metadata servers.  This makes the process of automating builds and deployments really easy.

As an object store, the technology is relatively lightweight. being more functional than delivering high performance.  I’ve installed a few versions of the NooBaa platform in the lab and found it easy to use and straightforward as a simple object store.

Red Hat

Red Hat already has a number of storage solutions.  These include Ceph Storage and Gluster.  Red Hat OpenShift Container Storage is built on top of GlusterFS.  With a distributed file system (Gluster) and a jack-of-all-trades storage platform (Ceph) in the Red Hat stable, why add another?

My first thought is that NooBaa is a relatively simple platform to install.  This makes it easy to deploy on existing infrastructure or within a software-driven environment.  By that, I mean one that is constantly changing, such as development platforms that need testing or temporary object stores.  With only a few VMs, the logical aspects of an object store can be easily be implemented.  Contrast that to Ceph.  Regardless of what’s claimed, Ceph is still relatively more complex to install.  Companies such as OSNEXUS have built tools and ecosystems around making Ceph deployment more efficient.  NooBaa takes all this effort away.

The Architect’s View

So that’s my view – NooBaa is simply easier and more practical for smaller or more dynamic environments.  This will be a key advantage for public cloud, where the hardware exposed to virtual machines is not 100% guaranteed.  We’ve already seen that with the availability of Elastifile in GCP.   When software-defined storage can be deployed on any shape or size VM – especially non-uniform designs – then this will fit well with the capabilities of public cloud.  The main challenge for Red Hat will be to communicate the use cases for each of their solutions clearly to their customers.  Oh, and of course provide interoperability between object store solutions.  We wouldn’t want trapped islands of data, now would we….

Copyright (c) 2007-2019 – Post #2684 – Brookend Ltd, first published on https://blog.architecting.it, do not reproduce without permission. 

Written by Chris Evans

With 30+ years in IT, Chris has worked on everything from mainframe to open platforms, Windows and more. During that time, he has focused on storage, developed software and even co-founded a music company in the late 1990s. These days it's all about analysis, advice and consultancy.