If your data doesn't exist in at least two places then it does not exist. This is the basis of the 3-2-1 rule made famous by data protection vendor, Veeam. The 3-2-1 rule states that administrators should:
Have at least three copies of data.
Store copies of data on at least two different media.
Keep copy of the data offsite.
This rule applies to keeping backups of data, to prevent data loss in case primary storage is lost. But primary storage also has its own resiliency concerns. Today's enterprise storage requirements are far larger than a single physical magnetic hard drive or Solid State Drive (SSD) can hold.
Enterprise data storage is done using storage arrays consisting of multiple drives. These storage arrays use data storage patterns that ensure data is preserved even if a physical drive fails. Exactly how many drives can fail before the array can no longer serve up the required data varies depending on a number of factors but this kind of resiliency isn't a form of backup. It's about ensuring that workloads can still be served from the storage array while hardware issues are taken care of.
All enterprises need multiple forms of data resiliency. For example, protection against hardware failure, protection against data loss and protection against entire data centers or clouds going offline. For decades, each element of data resiliency used a different product. Sometimes organizations would have a dozen different products from as many vendors just to get a bare minimum of resiliency for a mission-critical application. Just about a decade ago, that all started to change.
A Little History
In 2006, Amazon launched Amazon Web Services (AWS) with the release of Simple Storage Service (S3), the first really popular object storage offering and the beginning of the modern public cloud era. Cloud Service Providers (CSPs) and object storage had both existed before Amazon, but it was AWS that created the first global scale mainstream commercial offering and this changed storage forever.
Virtual machines, however, require block storage. In 2006, the world was in the process of consolidating workloads off of bare metal servers and into virtual machines. By 2010, this process was occurring in bulk, VMware had become a household name and enterprises were looking for storage with more flexibility and lower capital costs than traditional storage arrays. This was the birth of the enterprise Software Defined Storage (SDS) era.
SDS took several forms, the most popular of which were distributed object stores, scale out storage and Hyper-Converged Infrastructure (HCI). Distributed object stores were effectively trying to be Amazon's S3 but suffered the same limitations as S3: VMware just didn't talk object storage natively and putting one's VMs onto an object store was difficult.
HCI and scale out storage shared a different lineage. The principle behind each of these was to use inexpensive "white box" x86 servers and fill them with hard drives. Software on each of the x86 servers would claim all installed hard drives and add them to a cluster-wide storage pool.
Like the traditional storage arrays before them, scale out and HCI storage solutions created resiliency against the failure of individual drives. But they also allowed entire nodes in the cluster to fail and administrators could expand storage on an as-needed basis simply by adding nodes to the cluster.
The big difference between HCI and scale out storage was that HCI was designed to allow organizations to run workloads on the same nodes that were creating the storage fabric. In this manner, HCI created a lower Total Cost of Ownership (TCO) when compared to traditional storage arrays and servers.
Scale out storage typically did not allow running workloads on the nodes that were creating the storage fabric. This allowed scale out storage to build in features such as deduplication, while providing more performant storage than HCI. Scale out storage systems also tended to be able to scale out to become much larger than HCI clusters but nowhere near as large as object storage.
For most of the last decade, HCI and scale out storage vendors focused on providing the best storage for traditional workloads within a single site. Object storage vendors focused on providing the best storage for cloud-native workloads but they tended to focus more on multi-site – and multicloud – designs.
Over the past few years, enterprise needs have changed and storage has evolved. More and more applications were built along cloud-native lines. Instead of a single, monolithic workload, cloud-native applications consist of multiple workloads.
These cloud-native workloads are usually designed to scale through the addition of additional copies of the workload. If the application's database layer is under heavy load, simply spawn more database instances.
The application design of cloud-native workloads means that they were also good candidates for turning into distributed applications. Instead of spawning more database instances to respond to pressure on the database tier, why not spawn those database instances geographically proximate to demand? This would reduce latency for users of that application and improve customer satisfaction.
If every workload of every cloud-native application were built to use object storage, then the delineation between traditional workloads and cloud-native workloads would be clean and clear: traditional workloads would live on storage solutions like storage arrays, HCI and scale out storage. Cloud-native applications would live on object storage. Never the twain shall meet.
But that's not how the real world works.
The Container Problem
In the real world, cloud-native applications are a mixture of new and old. Traditional applications that rely on file systems, instead of object storage, make up many of the individual workloads that in turn comprise a modern enterprise application. This is a problem.
For a number of reasons, ranging from security to ease of use, applications need wrappers. When applications were monolithic affairs, VMs were fine wrappers. Each VM contained within it an entire operating system, but the overhead of that operating system was usually irrelevant compared to the resource demands of the application it served.
Let's say that you have an application that consumes 500GiB of RAM during regular operation. A 4GiB RAM overhead for the operating system seems perfectly reasonable for that sort of workload. Take that same application and shard it into microservices, and the math changes.
Instead of a single workload, you might have 20. 80GiB of overhead for a 500GiB workload is significantly less efficient, especially when the individual microservices don't need all the hypervisor or operating system-level redundancy features that VMs provide. This is where containers come in.
Containers pack multiple applications into a single operating system without letting those applications step on one another. The overhead per application is very small – a few MiB – but this comes at a cost.
By sharing an operating system, every time that underlying operating system is rebooted, so is every container. Unlike VMs, there is no vMotion to live migrate containers from one pod to another when the underlying operating system is rebooted. Container instances must be stopped and a new instance brought up on another pod.
In one sense, this isn't a big deal. This is exactly what cloud native applications are designed to do: scale by adding and deleting instances as needed. In fact, containers evolved to meet this need and the entire container ecosystem – dominated by Kubernetes – is designed to instantiate new pods and new container instances as needed.
The wrinkle in this is that if not only containers, but also the pods they operate on, are being created and destroyed on an as-needed basis, then the workloads inside those containers need a place to store their data that is more persistent than the highly changeable infrastructure they occupy.
When the server you live on can be deleted at any moment, the idea of "if your data doesn't exist in at least two places, then it doesn't exist" takes on a whole new meaning.
To meet the needs of today's application developers, storage must evolve. Storage needs to be something that can provide SDS-like resiliency against multiple types of failure.
Modern storage needs to provide this resiliency across multiple clouds, as well as in the on-premises data center. It needs to be able to make use of the storage on physical servers, if available, as well as the storage provided by VMs, or by cloud instances. This storage needs to be able to cope with the dynamic nature of modern infrastructure, such as the fact that a container pod can be destroyed as part of load shaping or that sometimes an entire cloud provider can go down.
Spin up a dozen AWS instances with LXC containers, managed by Kubernetes, and Juke can claim the local storage on each one. Juke will stitch this storage together in an HCI-like fashion to create a resilient storage fabric and then present that storage back to the Kubernetes pods using NFS.
Juke can do this at the level of a single cluster or in a multicloud distributed fabric. Try destroying a container on AWS “us-east-1a,” and reinstantiate it on Google Cloud in “asia-northeast1.” With Juke, not only can the workload pop up on any pod within the fabric but it can do so with full access to the data it had just been operating on all the way on the other side of the world -- and do so in seconds.
Juke integrates traditional enterprise storage functionality (such as snapshots) alongside native container management and multicloud scale.