There are a several good points made my new blogging buddy, Miguel. Number one, you don’t include in your design features for the sake of features. This may seem obvious, but perhaps for a passionate (maybe overzealous!) VMware Architect, implementing features on which on-site staff are not proficient or can’t manage is not a benefit. As Miguel shares in this “palm-to-face” anecdote, such features in the hands of untrained staff can have the opposite effect for which they’re designed. So take into account the staff’s abilities before including advanced features in your design. Number two, communication is key in any environment. Communicating to the customer the gravity of the decisions they make in regards to what’s included in the design and certainly sharing planned maintenance times with all stakeholders. A communication strategy and change control process are key to making this work. Number three, as Miguel shared with me, if an admin is looking at his virtual infrastructure like a hog looks at a wristwatch, well, things are pretty bad. And finally, always remember: VMware’s easy.
I had a long-term project at a customer site where I was to analyze, design, and architect a solution based on the equipment, environment, and requirements. Before I rolled in to the customer site as the new VMware SME, there had been a recommendation by a junior and recent VCP to implement distributed switching, linked vCenters and a few other feature sets of VMware and NetApp. There was not any experience with distributed switching by the on-site staff and their exposure to VMware was minimal, although many thought themselves as experts after a few weeks with the product. I kept hearing the comment that VMware was easy. I recommended a hybrid solution with the MC using standard switching, and VM network\storage on distributed switching as a compromise to a fully distributed solution. They decided against this even after I presented them with the advantages.
A few weeks later they had…
View original post 378 more words