Storagebod Rotating Header Image

Cynic

Five Years On (part 3)

So all the changes referenced in part 2, what do they mean? Are we are at an inflection point?

The answer to the latter question is probably yes but we could be at a number of inflection points both localised vendor inflection points but also industry-wide ones as well. But we’ll probably not know for a couple more years and then with hindsight we can look back and see.

The most dramatic change that we have seen in the past five years is the coming of Flash-based storage devices; this is beginning to change our estates and what we thought was going to become the norm.

Five years ago; we were talking about general purpose, multi-tier arrays; automated tiering and provisioning but all coming together in a single monolithic device. The multi-protocol filer model was going to become the dominant model; this was going to allow us to break down silos in the data centre and to simply the estate.

Arrays were getting bigger as were disks; i/o density was a real problem and generally the slowest part of any system was the back-end storage.

And then SSDs began to happen; I know that flash-based/memory-based arrays have been around for a long time but they were very much specialist and a niche market. But the arrival of the SSD; flash in familar form-factor at a slightly less eye-watering price was a real change-bringer.

EMC and others scrambled to make use of this technology; treat them as a faster disk tier in the existing arrays was the order of the day. Automated Storage Tiering technology was the must have technology for many array manufacturers; few customers could afford to run all of their workloads on an entirely SSD-based infrastructure.

Yet if you talk to the early adopters of SSDs in these arrays; you will soon hear some horror stories; the legacy arrays simply were not architected to make best use of the SSDs in them. And arguably still aren’t; yes, they’ll run faster than your 15k spinning rust tier but you are not getting the full value from them.

I think that all the legacy array manufacturers knew that there were going to be bottle-necks and problems; the different approaches that the vendors take almost points to this and the different approaches taken by a single vendor..from using flash as a cache to utilising it simply as a faster disk…using it as extension of the read cache to using it as both a read and write cache.

Vendors claiming that they had the one true answer….none of them did.

This has enabled a bunch of start-ups to burgeon; where confusion reigns, there is opportunity for disruption. That and the open-sourcing of ZFS has built massive opportunity for smaller start-ups, the cost of entry into the market has dropped. Although if you examine many of the start-ups offerings; they are really  a familiar architecture but aimed at a different price point and market as opposed to the larger storage vendors.

And we have seen a veritable snow-storm of cash both in the form of VC-money but also acquisition as the traditional vendors realise that they simply cannot innovate quickly enough within their own confines.

Whilst all this was going on; there has been an incredible rise in the amount of data that is now being stored and captured. The more traditional architectures struggle; scale-up has it’s limits in many cases and techniques from the HPC market place began to become mainstream. Scale-out architectures had begun to appear; firstly in the HPC market, then into the media space and now with the massive data demands of the traditional enterprises…we see them across the board.

Throw SSDs, Scale-Out together with Virtualisation; you have created a perfect opportunity for all in the storage market to come up with new ways of fleecing providing value to their customers.

How do you get these newly siloed data-stores to work in harmonious and easy to manage way? How do we meet the demands of businesses that are growing ever faster. Of course we invent a new acronym that’s how….’SDS’ or ‘Software Defined Storage’

Funnily enough; the whole SDS movement takes me right back to the beginning; many of my early blogs were focused on the terribleness of ECC as a tool to manage storage. Much of it due to the frustration that it was both truly awful and was trying to do to much.

It needed to be simpler; the administration tools were getting better but the umbrella tools such as ECC just seemed to collapse under their own weight. Getting information out of them was hard work; EMC had teams devoted to writing custom reports for customers because it was so hard to get ECC to report anything useful. There was no real API and it was easier to interrogate that database directly.

But even then it struck me that it should have been simple to code something which sat on top of the various arrays (from all vendors); queried them and pulled back useful information. Most of them already had fully featured CLIs; it should have been not beyond the wit of man to code a layer that sat above the CLIs that took simple operations such as ‘allocate 10x10Gb LUNs to host ‘x’ ‘ and turn them into the appropriate array commands; no matter which array.

I think this is the promise of SDS. I hope the next five years will see the development of this; that we see storage with in a data-centre becoming more standardised from an programmatic point of view.

I have hopes but I’m sure we’ll see many of the vendors trying to push their standard and we’ll probably still be in a world of storage silos and ponds…not a unified Sea of Storage.

 

 

What a Waste..

Despite the rapid changes in the storage industry at the moment, it is amazing how much everything stays the same. Despite compression, dedupe and other ways people try to reduce and manage the amount of data that they store; it still seems that storage infrastructure tends to waste many £1000s just by using it according to the vendor’s best practise.

I spend a lot of my time with clustered file-systems of one type or another; from Stornext to GPFS to OneFS to various open-source systems and the constant refrain comes back; you don’t want your utilisation running too high..certainly no-more than 80% or if you feeling really brave, 90%. But the thing about clustered file-systems is that they tend to be really large and wasting 10-20% of your capacity rapidly adds up to 10s of £1000s. This is already on-top of the normal data-protection overheads…

Of course, I could look utilising thin-provisioning but the way that we tend to use these large file-systems does not it lend itself to it; dedupe and compression rarely help either.

So I sit there with storage which the vendor will advise me not to use but I’ll tell you something, if I was to suggest that they didn’t charge me for that capacity? Dropped the licensing costs for the capacity that they recommend that I don’t use; I don’t see that happening anytime soon.

So I guess I’ll just have factor in that I am wasting 10-20% of my storage budget on capacity that I shouldn’t use and if I do; the first thing that the vendor will do if I raise a performance related support call is to suggest that I either reduce the amount of data that I store or spend even more money with them.

I guess it would be nice to be actually able to use what I buy without worrying about degrading performance if I actually use it all. 10% of that nice bit of steak you’ve just bought…don’t eat it, it’ll make you ill!

Don’t shoot the Messenger’s Friends….

Word has reached me that EMC Marketing may not be reacting so well to my previous post; yet if truth be known, I actually toned down what I really wanted to write because I wanted to ensure that people who I like and have time for didn’t catch so much flack. Although I speak only for myself, I know that I am not the only person who feels similarly about the current strain of EMC Marketing.

What I found so disappointing with the Mega-Launch is that with-in the hype and general hullabaloo; there are some interesting pearls but they got lost.

The re-write of the VNX2 code is very long overdue and from what I see gives EMC a solid base for their mid-range offering; it should allow them to support their current user-base whilst they work out how to transform them into the scale-out world.

It will allow them to take advantage of the tick-tock releases from Intel and if they have done serious work on the RAID code; it would surprise me if they haven’t at least enabled the possibility of a different data-protection method in the future; for example a micro-RAID enabling RAID to be better distributed across all disks and improving re-build times.

To move to a more modular software architecture has to be sensible and should allow them to transition to a software only virtual array in the future.

If they’d talked about such things as opposed to concentrating on the hype; putting the VNX2 into a context of future innovation…that’d been more interesting.

Of course EMC continue to talk very fast about VNX being a unified platform when all reality; we know it’s not really…not in the way that NetApp is. But that’s fine but it still grates that Marketing smoke and mirrors are involved.

But the VNX2 announcement is not without problems either; can I take an existing VNX and migrate non-disruptively to this new code? Do I have to take services and products such as VPLEX to enable this?

And then there was the ViPR GA announcement; much more detail and context could have been put around this; especially when aligned with the Nile ‘product’. I can see the beginnings of a platform strategy emerging and an interesting one at that. I’d be interested to know how some of their partner’s products fit into the picture; companies such as Panzura for example?

Yet where are the blogs, the context setting for these announcements? This side of EMC ‘marketing’ has sadly vanished only to be replaced by glitz. I think if the announcements had been accompanied by blogs and commentary more akin to Storagezilla’s here; much could have been forgiven and the announcement could have put to one side as the carnival it was.

It is sad that I miss Chuck’s take on these announcements; I know that Chuck was a real drum beater for EMC but there would have been technical content and interesting pearls in the blog. These days, it seems that the real detail has to be obtained face-to-face where most of the crap can be cut through.

So with a VMAX announcement probably due next year, probably at EMC World…I would hope for a more considered approach and a more balanced approach but I shan’t be holding my breath. Breathless seems to be the current EMC Marketing approach.

EMC have some good, some great and some products with serious challenges….I know from my day-to-day dealings with EMC that some are really trying to shift culture and convince customers that they are different.

Today’s Megalaunch leads me to question that.

 

Excessive Sorrow Laughs….

So you’ve manage to get yourself a job in storage? Commiserations, why did you do something so crazy; I hope you enjoy pain and misery, this is now your world. Perhaps if you do a great job, you’ll come back as something higher up the food chain such as desktop support.

Anyway here’s some hints and tips

1) You will never have the right amount and type of storage but it is probably better to have too much than too little. Applications fall-over when they run out of storage and adding new storage into an environment at a run is never a great deal of fun. Don’t believe vendors when they tell you that it is non-disruptive; even if it is non-disruptive technically, it will always be disruptive in other ways that you do not expect.

Learn to be economical with the truth about what you actually have available; keep something in your back-pocket for a rainy day but don’t save the day too often. Miracles need to be the exception as opposed to the rule.

2)Related to this is the fact that no end-user has any actual idea of how much storage they will use. They will glaze over when you start talking about terabytes, gigabytes, exabytes; my experience recently is that they under-estimate but this is probably a factor of the sector I’m in.

3)Every best practice document appears to have been written by someone who has shares in a storage company. This is especially true for databases; you have various options…

  • smile and allocate what they ask for
  • smile and tell them that you’ve allocated what they’ve asked for
  • frown and have an argument
I’ve been around for long enough to know that the last option maybe the most tempting but it only leads to pain.

4)Non-disruptive upgrades are rarely so; read the small print as to what non-disruptive means. Code upgrades will always result in more work for every other team as opposed to the Storage team as they struggle to bring their environments up to scratch to meet the crazed requirements of your chosen storage vendors.

5)Fibre-channel is not a standard; it is a vague suggestion of how things should work. Hence point 4)! But Fibre-channel scares the crap out of people, you start waffling on about FLOGIs and you can get away with murder. (Serious hint, don’t mix up WWPNs and WWNNs…understand the difference..please!)

6)Of course you will be tempted to head down the NAS route; whatever you do, don’t mix NFS and SMB shares…every vendor claims that they have a solution to the inherent problems with the mixed security model. They don’t! It breaks in subtle ways and never underestimate the power of a Mac user to put some very strange things in a filename.

7)’But I can buy a 1Tb USB disk in PC World for £50′; learn to tune this statement out or you will be committed or jailed.

8)Everyone can do your job better than you can….until it goes wrong. In your darkest hours, remember point 4); there is nothing more joyful than realising that a single storage upgrade can mean many hours of disrupted lives for every other team.

9)There is always a better technology; you just didn’t buy it. Don’t worry about it; what you’ve got will do most of what you want and probably most of the time. This is why the same sales-guy you bought NetApp from will later turn up selling you EMC; they aren’t clever enough to understand subtle differences in technologies…so basically, they are selling you a different badge.

10)Storage is actually quite easy…everything which surrounds it is hard…

11)Learn to laugh….

The Reptile House

I was fortunate enough to spend an hour or so with Amitabh Srivastava of EMC; Amitabh is responsible for the Advanced Software division in EMC and one of the principal architects behind ViPR. It was an open discussion about the inspiration behind ViPR and where storage needs to go. And we certainly tried to avoid the ‘Software Defined’ meme.

Amitabh is not a storage guy; in fact his previous role with Microsoft sticks him firmly in the compute/server camp but it was his experience in building out the Azure Cloud offering which brought him appreciation of the problems that storage and data face going forward. He has some pretty funny stories about how the Azure Cloud came about and the learning experience it was; how he came to realise that this storage stuff was pretty interesting and more complex that just allocating some space.

Building dynamic compute environments is pretty much a solved problem; you have a choice of solutions and fairly mature ones. Dynamic networks are well on the way to being solved.

But building a dynamic and agile storage environment is hard and it’s not a solved problem yet. Storage and more importantly the data it holds has gravity or as I like to think of it, long-term persistence. Compute resource can be scaled up and down; data rarely has the idea of scaling down and generally hangs around. Data Analytics just means that our end-users are going to hug data for longer. So you’ve got this heavy and growing thing…it’s not agile but there needs to be some way of making it appear more agile.

You can easily move compute workloads and it’s relatively simple to change your network configuration to reflect these movements but moving large quantities of data around, this is a non-trivial thing to do…well at speed anyway.

Large Enterprise Storage environments are heterogeneous environments, dual supplier strategies are common; sometimes to keep vendors honest but often there is an acceptance the different arrays have difference capabilities and use-cases. Three or four years ago, I thought we were heading towards general purpose storage arrays; we now have more niche and siloed capabilities than ever before. Driven by developments in all-flash arrays, commodity hardware and new business requirements; the environment is getting more complex and not simpler.

Storage teams need a way of managing these heterogenous environments in a common and converged manner.

And everyone is trying to do things better, cheaper and faster; operational budgets remain pretty flat, headcounts are frozen or shrinking. Anecdotally, talking to my peers; arrays are hanging around longer, refresh cycles have lengthened somewhat.

EMC’s ViPR is attempt to solve some of these problems.

Can you lay a new access protocol on top of already existing and persistent data?  Can you make so that you don’t have to migrate many petabytes of data to enable a new protocol?  And can you ensure that your existing applications and new applications can use the same data without a massive rewrite? Can you enable your legacy infrastructure to support new technologies?

The access protocol in this case is Object; for some people Object Storage is religion…all storage should be object, why the hell do you want some kind of translation layer. But unfortunately, life is never that simple; if you have a lot of legacy applications running and generating useful data, you probably want to protect your investment and continue to run those applications but you might want to mine that data using newer applications.

This is heresy to many but reflects today’s reality; if you were starting with a green-field, all your data might live in an object-store but migrating a large existing estate to an object-store is just not realistic as a short term proposition.

ViPR enables your existing file-storage to be accessible as both file and object. Amitabh also mentioned block but I struggle with seeing how you would be able to treat a raw block device as an object in any meaningful manner. Perhaps that’s a future conversation.

But in the world of media and entertainment, I could see this capability being useful; in fact I can see it enabling some workflows to work more efficiently, so an asset can be acquired and edited in the traditional manner; then ‘moving’ into play-out as an object with rich-metadata but without moving around the storage environment.

Amitabh also discussed possibilities of being able to HDFS your existing storage, allowing analytics to be carried out on data-in-place without moving it. I can see this being appealing but challenges around performance, locking and the like become challenging.

But ultimately moving to an era where data persists but is accessible in appropriate ways without copying, ingesting and simply buying more and more storage is very appealing. I don’t believe that there will ever be one true protocol; so multi-protocol access to your data is key. And even in a world where everything becomes objects, there will almost certainly be competing APIs and command-sets.

The more real part of ViPR; when I say real, I mean it is the piece I can see huge need for today; is the abstraction of the control-plane and making it look and work the same for all the arrays that you manage. Yet after the abomination that is Control Center; can we trust EMC to make Storage Management easy, consistent and scalable? Amitabh has heard all the stories about Control Center, so lets hope he’s learnt from our pain!

The jury doesn’t even really have any hard evidence to go on yet but the vision makes sense.

EMC have committed to open-ness around ViPR as well; I asked the question…if someone implements your APIs and makes a better ViPR than ViPR? Amitabh was remarkably relaxed about that, they aren’t going to mess about with APIs for competitive advantage and if someone does a better job than them; then that someone deserves to win. They obviously believe that they are the best; if we move to a pluggable and modular storage architecture, where it is easy to drop-in replacements without disruption; they better be the best.

A whole ecosystem could be built around ViPR; EMC believe that if they get it right; it could be the on-ramp for many developers to build tools around it. They are actively looking for developers and start-ups to work with ViPR.

Instead of writing tools to manage a specific array; it should be possible to write tools that manage all of the storage in the data-centre. Obviously this is reliant on either EMC or other storage vendors implementing the plug-ins to enable ViPR to manage a specific array.

Will the other storage vendors enable ViPR to manage their arrays and hence increase the value of ViPR? Or will it be left to EMC to do it; well, at launch, NetApp is already there. I didn’t have time to drill into which versions of OnTap however and this where life could get tricky; the ViPR-control layer will need to keep up with the releases from the various vendors. But as more and more storage vendors are looking at how their storage integrates with the various virtualisation-stacks; consistent and early publications of their control functionality becomes key. EMC can use this as enablement for ViPR.

If I was a start-up for example, ViPR could enable me to fast-track management capability of my new device.I could concentrate on storage functionality and capability of the device and not on the periphery management functionality.

So it’s all pretty interesting stuff but it’s certainly not a forgone conclusion that this will succeed and it relies on other vendors coming to play. It is something that we need; we need the tools that will enable us to manage at scale, keeping our operational costs down and not having to rip and replace.

How will the other vendors react? I have a horrible suspicion that we’ll just end up with a mess of competing attempts and it will come down to the vendor who ships the widest range of support for third party devices. But before you dismiss this as just another attempt from EMC to own your storage infrastructure; if a software vendor had shipped/announced something similar, would you dismiss it quite so quickly? ViPR’s biggest strength and weakness is……EMC!

EMC have to prove their commitment to open-ness and that may mean that in the short term, they do things that seriously assist their competitors at some cost to their business. I think that they need to almost treat ViPR like they did VMware; at one point, it was almost more common to see a VMware and NetApp joint pitch than one involving EMC.

Oh, they also have to ship a GA product. And probably turn a tanker around. And win hearts and minds, show that they have changed…

Finally, let’s forget about Software Defined Anything; let’s forget about trying to redefine existing terms; it doesn’t have to be called anything…we are just looking for Better Storage Management and Capability. Hang your hat on that…

 

5 Minutes

One of the frustrations when dealing with vendors is actually getting real availability figures for their kit; you will get generalisation,s like it is designed to be 99.999% available or perhaps 99.9999% available. But what do those figures really mean to you and how significant are they?

Well, 99.999% available equates to a bit over 5 minutes of downtime and 99.9999% equates to a bit over 30 seconds downtime over a year. And in the scheme of things, that sounds pretty good.

However, these are design criteria and aims; what are the real world figures? Vendors, you will find are very coy about this; in fact, every presentation I have had with regards to availability are under very strict NDA and sometimes not even notes are allowed to be taken. Presentations are never allowed to be taken away.

Yet, there’s a funny thing….I’ve never known a presentation where the design criteria are not met or even significantly exceeded. So why are the vendors so coy about their figures? I have never been entirely sure; it may be that their ‘mid-range’ arrays display very similar real world availability figures to their more ‘Enterprise’ arrays…or it might be that once you have real world availability figures, you might start ask some harder questions.

Sample size; raw availability figures are not especially useful if you don’t know the sample size. Availability figures are almost always quoted as an average and unless you’ve got a real bad design; more arrays can skew figures.

Sample characteristics; I’ve known vendors when backed into a corner to provide figures do some really sneaky things; for example, they may provide figures for a specific model and software release. This is often done to hide a bad release for example. You should always try to ask for the figures for the entire life of a product; this will allow you to judge the quality of the code. If possible as for a breakdown on a month-by-month basis annotated with the code release schedule.

There are many tricks that vendors try to pull to hide causes of downtime and non-availability but instead of focusing on the availability figures; as a customer, it is sometimes better to ask different specific questions.

What is the longest outage that you have suffered on one of your arrays? What was the root cause? How much data loss was sustained? Did the customer have to invoke disaster recovery or any recovery procedures? What is the average length of outage on an array that has gone down?

Do not believe a vendor when they tell you that they don’t have these figures and information closely and easily to hand. They do and if they don’t; they are pretty negligent about their QC and analytics. Surely they don’t just use all their Big Data capability to crunch marketing stats? Scrub that, they probably do.

Another nasty thing that vendors are in the habit of doing is forcing customers to not disclose to other customers that they have had issues and what they were. And of course we all comply and never discuss such things.

So 5 minutes…it’s about long enough to ask some awkward questions.

End Of Year Thoughts

I constantly wonder at hype and how it takes hold; Storage seems to be especially vulnerable to this at present, we are under constant bombardment that this technology or that technology will make our lives easier, our businesses more profitable and the world a better place. From the use of SSDs to the deployment of big data analytics for marketing; it is a barrage not seen in IT since the claims that 4GL languages were going to make every programmer in the world redundant.

Every year is going to be the year of the Cloud, Big Data, BYOD, VDI; every year it seems to be the year of something new but also the year of last year’s product; Product Will Eat Itself, every meme perpetuating another meme.

Analysts struggle to make sense and come up with meaningless tools to demonstrate that they know even less about the real world than you could possibly have thought; Magic Quadrants, Points of Proof, Hype-Cycles and Fluffy Clouds are used to try to influence people and con the influencers.

More and more products come to the market and vanish to all intents and purposes. Some find homes in niches allowing the vendor to claim some kind of success. Just don’t prod and poke too hard. There are simply too many start-ups in storage at the moment to make much sense of the market; many with the same USP.

Yet how many of us make time to talk properly to the vendors and give them some honest feedback? And how often is that feedback well received? Unfortunately we are all too nice in general and possibly afraid of upsetting someone. This will probably surprise many of the vendors out there but many of us do hold back (there are some grumpy exceptions).

Some vendors are very good at getting out and talking at the C-level; I’d like to see more vendors getting out and talking with the levels below. I’d like 2013 to be the year that you solve some of my problems and not just the CIO’s…because if you do, you might just find that I have time to implement this year’s product and may be buy some more product instead of bitching about the maintenance costs of last year’s product.

Software Sucks!

Every now and then, I write a blog article that could probably get me sued, sacked or both; this started off as one of those and has been heavily edited as to avoid naming names…

Software Quality Sucks; the ‘Release Early, Release Often’ meme appears to have permeated into every level of the IT stack; from the buggy applications to the foundational infrastructure, it appears that it is acceptable to foist beta quality code on your customers as a stable release.

Having run a test team for the past few years has been eye-opening; by the time my team gets hands on your code…there should be no P1s and very few P2s but the amount of fundamentally broken code that has made it to us is scary.

And then also running an infrastructure team, this is beyond scary and heading into realms of terror and just to make things nice and frightening, every now and then, I ‘like’ to search vendor patch/bug databases for terms like ‘data corruption’, ‘data loss’ and other such cheery terms; don’t do this if you want to sleep well at night.

Recently I have come across such wonderful phenomena as a performance monitoring tool which slows your system down the longer it runs; clocks that drift for no explicable reason and can lock out authentication; reboots which can take hours; non-disruptive upgrades which are only non-disruptive if run at a quiet time; errors that you should ignore most of the time but sometimes they might be real; files that disappear on renaming; updates replacing a update which makes a severity 1 problem worse..even installing fixes seems to be fraught with risk.

Obviously no-one in their right minds ever takes a new vendor code release into production; certainly your sanity needs questioning if you put a new product which has less than two year’s GA into production. Yet often the demands are that we do so.

But it does lead me wondering, has software quality really got worse? It certainly feels that it has? So what are the possible reasons, especially in the realms of infrastructure?

Complexity? Yes, infrastructure devices are trying to do more; no-where is this more obvious than in the realms of storage where both capabilities and integration points have multiplied significantly. It is no longer enough to support the FC protocol; you must support SMB, NFS, iSCSI and integration points with VMware and Hyper-V. And with VMware on an 12 month refresh cycle pretty much, it is getting tougher for vendors and users to decide which version to settle on.

The Internet? How could this cause a reduction in software quality? Actually, the Internet as a distribution method has made it a lot easier and cheaper to release fixes; before if you had a serious bug, you would find yourself having to distribute physical media and often in the case of infrastructure, mobilising a force of Engineers to upgrade software. This cost money, took time and generally you did not want to do it; it was a big hassle. Now, send out an advisory notice with a link and  let your customers get on with it.

End-users? We are a lot more accepting of poor quality code; we are used to patching everything from our PC to our Consoles to our Cameras to our TVs; especially, those of us who work in IT and find it relatively easy to do so.

Perhaps it is time to start a ‘Slow Software Movement’ which focuses on delivering things right first time?

No Pain, No Gain?

I always reserve my right to change my mind and I am almost at the stage that I have changed my mind on blocks/stacks or whatever you want to call them? And for non-technical and non-TCO related reasons.

I think in general componentised and commodity-based stacks make huge sense; whether you are building out private or a public infrastructure; a building block approach is the only really scalable and sustainable approach. And I wrote internal design documents detailing this approach eight or nine years ago; I know I’m not the only one and we didn’t call it cloud…we called it governance and sensible.

But where I have changed my opinions is on the pre-integrated vendor stacks; I think that they are an expensive way of achieving a standardised approach to deploying infrastructure and I have not changed from this opinion.

However I think that this cost may well be the important catalyst for change; if you can convince a CFO/CEO/CIO/CTO etc that this cost is actually an investment but to see a return on the investment that you need to re-organise and change the culture of IT, it might well worth be paying.

If you can convince them that without the cultural change, they will fail….you might have done us all a favour. If it doesn’t hurt, it probably won’t work. If it is too easy to write things off when it’s tough…it’ll be too easy to fall back into the rut.

So EMC, VCE, Cisco, IBM, NetApp, HP etc….make it eye-wateringly expensive but very compelling please. Of course, once we’ve made the hard yards, we reserve the right to go and do the infrastructure right and cheap as well.

Politics, Practicality, Principles and Pragmatism

Many IT infrastructure decisions are made for reasons which have little to do with the capability of the technologies and very few are even made with due consideration of investment returns, long term costs and even fewer are revisited with the light of truth shone upon them.

So it is a wonder that any IT infrastructure works at all?

Well not really, as we have moved into a pretty much homogenised environment where all is interchangeable and pretty much all is good enough; the decisions are going to be made for reasons other than technology.

Many decisions are made simply are the grounds that more of the same is the path of least resistance. You have already learnt to love what you hated about a product and you are comfortable with it.  You might have grown close to the account team, they know all your favourite restaurants and sporting events; why change? And change is costly.

Of course, then you get the obverse; you have learnt to hate what you loved and the account team has grown far too comfortable. Perhaps there’s been a change in account manager or simply you decide that you’ve spent too much money with a company. Of course at this point, you suddenly find that what you have been paying is far too much and the incumbent slashes their costs to keep the account. But you’ve had enough and you decide to change.

Then you get the principled decision; the decision which could be based on the belief that open-source is the right thing to do or perhaps you believe the security through obscurity myth. Sometimes these look like technological decisions but they are really nothing to do with technology in general.

So have we moved to a market where the technology is pretty much irrelevant and why?

I think that we have and for a pretty good reason; you can’t manage what you can’t measure and quite simply, we are still lousy in measuring what we do and what it means. It means that all decisions have to made based on reasons which often have dubious links with reality.

For all discussions about metering and service-based IT; I don’t believe that we are anywhere near it. Internal metering tools are often so expensive and invasive to implement that we don’t bother.

And what is worse, we are often working in environments which do not care really care; who really cares if solution ‘X’ is cheaper over five years than solution ‘Y’ as long as solution ‘Y’ is cheaper today. Tomorrow can look after itself, tomorrow is another budget year.

So not only is measurement not easy; perhaps we simply don’t care?

Perhaps the only option is just carry on doing what we think is as right as possible in the context that we work in?