Diamanti and State Management in Kubernetes

I’ve been tracking Diamanti since I encountered them at KubeCon 2016 in Seattle, WA and I noted at the time how Persistent Volumes were a bit of a hack.

Diamanti sells several things. It sells a hyperconverged family of hardware that runs Kubernetes as a kind of bare-metal k8s appliance so there’s no virtual-machine later in between the hardware and the containers. Diamanti also make hardware accelerator cards, Diamanti Ultima, that go in these appliances to speed up storage and network performance, and it looks like you can now buy these things separately. There’s also the software layer called Spektra that does the Kubernetes management and control plane parts and it looks like Diamanti now also sell that separately.

Splitting out the cards and software from the appliance makes sense because the HCI bandwagon has pretty much rolled into a ditch. The big gains have been made, and it’s now solidly moving into the economy-of-scale, town planning stage, so market share has entered the power law top-3 winners and “the rest” stage. Any HCI play now is only going to work for specialised niches or getting bought by a bigger player, and those acquisitions have all happened already.

There’s a potential channel play for accelerator cards if you can convince a server maker that the benefit of buying from you is cheaper/easier/faster than building one themselves. We see this play out fairly regularly, and you then just become a component maker in the supply chain. Selling direct to the customer only really works for consumer products like graphics cards, not for B2B products like the Ultima.

Then you’ve got the “make Kubernetes easier to manage” software things, of which there are dozens because Kubernetes is currently fashionable and it’s also terribly complex and hard to use in the real world. The play here is again a “build versus buy” situation but you’re trying to convince customers it’s easier to buy from you than to build something themselves or just run one of the managed Kubernetes services. There’s a lot of competition in this market at the moment as people try a bunch of things, and some early consolidation such as SUSE buying Rancher.

This probably has the greatest potential upside for Diamanti, but it’s also a tough market to play in while simultaneously trying to succeed in two other different markets. I see Diamanti exiting the HCI side of things completely, selling the accelerator cards business (perhaps just licensing the IP for cashflow), and then focusing on the k8s management pieces.

Part of the challenge here is the early focus on “k8s, but stateful” which I think is the completely wrong way to think about Kubernetes. Stateful containers are the exception that lives deep down in the layers of abstraction that are a modern IT stack.

I’ve started to think about container-based applications in general, and Kubernetes in particular, as being best suited to a good old-fashioned three-tier architecture.

There’s an access and routing layer that receives inbound requests for services and routes them to the appropriate micro-service. This used to be the load-balancer and webserver tier, and while it’s more complicated in Kubernetes the function is basically the same. There isn’t really any code here, it’s more configuration of standardised components.

Containers are superb here. What state exists is basically cache and session persistence, and it isn’t really shared between components. You can throw it away and start again with a fresh container every invocation, if you want.

Then there’s the application tier, which is where the code lives. This is the logic of your app that responds to queries (GET or PUT, Create/Modify/Delete or whatever) and it functions on state but is itself stateless.

Again, containers are great for this tier, because you can change the code by swapping out containers. With some coordination with the web/routing tier, you can pretty easily do canary deployments by sending a small amount of traffic to the new code to see if it works properly, and roll it back to the last known-good container version if not. The statelessness of containers is ideally suited to the goal we’re trying to achieve.

And then there’s the stateful tier: the database. All state lives in a database. All state should live in a database. A filesystem is, essentially, a database. If you need the characteristics of different kinds of databases—RDBMS, object store, filestore, columnar data, graph data, time series data—just use a different kind of database service provided to your web and app tiers.

And you can compose your database itself as a web, app, database tier system. There’s an access and routing tier, and app tier for the logic, and the raw data store (perhaps a filesystem of some kind). Ultimately the data lives on some kind of physical media (spinning disk, SSD, RAM, whatever) which is, you guessed it, a database service. It’s turtles all the way down.

Focusing on the lowest layer of turtles isn’t interesting to a large enough subset of the people interested in Kubernetes. They’re mostly building the apps that are visible to the rest of the world, so they only really see the uppermost layers of this turtle stack. State management happens in a cloud service they use, or as a thing they buy from a database vendor that deals with the lower level turtles on the customer’s behalf.

To be clear, there is value in concentrating on the lowest level of turtles, but there aren’t many companies manufacturing SSDs and writing customer facing applications, let alone also doing all the other layers of turtles all the way down, and none of them are good at all of it.

Division of labour is a thing and it works, partly because different people are good at—and enjoy—different things.

Vive la différence!