After returning from the OpenStack Summit in Austin, we reflected on the week’s experiences and enjoyed the time well spent with customers and future customers. But let’s not forget the BBQ, oh yes, the BBQ!

While we were there, we discovered that Datera has what cloud service providers and enterprises who operate like cloud service providers are looking for. But we spoke with a dozen or so individuals who didn’t know Datera or the hybrid cloud services, public cloud storage, or enterprise cloud applications we deliver. This is completely understandable since we emerged from “stealth” only a few weeks prior to the conference.

Among the people we spoke with, we discovered two distinct mindsets:

1. Those coming from a traditional storage perspective

2. Those coming from an enterprise cloud application and/or public cloud storage perspective

The idea of “intent-defined” was rather easily understood by those with an enterprise cloud application mindset. However, the idea was a little, shall we say “cloudy,” for individuals coming from a traditional storage perspective.

In the end, no matter which side of the spectrum you fall on, “intent-defined” will soon join your vocabulary and we’d like to help you understand how Datera is offering game-changing solutions and should be in your public cloud storage.

So, what are we? To keep it simple, Datera is a software-based, low-latency block storage on commodity hardware.

Wait a second, what’s so unique and game-changing about that?

We’ll start from the storage servers which contain Datera software…

Datera software creates a symmetrically distributed system on commodity hardware. This means each server is a node in the distributed system cluster. There’s no leader or “head node” so the system is more and more resilient as it grows. Each node is self-describing. This means each node can be made up of a heterogeneous mix of media (SSD, HDD, NVDIM). Each node can be different than another node and built by different qualified sources (Dell, HP, Lenovo, Supermicro, etc.). Each node can support multiple media types. With targeted volume placement, the system delivers the best economics for any use case (HDD for low-cost, SSD for performance). The architecture encourages tech refresh. Grow capacity with the best performance and density without needing to make a point in time technology “bet”. Low-latency. Datera founders created and maintain Linux IO. This experience has been applied to the block storage IO path. We have unmatched low-latency on industry standard software. Best TCO in the industry — even before operational benefits. Example: three year TCO for 750 TB is 7x less TCO than Ceph, 13x less than SolidFire and 5x less than equivalent in AWS.

Economically viable, low-latency, and block storage with the best TCO in the industry is the end goal of many service providers. But this is only half of our story.

We’ll continue the story by moving up toward the application to explain the rest, including “intent-defined.”

Datera’s architecture has three primary inputs:

1. Self-describing storage nodes — what the storage infrastructure can deliver (i.e. capacity, performance, replication, isolation, etc.) from both a node and cluster perspective.

2. Data center environment, capabilities, and constraints — this includes network throughput on each node, IP blocks, and availability zones.

3. Each application’s “intent” — from an application viewpoint, this includes what the app “wants” or “needs” from a storage infrastructure. Example: a database app might need “high capacity and performance” and a microservices or logging app might need “low capacity and performance”.

So what do we mean by “intent” as opposed to a pre-determined definition? It’s a critical element of the architecture which enables service delivery velocity, which until now, has never been possible.

Intent is quite simple. It’s an abstract expression of a specification or configuration for the requirements or needs of a microservice or application.

As an example, an app owner may define an intent for an app in abstracted expressions as “HIGH” IOPs, or “LOW” capacity, “HIGH” throughput, “MIN” or “MAX” replication. But what does “HIGH” IOPs mean if you don’t know the max IOPs possible in the cluster? What about tenant policies? Do different “HIGHs” exist? Does a Gold level tenant get a different “HIGH” than a Bronze level tenant? Does a “PRODUCTION” workload get a different “HIGH” than the same app deployed in “TEST,” even though is the same application?

Finally, how does the abstract expression of “intent” translate into deterministic instantiation of storage volumes that meet the app owner’s “intent”?

This right here is central point of Datera’s “Intent-Defined” storage architecture.

The three inputs (application intent, self-describing storage notes, and data center environmental variables) are constantly evaluated to self-optimize the cluster. This means, the composition of the underlying storage infrastructure is continuously being molded to best meet the needs and wants of the applications (based on intents) and multi-tenant policies.

For example, a MySQL app has an intent manifest that wants “MAX” IOPs, “HIGH” capacity, and “MAX” replication. A request comes from someone in the test/dev organization through the orchestration system to spin up 100 container instances. The tenant policy for test/dev defines “MAX” IOPs as 2,000 IOPs, “HIGH” capacity as 100 GB and “MAX” replication as R2. The instances are delivered.

Yet, if using the same MySQL intent manifest, the request comes from a production organizationuser, the instances would get 10K IOPs, 1 TB and R3, based on the production tenant policy. In either situation, the storage volumes are created automatically and instantly without human intervention.

If, let’s say, a month or so down the line new storage nodes are added to the cluster with the ability to deliver “MAX” IOPs of 50K. Any volumes being deployed or already deployed with “MAX” IOPs intent would be moved to new nodes automatically to maintain the “MAX” intent. This means no data migration. EVER.

By using this architecture, application owners can describe complete app environments where each microservice making up the environment can have differing “intents” for logging services, database services, and more. This means the orchestration systems to instantiate one or even thousands of instances in the app environment with a single API call. The Datera system puts volumes in the appropriate tier and continuously self-optimizes to maintain the “intended” service quality as defined by the combination of tenant policies and app intents.

Now that you have the basic understanding of “intent-defined,” stick around as we discuss in further posts how intents are mapped into container manifests, including how Datera works through Cinder in OpenStack clouds.