Home » VCDX » Using CI or HCI for VCDX? Read this.

Using CI or HCI for VCDX? Read this.


Disclaimer: These are my personal thoughts and not the representation of any of the vendors mentioned in the blog below. If I have misquoted a technological aspect or misrepresented any vendor, please let me know and I will either remove it or modify it. All information provided here is as per my understanding and are not statements or facts from the vendor, for accurate support statements please consult your respective vendor.

I have been told multiple times before I submitted my VCDX Design  and also during VCDX Boot camps that using pre-built Converged Infrastructure or Hyper Converged Infrastructure might be harder to defend. This becomes a constraint in my mind but definitely not something thats a show stopper.

To truly architect a solution, one has to  know how to architect a solution not just with one technology, but be able to swap the technology or product on the go and still achieve the same outcome. This is especially true in case of a VCDX Design submission, as you will be asked for alternatives, around technology/hardware stack that you have used. If you don’t know the alternatives are for your solution, you better read up.

I defended my VCDX design that was based on VCE vBlock, so I speak with experience when it comes to this point. It was hard, but I am not sure it would have been different if it were any other hardware provider. At the end of the day it was only one of the constraints, my solution design met all the requirements of the client and that’s what matters the most. I am sure the same requirements would’ve been met if it was HP, IBM, Hitachi, NetApp or any other solution out there.

This post is not meant to deter people who are working on their VCDX designs based on vBlock or Nutanix or FlexPod or Simplivity or any other vendor. If you don’t know the reasons why your company chose a particular vendor, either speak to the decision maker or read up on proposals put together by the vendor.

You also need to know the pros and cons and possible substitutes for each solution, doesn’t matter what platform it is on. Every platform has its own challenges, from the business aspect to the technological aspect. One of the clients where I worked previously was so much against HP and EMC, they never even entertained RFQ’s from them. The same can be said about all the other vendors.

Lets get back to the point. 🙂 .

Here are a few points which will help you in  defending your design based on CI or HCI:

  • Know the pros and cons of each aspect of the solution. Even if you haven’t had the final word on any aspect, know why a particular decision has been made. If you don’t agree with it, raise it and get more clarification.
  • Know the alternatives provided by other vendors for the same solution. This will definitely help you broaden your decision making abilities.
  • Know the limits of what the CI or HCI can do and can’t do ( what is supported and whats not supported).
  • A Solution Design should be repeatable and reusable infinitely (within reason). So get the scale up or scale out or up and out decision firm.
  • Make changes, the whole premise about having a CI or HCI is a template to start off with. So make the necessary changes (within reason) wherever required.
  • Know the operational aspects of the technology you are designing, an architects job is not finished after design. If it can’t be implemented successfully, it’s a failed design. (Similar to when a house crumples down, its not just the builder who messed up, it’s the architect too).
  • Test all the facets of the solution and document where the outcomes were not as expected. Re-engineer and re-test until you get the desired outcome.

I think its true that defending a ‘real world’ design with Converged Infrastructure might be harder. Here are the reasons why:


  • There are a lot of moving parts in the new age Infrastructure. You will have to design all the components individually and together. So each aspect has to adhere to the availability requirements and together with other components of the design as well.
  • You are limited to the hardware options provided by that (Hyper) Converged Infrastructure provider. You are also limited by what each vendors self-imposed limits are. For example, VMware say that you can have 10,000 VMs powered on concurrently, the vendor having tested the theoretical maximum might cut it down to lets say 8000 VMs per vCenter.
  • You can’t really swap lets say a VNX 5600 to VMAX in a lower model vBlock or from 2 SSD 4 HDD node to all SSD on the same node on Nutanix (This was more recently announced so it ‘may’ be possible).
  • Scaling out or up or up and out is easy with both CI and HCI but becomes very expensive very fast if there is no control. Adding more hardware is never the solution for application related problems.
  • If you didn’t do your capacity planning properly, going back to the project board for more money after the procurement is done is usually not something a project manager wants to do, regardless of what technology you use.
  • In addition to this, there are multiple facets of the design that have already been decided, like the Recoverability aspect for example.  Nutanix (I think) recommend using Veeam, whereas VCE use EMC RecoverPoint/Avamar/DataDomain products. You might not be aware of operational processes of either if you have been using Netbackup or TSM. So one should know what facets of the design are being influenced by using these products.
  • When something like a vBlock or Flexpod or Nutanix or Simplivity has already been purchased, the business requirements that were given to the sales / pre-sales team don’t necessarily make sense from a technology point of view for a solution design. So the architect always has to go back to the Sales/Pre-Sales guy for confirmation on requirements as opposed to going directly to the customer. This sometimes can be a good thing, but mostly is not.

The advantage of using the prebuilt (hyper) converged infrastructure is that you architect the complete solution before the infrastructure is on the DC floor and everything comes in pre-built, pre-configured and pre-tested. So you are good to go in a few hours and start putting your workloads on the shiny new toy.

There are a lot of things that one needs to consider when architecting a virtualisation or cloud platform. To truly architect a solution, you should be able to achieve not just what’s in the VCDX Blueprint (although the blueprint gets you 70% there) but also ensure that the customer understands the nuances of using the technology day in day out. If the support staff is not trained in the particular technology, they will have to trained properly. User Experience is paramount when it comes to Virtualisation or Cloud Solutions, if it’s too hard you are doing it wrong.

I know this is going to get some very heated debates about platforms and which one has the better technology, but its not a post about whos better, these are my observations on  defending a VCDX design when you are not the absolute decision maker on every single facet of the solution.


Leave a comment

Your email address will not be published. Required fields are marked *


Check Out koodzo.com!