Over the course of the last few weeks I’ve been reading Scott Lowe’s book on vSphere Design. While centered around vSphere 4.x, most if not all of the information still applies today. The concepts of breaking design down into Organizational, Operational, and Technical subsets that make up the overall design is still relevant and will be valid for years to come.
The overall planning, architecting, and implementation, are set around a broad set of facts which are functional requirements. It’s within those facts, however, where extreme granularity comes into play.
You first need to understand the business requirement in broad terms. What is it exactly they want/need to accomplish? What is the goal? What are the constraints? When that is determined, then the granularity comes into play at each of the subset levels and each one has its own set of questions and facts that need to be obtained.
Virtualization brings many more changes to an organization than just a change of technology. More importantly, when we move from the physical to virtual worlds, many things that were applied in the physical world fall by the wayside. By the sheer nature of the “pooled” architecture, many things change from management of resources, to troubleshooting, etc, and this is where most of the concerns will originate. IT shops and businesses are used to doing things a certain way and they come to realize a comfort level in what they know and do every day. I believe it’s addressing those concerns within the overall design that is most important. Working with your client/customer, and building a strong partnership to show that you are not there just to sell them some technology, but that you will guide them through the process in a clear and concise manner, making the transition as smooth as possible.
This comes to my first finding that I’m learning to accept as I go through this process, and that is provide a design that is simple and modular and can be supported with minimal risk.
Unfortunately, as we all know, sometimes this just can’t happen. The customer may have some pretty stringent requirements where the only option is a complicated solution so that you can meet their functional requirements. However, even in those cases, you still need to look at making some of these things easier by looking at reference or converged architecture where it makes sense.
In the coming weeks, I’m going to continue down this path of learning vSphere Design principles and concepts. I’ll break down some of the things I’ve learned and get into some specific areas such as Networking, Storage, Mgmt Infrastructure..etc.