Storagebod Rotating Header Image

Corporate IT

Storage Blues…

January not even out yet and already we have an interesting technology market happening; IBM’s withdrawal from the x86 server market does lead to a number of questions. Both on the future of IBM but also on what IBM feel the future of the market is; yet could this be another market that they withdraw from only to long-term regret as they did with the network market allowing Cisco to dominate?

IBM’s piecemeal withdrawal from the hardware market; a retreat to the highlands of the legacy enterprise market in hardware will lead to questions across the board as to what the future is for any IBM hardware. I am not sure of the market acceptance of their converged compute/network/storage strategy in the form of PureSystems; their me-too ‘Block’ offering but surely this is dead-duck now; Lenovo may continue to make the x86 components for IBM but how committed can we feel that IBM is to this. IBM appear to have completely ceded this space to their competitors; personally I’m not convinced by most of the converged offerings and the value but to completely cede a market seems to be rash.

But how does this impact IBM storage?

The heart of IBM’s Storwize product set is x86-based servers; SVC especially was ‘just’ an IBM server. IBM were one of the first companies who really leveraged the idea of the server as storage; Shark is and was simply a pair of RS/6000 or pSeries boxes, this has allowed them to utilise and share R&D across divisions. Something which should have been an advantage and enabled them to do some clever stuff; this stuff  they demonstrated yet never delivered.

Now there is no reason for them to simply source the servers from others, the same as almost every other storage company in the world and it moves the Storwize product set firmly into the realms of software (it was anyway) but will IBM move Storwize to a software-only product?

There is part of me who really feels that this is inevitable, it may be as a reaction to a move by a competitor; it may be as a move to enable a vV7000 to run as a cloud appliance? It may well end up being the only way that IBM can maintain any kind of foothold in the storage market.

No I haven’t forgotten XIV or IBM’s Flash offerings; XIV is a solid Tier 1.5 offering but it is also a collection of servers. XIV’s issue is really scalability and simply putting larger drives in is just reducing the IOP density. The Flash offering is as good as many and if you want raw performance without features; it is worth considering.

IBM’s GSS could be built into something which scales and with many of the ‘features’ of XIV. And in a software only IBM Storage strategy; it could develop into a solid product if some of the dependency on specific disk controllers could be relaxed. Yet the question has to be whether IBM has time.

And yet without either a scalable NAS or Object store; IBM have some real problems. None of which are are really hardware problems but moving away from building your base platform probably makes none of them easier to solve.

Or perhaps if they concentrate on software and services….

Already Getting Busy…

I’ve not been away but a mixture of illness, Christmas and general lethargy have meant that I’ve not bothered with writing for a bit. But 2014 and a new year appears to be upon us and I do wonder what it is going to bring us, especially in the world of IT infrastructure.

As we ended 2013, we saw both winners and losers in the world of Flash for example; Violin crashing as they struggle to increase sales and reduce burn; yet Pure seem to be on a stellar rise and hiring like maniacs. A UK launch is imminent and they are going to be interesting to watch. All Flash Arrays are still very much niche and even companies who need them are holding off on making any big decisions.

I’ve already spoken to a hybrid vendor this year; pushing their hybrid is good enough for most cases, very tied to the virtualisation use-case. And yes, VDI all over their powerpoints as a use-case. 2014, the year when VDI happens!!

I expect that I’ll spend time with more hybrid vendors who are playing some kind of chicken with SSD/Disk ratios; how low can they go? However, I’m also seeing more KVM/Openstack appearing on road-maps as they begin to realise that VMware might not be the only game in town.

I’m sure we’ll see more hype around hyper-convergence as attempts continue to build a new mainframe and I shall continue to struggle to work out why anyone wants to? I like being able to scale my infrastructure in right place; I don’t want to have to increase my compute to increase my storage and vice versa. Flexibility around compute/storage and network ratios is important.

Yet convergence of storage and compute will continue and there’s potentially some real challenge to the traditional storage technologies there. If I was building a new infrastructure today, I’d be looking hard whether I needed a SAN at all. But I wouldn’t be going straight to a hyper-converged infrastructure; there be dragons there I suspect.

I’ve already had my first vendor conversation where I’ve suggested that they are actually selling a software product and perhaps they should drop the hardware part; that and asking why the hell were they touting their own REST API for cloud-like storage…if industry giants like EMC have struggled against the Amazon juggernaut, what makes they think that they are any different?

And marketing as differentiation will probably continue….especially as the traditional vendors get more defensive around their legacy products.  No-one should get rich selling disk any more but it won’t stop them all trying.

 

Feeling Lucky?

And here we go again, another IT systems failure at RBS; RBS appear to have been having a remarkable run of high-profile core-system failures but I suspect that they have been rather unlucky or at least everyone else has been lucky. Ross McEwan, the new Chief Executive of RBS has admitted that decades of under-investment in IT Systems is to blame.

Decades seems to be an awful long-time but may well be accurate; certainly when I started working in IT twenty-five years ago, the rot had already set in. For example, the retail-bank that I started at had it’s core standing order system written in pounds, shillings and pence with a translation routine sitting on top of it; yet many of these systems were supposed to have been re-written as part of the millenium-bug investigations. Most of this didn’t happen, whole-scale rewrites of systems decades old and with few people who understood how they worked, this was simply not a great investment; just patch it up and move on.

RBS are not going to be the only large company sitting on a huge liability in the form of legacy applications; pretty much all of the banks do and many others. Applications have been moved from one generation of mainframe to the next and they still generally work but the people who know how they really work are long gone.

Yet this is no longer constrained to mainframe operations; many of us can point at applications running on kit which is ten years or more old on long-deprecated operating-systems. Just talk to your friendly DBA about how many applications are still dependent on Oracle 8 and in cases even earlier. Every data-centre has an application sitting in the corner doing something but no-one knows what it is and no-one will turn-off just in case.

Faced with ever declining IT budgets; either a real decline or being expected to do more with the same amount; legacy applications are getting left behind. Yes, we come across attempts to encapsulate the application in a VM and run it on the latest hardware but it still does not fix the legacy issue.

If it ain’t broke, don’t fix it…but the thing is, most software is broken but you’ve just not yet come across the condition that breaks it. Now the condition that breaks it may well be the untrained operator who does not know the cunning work-around to keep an application running; work-arounds simply should not become standard operating procedure.

Question is as we chase the new world of dynamic operations with applications churning every day; who is brave enough to argue for budget to go back and fix those things which aren’t broken. Who is going to be brave enough to argue for budget to properly decommission legacy systems, you know those systems who only have one user who happens to have a C at the beginning of their job title?

Now it seems that Ross McEwan may be one who is actually being forced into taking action; is anyone else going take action without a major failure and serious reputational damage? Or do people just feel lucky?

 

 

 

In With The New

As vendors race to be better, faster and to differentiate themselves in an already busy marketplace, the real needs of the storage teams can be left un-met and also that of the storage consumer. At times it is as if the various vendors are building dragsters, calling them family saloons and hoping that nobody notices. The problems that I blogged about when I started out blogging seem still mostly unsolved.

Management

Storage management at scale is still problematic; it is still extremely hard to find a toolset that will allow a busy team to be able to assess health, performance, supportability and capacity at a glance. Still too many teams are using spreadsheets and manually maintained records to manage their storage.

Tools which allow end-to-end management of an infrastructure from rust to silicon and all parts in-between still don’t exist or if they do, they come with large price-tags which invariably do not have a real ROI or a realistic implementation strategy.

As we build more silos in the storage-infrastructure; getting a view of the whole estate is harder now than ever. Multi-vendor management tools are in general lacking in capability with many vendors using subtle changes to inflict damage on the competing management tools.

Mobility

Data mobility across tiers where those tiers are spread across multiple vendors is hard; applications are generally not currently architected to encapsulate this functionality in their non-functional specifications. And many vendors don’t want you to be able to move data between their devices and competitors for obvious reasons.

But surely the most blinkered flash start-up must realise that this needs to be addressed; it is going to be an unusual company who will put all of their data onto flash.

Of course this is not just a problem for the start-ups but it could be a major barrier for adoption and is one of the hardest hurdles to overcome.

Scaling

Although we have scale-out and scale-up solutions; scaling is a problem. Yes, we can scale to what appears to be almost limitless size these days but the process of scaling brings problems. Adding additional capacity is relatively simple; rebalancing performance to effectively use that capacity is not so easy. If you don’t rebalance, you risk hotspots and even under-utilisation.

It requires careful planning and timing even with tools; it means understanding the underlying performance characteristics and requirements of your applications. And with some of the newer architectures that are storing metadata and de-duping; this appears to be a challenge to vendors. Ask questions of vendors as to why they are limited to a number of nodes; there will sheepish shuffling of feet and alternative methods of federating a number of arrays into one logical entity will quickly come into play.

And then mobility between arrays becomes an issue to be addressed.

Deterministic Performance

As arrays get larger; more workloads get consolidated onto a single array and without the ability to isolate workloads or guarantee performance; the risk of bad and noisy neighbours increases. Few vendors have yet grasped the nettle of QoS and yet fewer developers actually understand what their performance characteristics and requirements.

Data Growth

Despite all efforts to curtail this; we store ever larger amounts of data. We need an industry-wide initiative to look at how we better curate and manage data. And yet if we solve the problems above, the growth issue will simply get worse..as we reduce the friction and the management overhead, we’ll simply consume more and more.

Perhaps the vendors should be concentrating on making it harder and even more expensive to store data. It might be the only way to slow down the inexorable demand for ever more storage. Still, that’s not really in their interest.

All of the above is in their interest…makes you wonder why they are still problems.

 

 

Xpect More…

So we finally have the GA of XtremIO; not that the GA is much different from the DA in many ways, it is still going to be pretty hard to get hold of an XtremIO if you want one. And that is of course a big *if*; do you really need an All-Flash-Array? Can you use it? Is it just going to be a sledge-hammer to crack a performance nut!

Firstly, I think that you have to point out that presently even under GA, the XtremIO array has some pretty horrible official caveats; not guaranteed non-disruptive upgrade, lack of replication services and the like mean that this is no-where near ready to replace the normal use case for an Enterprise array.

Add in today’s fairly limited scalability and it is obvious that this is not a VMAX replacement today. So will it be in future?

At the moment, that is pretty unclear; we’re due a tick in the tick-tock of VMAX releases; I’d say EMCWorld 2014 is going to be all about the next generation of the VMAX.

But what about the XtremIO in general?

Is it a good idea or even a good implementation of a good idea? It’s odd because looking at the architecture…it feels like what would have happened if XIV had built an all-flash-array as opposed to the spinning-rust array that they have. Much of what we are coming to expect from a modern array from an architectural point-of-view is here; balanced i/o, no hot spots, no tuning, no tiering and minimal management is here. Yet without the aforementioned Enterprise features such as replication, it all feels….well, undercooked.

And there is still the question as to where you are going to use an All-Flash-Array; if I never see another presentation from a flash vendor that mentions VDI again, it’ll be too soon! Let’s just use our AFA arrays as super-fast boot-drives!

So where else are you going to use it? Probably in the same place that you are already using hybrid arrays…to accelerate poorly performing applications? But do you need to keep all your data on AFA and can you tier easily between multiple array types?   You see, you need a capacity tier and you need data mobility…data has to flow. The hybrids have a distinct advantage here. So what is the answer for XtremIO

If you manage the data silos at the application layer; you might well find that you begin to loose the value of an all-flash-array, you’ll be moving data from the array to another array. Doing more I/Os at the host level..

I’m intrigued to see how EMC and others begin to solve this problem because we are not looking at an All-Flash data-storage environment for most people for some time.

Could we see clustering of XtremIO with other arrays? Or are we doomed to manage storage as silos forever.

I don’t see XtremIO as replacing the Enterprise storage arrays anytime soon; I think the traditional EMC sales-drone has plenty of refresh opportunity for some time.

 

 

Bearing the Standard…

At SNW Europe, I had a chance to sit down with David Dale of SNIA; we talked about various things, how SNIA becomes more relevant, how it becomes a more globally focused organisation and the IT industry in general. And we had a chat about SNIA’s role in the development of standards and suddenly companies who were not interested in standards are suddenly becoming interested in standards.

It appears in the world of Software-Defined everything; vendors are beginning to realise that they need standards to make this all to work. Although it is possible to write plug-ins for every vendor’s bit of kit; there is a dawning realisation amongst the more realistic that this is a bit of a fool’s errand.

So after years of dissing things like SMI-S; a certain large vendor who is trying to make a large play in the software-defined storage world is coming to the table. A company who in the past have been especially standards non-friendly…

Of course, they are busy trying to work out how to make their software-defined-storage API the de-facto standard but it is one of the more amusing things to see SMI-S dotted all over presentations from EMC.

But I think that it is a good point and important for us customers; standards to control and manage our storage are very important, we need to do more to demand that our vendors start to play ball. Storage infrastructure is becoming increasingly complex due to the new silos that are springing up in our data-centre.

It may well to be too early to predict the death of the Enterprise-Do-Everything-Array but a vigorously supported management standard could hasten its demise; if I can manage my silos simply, automating provisioning, billing and all my admin tasks…I can start to purchase best of breed without seriously overloading my admin team.

This does somewhat beggar the question, why are EMC playing in this space? Perhaps because they have more silos than any one company at the moment and they need a way of selling them all to the same customer at the same time…

EMC, the standard’s standard bearer…oh well, stranger things have happened…

 

 

 

So I wouldn’t start from here…

We’ve had a few announcements from vendors and various roadmaps have been put past me recently; if I had one comment, it would be if I was designing an array or a storage product; I probably wouldn’t start from where most of them are….both vendors, old and new.

There appears to be a real fixation on the past; lots of architectures which are simply re-inventing what has gone before. And I although I understand why; I don’t understand why.

Let’s take the legacy vendors; you can’t change things because you will break everything; you will break the existing customer scripts and legacy automation; you break processes and understanding. So, we can’t build a new architecture because it breaks everything.

I get the argument but I don’t necessarily agree with the result.

And then we have the new kids on the block who want to see to continue to build yesterday’s architecture today; so we’ll build something based on a dual-head filer because everyone knows how to do that and they understand the architecture.

Yet again I get the argument but I really don’t agree with the result now.

I’m going to take the second first; if I wanted to buy a dual-head filer, I’d probably buy it from the leading pack. Certainly if I’m a big storage customer; it is very hard for one of the new vendors get it down to a price that is attractive.

Now, you may argue that your new kit is so much better than the legacy vendors that it is worth the extra but you almost certainly will break my automation and existing processes. Is it really worth that level of disruption?

The first situation with the legacy vendors is more interesting; can I take the new product and make it feel like the old stuff from a management point of view? If storage is truly software and the management layer is certainly software; I don’t see that it should be beyond the wit of developers to make your new architecture feel like the old stuff.

Okay, you might strip out some of the old legacy constructs; you might even fake them…so if a script creates a LUN utilisng a legacy construct; you just fake the responses.

There are some more interesting issues around performance and monitoring but as a whole, the industry is so very poor at it; breaking this is not such a major issue.

Capacity planning and management; well how many people really do this? Although it is probably the really big customers who do so but they might well be the ones who will look at leveraging new technology without a translation layer.

So if I was a vendor; I would be looking at ways to make my storage ‘plug compatible’ with what has gone before but under the covers, I’d be looking for ways to do it a whole lot better and I wouldn’t be afraid to upset some of my legacy engineering teams. I’d build a platform that I could stick personalities over.

And it’s not just about a common look and feel for the GUI; it has to be for the CLI and the APIs as well.

Make the change easy…reduce the friction…

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.

 

 

Speed2Pb is Heavy Going…

EMC Marketing have done it again and managed to turn into what might be an interesting refresh of a product into something that just irritates me and many others.

It started off badly when they put the Sneak Preview video up and decided to have a dig at their lead competitor; then some tweets where they used the tag #NotAppy.

And then the hype cycle started to ramp up. So we have a ridiculously overblown launch with some tenuous link to F1. Tyre changing competitions and the likes which appear to be fun but just break up the presentations and destroy the flow.

EMC are just very bad at this sort of launch; speeds, feeds, marketing mumbo-jumbo linked in with videos/events which trash competitors, bore the audience and add little value. But all with the highest production values.

So what did the event feel like? It felt like an internal kick-off, an event where EMC high-five themselves and pretty ignore the customers. This felt more like an EMC event of eons ago along with a smattering of cheer-leading from Social Media.

There was little about the value, the use-case and what it will allow customers to do.

Death by PowerPoint; overly complex and busy slides.

And no humour…no humour! Make me laugh, make me smile!

Obviously I’m sure that it all played well to everyone else…and I’m not the target audience.

However, I think the technologies launched might be interesting; I think if the VNX2 code has undergone a rewrite, it’s long overdue and an achievement. It deserved better…

You Will be Assimilated.

So why are the small Flash vendors innovating and the big boys not? Why are they leaving them for dust? And do the big boys care?

Innovation in large companies is very hard; you have all the weight of history pressing down on you and few large companies are set-up to allow their staff to really innovate. Even Google’s famous 20% time has probably not born the fruit that one would expect.

Yet innovation does happen in large companies; they all spend a fortune on R&D; unfortunately most of that tends to be making existing products better rather than come up with a new product.

Even when a new concept threatens to produce a new product; getting an existing sales-force to sell a new product…well, why would they? Why would I as a big-tin sales-droid try and push a new concept to my existing customer base? They probably don’t even want to talk about something new; it’s all about the incremental business.

I have seen plenty of concepts squashed which then pop up in new start-ups having totally failed to gain traction in the large company.

And then there are those genuinely new ideas that the large vendor has a go at implementing themselves; often with no intention of releasing their own product, they are just testing the validity of the concept.

Of course, then there is the angel funding that many larger vendors quietly carry out; if you follow the money it is not uncommon to find a large name sitting somewhere in the background.

So do the big boys really care about the innovation being driven by start-ups…I really don’t think so. Get someone else to take the risk and pick-up the ones which succeed at a later date.

Acquisition is a perfectly valid R&D and Innovation strategy. Once these smaller players start really taking chunks of revenue from the big boys…well, it’s a founder with real principles who won’t take a large exit.

Of course, seeing new companies IPO is cool but it’s rarely the end of the story.