A lot of people want to submit and defend for their VCDX, but they never get around to putting their design together because they just don’t know where to begin – especially people who are starting from scratch with a wholly fictitious design. I suffered from this myself, and wrung my hands for a long time before I just picked something and started typing… once the ice was broken, the typing continued nonstop for quite some time… In the end, I produced ~500 pages – so the content was there in my head, I just had to get it out. The intent of this article is to help people staring at a blank word doc break that ice.
The design I created back in 2013 for my VCDX-DCV was fictional in the sense that this particular scenario never occurred in reality – it was basically how I would have redone things when I worked at Demand Media had I been given a free hand to rebuild their virtual environment. That said, many of the sections in it were based upon real life things I had implemented for customers. Storage setup taken from customer A, Network taken from customer B, Security from customer C, that sort of thing.
Partly this was because I was laboring under the misapprehension that a VCDX design needed to be the ultimate design that cost millions and proved to everyone that I knew how to work on big stuff. To do this, I used the coolest bits and pieces from various projects as well as some stuff I had pitched but got shot down on due to budget constraints. As it turns out, this only served to make things much harder on myself. I had to bend and contort these building blocks to make them fit together. I had to remember a LOT of facts to keep my fictional world straight.
Ultimately, I was successful on my first defense attempt at what was essentially a fictional design, so it’s not impossible. Let me tell you, though, my entire life for months was about preparing for that 3 hours. Not everyone has a work or family situation that can support this, and that’s why the pass rate for fictional designs is so low.
In retrospect, I should have done things differently. It would have been one thing to take an actual design I had done in real life and beefed up the one or two weak sections and called that a partially fictional design. It’s a lot easier to remember reality under questioning than to cohesively maintain a web of lies to sustain a fictional world. I managed to do it – but in the end, the stress was not worth it.
I get that there are people out there who have no choice but to do a fictional design because they simply haven’t worked as architects – and IMO there’s no reason they shouldn’t attempt a defense. Being an architect first certainly makes things easier, but don’t buy into the notion that you should give up. I’ve known several VCDXes who were only able to become architects AFTER they had the VCDX credential. That said, if you’re doing a fictional design, I would highly recommend the following approach to get started:
1. DO NOT start from the bottom up. By this I mean, do not start sketching out clusters and SANs, and resource pools, and after you have something sufficiently cool looking concoct Requirements, Constraints, and Assumptions to fit what you already built.
2. DO start from the top down – meaning you begin with a list of Requirements, Constraints, Assumptions, workload patterns, SLAs, growth projections, etc and build to that.
3. DO have SOMEONE ELSE (ideally a disinterested third party) give you some requirements and constraints, then don’t fudge them later. Build to them as if the customer is being a jerk and won’t budge. Even better if they conflict with each other. Document an imaginary meeting where you decide which will win out and type up the rationale.
4. DO create a spreadsheet of every VM that will exist at the start – list out values for CPU utilization, RAM utilization, IOPS, Primary Block Size, disk transfer bw, disk % util, category of apps running on it, anything about it that you might want to know. Use formulas in Excel to seed it with semi-random values if needed. Now you have your fictional workload pattern. Freeze it in stone, name it REALITY and build to it. Make all calculations from this spreadsheet. Any time you have to come back and cover something you forgot, there is an objective reality you can use to inform decisions.
5. DO NOT limit your design approach to what seems realistic or “normal” based on industry standard practices, or how the customers you’ve dealt with in the past have insisted things be done. Remember, the point of being a VCDX is you’re the person who can CREATE best practices when presented with a challenging problem. For instance, you might come up with a unique approach involving doubling up on network hardware to meet some crazy SLA that goes against industry norms. As long as you have a solid rationale and can defend it.
6. DO lab up your design to the best of your ability. For VMware employees, this is easily done using nested ESXi hosts inside of OneCloud. Non VMware employees could do it inside a vCloud Air OnDemand account, or build it in your homelab. I know it may be hard to simulate performance stuff due to limited resources, but at least make sure to functional testing of as many failure modes as you can, to validate what you THINK is going to happen in a given scenario, actually happens. This work can also form the basis of your testing plan. No matter how well you know a technology like, for instance, LBT – you can’t be sure how its going to react in a unique combination of circumstances unless you’ve personally witnessed it.
7. DO create a table of design decisions and at least a quick sentence about why you went the way you did. Keep in mind every setting represents a decision, even the ones you leave at the default.
8. DO take that table (which should be long, like a hundred+ items) go on Quizlet or otherwise make flash cards and study them until you can repeat an optimally formed sentence about that decision by rote. You do not want to have to do any thinking in the defense.
9. DO as many mock defenses as you can BEFORE you submit the design. You don’t want to find yourself in a situation (like I did) where you’re hoping some inconsistency that a mock defense ferreted out after you already submitted doesn’t get noticed by the panel. Don’t limit yourself to VCDX holders to conduct your mocks (though they usually are helpful if they have the time). For instance, I had some guys in my office who were junior SEs – people who at most had their VCPs – read my design and grill me on it. Due to their varied backgrounds, several of them came at things from angles I hadn’t considered. In fact, they may have been better at this than VCDXes because they didn’t already have a lot of the baggage.
10. DO NOT use Constraints to try and buy your way out of having to know something you’re weak on. If you constrain your way out of having to make any network decisions (for example, by saying something like “all networking is owned by the NE team and we can’t change any of it”), or think you’re clever by using vSphere 5.0 to avoid SSO considerations, or declaring that the customer had no SLAs of any kind – you aren’t giving the panel much to go on to evaluate your skill in that department.
A good article.
I also successfully defended a fictitious design, although in my case, i had 3 goes at it.
I would agree with the approach you have outlined.
Had i have followed some of these items the 1st time, i may not have needed 3 defense appointments.
Shane.
Hello Sean,
I started creating my VCDX design already and still in progress. With your tips I believe I be able to achieve this one. Thanks for the heads up and more power to you!
Paul Vincent Fajardo
IT Systems Manager