There’s lots that can be debated, many topics that can be debated. One thing that cannot be debated is that people are trying to make parts of IT that they view as important but low “differentiation” (for their business) SIMPLER.
This is the really basic observation that is behind the success of converged, hyper-converged infrastructure - packaged IaaS offerings, and all forms of cloud business models (Private, Managed and Public).
Since EMC is a public company*, how our business is working is wide open to the public every quarter. We’ve publicly noted that VCE was on a $2B run rate, and in Q2 of this year, we publicly disclosed a 30% revenue growth rate. Now - until recently - VCE was in effect a single “product” company with only “block” style converged infrastructure.
*People have recently noted that sometimes when a company is forced to publicly disclose revenues/burn rates… well just how much can be hidden behind stating “percentage growth” rather than absolute dollar terms. Something to consider with any startup (whether you’re looking to buy, or join) - don’t ask the person you’re talking to for how they are doing on growth, ask them for absolute bookings, cash position and burn rate.
Posting big numbers, and fighting the law of big numbers (every time the number grows, maintaining a high growth percentage just gets harder) is very impressive. It highlights something that cannot be denied: when for whatever reason customers cannot use or are not best served by a public IaaS cloud or a managed virtually private one - customers want simplified and converged infrastructure, and then on that, they want simplified “Cloud Personas”. This highlights the main “why” on all forms of converged infrastructure: “go faster, and get out of a low-value part of IT”. It also highlights why EMC views “winning all forms of CI” a strategic imperative.
But - there’s an inherent upside/downside of the “block” style of converged infrastructure:
Scale:
Block architectures are really only available in “medium/large”. Upside: CI Blocks are remarkably cost-effective from a CAPEX standpoint at those larger scale points. Downside: they are composited of traditional architectures assembled, engineered and packaged in a converged fashion, the smallest one is not inexpensive, and they scale to a certain point where you then need another big block. Think of a CAPEX picture with big, $750K steps in the step function.
Operation:
While they are delivered in a single large block - they are a composite of traditional components. Upside: CI:Blocks have the full set of data services and operational behaviors on which some traditional workloads depend. Downside: while the CI vendor takes on the responsibility of testing, engineering, updating - it’s not easy - and while there is some OPEX benefit of going CI, it’s not enormous.
Both of these points highlight why the hyper-converged category exists - is well populated by strong startups, and why EMC (and VMware) views hyper-converged as a critical market to win - over time, as important (perhaps more important) than “Block” traditional style architectures - which will continue to be popular at scale, and when building a “unified” stack that must support workloads with traditional data service requirements.
Q: So, what defines a hyper-converged infrastructure offer?
A: Here’s my list:
- Uses lower-value industry-standard servers with local storage as the modular component (don’t try to build a ton of value into the server itself)
- Uses an SDS layer to deliver the persistence capability - and grow in a linear way as additional nodes are added. SDS layers are wildly different.
- Uses a management and orchestration (M&O) layer to automate a lot. How much is automated varies - and HOW this is done varies, but it’s a lot of system-level automation.
Q: Are all hyper-converged infrastructure offers the same?
A: No, they sure aren’t. While the all have the 3 above - their design centers are WILDLY different.
Let me ask you something. Do you think it’s possible to design something that NAILS the requirements of: A) an ROBO/SMB/SME customer looking to host a mix of VDI/general purpose virtual servers - maybe even a few thousand (a pretty big customer!); AND B) simultaneously with an Enterprise Datacenter (with a crazy variety traditional apps and some brownfield Cloud Native Apps) AND C) hyper-scale green field Cloud Native App focus?
No - that’s totally delusional.
The fact is that each of those CAN be met with a hyper-converged infrastructure approach - and they all will kind of “look” the same in the sense that they have: 1 (industry standard servers), 2 (SDS), 3 (system M&O) in the list above - but the design centre of the systems as a whole are WILDLY different.
People have started to realize this when they take hyper-converged systems that optimize around the SMB/SME customer bands and then push them into the other use cases. They LOVE the simplicity and low entry price they deliver, but then discover the economic and system level scaling gets less awesome as they scale up. And while they “look” like how everyone imagines a “hyper-scale Cloud Native App” infrastructure should look (and often they use some of these technologies internally) - the design center of the system is totally different.
This means something simple: there is no unicorn: there is no single hyper-converged stack (hardware and software) that can cover these wildly differing use cases.
Now - people will surely disagree with me (and I can imagine who!), but that’s why I think a portfolio is needed. The portfolio should have exactly the amount of variation needed - not an ounce too much, but not an ounce less.
Here’s the VCE portfolio - and these are all now available (the VxRack is in directed availability now, as VCE ramps up to make sure they can deliver the white glove experience people have come to expect from them).
Blocks: Converged Infrastructure built from traditional datacenter architectures - which makes them ideal for a broad set of workloads including the most mission critical monolithic apps with deep infrastructure and data service requirements. Comes in medium and large - not available in small. Has a big “step function”. Simplifies operation and lowers OPEX since it’s an engineered system - but only so much as the traditional architecture can support. Offer: VxBlock (and Vblock for people that don’t want NSX)
Racks: Hyper-Converged Infrastructure built using industry standard servers + SDS + Management and Orchestration layer. Optimized for Rack and multi-rack scales. Comes in small to VERY, VERY large - in small linear steps. Disaggregated system design for broad hardware flexibility. Simplifies operation and lowers OPEX since it’s an engineered system - beyond blocks because it does not have a traditional datacenter architecture. But - this means that they can support broad workloads - but in general not those that are the most mission critical monolithic apps with deep infrastructure and data service requirements (can only do what the SDS layer can support). Can support multiple software “personas” for wildly different use cases. Offer: VxRack
Appliances: Hyper-Converged Infrastructure built using industry standard servers + SDS + Management and Orchestration layer. Optimized for “start small, be super simple”. modular building block system design for simplest operational model. Supports a single persona, a single SDS - because in that market - low entry price, simplest operation, rules the day. Offer: VSPEX Blue
Now - I want to double-click on the Appliance and Racks categories.
Appliances.
In this category, we know we need to be the simplest, most awesome turn-key product. It needs to start in low price bands - be feature rich, and nail the ROBO/SMB/SME use cases.
I’m going to make this simple - because most people know VSPEX Blue - and I will run out of space to update on VxRack.
- The joint team has a singular mission: to completely win in the Hyper-Converged Appliance Infrastructure category.
- There have been lots of updates: support for different licensing and support models, updates to the software stacks - and there are a lot more coming.
- We know what works - and what we need to do to fill in gaps.
- We are in it to win it.
- We are going to accelerate our iteration in every vector.
- I would not want to be one of our competitors in this space (who we respect fiercely) - because we are going to hit the gas.
- Partners - learn about VSPEX Blue - and hang on to your hat.
Racks.
At EMC World in May, we talked about our early work on VxRack. It is now in Directed Availability - and will be generally available shortly.
People speculate wildly about the hardware in it (and I see competitors get it wrong). There are 3 node “types”, but each of those have a broad range of configs - it’s a disaggregated system.
What do I mean by “Disaggregated?” - well unlike appliances that generally are optimized to scale somewhat linearly - with a disaggregated rack-scale system - you can scale compute and storage in different dimensions. This is what I mean:
Looking at the above - you can imagine that this design could easily include things like DSSD in the future, or the crazy new interconnects that Intel keeps introducing.
Unlike appliances, it has a spine-leaf network architecture that is there always - because like all true rack-scale systems - you need to contemplate the network if you really want to scale. All of this means there needs to be a hardware management and orchestration layer that is MUCH more sophisticated than in the appliance category. This layer of tech needs to do fault, remediation, firmware, low-level hardware management and telemetry.
This is a place where there’s a lot going on - with more to come in the future. We’ve talked a little about the work that EMC has been doing (OnRack), VMware has been working on something called Hardware Management System (HMS) - and Intel has some really cool things also. Hint - stay tuned!
And lastly - if you want to support multiple “personas”, you need to have a system-level management function and a vehicle to keep the whole system current and linked to the system support tools - which is VxRack Manager and VCE Vision, which we showed at EMC World:
So - you now have an idea of what VxRack is - with the “bring your own persona” baseline.
Now, what will be the first pre-packaged “personality” that we will support on VxRack - the VMware SDDC of course! This where our partnership with the EVO SDDC Suite and EVO SDDC Manager comes into the picture.
Ultimately - no one just want Hyper-Converged Infrastructure - they want to DO something with it. Some people will want to build their own cloud IaaS stack - or deploy other applications. Many people will want to deploy the VMware SDDC in a way that’s simple and easy.
If VxRack makes deploying, updating, supporting a hyper converged rack scale infrastructure easy - then the EVO SDDC Suite makes deploying the VMware SDDC on top of hyper-converged rack scale infrastructure easy.
Thanks to the VMware EVO SDDC Suite team (thanks!), here’s a demo of the EVO SDDC Manager in action!
You can go to the EVO SDDC Suite booth at VMworld and see the EVO SDDC Suite and VxRack for yourself!
There’s lots of work to do still… VxRack needs to exit directed availability. We need to finalize the integration between the OnRack and VMware HMS elements - but the teams are working furiously down this path, and if you want the latest, reach out to your VCE team (or hit me on twitter :-)
Will we stop with the EVO SDDC Suite persona? No - expect to see “Greenfield Cloud Native App” personas in the future - lots to do there around the Photon Platform and Pivotal Cloud Foundry - and heck, even things for customers who reject the “full Federation" Cloud Native App stack.
I’m going to close out this post by re-emphasizing an important and simple observation.
Q: Aren’t Hyper-Converged Appliances and Hyper-Converged Rack-Scale systems fundamentally the same?
A: NO. And don’t fall for marketing. Note the real, fundamental architectural differences:
- HCI Appliances are: 1) Made from building blocks + 2) are designed to start small + 3) have a lightweight hardware M&O layer
- HCI Rack-Scale systems are: 1) Made using a disaggregated system components + 2) are designed to scale big + 3) have a material hardware M&O layer
Trust me. Over time, Converged and Hyper-Converged Infrastructure will consume the stand-alone infrastructure component markets (which will still exist - but simply feed into CI and HCI offers from giants).
That means you will see a lot of craziness in this area over the coming years - challenge me, challenge us, challenge others - and think clearly - architecture-level thinking is valuable.
Comments