Storagebod Many years ago, as an entry-level systems programmer, I decided there were two teams that I was never going to join: the test team and the storage team - because they were boring.*
A fellow blogger has a habit of referring to storage as snorage and I suspect that is the attitude of many. So why do I keep doing storage?
Well, first, I have little choice but to stick to infrastructure. I’m a pretty lousy programmer and it seems that I can do less damage in infrastructure. If you have ever received more chequebooks in the post from a certain retail bank, I can only apologise.
But storage is cool. First of all, it’s BIG and EXPENSIVE - who doesn’t like raising orders for millions? It is also so much more than that just the place where you store your stuff: for starters, you have to get it back.
I think that people are beginning to realise that storage might be a little more complex than first thought. A few years ago, the average home user only really worried about how much disk they had. But the introduction of SSDs into the consumer market has hammered home how the type of storage matters - as does the impact it can have on the user experience.
Spinning rust platters keep getting bigger, but for many, this just means that the amount of free disk keeps increasing. However, the increase in speed is what people really want. Instant On ... it changes things.
Even in the consumer market, which spends a bit less than the millions spent by big firms, storage is taking on a multi-dimensional personality. Consumer storage now scales both in capacity and speed.
In the enterprise, things are more interesting. Corporate types need the kit to perform well, and quickly, to squeeze the maximum value out of their staff and their purchase.
Capacity is obvious: how much space do you need? But performance is more complex and has more facets than most people realise. Are you interested in IOPs? Are you interested in throughput? Are you interested in aggregate throughput or single stream? Are you dealing with large or small files? Large or small blocks? Random or sequential?
Storage has a real effect on how your apps work
Now for 80 per cent of use cases, you can probably get away with taking a balanced approach and just allocating storage from a general purpose pool. But 20 per cent of your applications are going to need something different and that is where it gets interesting.
Most of the time when I have conversations with application teams or vendors and I ask what type of storage they require, they answer: "Fast". Then we have to discuss what "fast" means and whether the budget meets their desire to be "fast".
If we move to "software-defined storage", this could be a lot more complex than people think. Application developers need to understand fully how their applications store data and how they interact with the infrastructure they live on. If you pick the wrong pool, your application's performance could drop through the floor or achieve the wrong availability level - and the users would experience a massive outage.
So if you thought storage was snorage - most developers and people do - you might want to start taking an interest. If infrastructure becomes code, I might need to get better at coding, but some of you are going to have to get better at infrastructure.
Move beyond fast and large and try to understand the subtleties. It is it is interesting ... I promise you! ®
* I have recently I have run both a test team and a storage team. I confess to enjoying the experience immensely.