Blog B as in back-end, of course...
My attraction to this technology started when it was first introduced on Sun Solaris and I had the opportunity to work with it. Now, of course, it is more appealing and portable than back in 2005.
Indeed containers are quickly becoming one of the most compelling revolutions to hit IT in the last decade. For many, in fact, it can arguably be just a leaner form of virtualisation, but there is much more than that, especially when it comes to corner cases as with storage.
Agility at the back-end
One of the most appealing aspects of containers is the simplification of software distribution. Because of its stateless and disposable nature, a container image can be easily updated, and containers in production can be killed and re-instantiated from a newer image in seconds.
This simple mechanism is of great interest to the vast majority of storage vendors, and many are working to deploy their software through containers. This is not difficult, especially because Linux is now quite common among software-defined and traditional storage vendors, and mosthave already moved all of their code out of the kernel space a while ago.
The results are clearly visible. They have an easier way to distribute software, but other advantages come from the ability to speed up software release cycles (some vendors are considering releasing one new version per month, or even more frequently) and even from the ability to maintain more versions of the same piece of software on the same machine. You don’t run them at the same time -but it’s of great use when it comes to doing a roll-back after discovering a bug, for example.
Not everything… not now
Actually, we’re still at the beginning and vendors are taking their time to “containerise” their software … we are talking about storage, after all.
There are at least a couple of problems. The first hinges on how software is written and organised. For some components it’s straightforward; they are stateless and it’s quite easy to put them in a container (a management console could be a good example). But sometimes they are stateful and essential for data consistency.
In these cases it’s quite hard to put software in a container because of the maturity of the container mechanism itself and its inability to have direct hardware access. It’s not impossible though and in time we are sure to see the deployment of more and more pieces of the stack in containers.
The second problem comes from human psychology. You know the saying “if it works, don’t mess with it!”. Storage is a very conservative field, possibly the most conservative of the entire data centre. Telling a Storage Admin that his or her storage system will be updated on a bi-weekly basis is quite difficult… isn’t it? But again sooner or later it will happen with storage too.
Closing the circle
Storage is a fundamental component of the infrastructure stack and the role of infrastructure is to serve data and applications. At the end of the day, if the way of developing, delivering and consuming applications has changed, infrastructure must follow and storage should not be an exception.
I know, it will take time (also because some software stacks were not written to be unpacked and delivered as a set of micro services …) but I’m also certain that the benefits of this approach are manifold and that we’ll be seeing more and more containers in the back end of our storage systems.®