The Infrastruggle

Some Depressing But Hard Truths About Cloud Storage

Lack of management is at the heart of most cloud storage struggles. So why is it that most of the conversation veers away from that topic?

• By Jon William Toigo
• 06/19/2014

At IBM's Edge conference in May, I watched a customer, an IT planner for a large financial firm, describe his department's effort to make something out of all of this "software-defined" stuff we've been reading about in the funny papers for the past few months. I listened with great interest as I have been struggling to find anything whatsoever to ground the rampant marketecture in the realm of real-world architecture.

After listening intently for several minutes, it struck me that the fellow kept mixing and matching terminology -- some concepts from clouds, other ideas from virtualization, buzzwords from software-defined -- the kind of meaningless mash-up that seems to float around every discussion of software-defined that I have heard. In addition to being irritating, it seemed like this fellow -- like most of his peers in software-defined -- didn't really want to talk about the underlying problem he is trying to address:  lack of management.

Truth is, we have deployed a lot of server, storage and network technology in the distributed world while paying little or no attention to how we will manage it. According to a Gartner report a couple of years ago, the cost to manage and administer the kit we were deploying was five or six times the cost to acquire and deploy the kit in the first place -- testimony to a lack of unified or standards based monitoring and management hooks in the products that we buy. Those hooks, like open REST APIs that would allow unified cross-platform management of infrastructure components, aren't there vendors say because consumers haven't demanded them (or been willing to pay anything extra for them).

That observation is true for the most part. In repeated seminars that I've conducted, the majority of attendees have told me that "management" wasn't even on the top ten list of criteria used to select storage, network or server equipment. Generally, they were happy with the simplistic and isolated management tool that came with the box.

If you think about it, it was the years of neglect of infrastructure management that set the stage for server virtualization. Terrible mismanagement was behind the oft-stated Big Reason for deploying VMware nine or so years ago:  to boost resource utilization efficiency in poorly managed infrastructure. The argument conveniently ignored the fact that Linux servers (and mainframes) typically operated at more than 80 percent efficiency given an excellent management software stack and administrators who knew what they were doing. Without infrastructure management that could scale with infrastructure itself, each hardware acquisition required the hiring of additional IT folk, like that old Xerox commercial describing the failure of a photocopy machine that necessitated the hiring of a room full of monks to copy and illuminate documents by hand.

By their own definition, the culprit behind utilization inefficiency was a lack of management. Only, instead of fixing management deficits, most of those virtualization, cloud, software-defined evangelists seem hell-bent simply on deploying their preferred technology to hide infrastructure mis-management from view. Like unattractive folks turning to plastic surgery to improve their dating opportunities on Friday night, they do not concern themselves with the likely outcome:  ugly kids. Virtualization doesn't change the genetics of the underlying infrastructure, it just masks it from view.

Advocates, like the IBM customer, say they are improving IT management, of course. In one respect, they are speaking some truth, I guess. After all, there is a lot of talk about surfacing "services" (basically value-add services on hardware controllers that vendors charge too much for in storage) or "separating the data layer from the control layer" (same as before, but for network gear) and placing these server, network and storage functions into centralized service pools. This might help to make the value-add services easier to apply to workload. But, these advocates are doing nothing whatsoever to improve the monitoring and management of the plumbing layers down below the services layer -- which is to say, the nagging problem that brought us all to the virtualization table to begin with.

Anyway, after firing both barrels of marketecture-infused rhetoric, the IBM customer tried to get folksy and personal by turning to Disney metaphors. He characterized the folks who did not share his enthusiasm about his software-defined vision as "Eeyores," after the Winnie the Pooh character with depressive personality disorder. Those that embraced his vision enthusiastically, observed the IBM handler, were by contrast, "Tiggers."

Was that a good thing?  I had to wonder, given the Canadian Medical Association's diagnosis of Tigger as a hyperactive ADHD sufferer, likely with a substance abuse problem rivaling that of Toronto's Mayor Ford. Extending the metaphor further, the CMA warns that folks with Tigger personalities tend to be social magnets, but their impulsive natures soon put followers and themselves in danger.