By all that is right and just in the world, advanced automation should be the holy grail of modern enterprise IT. You might expect progressive IT organizations to be investing like crazy in a never-ending race to automate, automate, automate — an arms race that never ends.
If that’s happening, I’m not seeing a lot of it. When I talk to enterprise IT organizations, automation is usually on the list of “yeah, we’re working on that too”.
This puzzles me.
On one hand, there’s ample evidence from many non-IT industries that a continual pattern of heavy investment in automation is required to successfully compete. On the other hand, so few enterprise IT organizations seem to be willing to organize and invest appropriately.
Everything exists for a reason, and I think I’ve come up with a handful of reasons why the disparity between opportunity and execution remains so great.
For those of you grappling with these issues in your own environments, see if any of these apply to you.
The Promise Of Automation
There’s a long list of extremely competitive industries that have been fundamentally transformed by successive waves of automation: manufacturing, telecommunications, drug research, financial services, logistics, etc.
Look closely, and you'll see that automation isn’t the icing on the cake, it’s the cake itself: the investment in continually improving and automating operational processes is a critical component of the firm’s competitive advantage.
When we consider the current situation of enterprise IT, it’s ripe for the same investment pattern.
Demand grows, budgets don’t.
The only pragmatic solution to the equation is massive leaps in productivity and efficiency — and that means automation.
By “automation”, I mean a focused, well-funded and never-ending effort to (a) identify core business processes, (b) measure their current effectiveness, (c) propose redesigned processes that are more efficient, (d) test and implement them, and (e) measure their resulting effectiveness.
If you’ve been involved with Six Sigma, this is the familiar DMAIC: discover, measure, analyze, implement, control.
I’m specifically not talking about pouring scripted automation concrete around existing archaic processes.
So, why do we continue to see a gap between theory and practice? I have my suspicions …
#1 — It’s Intellectually Difficult
Getting your head wrapped around a single IT process takes some effort. Getting your head wrapped around dozens — or hundreds — of processes can be mind-melting. Understanding those processes at a deep enough level that common patterns and architectures emerge as a basis for re-engineering -- well, that takes serious intellectual horsepower.
Teams of seriously smart and knowledgeable people who work together well aren’t all that common, and that is what’s required here. Instead, I tend to see well-meaning — but woefully under-resourced — efforts: maybe a semi-dedicated team lead and a bunch of people helping out.
Compare that investment pattern with other industries that have come to accept continually-improving automation as a core business tenet, and there’s a sharp contrast.
#2 — It’s Politically Unpopular
Serious process redesign and subsequent automation always cuts across traditional organizational boundaries: that’s what makes it so darn powerful.
But as you do that, you’re messing with people’s worlds: changing their roles, changing how they get work done, who they work with, etc.
And although we all talk a good game, no one likes to have their world messed with — especially if you’re not in control. I am no exception.
Most people prefer to be well-liked where they work (hey, we're all peer-reviewed!); being seen as a well-intentioned but unpopular troublemaker isn’t everyone’s cup of tea.
#3 — It’s A Never-Ending Journey
“Are we there yet?” No. “When will we be done?”. Probably never.
If we look outside of IT at automation-centric business models, they never want to stop improving, so they never stop investing. The notion that a bunch of money ia going to be spent on something in perpetuity -- and will never finish — well, that’s a tough sell.
Will there be continual and meaningful improvement along the way? Of course. Can we package this as a well-defined project, with a clear beginning and end? Of course not.
It’s generally accepted in the business world that everything must continually improve over time — just to stay competitive. And in a world where so much business depends on IT, it too must continually improve.
And that takes continual investment.
#4 — The Vendors Aren’t Always Helpful
I have waded through many of the different management frameworks and tools, and how they are marketed. At least for me, it takes serious effort to decode what they’re actually saying.
Some clearly fall into the “unicorns and fairy dust” camp: magical and effortless improvements simply through acquiring the right software.
If it was that easy, everyone would be doing it.
Others are far more pragmatic: here is what we do well, here is how we integrate with others -- and here is what you the customer are responsible for. The landscape is littered with automation projects that didn't automagically self-materialize once the purchase was made.
I am reminded of the first wave of SAP implementations back in the 1990s. The winners realized that SAP wasn't simply new software, it was a new way of running your business. The failures could often be traced back to well-intentioned "customizations" that reflected the old way of doing things.
#5 — The Supporting Architectures Can Be Complex
As before, better processes and better automation means crossing traditional boundaries — and lots of them. That means that simply understanding how the various management and automation pieces fit together is also intellectually challenging.
If you’re using a dozen or more tools to automate, that means you’ve also invested in a dozen or more rather specialized skill sets, suites of interfaces, etc.
From what I’ve seen, as IT organizations move from model to model along their automation journey, they tend to frequently discard tools that made sense in the old model, but don't fit the new one.
Getting comfortable with a pattern of continually investing in — and de-investing in — multiple management tools: licenses, skills, interfaces, etc. — well, that’s a really big pill to swallow for many people.
Getting To “Automation First”
Where does that leave us? With a big opportunity — and a correspondingly big set of challenges.
If "virtualization first" was the rallying cry of our recent wave of IT thinking, perhaps "automation first" should be our call sign for the next one.
I tend to think about this through a decidedly Darwinian lens: those IT organizations that fail to invest heavily in automation will likely suffer at the hands that do: be they external service providers, or embedded in companies that compete directly with yours.
In an ideal world, what might a winning strategy look like?
#1 — Invest In An Empowered, Well-Resourced Team
Process change and subsequent automation at scale is not trivial work. Several distinct skills are needed: people who can visualize new workflows and processes, people who understand how all existing bits fit together from both a business and technology perspective, people who can sell change and make it happen, and more.
Whether these are your own people, an outside consultancy, or preferably a mix — without the right set of dedicated people, it’s hard to even get started.
This inarguable requirement comes at a time where many IT leaders realize that they're in a war for talent, and automation just opens up another front in the battle :)
#2 — Create A Model For The Journey
Everyone involved will need to understand three things: where we are today, where we’d like to be at some point in the near future, and how we expect to get there. People can’t execute on what they don’t understand.
I’ve seen a few different approaches, each with their merits. One example is to pick a very focused operational area (e.g. financial reporting, provisioning, etc.) and start there. As success is seen in one area, other areas are considered.
Another apparently successful model is greenfield: when a sizable new environment is being stood up (e.g. private cloud, VDI, big data, etc.) use it as a lab to try out entirely new ideas around process automation. Benchmark the new environment against existing practice, and use the disparity as a lever to drive change.
One model that doesn’t seem to work is the intergalactic approach: mapping out everything that has to change, and all at once. People can’t grasp the complexity; there’s no obvious place to start, by the time the pieces are in place your understanding of the problem has fundamentally changed, etc. It doesn't start to fail, it fails to start.
A model that starts well — but frequently stalls — is the “automate within disciplines” approach: server team automates, network team automates, storage, etc. While there are frequently good improvements to be seen, at some point you realize you need to get good at process design and automation across the silos (err, “cylinders of excellence”) rather than within them.
#3 — Invest In Stuff That Supports Advanced Automation Models
Some people believe that -- theoretically -- any entity in the IT universe can be automated -- all it takes is a little scripting! I would argue that there is a huge difference between products that can be potentially automated -- and those that are designed to be automated.
Driving to successively more productive levels of automation can be directly impacted by how automate-able the components are. Especially if you see yourself on an inevitable journey of progressively deeper and more extensive automation.
Indeed, this is one of the big ideas behind SDDC (software-defined data center) and all of its SD-related disciplines: software-defined networking, software-defined storage, software-defined security et. al.
For example, in my happy little storage world, it’s not enough to say “we have APIs”; I must apply a higher standard: anything a human can do from a console or GUI should be programmatically accessible, along with bindings and adaptors to popular frameworks, sample workflows, etc.
Not coincidentally, that’s how my employer VMware thinks about these things.
Ask yourself: when your team is debating what to buy, how much importance is given to programmability and automate-ability? Pushing the point: would you prefer a solution that’s strong in this regard, but may be less attractive in other aspects?
That's part of the "automation first" mindset.
And every time an Exa-something lands on a data center floor, a kitten dies.
#4 — Defend Against Distractions
Once all of this is in place, be prepared to defend it against the latest crisis-du-jour or recent hot project.
I suspect that these process and automation teams can only make progress if they stay focused on the task at hand, and not brought in as extra resource on the dozens of distractions that are an integral part of the enterprise IT world.
But that's exactly what I see strong leaders do: set the priorities, make the investments and firewall resources so the long-term stuff doesn't suffer at the hands of today's fire alarm.
What Really Makes This Hard
Part of the inherent challenge is that business leaders aren’t directly asking for better process and better automation: they’re asking for better apps, mobility, analytics, lower costs, improved agility, etc.
Not that anyone in IT would think of themselves as an order-taker, but ...
The natural tendency is to give people what they want, when they want it — rather than making the hard investments in the people, process and tools required to create a continually-improving automated environment that does all of this, and much, much more.
New storage products rarely generate as much as enthusiasm as we've seen with VSAN. That’s good.
But I’ve been dismayed to see industry commentary where VSAN gets arbitrarily lumped in with either (a) a gaggle of software-based storage products, or (b) some of the newer software-clothed-in-hardware products.
From my perspective, that’s not ideal. Something important is getting lost in translation.
I see strong, relevant architectural differences between VSAN and everything else that’s out there today.
Maybe those differences are important to people, maybe not — but the distinctions need to be understood and appreciated to be intelligently debated.
So let’s dig in …
If this whole VSAN thing is new to you, I’ve written a few posts that’ll bring you up to speed. Want to go deeper? There’s a ton of deep technical content out there from bloggers around the world. And there will be a VSAN "special online event" on March 6th. The beta has been long and successful, GA is promised for Q1, which would be before the end of March.
The source of the enthusiasm is clear: VSAN is a new kind of storage solution, targeted at a new storage buyer. It establishes a very different model for storage. While this is all well and good, it does tend to cause some cognitive dissonance with people who are deeply immersed in storage technology.
It All Starts With Being Hypervisor Converged
VMware describes VSAN as “hypervisor converged”. That means it is deeply integrated with the ESXi hypervisor and the broader vSphere environment.
Although it is a separately licensed product, there is no separate distribution. Unlike traditional storage, it won't run with anything other than vSphere anytime soon. The depth and level of integration takes a while to fully appreciate, but it's amazingly deep and well-thought out.
VSAN runs with VMware only? Compared against more familiar storage, that might appear to be limiting at first glance. Consider the context ...
Let's assume that the majority of workloads today run virtualized, and the proportion will continue to grow. I think it's also safe to assume that -- for most enterprise IT shops -- this becomes primarily a VMware discussion.
If any architectural advantages result from being deeply integrated with the hypervisor (and I will argue here that there are several), software storage products that run under a guest OS in a VM simply won’t have those advantages.
That’s true whether they are delivered as software alone, or wrapped up in an appliance of some sort.
Just to be clear, I’m explicitly comparing the VSAN architecture against software-only storage stacks (HP’s VSA, Maxta, ScaleIO, Nexanta, Atlantis, etc.) as well as the newer breed of software-encased-in-hardware appliances (Nutanix, SimpliVity, etc.). Let's not forget several stealth startups scurrying around for VC money.
It's a long list of players, and the arguments I present here apply to all of them.
All of them have the same thing in common: their storage stacks run in a guest VM, and aren't an integral part of the hypervisor. From that seemingly minor implementation detail, serious implications result.
Given the vigorously competitive nature of this market, I fully expect heated rebuttals to my points. I encourage that; I'd disappointed by anything less!
#1 — Server Efficiency
As VSAN is built by extending existing kernel capabilities, it needs less code, less memory and less CPU than self-contained storage stacks that run as a guest.
The numbers we've seen so far don't lie: you get more bang-for-your-buck in terms of compute and memory resources used to provide storage services when using this approach.
Most software storage stacks that run in a guest OS have to be fully provisioned up front: all the memory, all the CPU, etc. Yuck.
Contrast that with VSAN: it uses less than 10% of available CPU, and a modest amount of memory that scales with capacity. Compare this with the somewhat more outsized requirements you’ll find associated with many of the software-ish alternatives presented above.
The counter argument is that — hey, compute and memory are cheap. While this is certainly true, perspectives differ — I certainly have met customers who are very concerned about the efficiency of their server environment.
#2 — More Performance, and More Predictable Performance
There’s no getting around it: unless your storage software is deeply integrated with the kernel, you’re always going to be traversing one or more VMs for each and every storage IO. That doesn’t exactly help when it comes to latency. Our initial testing shows that — yes — storage software stacks that run in guest OSes tend to uniformly suffer in this regard.
Just to make my point clear, imagine you're an application and you want to read or write data. Here's the flow:
1. Application makes IO request
2. Traverse the guest OS IO stack
3. Traverse the hypervisor IO stack to reach the storage software
4. Traverse the storage software VM's stack as well as its guest OS
5. Traverse the hypervisor IO stack to do the physical IO
6. And all the way back again!
When storage software is implemented as an integral part of the hypervisor, you avoid traversing #3 and #4 twice.For every IO.
Digging a bit deeper, you quickly realize that the protocol between application client and storage services doesn't have to be iSCSI, NFS, etc. As both endpoints are native to vSphere, you can build a very efficient, optimized storage protocol that avoids the overheads associated with traditional IO presentation stacks.
Which is exactly what VSAN does.
But there’s more here — and that’s predictable performance.
A self-contained storage stack running under a guest OS has to compete for resources alongside other application workloads.
While there are good QoS services in the hypervisor, they're designed for application workloads, and not designed to handle storage software workloads. What features do exist would have to be explicitly managed.
Hypervisor-converged storage stacks have a distinct advantage here. First, all IO services are provided by the kernel, and not a user VM. Big potential win for latency, and perhaps bandwidth.
Second, the hypervisor knows about VSAN, and vice-versa. Critical storage operations are prioritized ahead of user tasks if required. That’s particularly important when there’s a transient workload (e.g. a rebuild) or similar.
If you're using a software storage stack running neatly in a VM, you don't want that VM to be starved when you need it the most.
When I talk to infrastructure pros, they routinely tell me that predictability (“no surprises!”) is what they really want. Architecturally, VSAN has an undeniable advantage here -- simply because it is hypervisor converged.
#3 — Availability and Recoverability Semantics
This will end up being a hotly debated topic, once you get beyond simplistic failure scenarios. My view stems once again from hypervisor convergence, and being deeply integrated with the hypervisor.
A standalone software stack running in a VM is essentially running blind to its infrastructure: it can only see — and react to — what the hypervisor can expose.
That means its recovery logic has to be fairly binary — basically, “I’ve fallen and I can’t get up”, so please fail me over to another node, disk, etc.
A storage stack that’s deeply integrated into the kernel has a much wider palette of potentially more sophisticated responses.
For example, it can directly probe the status of the physical hardware through native device drivers: disks, CPU,memory, network, etc. It understands the entire cluster, and all of its resources. It can intelligently balance recovery activities with application processing.
Anything running in a guest OS -- by design -- has all this abstracted away on its behalf.
If you're following me, you can certainly see the architectural potential for more nuanced and sophisticated recovery logic. And-- in the gritty real world -- failure recovery semantics do matter.
#4 — Management That’s Built-In, Not Bolted On
All standalone storage products face the same challenge: their management interfaces have to be exposed through one or more plug-ins.
While that approach is certainly serviceable, it isn’t the same as having the management experience fully integrated into administrators’s workflow.
If you watch a VM admin using one or more storage plug-ins, you’ll see a lot of flipping back and forth between the plug-ins and the rest of the environment. There’s a lot of correlation: find an object on one side, find it on the other side, make sure it’s the same thing, make the connection, etc.
You don’t see that with VSAN. Everything is logically and consistently presented in the context of the workflow. That directly results from being an integral part of the hypervisor.
This might not sound like a big deal, unless you’re a time-compressed VM admin. And, not surprisingly, this is one of the things they like best about VSAN. More importantly, all the cool VMware bits just work as expected :)
Architecturally, you can’t reasonably achieve this result unless you’re deeply integrated into not only the kernel, but the various tools and management views as well.
#5 — Aligning Around Applications, Not LUNs
VM admins think in terms of applications. Storage admins think in terms of storage containers, like LUNs and filesystems. The two don’t easily align. This mismatch can be frustrating, and introduces needless complexity and inefficiency.
Both parties would like an easier way to transact business ...
We’ll have to wait a while before we’ll see this challenge addressed for external arrays (VASA 2.0 and VVOLs), but today's VSAN gives a great preview. If we’re being strict here, this attribute is not unique to being hypervisor converged, but it does illustrate the magic that can result through deep integration.
It’s a deceptively simple mechanism.
The administrator defines policy, using a template, which — of course — includes storage policy: capacity, performance and availability today. That policy is pushed down to to the storage layer, and a container is dynamically provisioned that precisely aligns on application boundaries, and delivers the exact policy requested.
Change the policy (or the definition of a policy), and the changes happen behind the scenes. You can quickly view which applications are in compliance, and which ones aren’t.
Compare that with the bottoms-up, storage-centric approach, and it’s not nearly as elegant.
Storage administrators usually pre-carve separate pools with distinct characteristics, and publish them. Applications then consume from the pre-existing storage containers. Matching supply and demand is imperfect at best, resulting in the familiar “have a hunch, provision a bunch” approach.
Digging a bit deeper, dynamically changing policies isn’t straightforward with the traditional approach, nor is verifying compliance.
This inherent application-centricity is also very powerful when it comes to monitoring, trouble-shooting, reporting, etc. Let's face it, it's all about the applications, isn't it?
The beauty of this approach is the ability to easily view all resources (storage, compute, network, etc.) from the point of view of the application container (the set of relevant VMs) vs. trying to reconstruct an accurate picture from the bottom of the infrastructure upwards.
Simply point at the applications you're interested in, and everything you need is right there, organized as your users see them -- by application.
Again, architecturally very difficult for a non-hypervisor-converged storage stack to achieve.
VSAN Is Different
While I am a big fan of strong and detailed comparisons between competing technologies, I’m disappointed when surface comparisons miss the deeper zeitgeist behind the technologies.
That’s understandable: products like VSAN are relatively new ideas, and the tendency is to lump everything into big, familiar categories where everything appears similar.
However -- in this particular case — things are quite different indeed.
I think that people will quickly come to appreciate the architectural benefits that result from storage services being directly integrated into the hypervisor. Hypervisor convergence is not a buzzword, it’s a meaningful distinction in my opinion.
Are these differences relevant or not? That will always be in the eye of the beholder …
So many IT leaders realize their world is becoming a different place, and fast. You can see it in their faces, hear it in the tone of their voices — almost feel the anxiety.
Like most leaders, they often go looking for examples from others who are adjusting well to their new realities.
While there is plenty to learn from their peers, I usually counsel that understanding how modern manufacturing has changed (and continues to change!) provides ample lessons and tools about how to think about the modern IT organization.
One things for sure, there’s no going back to Kansas anytime soon …
A Wealth Of Parallels
At a fundamental level, manufacturing is about creating value-add around physical goods. One could make an argument that IT (and computing in general) is about creating value-add around information.
Both manufacturing and IT face somewhat similar constraints: the cost of capital, labor, limits in technology, unpredictable demand, long supply chains, and much more.
Both find themselves aggressively competing for their customers.
Both are continually figuring out their unique value-add: what things do we do for ourselves, and what things do we leave to others to do more efficiently?
Both have to continually re-invent their model, otherwise risk falling behind.
For those of you who work at companies with a strong manufacturing component, there’s a wealth of experience and perspective waiting to be tapped by the IT team. For the rest of you, there is plenty of material readily available on how modern manufacturing is practiced.
I’d encourage you to invest the time.
A Brief History?
Thanks to Wikipedia, it’s not hard to get a sense of how manufacturing evolved. It started with individual artisans — craftspeople — and then evolved into highly structured guilds.
Remember that “guild” concept the next time you interact with your database, network or security team :)
The advent of better power sources and transportation changed manufacturing from a local industry to a global one where scale mattered. Human hands gave way to increasing levels of automation. The traditional guilds were replaced new models, and new skills.
All somewhat reminiscent of what the microprocessor, the internet and “cloud” is doing to enterprise IT.
Over the last few decades, the pendulum in some manufacturing sectors appears to have swung from mass efficiencies to mass customization: valuing flexibility, agility and responsiveness over ultimate efficiency.
If you’re curious, check out this short piece on Reconfigurable Manufacturing Systems, circa 1999. The idea is simple: physical manufacturing assets should be under software control, and completely reconfigurable based on changing demands.
This should sound vaguely familiar to many of you …
No discussion would be complete without acknowledging the advent of 3D printing — transforming yet another labor and capital intensive component of manufacturing into something that is entirely under software control.
One could justifiably say that — when it comes to modern manufacturing — it’s quickly becoming all about the know-how that’s implemented in software.
Back To IT
Recently, I was reading an analyst’s survey finding that SDDC concepts— software-defined data center - had been strongly adopted by about a third of the participants. The remainder either weren’t quite sure or saw themselves going in a different direction. I'm not exactly sure what that different direction might be …
As a VMware employee, you might think I would see the findings as potentially negative news. Quite the opposite, I was gratified to see that a third of the participating senior IT leaders understood SDDC concepts and saw themselves moving in that direction.
To be fair, the concepts have only been around for a relatively short period, and the supporting technologies (beyond compute, that is) are now just entering the marketplace.
Combine that reality that with the unavoidable fact that the entire IT (manufacturing?) organization has to be re-envisioned around how information services are sourced, produced and consumed in an SDDC model — and I’m impressed.
A Bigger Picture
I’ve often argued that our society is quickly evolving to an information economy. All businesses will be information businesses before long — if they’re not today.
Just as manufacturing played a central role in previous business models (and still does today), information and the supporting IT functions will continue to increase in prominence.
These IT factories will need new technology blueprints to be efficient, agile and responsive. That’s what I see in SDDC — and I guess I’m not alone.
And there is plenty to be learned from how it’s done in the physical world.
An awkward moment: I’m with a customer group, and someone asks me an innocent question: “so, what’s happening in the storage world these days?”.
Gulp! OK, do they really want to know?
I give them a choice between the short answer and the long answer.
The short answer? A lot is changing, maybe too much.
Ready for the longer answer?
Once you understand it, you may be sorry you asked :)
Why You Should Care
Enterprises invest an awful lot in storage technology, the rough cut is about $30B annually in hardware alone. I think that’s a low number — we have to consider software, services and the all-important investment in skills, people and processes to make it all work usefully.
That money invested in storage technology is intended to last a long time: a minimum of 3 years, with longer periods not unusual. So the technology decisions people are making today will be used through 2017, or longer. The considerable investment in processes and skills around the technology, even longer.
I'm empathetic: given the rate of change that’s now in play, making “safe” bets with that sort of time horizon is becoming an increasingly difficult challenge. This makes things exceptionally difficult for most enterprises that have to commit a big pile of money to a particular technology.
I can’t tell you what the world will look like for you in 2017, but I *can* share with you what I think is very likely to change during that time.
One of the things that Pat Gelsinger has always been adamant about — both at EMC and now at VMware — is “always be on the right side of the technology curve”. By that, he means to make sure you’re investing in the new way of doing things vs. perpetuating legacy approaches.
I think that advice makes obvious sense for any technology vendor. It also makes good sense for many customers who want to invest wisely in the future. People are spending an awful lot of money on storage these days.
And when it comes to enterprise IT, the decisions you make today will be around for a very long time.
A Disclaimer Of Sorts
I work at VMware and focus on storage and availability topics. The list of “what’s changing” I'm presenting here is clearly from that perspective. Indeed, I’ve lifted this whole discussion from various internal strategy documents I’ve written.
While the arguments here tend to reinforce the VMware viewpoint, I also they’re also useful viewpoints for any enterprise spending decent money on storage tech.
#1 — A New Foundational Storage — Flash
Flash storage has now been around for many years, and most everyone understands that it can be a cheap way to get more performance, $/IOPS if you prefer.
What may not be as obvious is that flash is migrating its way closer to the CPU.
The first flash implementations were array-based, and then flash on the PCI-e bus became popular, and now it’s starting to find its way onto motherboards.
Why? Flash is faster when it doesn’t have to traverse a network — or an external bus, for that matter. The result is that the $/IOPS equation improves as a result — more performance for less money.
Once flash finds its way into the server, it’s a resource — like compute and network — that wants to be managed and virtualized -- ideally by the hypervisor.
#2 — A New Implementation Model — Storage As Software
Array vendors will joke that they’ve always been software vendors, it just comes in a really large box :) Hahaha …
All things being equal, many IT shops are expressing the desire for storage to be implemented as software on their choice of familiar server hardware. Maybe not everywhere, but they'd like to have that option.
Their motivations are multiple: simpler environments, perhaps less-expensive hardware, the ability to invest in functionality vs. proprietary hardware, and so on. Once again, the hypervisor seems a logical place to do this.
#3 — A New Technology Integration Model — Convergence
Convergence — the bringing together of disparate technologies — is one of those powerful forces in the technology business, and enterprise IT infrastructure is no exception.
We’ve already seen the popularity of hardware convergence: whether that be things like Vblocks or some of the newer all-in-one appliances.
But there’s more to be done.
If infrastructure functionality is to be delivered as software, shouldn’t we be aspiring to software convergence models? And, given that the hypervisor already abstracts compute — and more recently network and storage, the notion of hypervisor convergence has a certain technical and architectural appeal.
#4 — A New Alignment Model — Application-Centric
Today, we have a rather brute-force model for aligning storage with application requirements.
Perhaps the best way to describe it is “bottoms-up”: storage is acquired, carved into pre-defined buckets, and applications consume from the buckets as needed.
A better approach would be to flip the model: as an application gets provisioned, its requirements are driven via policy down to the supporting storage infrastructure. Resources and service levels aren’t carved into buckets until they are actually consumed.
Better yet would be to have these services precisely align by application boundaries vs. being part of a larger, generic container such as a LUN pool or similar.
Finally, the control model should be based around what applications need -- and not aligned around traditional infrastructure silos.
It’s not hard to conclude that the hypervisor — as the key interface between application and infrastructure — is in a perfect position to define the boundaries of an application, capture application policy, express it downwards to the infrastructure, and monitor compliance.
#5 — A New Consumption Model — Cloud
Yes, there it is again -- that "cloud" word.
The advent of public clouds has made IT incredibly easier to consume for many use cases. IT shops of decent scale have realized that there’s no real reason that prevents them from offering their users similar services. Everyone has access to the exact same technologies and operational models.
When it comes to basic storage, doing it in-house often has a clear cost and control advantage. But when it comes to topics like content distribution, unpredictable application demand and improved availability, external clouds can have a distinct advantage.
For external clouds to be effective as part of an enterprise IT environment, they need to seamlessly blend in with other assets. Ideally, everything would be managed consistently, and end users unaware of what was going where.
I believe that the hypervisor — as a broker of available services, sitting between applications and infrastructure — can potentially be very relevant in this context, even in a world of many public clouds.
#6 — A New Operational Model — IT as a Service
It’s pretty clear that the IT operational model is moving away from traditional functional silos (or, more euphemistically, cylinders of excellence) towards an integrated service delivery model.
IT becomes a builder/broker of services that the business wants to consume. IT gets reorganized around IT service production and consumption vs. the more familiar project orientation. Processes changes, roles change — and tools change as a result.
Ideally, storage becomes just another software service that can be dynamically invoked and adjusted arbitrarily. Storage becomes part of the service deliverable being consumed, and less of a stand-alone discipline.
#7 — New Application Models — Web-Scale and Big Data
Look at a modern web-scale application, and you’re immediately struck by how it uses storage very differently than a traditional application. The data management layers are different, the access patterns are different, data services like availability and replication are handled farther up the stack, and so on.
Turning to big data and the associated Hadoop environments, once again a sharp contrast to how traditional applications access data and use storage.
New application requirements means a new desire for newer approaches in how storage is built, deployed and managed.
#8 — A New Storage Buyer — The Cloud Architect
Historically, storage was the domain of dedicated storage teams: the server guys did their thing, the storage guys did their thing, and so on.
But in today’s virtualized and cloudy world, there’s a blurring of the lines where the newer infrastructure architects look at this whole thing very differently.
These people would prefer to think of storage as a software service, invoked as needed, and running on bog-standard industry hardware if at all possible. Everything should be orchestrate-able and programmable from higher-level frameworks. And you shouldn’t need a dedicated storage team just to provision a new application.
This is not an especially new thought. What is new is its recent groundswell. Once people start standing up and operating fully virtualized cloud-like environments, they start thinking about storage very differently.
Hard Decisions All Around
There’s a logical tendency in IT organizations to continue to do what’s worked in the past. In a complex, fast-changing world, it makes sense to stick with technologies and approaches you’re already familiar with.
And making an argument for change in a large organization can be, well, unpopular.
But from my perspective, things are moving very fast in our little storage world — faster than I’ve ever seen them move.
I'm sorry, I can’t tell you what the world will look like in 2017.
But I can tell you which side of the technology curves you want to be on :)
For those of you who managed to stay awake in your Economics class, you’ll recall that — between inflation and deflation — the latter is thought worse, and is associated with economic depressions.
During deflationary periods, prices for goods fall at such a rate that consumer behavior changes.
Why buy something today when it’s virtually certain that its price will fall tomorrow? There’s now a strong economic disincentive to carry any inventory at all — defer purchases as much as possible, and buy only what you need when you absolutely need it.
While it’s true that I now work for VMware, I came from the storage hardware business. I scrutinize analyst reports, earnings announcements, etc. And I think I could construct a plausible argument that we are in a sustained deflationary period for storage capacity: disks and arrays.
If that’s true, there are plenty of implications all around …
If you were buying home computers during the previous decade, you know what this is all about.
You’d buy the latest-greatest desktop technology, and — no sooner than you got it up and running — that something newer, faster, better (and cheaper!) was just reaching the marketplace. You felt like a schmuck just a few weeks after laying down your hard-earned cash.
As a result, I quickly realized that I should defer purchasing a new unit as long as humanly possible. When I did buy, I should go with a bare-bones expandable system, knowing that buying the upgrades later would be cheaper than doing it up-front. I was willing to ride the technology curve, but recreating my personal computing environment on the new PC turned out to be an onerous task.
On one hand, deflation was great, as consumers got a great deal: more bang for the buck — although figuring out what and when to buy became a full-time job. But the consequences for the PC industry became absolutely savage: rampant commoditization, razor-thin margins, brutal competition — and all the money going to software.
Economists can point to many causes of deflation, with technological innovation and oversupply being two primary causes. And when it comes to storage capacity, both seem to be in play.
What Brought This About
There are two publicly-held reasonably pure-play storage vendors that are very transparent about their business during their earnings calls: EMC and NetApp. I not only read the transcripts (thanks to Seeking Alpha), but also all the analyst commentary.
The best part of any earnings call is the Q+A at the end — it reflects what’s on everyone’s mind. And a central theme on many recent earnings calls is “what’s happening to storage demand?”
While we could argue whether total industry revenue is flat, down or slightly growing, it ain’t what it used to be— not in aggregate capacity, but in total revenue.
The are several theories that are usually advanced. I’m going to argue that we might need a new one.
One frequent explanation is the economy — things are uncertain, U.S government spending, debt crises in Europe, growth cooling in China, etc. While there’s always economic uncertainty in play, it doesn’t satisfy as a longer-term explanation.
Why? Information grows in both good economies and bad economies — and people need a place to store it. And the majority of enterprise IT groups I talk to still see their managed capacity continuing to boom. While economic uncertainty might explain a particular quarter or two, its explanatory power fades as one considers multi-year time periods.
Another popular explanation is the introduction of storage efficiency technologies: dedupe, thin provisioning and similar. I consider flash an efficiency technology: you pay far less for IOPS than by using rotating rust. Certainly, these technologies have been around for a while, and their use is becoming pervasive. But here too, their explanatory power is not entirely satisfying.
I keep in mind that these approaches can’t be used uniformly, and — in particular — rich content (images, videos, log files, etc.), —which is responsible for the majority of capacity growth— frequently isn’t amenable to these approaches.
Then there’s the bugaboo that everyone talks about: cloud. Yes, that’s it — all this data is going to the cloud!
While it’s certainly true that some workloads are now cloud-based (and taking their data with them), once again you come away not entirely convinced. Simply compare the industry capacity estimates for what the storage vendors are shipping with estimates of capacity growth in the big public clouds, and you’ll see that — while this certainly is a factor worth watching — it doesn’t begin to explain everything.
Besides, let’s not forget that — while compute capacity might be fungible and very amenable to a demand-based cloud model — storage capacity is usually *not* fungible and wants to persist. And anyone who’s looked at the numbers realizes it’s usually much cheaper to buy and run your own storage capacity vs. rent from a cloud provider.
Space saving technologies, an uncertain economy, external consumption models — it just doesn’t add up for me. All are valid and plausible factors, but I think there’s something else at play here.
The Deflationary Scenario
Exhibit 1: a 2 TB enterprise-class disk drive is now less than $150 on NewEgg. Retail. As a result, a petabyte isn’t what it used to be: ~$75K for the commodity media. Remember that the next time you hear a storage vendor bragging about how many petabytes they’ve shipped.
While it’s true that enterprise storage vendors get a justifiable premium for their value-add, they’re not immune from the rapid drop in commodity prices. It’s now becoming common practice among storage vendors to continually revise their prices downward — which helps to feed a deflationary mindset.
Oversupply is another factor. If you’re an enterprise IT buyer, how many viable vendors are out there? You’ve got the big traditional names, a handful of server vendors intent on keeping their storage businesses in the game, and at least a dozen reasonable smaller companies hungry for new customer names to show their demanding investors.
Simply put, it appears to be a buyer’s market.
There’s another factor as well — there's less friction involved. Enterprise storage is far easier to acquire and get running than it used to be. It wasn’t all that long ago that getting more enterprise capacity was a big deal: lots of planning, lots of vendor selection, negotiations, long lead times, cumbersome installation processes, migrations, etc.
But all the vendors have been working on improving this for many years — meaning it’s far easier to get what you need, when you need it — another factor in the deflationary scenario.
Far less incentive to plan big and buy big.
Implications Of Storage Deflation
I think enterprise storage buying behavior is starting to change as a result of all of this. More people want to pay spot prices for capacity vs. making long-term contractual commitments. Needless to say, that desire stands in stark contrast to the historical enterprise sales approach.
While this might sound like a good thing, the long-term industry effects aren’t as pleasant. There’s less money available for things like top-shelf customer support, new software enhancements, value-added integrations, innovation, etc. Going back to our familiar desktop computer example, the pace of innovation has almost flatlined as a result.
The Shift To Software — And Software-Defined Storage?
Anyone who’s studied the PC business from the last few decades knows that the big winners were Intel and Microsoft. Everyone in the middle become inevitably compressed. Could we see the same thing happen in enterprise storage?
Our first candidates are the hardware media vendors: disk and flash. They don’t seem to be able to exert any meaningful sort of pricing power, except during unusual circumstances — like a flood in Thailand. Their model seems to be to ship as much capacity as possible.
So the real focus *has* to be on software — the magical stuff that transforms raw storage media into something usable.
For those of us who work for software-defined storage vendors (I work for VMware), we’ve been preaching that the enterprise storage world will inevitably shift from hardware-defined to software-defined.
The VMware-specific view is that value shifts to software that creates a persistent data plane, rich storage services that are application aligned and storage agnostic, and an application-centric, policy-driven control plane that orchestrates this functionality.
We believe that the hypervisor will emerge as the ideal place for this functionality to converge -- hence the term "hypervisor-converged".
Our expectation is that more customers will focus on the software functionality they want, and become spot buyers of capacity when and where they need it.
While it’s not pleasant to consider the effects of this potential transition on storage vendors (friends and colleagues all), it almost seems inevitable from where I sit. Although I'm not close to it, something similar appears to be going on in the network business.