EMC World Day 1: BLOCKS, RACKS, APPLIANCES.

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!

Ok – first, let us start with baseline axioms:

• We are talking about SYSTEM architectures.   While you can group examples into one “phylum” or another – it doesn’t mean that they are all the same.   While you could make an argument that VSPEX Blue and other hyper-converged appliances fit into the APPLIANCE category, that doesn’t make them all the same.   Their SYSTEM design center has certain similarities.
• This is about SYSTEM architecture not hardware vs. software.   Software tends to define the SYSTEM architecture, though (I agree with Chuck’s point here point that these system architectures are defined by software, and packaged in various ways).  Some CI variations will come in software + bring your own commodity hardware, some will come with software coupled with hardware in appliance form.  Now, in my experience customers seem to be voting with their feet that they want minimal self assembly.  All these observations may be important distinctions but they don’t change the SYSTEM level architecture.

Ok – let’s look at each of these:

BLOCKS:

• Design Center = “Proven”
• Prioritization/Focus =  Rich Infrastructure Services – P2 Applications – specific use cases
• System Architecture = disaggregated compute/memory/network/storage – loads of variation, lots of traditional “appliance” elements (required to deliver legacy persistence and networking capabilities)

RACKS:

• Design Center = “Flexible”
• Prioritization/Focus =  Different personality types (P2, P2.5, P3, kernel mode VMs, containers – you name it) performance/reliability and operational simplicity at large scale.
• System Architecture = Defined by the SDS layer in large part, as these use SDS + Commodity off the Shelf (COTS) hardware.  Can start moderately small – but fundamentally designed for scale.

APPLIANCES:

• Design Center = “Simple”
• Prioritization/Focus =  Simplicity and small starting scale above all else.
• System Architecture = Defined by the SDS layer in large part, as these use SDS + Commodity off the Shelf (COTS) hardware.  Can start moderately small – but fundamentally designed for scale.

Now, I want to be clear – it’s not that BLOCKS aren’t “flexible” or “simple”, or that APPLIANCES can’t be “FLEXIBLE” – but this is their DESIGN center.   It’s a false argument to say: “but I want to be able to support all the proven workloads I run today unchanged, with total flexibility, and total operational simplicity”.  Sounds nice, but it’s a delusion.  This observation is a variation of the classic idiom: “fast, cheap, reliable – pick two”.

For example: imagine designing an APPLIANCE, and having a choice – to broaden hardware architectures or scale, but at the expense of the overall “simple” experience – what do you trade off?  Answer = keep a tighter control on hardware variation in favor of maintaining/improving simplicity.

Another example: imagine designing a BLOCK, and having a choice – to simplify operations, but at the expense of being able to support traditional use cases – what do you trade off?   Answer = work around more complex operational elements, in favor of supporting the requirements of the traditional use case.

Warning – what you will see/experience of course is that people will vehemently argue in favor of BLOCKS! No, it’s all about RACKS!   No you idiot, it’s all about APPLIANCES!   

In my experience – that perspective comes when consciously or subconsciously you “block off” the logical arguments around the strengths/weaknesses of each.  It’s a variation of the ancient furious battles of “NAS! NO, BLOCK!” or “PRIVATE CLOUD!   NO, PUBLIC CLOUD!”

As some have observed, startups are often fueled by passion, and fanatical fervor.   It’s funny, I wrote this before I read Chuck’s post here on “The Cults Among Us”.  I’ve been there – and it feels really, really good :-)  Life is simple :-)

Sometimes that fervor is not driven by belief/passion.   Sometimes it’s something more insidious.   Sometimes the fervor is rooted in “I only have a hammer, so I better argue that everything is a nail”.   I get that too,I suppose.  

I suspect (and encourage) that this post will get lots of arguments to this post from some (customers, companies, whatever) saying that this taxonomy is a false one.   I would encourage each reader to think for themselves, and come to their own conclusions.  I WANT to debate, discuss with you – but let’s not let any of us be cultists!

Ok… just like with the storage taxonomy, it’s VERY useful intellectually to think of these system architecture without attaching a vendor label or implementation, because it helps group similar things together.  

Just like with the storage taxonomy, I would argue that these are SYSTEM architectures – and while different implementations will have various strengths and weaknesses, those SYSTEM design centers will influence the strengths and weaknesses of everything in a category – across different vendor implementations.

Now – one observation that is an interesting one:

People tend to assume that the capex model of BLOCKS is worse than the capex model of APPLICANCES and RACKS – because the APPLIANCE/RACKS use industry standard components.

The reality is that the economic cost curves are different.

This diagram on the left is a simplified representation of a basic idea:

System architectures that are BLOCKS have a large step function of capex cost embedded in them.

Conversely, SYSTEM architectures of RACKS and APPLIANCES tend to have smaller step functions of capex cost.

Depending where you are on the scaling axis, BLOCKS can be have more, or less capex cost embedded in their model than RACKS and APPLIANCES.   There are also other factors (the above is a simplification) – like often the density (capacity/IOps/compute/memory) of the 3 system architecture vary.

Ok – next observation: that is capex COST (the inherent capital embedded in the architectures) – not the PRICE (what people pay) curve.   What does the price curve of a “utilitized” (aka “sold as a utility”) BLOCK look like?   Answer – a linear line.  

The lines in the diagram represent the inherent cost in the architectures of their hardware scaling model.   Likewise – price is also a function of so many other factors, you can’t simply map it out like this (everyone has different economic models, and different values inherent in the software stacks).   BUT – the diagram above does reflect the inherent hardware capital cost model.

There’s another HUGE factor – frankly, I think the more important economic factor – which is the OPEX model.  

Since BLOCKS have traditional elements for persistence and network as well as traditional SYSTEM level design (both required to support some existing workload requirements), the scaling of the opex model looks a little more like traditional stacks – even when well integrated as a converged infrastructure model.  It looks like a step function (matching the capex curves)

Conversely, the operational model model of RACKS and APPLIANCES has a more simple scaling model, and are designed around a simpler operational model, so their OPEX scaling curve looks more logarithmic.

At EMC – our CI portfolio maps out like this (all are about accelerating outcomes) :

• BLOCKS = Vblock and VxBlock.   Step function scaling with disaggregated hardware.  Design center = “Proven” 
  • They are widely deployed.  We have customers who are now refreshing their Vblock/VxBlocks.
  • They can support any workload in the datacenter that isn’t a mainframe.
  • They have broad sets of services for classic requirements that many current SDS models cannot meet
  • They have the “Block” architectural and economic scaling model.
• RACKS = VxRack.   Linear function scaling, with hardware and persona flexibility.  Design center = “Flexible”
  • They will come in multiple personas – open, and also VMware-centric.
  • They are engineered systems.  Think of the experience of a bespoke suit vs. a suit off the rack.   They think of things like network design for example (because at scale, ToR design is critical)
  • They have the same the “RACK” architectural and economic scaling model.
• APPLIANCES = VSPEX Blue.  Linear function scaling, fixed hardware and personas.   Design center = “Simple”. 
  • There is nothing simpler – not just to operate, but acquisition, deployment, updates.
  • They have a simple entry point, and simple configurations.   Bring whatever network you want (because at small scale, ToR design isn’t critical)
  • They have the the “APPLIANCE” architectural and economic scaling model.

Today we announced VxRack – which is the family of offers built around the “RACKS” design center.   The CI leader is now the “complete CI Portfolio leader”. 

BTW - There’s a SIMPLE decoder for the EMC/VCE product naming:

• __Block = a “BLOCK” architecture.  Compute/network/storage disaggregated, in a “big block” consumption model.   The number behind the name = a model of that type, which is a function of the data services.
• __Rack = a “RACK” architecture.   Compute/network/storage are in some form of hyper-converged model – some tightly coupled, some pretty disaggregated.   The number behind the name = a model of that type, which is a function of the type.   The first persona type announced was the “open” persona – the VxRack 1000.   We indicated that there would be a “VMware only” persona built on EVO:RACK.
• In ___Block and ___ Rack
  • IF “___” = V = then it’s just Cisco, EMC, VMware, and Cisco is the – only networking stack.
  • IF “___” = Vx = then it’s EMC with any server type, and any network type.  Could be Cisco, could not be.
• VSPEX ____ = an “APPLIANCE” architecture and a channel/distributor GTM model.   Note that “VSPEX” without a word behind it is our reference architecture program for our channel partners/distribtors.   While this is a reference architecture and not full converged infrastructure (with integrated support/update/warranty etc) – it is still a “BLOCK” class infrastructure system architecture.

I’ll do a standalone post on VxRack for people who want to learn more about it (including details and demos!)

The whole CI portfolio all comes from EMC and our partners with a fully converged model – buy as a system, support as a system, manage as a system.

So – how to navigate these choices?   He’s an example of how I’ve been guiding customers in simple question-driven flows:

Here – a customer says “I will forgo all workloads that have traditional data service depenencies that are not handled in the SDS data planes” (or they will handle those workloads otherwise).

The core question is then “do you believe in the design of a single abstraction layer for all workloads?”   If yes, put it all on vSphere, and the RACK based design, which is VxRack with the EVO:RACK personality – later this year.

If no (perhaps there are workloads that for any reason won’t be on vSphere, but will be on physical – or perhaps the customer has a mix of non-vSphere hypervisors), the answer will be VxRack with the open personality.

What about the case where a customer has broad application requirements, and doesn’t want to “not go CI” because the SDS layer and various networking functions can’t support them?   Let me give you an example.  What if they want to deploy an SAP Landscape, and need consistency groups.  Or what happens if the application stack has a specific dependency or certification against a given target?   Or perhaps it’s SAP HANA and they need a TDI or appliance support position?

Well – in that case it CANNOT be deployed on the path to the left in the diagram here.   Note that going down that path (staying in the RACK system design) and only getting the VxRack with the vSphere persona means that they would have to not put those workloads on it.

They would generally go down the path to the right – use Vblock for the subset of workloads that demand that behavior, and VxRack for the rest.

Another question is how the customer views the world of P2 workloads (dependent on infrastructure resilience, scale up, pets) and P3 workloads (app-level resilience, scale-out, cattle)

Some customers (generally those with a small amount of P3) go down the path to the left.  They work to have a single stack, a single team operate the whole thing.   They use vSphere for the world of P2 workloads and will use VxRack with the EVO:RACK persona to optimize it using some of the ideas in P3-land (vSphere only SDS layer + commodity hardware, SDN model) to make it “P2.5”.   They love the idea of using Cloud Foundry and getting the openstack APIs on top of the same stack for their P3 models.  Photon as a thin light linux distribution seems great!

Other customers (generally those with a lot of P3, or working towards a lot of P3) go down the path on the right.   They will use VxRack with the open persona, and simply put their P2 workloads on there using some of the ideas in P3-land (an OPEN SDS + commodity hardware, OPEN SDN model) to make it “P2.5”.   Their P3 workloads will be more “pure” open source.

This last question example is a nice one.   Someone still reading this (thanks for sticking with me!) might ask themselves: “WTF is Chad talking about?!?!   I only have a few hundred VMs.  I don’t have a huge SAP landscape.  I don’t have ANY P3 workloads.  All I want is the ‘easy button’!”

In that case – there’s no decision tree :-)   VSPEX Blue can be ordered in minutes, arrive in days, and be setup and running in less than 10 minutes.   There’s nothing simpler.  

Remember the design center = Simple.  That’s simple in all things (including acquisition/configuration/etc).

Let me make one final observation.   Humans like there to be ONE ANSWER.

It’s a TRAP!

Just like with the diversity in the storage phylum – there is diversity in the converged infrastructure phylum for a reason: they are adapted to fit their environment.   The name of the game is to pick the right amount of diversity.  Not too few (you’re not efficient) and not too many (you’re overcomplicating things).

In my opinion, the correct way to look at the question of “what is the right CI strategy for me?” is along these lines:

• “Is CI right for me?”  Hint: whomever is saying “No” is likely wrong, and is holding on too tightly to the old ways of operating the domains of server/network/storage as silos – which is a waste of time.
• “How much time do I want to spend on self-assembly?”  Personally – I think the right answer to that one is “none”.
• “What percentage of my workloads are ideal for BLOCKS – and which model?”
• “What percentage of my workloads are ideal for RACKS – and which persona: open, VMware-centric?”  
• “What percentage of my workloads are ideal for APPLIANCES?”

Evaluate the landscape, and make your choices based on who you think can execute best for you.   To deny that CI is increasingly the right answer, and that there is a diversity of CI choices and system architectures is to have one’s head in the sand IMO.

Would love your thoughts, your input?   Am I thinking about this in the right/wrong way?