The VCDX path has changed how I see technology design. I just wanted to share my experience, specifically for those who are considering the going after the VCDX.
It’s About The Journey
First let me say this, it’s not my saying. It’s about the journey, not the destination. What does that mean?
- It means you must be committed to bettering yourself at all costs
- It means that this will likely take you hundreds of hours, most of which personal
- It means it will cost you financially for lab gear, travel, application and defense fees
- It means there is a high probability that you will need to defend the VCDX more than once
- It means your family MUST buy into this, or VCDX will become Voldemort (that which must not be named) in your household
- Getting the certification does not make you more qualified, smarter, etc. It means you already are qualified and others agree.
I was successful on the first attempt, but I was fully prepared to have bad news after even several attempts. Don’t let it get you down. Listen to the feedback.
It will change the way you see everything. I was (am) a pretty good delivery consultant at virtualization. Delivery consultant actually means I get my hands dirty and go on virtualization engagements to do the upgrades, maintenance, greenfield installs, rack and stack, fight and identify firmware and driver bugs, do P2V projects, performance troubleshooting, etc. Before the VCDX, I had a good idea of the process for building clusters that would function for the target workloads with enough servers for redundancy. But before the VCDX, I looked at it much differently, all I saw was vSphere. The beauty of abstraction is that it’s not really about servers, your hardware vendor, networks and storage. Sure, these are critical components, but in the end it’s really all about business requirements in terms of availability, manageability, performance, recoverability and security. Much like Neo when he was enlightened, so was I as a part of the VCDX preparation process. You must see it all.
What do you get out of the process?
- If you do things right and form a study group, you will definitely make some new acquaintances, maybe even friends. I know I did. : )
- YOU WILL LEARN MORE THAN YOU EVER IMAGINED.
- As a VCDX, you are responsible for all decisions in your design, and you have to document them. You will learn about them for sure.
- You understand why you chose particular components and configurations, and how they met the business requirements.
- Mock defenses will show you your weaknesses from a technology and verbal defense standpoint.
- Embrace these weaknesses, your peers are HELPING you by pointing out flaws and weaknesses.
- Industry Recognition on a peer vetted certification
- A unique number
- Listed in the VCDX Catalog
What are my recommendations?
- Get buy-in from your family, especially if you have kids. Explain the costs and time involved. The VCDX is a team sport on the home front.
- Understand up front that an expert will have dealt with a variety of hardware, storage and network products. It’s just the way it is.
- Don’t do a fictitious design; it will be much much harder. This is about business requirements.
- Read the blueprint. Then read it again. Re-read it later. Then again later. Print it out and put it under your pillow. Only half serious.
- Form a study group and start meeting before and after you submit. Plan on meeting together the week before the defense.
- In person mock defenses are WAY more valuable than over Webex.
- If you do a Webex, make sure to use a whiteboard and video camera. Will definitely help add simulated pressure.
- Get someone that doesn’t know technology to proof read your submission. They will find all sorts of goofs you’ve completely overlooked.
- Write some kick butt documentation. Let’s be honest, this is kind of like a thesis, it should be the best thing you’ve ever written.
- Your design doesn’t have to be 100% sweet-ness factor awesome with latest greatest state of the art gear. It needs to meet the requirements.
- As it gets closer to defense time, think about all the different ways you could have done your design, know why you didn’t go the alternative routes.
- Greybox test/Fuzz your design. Look at it objectively and find the holes. Ask reasonable questions, then make quizlet flashcards about each question.
- Go read Rene Van Den Bedem’s series on the VCDX. Awesome blog series that needs no duplication.
- When preparing for the Design and Troubleshooting scenarios, you absolutely MUST understand the big picture.
To sum it all up in two words: DO IT.