Home » VCDX » VCDX-CMA or VCDX-DCV. What are the cool kids doing these days ?

VCDX-CMA or VCDX-DCV. What are the cool kids doing these days ?


I have been seriously thinking and prepping for #VCDX-Cloud. It couldn’t have been more different to think about CMA than when I was starting with prep for VCDX-DCV.

Having said that, came across an interesting discussion on Twitter yesterday where a few guys I know and a few I know on Twitter (you all know who you are) were discussing which VCDX stream should one be focusing on right now.

Let me clarify that last sentence, since a lot of the current VCDXs are DCV with a few CMA / EUC / NSX doubles, somehow DCV might be considered not as tough as CMA. Well that’s what I got from the conversation anyway, I was wrong in where the discussion was heading (Thanks @grantorchard for pointing it out).

But nonetheless got me thinking about how one should decide whether VCDX-CMA is the way to go or is VCDX-DCV still a good stepping stone.  Looking at the blueprints of both the VCDX Streams, its hard to point out the difference in what is required. Yes I mean CMA has to have a cloud component for VCDX whereas DCV has to be vSphere. Everyone knows that. Lets hear it from someone who has done VCDX-CMA recently, here is Will Huber (@huberw) talking about what is different on his VCDX-CMA submission as opposed to the VCDX-DCV one, yet how the blueprint is still very vSphere centric.

But can we make a DCV submission a CMA submission just by whacking the cloud component on top ? I don’t think so. You can defend a cloud design for DCV but don’t think it’d fly if you ‘include’ cloud components into a DCV design and try to defend it (if you get invited that is). In my opinion VCDX submission is all about the focus of the Architecture Document and meeting the business/technical requirements with the proposed design. A virtualisation design requirements will definitely be wayyy different to the requirements for a cloud design. Mainly because the focus of the project is completely different.

For a cloud design (in addition to the usual vSphere design), one needs to consider the following:

  • How is the cloud aspect going to affect network and security of the design?
  • How is the cloud aspect going to affect how RBAC is designed and managed ?
  • How do we ensure that the automation aspect of it is secure and more importantly adheres to the business requirements?
  • How do we do the capacity forecast ? Based on resource consumption or based on business requirements?
  • How are RTO / RPO going to be affected (Cloud is meant to be always on remember)
  • What about backups? How do we ensure Backup is provisioned seamlessly to the user?
  • What about provisioning operations? Who has what rights on the VM?
  • How do we define the processes which aid the lifecycle of service strategy, design, transition, operation and improvements
  • How do we manage upper layer presentations of the service catalog and the accountability and chargeback of cloud resources ?
  • How do we build an extensible orchestration design where in other components can be plugged in?
  • What about the ITIL/ITSM processes for the environment ?
  • What about the end user training and enablement to use the new environment?
  • What other criteria needs to be considered when looking at PaaS or SaaS or XaaS ?
  • How do we report on usage ?

See where I am going with this. With a DCV design, its all about the VMs, how we enable the management of VMs and performance of VMs without affecting other VMs. For a cloud design, its all about the users and the ‘apps’ that they use. It still about the VMs for the administrator but not for the end user. The EU couldn’t care less if his ‘application’ was running in cloud or on a ‘PC Server’ in the DC, he wants it to perform.  My take is you can’t have a VCDX-CMA design without a very robust VCDX-DCV backbone.

I have always maintained that at the end of the day VCDX is just a “vendor cert”, it doesn’t give you knowledge or make you more intelligent. What the VCDX journey taught me is to focus on what the solution is going to achieve, not what the solution is. I still work in the same way, speak to people the same way, but yeah I think differently when asked a question.

VCDX is only about validation of your VMware <insert stream>knowledge. It doesn’t make you an architect or make you a better one if you are already an architect. I know plenty of enterprise architects who aren’t VCDX certified and they are still very good. Knowledge should be the pursuit of whatever certs you go for. The moment you put a tag (with make, model and price) on knowledge it becomes useless.

Adios !

PS: The last statement also applies to another twitter comment, where one thought that his VMware Certs are ‘not as useful anymore’ in pursuing NPX. Guess what, #NPX is also ‘just another vendor cert’. It validates that you have knowledge in designing and administering very complex Nutanix / HCI environments (albeit on multiple hypervisors). Period. Nothing else. Either of these certs (VCDX or NPX) still wouldn’t warrant being used or even be a requirement as an architect if one is looking at using IBM Cloud, HP Helion , AWS, OpenStack or Google ComputeEngine. Knowledge about any of these + NPX + VCDX would give you a definite advantage in deciding “what meets your business requirements best “..

Leave a comment

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


Check Out koodzo.com!