I have been thinking a lot about infrastructure composability since TFD17. I’ve always considered composability mostly as a marketing buzzword to shake up the server market a bit, especially in the blade segment. But, after talking with companies like DriveScale and Pavillion Data, I’ve changed my mind to the point that I’m now conducting a research for GigaOm with the goal to write a report about Composable Storage Infrastructures!
First discoveries
I’ve ascertained that composable infrastructures can be roughly broken down into three different typologies: Chassis-, Rack- and Datacenter-scale.
The first is more likely to suit enterprise needs in the small to medium size range, while the others are more tuned for specific use cases in large enterprises as well as service providers. There are exceptions of course but that’s the general idea.
I also found several players in the market, many more that I thought at the beginning, and most of them are recently founded startups with interesting ideas and innovative products. It is also quite interesting to see that both Hardware- and Software-defined approaches are chosen all across the spectrum of solutions.
What is storage infrastructure composability?
Opposed to Convergence first and hyperconvergence later, infrastructure composability is all about efficiency, agility and granularity to bring the necessary resources where they are actually needed quickly.
In general terms, storage composability organizes all available resources in large pools that can be distributed to servers by applying policies and templates allowing, for example, to configure a large cluster of servers in a few minutes. When explained in this way it looks like a SAN but, if you dig deeper, it is easy to discover that we are talking about large amounts of raw resources or, at least, volumes that look like direct attached devices. And in the scale-out world we are living now, with Big Data, HPC, and other share nothing cluster designs that are more and more common, direct attached storage is the new black (again!).
When does infrastructure composability makes sense?
Long story short, it makes sense in ever changing infrastructures such as in the case of service providers, for example, but also for any other infrastructure that needs to be repurposed quickly when necessary; just to make another example, think at two or more teams with different big data applications, each one of them needing specific resources for a few days, or hours, per week. You probably work with Linux and bare-metal servers without expensive virtualization layers… and here is exactly where storage composability really shines.
Composability and Automation are best friends
Most of the solutions have nice UIs and you can deploy thousands of servers through that kind of interface (look at the video from ScaleDrive session at TFD17 for example), but you can reach the full potential of these solution when they are managed through automation tools like Ansible and the like. You just run your playbooks to get a full functioning Hadoop cluster in minutes and that’s it. Probably your persistent storage is a large external scale-out repository and you just need to copy your data set locally ofor that precise job, after it is finished you can just reconfigure the cluster for the next application.
Automation, means APIs of course, and I do not think you can get a real composable infrastructure without a decent API to make all the provisioning process fully automated, without the need of human intervention.
Closing the circle
If you want to get a grasp about storage infrastructure composability you should probably take a look at the videos recorded at TFD17 at DriveScale. They are quite interesting and educative.
As I said I started to look into storage composability more seriously now and it is the focus of an upcoming report I’m writing for GigaOm Research. stay tuned!
Disclaimer: I was invited to Tech Field Day 17 by GestaltIT and they paid for travel and accommodation, I have not been compensated for my time and am not obliged to blog. Furthermore, the content is not reviewed, approved or edited by any other person than the Juku team.
