Yesterday I and a number of other VCDX holders and Panelists were having a discussion with a hopeful candidate about the implications of submitting a design for VCDX that included core foundational components that were proposed to leverage beta software. The short version of the outcome of this discussion is that it’s not a good strategy for success. It has a extremely low likelihood of success in fact. Ask anyone who’s gone through the VCDX process, it’s hard enough to defend designs made entirely of production ready GA component software that has been thoroughly tested by the various vendors and been around for a while. For those of you that are curious why this is the case if it is not self evident, it’s clearly spelt out in the VCDX blueprint and many other information sources. To save you having to look up the specific page here is the key point.
For a design to have a chance of success in the VCDX program the design must be driven by business requirements and implementation decisions must be suited for mission critical applications in a managed environment. This is the key point. Suited to run mission critical applications in a managed environment. It is hard to argue and justify that running beta software code as part of a core foundational component that every other component is dependent upon is suitable for mission critical managed environments. Even if the beta code was used in a minor component it would require very strong justification and mitigation of risks. Remember when you submit a VCDX design package you are not just submitting an architecture design, you are submitting a complete end to end project. Architecture Design, Test/Verification Plan, Implementation Plan, Standard Operating Procedures etc. As Mark Brunstad, Program Manager for VCDX Certification at VMware said during the discussion “Beta code supporting mission critical apps in a prod environment = big risk, big unmitigated risks make it hard to pass review.” Why would you want to make the process harder on yourself than it already is?
If you really want to defend a design using foundational software components that are currently in beta then I would recommend you wait to submit until after those components go full GA into production. Even then you’d may have to justify being an early adopter of the software and mitigate any risks it might pose to the mission critical applications that it will support and the business that will rely upon them. My very strong advice as a VCDX and as a panelist is that you don’t over-engineer your designs, don’t make them any more complicated than they need to be, don’t make them any more risky (or costly) than they need to be, and make sure all designs are traceable back to a bonafide business requirement and that any risk areas are thoroughly documented and mitigated.
I wish all candidates great success with the upcoming VCDX applications submission deadlines and the defences for those of you who make it past the review stage. Do arrange mock defences, do stick to the defence timings during mock defences, do review your design thoroughly, do buy and read the VCDX Bootcamp book, do attend a VCDX bootcamp and review the online recordings and the presentation deck. Don’t reach out to panelists for a design review, we can’t review your design, we are only able to discuss already public published information that is already well known, generic, and already part of the VCDX Bootcamp. We can’t give specific advice. Your best chances of success will come if you follow the preceding advice, attend a VCDX bootcamp before your defence to leverage the combined experience of a number of VCDX during these invaluable events, and use all the other available sources of good VCDX preparation material.
Final Word
There will always be trade offs, and every aspect of a design, requirements, constraints, assumptions and risks can have an impact on other components of a design. You need to know this for your design, and for the alternatives like the back of your hand. Don’t make it any harder than it must be.
This article is also published in the VMware VCDX Community here.
—
This post appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.
I would largely agree to your analysis, however when it comes to Business Critical apps, it's not that application or the underlying platform alone but the Business Process that defines the number of apps involved to complete a full business transaction end-to-end. The technical design does pose a challenge then, especially in the area where specific technologies or s/w may either have limitations in terms of resources or functionality or both. I've been in many projects and seen multiple times where beta software has been used with complete success. Many a times, beta or open source software is never studied properly enough. There needs to be a clear test plan in place with almost all possible error checks and handling. At the same time, one needs to have a very clear SDLC and corrective measures in place along with rapid deployment to test plans to ensure that any updates to the Beta s/w is carried out with as little jolt and shock to the production environment (ideally none). Last but not the least, if the beta s/w does not come with a clear release plan and a roadmap on version releases, then the risk goes up, hence we need to take a call between what the s/w can achieve with higher risk vs. what a manual workaround with some validation might receive with relatively lower risk. Happens in large SAP and other deployment projects all the time. In the context of VCDX defense however, it might not be such a good idea. In real world though, it does work.
You've described some of the additional thought, documentation and mitigations that need to go into a solution that includes some beta components. I absolutely agree with you re the business process, BCP and DR are core components of the application package too. It all comes down to benefit vs risk and impact and the trade offs that need to be made to meet the customers business requirements. But answer me this. Would you put a multi-billion dollar financial system into production when all the underlying foundational code that would support that system was running unproven beta code that nobody else in the world was running in production? Especially if the impact could be the financial institution running it would go out of business if there were a severe failure? It's not impossible, but the lengths you'd have to go to in order to validate / test / verify the entire solution works, how it behaves when things go wrong, how to recover, and all other aspects, implementation plans, standard operating procedures, and very detailed and thorough risk mitigations, it makes it very impractical to justify and defend. With a few strokes of a pen (ahem, keyboard) you could make your job a lot easier and your chances of success that much higher.
Well, I wouldn't put a Beta technology on the absolute base of the solution itself. What I am referring to is components in general. Certain beta s/w components in any large project, with the above considerations, is pretty normal. But something like beta version of some virtualization engine or storage technology which is not even a 1.0 product and/or unproven in the mission critical apps space is something I'd clearly steer away from. Will the business of the customer collapse if they get a report a few mins later on an existing proven storage technology or database as compared to a beta version which can potentially serve it a lot faster, with higher risks? Answer is No. That's a business decision based on the various perspectives you've highlighted. Having said that, it's not unusual for some customer to become the first guinea pig…oops….revolutionary cutting edge technology adopter to run with it first. What we both have highlighted then becomes an absolute must. I'd like to see someone challenge this notion in the context of a VCDX defense. It'd certainly make some panelists uncomfortable in their seats and make them draw out the red pen from their pockets for scoring on this, but it'll certainly be interesting to see someone cover this from an objective perspective and a damn good reason to include it in the first place. (E.g. would be my SAP design :))