Over the last few months as VxRail has taken off, VxRack SDDC has been launched, the Dell EMC position on the XC platform has become more clear – and finally as people have internalized that HCI and CI (VxBlock) will coexist for years… I’ve started to get a question that is a real head-scratcher for me, and I’ll paraphrase:

“Is VxRack FLEX important, what is its future, and what are the use cases?”

The answers to the compound question are simple: “Is it important? Heck yeah. What is it’s future? Bright. What are the use cases? There are many.”

Making it really clear, the role of VxRack FLEX is right in the name. It’s FLEXIBLE.

1. VxRack FLEX is FLEXIBLE in the sense that it is a rack-scale HCI system that is heterogeneous – not only able to support multiple hypervisors, multiple physical OSes and bare-metal container use cases – but also able to support them simultaneously.
2. VxRack FLEX is FLEXIBLE is the sense that it is a rack-scale HCI system can scale compute and storage as almost completely independent variables.
3. VxRack FLEX is FLEXIBLE in the sense that the compute, storage, network resources can be applied and redirected without being bound by the natural “boundaries” of any given stack (cluster boundaries for example).

Now – FLEXIBILITY and SIMPLICITY are design centers that pull product teams and offers in opposite directions (and if you think otherwise, there’s a bridge in Brooklyn that someone wants to sell you)

Yes, good design, and good software/automation can make any given offer simpler (or if you do it wrong, more complex) – but as a general principle, you gain simplicity as you start to “pin down” independent variables and assign fixed values – reducing optionality, but increasing system level integration and simplicity.

Put otherwise, VxRack FLEX is always going to require more expertise than an HCI rack-scale system that “pins down” the core abstraction/virtualization layer to always being vSphere for example (like VxRail, VxRack SDDC).

Covering the whole market requires that we cover these two ends of the HCI spectrum (flexibility and simplicity) with the best offers in the market – so VxRack FLEX plays a critical role both today and tomorrow.

Read on past the break to understand more. I’ll deconstruct each of the 3 points, and also share where we are taking VxRack FLEX next!

Let’s start by looking at a couple of customer VxRack FLEX installations:

What do you see in common?

The first thing people observe is that VxRack FLEX systems are BIG. Q: Is that the defining element – scale? A: No.

The defining elements are NOT that VxRack FLEX systems can be big (though they certainly can – they scale like nothing else I know of!).

The defining elements for VxRack FLEX are the three points: 1) heterogeneity; 2) compute/network/storage independent scaling; 3) complete freedom in resource redirection.

Let’s be clear – all HCI Rack Scale Systems from Dell EMC share a common characteristic: networking is part of the system design and integral to the product offer.

• Hint: Think “HCI Appliance = bring your own network, and you don’t need to change anything”.
• Hint: Think “HCI Rack-Scale system = networking (physical and SDN) is part of the system – so you need to change the way you think of networks”.

This is true of both VxRack FLEX and VxRack SDDC, our two current HCI Rack-Scale offers.

The “bigness” (scale) is the first thing people see – and incorrectly think of as how to “segment” or build a mental taxonomy of where they apply. Darn humans… we’re so tactile – we ground ourselves in the physical always.

With HCI – some of the traditional ways that people segment infrastructure (“SMB, Mid-Range, Enterprise Datacenter”) just don’t apply – no matter how one tries.

Frankly, when we started with VxRail, we thought it was reserved for “SMB/ROBO” – we figured out quickly that wasn’t right as people pressed it into action in datacenters with tens, and then many tens of appliances.

With HCI appliances – like VxRail or XC – frankly, there is nothing stopping a customer from having hundreds of them in a core datacenter. Start small – scale as big as you want/need. You can see a massive VxRail deployment here.

Now, it’s not a hard and fast rule that VxRack FLEX has to be big – but the simple reality of making the network part of the system design means a set of pretty dense/powerful ToR switches, management switches, and there’s of course the minimum node counts (4 for VxRack FLEX). You can’t see it in each of the pictures above, but each cabinet has integrated ToRs with many 40GbE ports, many Tbps of aggregate switching capacity – and SDN operational models have always figured into the design centers of VxRack systems.

That means that the smallest HCI Rack-Scale system (think “scale really big!”) will always start bigger, and start with more capital gear than HCI appliance (think “start small!”) – because it is designed to snap in nodes, and scale horizontally across many cabinets in an integrated system fashion.

That said – as a general principle, if you know you are going to need more than 10 or so HCI Appliances, you should REALLY consider starting HCI Rack-Scale systems.

Asking yourself this question forces a dialog along these lines: “If we know we will be needing a lot of east-west network traffic for SDS, and ultimately we will need to scale across cabinets – shouldn’t we be evaluating whether we should make the network design part of the system? And while we’re at it, shouldn’t we evaluate whether we are ready for network transformation with SDN?”. The answer may be “no, we are not ready for network transformation” (in which case you deploy a truckload of HCI appliances) or the answer may be “yes, we are ready” (in which case you start with a smaller HCI Rack Scale system).

In the 2 x 2 quadrants of the Dell EMC HCI portfolio – this distinction (HCI Appliances, HCI Rack-Scale Systems) represents the “left and right”.

Ok – so if “bigness” is not the main point – let’s get back to what IS defining about VxRack FLEX…

First, heterogeneity.

Understanding the critical role of VxRack FLEX is to understand that HCI design centers have an orientation that I don’t know how to refer to other than “vertical” or “horizontal”.

“Vertical” denotes a design orientation around a specific stack. VxRail, VxRack SDDC are examples, as well as the current approach of the Microsoft Azure Stack. This design center deeply roots the design (both the hardware choices and more importantly the software and lifecycle management) around fixing one or more variables, like the hypervisor.

For example, VxRail and VxRack SDDC start with a core assumption: “Every host will run ESXi”. This then leads to: “every workload will be a VM”. This then leads to: “natural boundaries are vSphere and vCenter boundaries”. This then leads to… So on, and so on. The advantage of this approach is nothing can match its INTEGRATION & SIMPLICITY (operative words) with that particular set of stack choices.

“Horizontal” denotes a design orientation where HCI is viewed as a pool of compute/network/storage resources that can be used across many stacks, and very generalized use cases. This leads to a much more FLEXIBLE (operative word) design – from the hardware variability to how the SDS layer needs to work. It also means that resource (compute/storage/network) distribution cannot pre-suppose any given natural “stack boundary”. The management and orchestration stack of horizontal HCI models is much more challenging – because no variables are “pinned down”. The advantage of the “horizontal” approach is nothing can match its FLEXIBILITY (operative word) across different stack choices.

Here’s a chicken scratch diagram (yes, I’m enjoying my new XPS 13 2-in-1 🙂

The “vertical” stack on the left is fully integrated all the way up to the abstraction. In the example of our two VMware HCI offers that are vertically integrated (VxRail and VxRack SDDC), the abstractions are vSphere which leads to ESXi/vCenter, vSAN, and in the case of VxRack SDDC – VxRail’s HCI Rack-Scale system sibling (remember, Rack-Scale = network included) – NSX. This is always the case with VxRail and VxRack SDDC.

Note that this tight coupling means that the integration of the whole set of HCI offers goes further – which makes them fundamentally simpler. “Fixing” those variables also means that things like vSphere cluster boundaries, vCenter maximums – these trickle down into all the elements of the design. What workloads can you run? Good thing with vSphere as the “fixed variable” is you can run a heck of a lot – the majority of enterprise workloads, frankly. But – not all. If someone said “I need a workload that does 5 million IOps”, it would be a bear, if not impossible.   It also means that you can simplify certain choices – for example, you don’t need any imaging services other than those needed to image nodes with ESXi.  You don’t need hardware telemetry that is independent of what you get through ESXi.   You can get by with a simple hardware abstraction layer.

The “horizontal” stack on the right is integrated, but not all the way up to the abstraction. You could use multiple different abstractions. Uniquely with VxRack FLEX – this heterogeneity isn’t just a one time choice (“pick your hypervisor”), but literally you can have vSphere, KVM, and physical hosts with no hypervisor all on the same system at the same time.

Note that this looser coupling is fundamentally more FLEXIBLE (there’s that operational word). Frankly, almost any workload – aside from those that need the most stringent remote replication requirements, or cannot run on an x86-based system – can run on a VxRack FLEX system. It means that “some assembly is always required”. The integration doesn’t go all the way up into the abstraction layer. Yes, you can use vSphere (in fact, that’s the most common abstraction on VxRack FLEX), and it works great – but vSphere deployment/patch/lifecycle – this falls outside the system itself.   It means also that the management & orchestration layer needs a lot more modularity – after all, it can be pressed into many, MANY use cases.

This “horizontal” and “vertical” distinction is the other way of looking at the 2×2 matrix of our HCI offers at Dell EMC. VxRail and VxRack SDDC represent the “vertical” orientation. XC and VxRack FLEX represent the “horizontal” orientation.

Not that it matters, but it’s interesting – we are organized around this principle.

• For the team that is working on the vertically integrated VMware HCI offers (VxRail and VxRack SDDC) – they are one team, and it’s a team that is filled with VMware and Dell EMC employees. They live, breathe every day in a world where it’s VMware, all the time. Their roadmap is one. When there is a fix for vSphere, it is integrated into the roadmap in a heartbeat. If vSphere is your standard, VxRail is for you, and if you are ready for network transformation – VxRack SDDC is where to start.
• For the team that is working on the horizontal HCI stacks – they have to think about vSphere to be sure (it’s the most common use case), but have customers with all sorts of other use cases. VxRack FLEX also is the design underpinning for work that we do around other stacks – and my aim over time is to use VxRack FLEX more and more as the basis for what we do with Microsoft and RedHat, as well as other stacks.

What are common VxRack FLEX use cases? Frankly as a “horizontal HCI stack” – there are a million. It can be used as a simplifying set of infrastructure for any “horizontal” infrastructure use case. Here are some common examples we see:

Now – in several of these cases, Dell EMC also has a “vertically integrated” approach as well as the “horizontal” one.   For example, running EHC on VxRail would be an example for Transforming IT operations with a very simple, very “vertically integrated” stack.   Another example would be Modernizing Applications could be NHC on VxRail also.   Both  EHC and NHC will both will also be available on VxRack SDDC as well.  

However, some customers prefer the horizontal HCI Rack-Scale approach – a common pool of compute/network/storage for all workloads simultaneously.   Let me give you some real world examples:

• One real world example is at a large retailer. They needed to cut $10B in logistics costs over the next 10 years, and a part of that was a high availability platform to operate a third party robotics warehousing application. They wanted to be able to integrate into existing management tools and the ability to remotely manage and define the entire solution. Note how this is a very “horizontal use case” in the sense that it doesn’t start with a given stack (VMware, Microsoft, whatever), but instead started with a generalized (but industry specific) app. They deployed VxRack FLEX and saw a 50% cost reduction, simplified operations and accelerated time-to-market for their new app. Net? Rapid integration and deployment of IT piece of the logistics and supply chain automation = business happy.
• Another real world example you will use often dear reader is if you check in online or at a hotel of one of the largest hotel chains, the massive OLTP system, demanding insane IOps (and in this case not running virtualized) runs on a VxRack FLEX system.
• Yet another customer, one I spend a lot of time and love for their mission – in their case, they use VxRack FLEX as the basis of their SDDC approach – using it mostly with vSphere, but also for some cases for non-vSphere use cases.  in their case “SDDC” is not synonymous with vSphere as it is with many customers, but rather a software-defined, programmable infrastructure approach in general.

There you have the FIRST of the things that make VxRack FLEX important – and reinforces the core value of FLEXIBILITY: any mix of workloads, any hypervisors, physical hosts – all at the same time, on the same system.

Second – hardware variability and independent CPU/storage scaling.

When you design a “vertically integrated” stack – you know that you can assume certain “common combinations” of compute/memory/storage.  Yes, there’s a broad range of configurations with VxRail and VxRack SDDC – but how the stack “comes together” ends up building around what you generally see in 99.9% of the cases with that abstraction model. You can see this “pop out” in some of the vSAN best practices. It’s relatively hard to create a mix which is VERY CPU heavy/storage light, or CPU light and VERY storage heavy with VxRail or VxRack SDDC. This is one of the reasons BTW that we’re working together with VMware to make bringing external storage (including SDS server SAN with ScaleIO) to bear to VxRack SDDC over time.

Conversely, with VxRack FLEX – node mix and match is very FLEXIBLE.

Frankly, the 3 examples in the diagram above here are just that – examples. You can mix and match node types all over the place with VxRack FLEX, covering an almost infinite range of CPU/storage mix and ratios. In fact, a system could have multiple domains with different combinations. This is important, because in VxRack FLEX – we can’t make any assumptions about common use cases.

There you have the SECOND of the things that make VxRack FLEX important – and reinforces the core value of FLEXIBILITY: any mix of CPU/Memory/Network/Storage – because we need the flexibility for almost any set of datacenter workload mix.

Third – completely flexible resource distribution.

When you cannot assume any given abstraction – you need to be able to move resources that are fungible to any workload. The power of ScaleIO as the SDS that underpins VxRack FLEX shines in general, but very much so in this area. You can see how this need is echoed in the “two types of SDS” post I did here – and why ScaleIO is at the core of VxRack FLEX. The flexibility of a SDS that is a “server SAN” is that the capacity/bandwidth/IOps can be distributed in any way one could possibly need.

For an example, if you use the nodes in a dense storage configuration – you could take 24 nodes and direct the full oomph of the 24 nodes to a single workload. Think of the OLTP example for the hotel chain – that workload does need millions of IOps for a single set of host that are clustered (and in that case a physical host).

Furthermore – the pool of storage resource pooling and distribution is completely independent of abstraction.   You can assign it all to one VM, one host.  You can pool it across clusters.  You can share IOps across tenants, or dedicate them.   The idea of a “vSphere cluster” as a natural boundary would not be applicable – because by definition, vSphere is one (the most popular) abstractions, but not the only one.  

There you have the THIRD of the things that make VxRack FLEX important – and reinforces the core value of FLEXIBILITY: resources can be distributed anywhere across the system – because we need the flexibility for almost any set of datacenter workload mix, and can’t assume any “natural abstraction boundaries”.

There you have it – VxRack FLEX is FLEXIBLE.  

It means that VxRack FLEX can be put into an incredibly broad set of use cases – but needs a little more work for the customer to integrate into any one given stack or use case.   Some readers may scratch their head and say “I don’t get it”.   That’s OK – it means you’re likely someone that has a very VMware-centric world-view (which is great!)  For those people, VxRail and VxRack SDDC are the Dell Technologies manifestation of that vertically integrated stack by Dell EMC and VMware – and no better choice for that type of customer.

Conversely, others naturally think: “No way – I want my HCI Rack-Scale system to be flexible enough to support vSphere and other use cases, and I’m willing to trade off SIMPLICITY for FLEXIBILITY”.

Customers in my experience very rapidly sort themselves into one of the two architectural approaches – and it’s our intent to lead in all forms of Hyper-Converged infrastructure, just like we lead in all forms of Converged Infrastructure (VxBlock).

So – what’s next for VxRack FLEX? A lot.

1. We are working furiously on the next-generation management and orchestration layer. This is the critical next piece for VxRack FLEX. It ties very strongly into the idea of flexibility, openness that is necessary from a model like VxRack FLEX. Expect more on this front this year – and it will also represent the future for Vision, Active System Manager and more. It’s use will NOT be limited to VxRack FLEX (and will include VxBlock for example, as well as other Dell EMC blueprint solutions like Ready Nodes) – but it must NAIL the VxRack FLEX use cases.
2. We already leverage the Dell EMC PowerEdge family (R630 and R730xd) – but can do more. Right now, we are still using an “early merger” process where the nodes come from the heritage Dell factory and then are assembled in to systems in the heritage VCE factories. It’s a good approach, but over time – we know we can make it even better. As HCI becomes a core part of how all enterprises consume infrastructure on premises, optimizing the snot out of this supply chain/manufacturing may be boring from a technical perspective, but matters a LOT from a business and outcome perspective.
3. Technical roadmap. In the earliest days, we’ve been building HCI out of the components we have, versus thinking about how we would optimize components (SDS stacks, networking components, SDN elements, server nodes) as HCI ingredients. For example, I want to take things like Isilon SD Edge and ECS (SDS unstructured data stacks) and make them available as options on VxRack FLEX. The team is now working with their new Dell PowerEdge brothers and sisters to think through: “how would we create server platforms if they were not generic, but were purpose built for use in HCI systems”

While most analysts/market noise is about the battles in the HCI appliance space and market (and it is hot, fast and furious!) where VxRail is making massive headway – I believe that VxRack FLEX will be a billion dollar market in the next 2 years (along with VxRail and VxRack SDDC).