I have a question for you. Actually, a couple questions.
Q: Do you think that there will be ONE form of converged infrastructure for all customers?
Q: Do you think that the answer is always hyper-converged, or always converged – or that the answer is “it depends”
Q: Do you think that at very large scale (think many thousands or tens of thousands of VMs, millions of Containers) – is hyperconverged (compute/network/memory/storage scale together) right, or is disaggregated (compute/network/memory/storage scale independently) right?
Q: Do you think that at very small scale (less than hundreds of VMs/containers) – is hyperconverged (compute/network/memory/storage scale together) right, or is disaggregated (compute/network/memory/storage scale independently)
Q: Do you think that if you are using a “converged infrastructure” strategy – should it match the workloads, or should the workloads match what the infrastructure can do (ergo you don’t deploy the workloads that can’t run on that CI there, and put them to the side, or change their requirements)?
Q: Which of statements do you indentify with:
- “I want to use vSphere as a single common abstraction layer for all compute/storage/network – if I could standardize on that for everything, life would be grand – and I will drive to that furiously!”
- “I love VMware, but I know I will have a heterogeneous strata of abstraction, and will have some physical stuff for the foreseeable future.”
- “I hate VMware – and love ______” (like KVM/Openstack, Hyper-V, or forget all that jazz and drop all ‘Platform 2’ workloads and go for ‘Platform 3 gusto’ – go containers on bare metal)
Seriously – I want to know :-) I posted a little survey here. Share anonymously – and I will share the what you share with me in a couple weeks!
The point here is a simple, but important one.
Even if you believe that converged infrastructure vs. assembled infrastructure is an inevitable simplification – converged infrastructure will NOT come in a single form, but instead a broad spectrum of forms of converged infrastructure that will each evolve over time.
Now – I truly believe that an increasing consumption of infrastructure in converged forms is inevitable. Why?
People are starting to grok something fundamental: while there will always be innovations in parts of the stack (network/server/storage/abstraction/automation etc) – the incremental benefit of hyper-engineering elements of the stack is minimizing (except for certain important corner cases).
Frankly one side effect of the success of the hyper-scale public clouds is an acceleration of this understanding: business benefit comes from outcomes, and frankly “lock-in” risk below the IaaS layer is a nit.
Yeah, sure – there are some that fight this furiously – but usually it is people trying to protect their “turf”.
There are a multitude of different “converged infrastructure” offers on the market – all different. Vblock and VSPEX Blue and other startups focused on hyperconverged architectures (each coupled with an IaaS layer to make them a cloud) and yes – the IaaS layers of things like vCloud Air, Azure, AWS are each proving something…
You’re wasting time if you are optimizing and managing component by component. Let someone else do that for you, and focus on more valuable things.
But – as the questions and observations above show (we’ll see if the survey confirms!) – converged infrastructure system design is not going to be “one way”.
In other words – it’s time for a “phylum” or taxonomy for converged infrastructure architectures, just like there was one for storage (here).
Now – I can’t claim to be the inventor of this taxonomy. It’s one that has had a lot of discussion/thinking across EMC, VMware, VCE by many over many, many years – and it’s not an “invention”, but rather something that flows naturally from talking to lots, and lots, and lots of customers.
I believe that the taxonomy of BLOCKS, RACKS, APPLIANCES captures 3 distinct design centers and groups of various forms of converged infrastructure system-level design.
EMC/VCE is the CI leader by a long margin with Vblocks and VxBlocks in the BLOCK category. We’ve come out swinging with VSPEX Blue as our first APPLIANCE. And today, we’re extending our leadership position with the tech preview of VxRack as our first RACK system architecture.
Read on to understand/discuss the idea of the BLOCKS, RACKS, and APPLIANCES taxonomy. Please – I want YOUR thoughts and comments!