Pure Storage – “Architecture Matters”

I received my Xtremio Upgrade Survival Kit from Pure Storage last week and wanted to just provide a little of commentary on it. I know it’s “old news” now, but it’s been on my mind for a while and the gift pack prompted me to burst into print.


Firstly, it was interesting to see the blogosphere light up when news broke that the upgrade from 2.4 to 3 was destructive. You can read a few of the posts from Nigel here, Chris here and Enrico here. Chad tried to defend the position with a typically insightful (and when you’re a VP with the vendor you hope it’s insightful) post that defended a number of decisions that got them to that point and was basically a mea culpa combined with a broader discussion around architecture. The vendors didn’t miss their chance either, with Vaughn having his say here and an interesting post by Calvin that you can read here.

But the post that I think put everything in perspective was Stephen’s. Yes, it’s all technically a bit of a mess. But we’ve been conditioned for so long to read between the lines of vendor glossies and not believe that anything is ever really non-disruptive. Every NDU carries a risk that something will go pear-shaped, and we prepare for it. Most people have had an upgrade go wrong before, particularly if your job has been enterprise storage field upgrades for the last 5 – 10 years. It’s never pretty, it’s never fun, but nowadays we’re generally prepared for it.

While I enjoy the generally ballsy marketing from Pure Storage for calling out EMC on this problem, I think that ultimately we (partners, customers) are probably all not that fussed about it really. Not that I think it’s good that we’re still having these problems. Architecture does matter. But sometimes things get stuffed up.

As an aside though, how good would it be if you worked in an environment where all you needed to do was fill out a paper slip to do a change?

Storage – Capacity planning thinky post

I don’t like to do too many thinky-type blog posts, preferring instead for this to be more a vehicle for educational demonstration. I tend to spend too much time talking about how I don’t do these post too often. Then I spend as little time on the idea as possible. Invariably, I’ll finish off with some naff comment that doesn’t in any way support what I’ve said previously. That said, I’ve been thinking a bit lately about how we approach capacity planning, and our view on the overall health of infrastructure. Having been on the ops side of the fence, then moving between solution architecture and systems integration, I’ve seen a number of approaches to the problem. So I guess I just wanted to put this out there as a concept that, while it’s by no means new, is sometimes overlooked by punters and integrators alike.

In my opinion, there are three elements that are key to the overall health and usefulness of a storage array. These are:

  • Configuration;
  • Capacity; and
  • Performance.

The ability of a storage array and, indeed, other infrastructure (such as compute and network) to service the requirements of its applications is dependent on these elements in the following way:

  • Configuration – the ability of the array to be perform tasks as intended by the vendor;
  • Capacity – the capability of the array to provide sufficient storage to meet the applications’ requirements; and
  • Performance – the ability of the array to service the requirements of the hosted applications from a performance perspective.

If any of these elements are not functioning as designed, the capacity of the array to perform as expected is diminished. In my day job I have clients asking for capacity plans all of the time. Oftentimes, I think, we spend too much time on one of these elements, but not enough time on all three. Ideally, you want a platform that takes care of all of this for you. I suppose the point I’m trying to make is that if your preferred vendor isn’t talking to you about capacity planning in these terms, maybe it’s time to re-think who you’re talking to.