vDesign factors – From your Lab to the Enterprise

vDesign factors – From your Lab to the Enterprise


No matter the scope of your project, the same universal vDesign factors hold true from the lab to the enterprise.



Throughout my career to date I’ve had the pleasure of working on a wide variety of Virtualization projects, paying my dues from support, build, implementation and up to design and architecture. Looking back I found that it doesn’t really matter how many IOPs, users or Terabits of bandwidth your infrastructure is required to support, the fundamental facets of every single vDesign are set in stone.

I’ve attempted to classify these as simply as possible, but the truth is that there are so many factors that relate to so many other factors.  With all those butterflies flapping their wings through the Rainforest of your design, it makes more sense to map these relationships out to make sure one butterfly flapping it’s wings in one area doesn’t flatten another part of your design with a tsunami of unforeseen consequences.

Now this is far from a definitive list but instead should serve as a guide, a checklist of sorts to refer to as a reminder.  Not all projects or designs will have requirements around all of these points, but as an exercise to go through each of the main points is a good practice.

So let us attempt to see the unforeseen, to consider the consequences of design decisions and map out the thought processes that turn conceptual fag-packet theory into a green-lighted full-spec Visio bastard of a design.

Essentially then, this is what we’re dealing with:

  • Scale
  • Performance
  • Availability
  • Manageability
  • Security
  • Recoverability
  • Cost
  • Accessibility

Here’s what it looks like:

vDesign Factors

Excited?  You bet you are!  Let’s flesh this out a little.

Every platform should be designed to scale, whether it’s projected to grow or not- there’s just no real reason not to in my mind.  I’m a huge proponent of the ‘building block’ approach, aspects of the environment should be essentially interchangeable to a point and when it comes to scale, you simply ‘plug-in’ another block.
You will need to consider which approach- Scale Up (Pack less tin with more resources) or Scale Out (Add more tin with less resource each) suits your project best but in either case you need tangible, measurable and reportable metrics from which you can derive your thresholds that will trigger the scaling of your environment.  Obviously the procurement process will also play a part here to make sure you give yourself or the business enough notice of scale to allow the actual procurement of tin/cloud capacity.

Your platform could essentially live or die by it’s performance so you need to make sure that whatever your vDesign solution is trying to achieve, it is fit for purpose.  So key to this is obviously the workloads you intend to run on your environment, you need to make sure you consider the average and burst for all major resources- namely CPU, RAM, IOPs and network bandwidth.  You will also need to understand the business cycles for all workloads, whether there are periods in the month/year that are more ‘resource-intensive’ than the usual BAU.
You may also have to consider the expected level of performance by the workloads running on the platform, performance-based SLAs may be in place so you need to make sure you can meet the expectations and also be able to show this through the monitoring and reporting of metrics.

Your vDesign will of course need to consider the availability of the workloads it is designed to run.  There are many ways you can ensure availability to the required SLAs- and it’s ALL about the required SLAs here when it comes to factoring availability into the design.
Briefly put, there is availability at the application, VM, Host, and component levels at least to be considered.  Is HA enough or do you need to design for FT?  Are the workloads themselves highly-available and resilient, or is it a tiered application which needs different levels of protection at each tier?  Have you eliminated any Single Points of Failure or do any need to be flagged as risks?  Do you have multiple phases of power and do the cable diagrams detail the cabling to take advantage?  What are the Disaster Recovery and Business Continuity plans and how can you accommodate these in the design?
There are far more questions than these that will need to be asked to ascertain the requirements, from there you can design how best to cater for them.

How will the platform be managed and maintained?   There’s no real excuse not to make it easy for the environment to be patched and updated at all levels, and if you’re relying on getting any sort of buy-in for your vDesign then the ongoing operational day-to-day administration and maintenance is more important than some may credit it.  The stakeholders will want to know they can keep the platform up and running long after the project is wrapped up.
Part of the manageability is also how the platform will be monitored and how any alerts will be configured, which also feeds into the SLAs dictated by the business or stakeholders- this is also key and should not be overlooked.

More prevalent in some projects and therefore vDesigns than others, the level at which you need to consider the security will depend largely on the purpose of the environment you’re designing.  But then that’s obvious right?  Be sure you know what needs to be protected, both in the infrastructure itself and the data that will reside on it and what the threats are.  Knowing your attack surface can help you know where the threats are likely to come from and how to negate as much risk as possible by design.  This can also be process-based as much as it is design and configuration, so don’t forget to build the operational processes around the environment, if the project requirements dictate it.  Securing your environment is all just about changing default passwords and popping a firewall in, sadly.

Recoverability is not only about disaster recovery or recovering from a failure, you also need to consider how you cater for any SLAs around data restore and also defined retention periods.  When thinking about recovery you should think about it in terms of recovering the service, not necessarily about the individual VMs or datasets.  Any RPO or RTO will be defined in terms of how quickly you can get the service backup and running and to what point that service is restored- what happens to get that service back online is up to you and how you design the platform.  Whatever the method of recovery, all processes must be documented- and tested.

Budget will always be a factor in any project, it should be one of the first things you need to ascertain before you really get into the meat of any vDesign.  To no small degree budget will dictate many of the operational qualities of the solution you will be expected to deisgn- The more Highly Available, the lower the RTO and RPO the more it’s going to cost so the budget and the requirements need to be in line.
The cost is not only initial outlay, although it’s likely that the CapEx will form a decent part of the budget.  Ongoing costs such as software licenses and support, as well as the operational costs of running any equipment whether it’s on premises or in a datacenter (power and cooling costs need to be factored in) or in a Cloud service.  Often, the business may prefer to lump more budget into the OpEx as opposed to the CapEx outlay so how will this inform your design?

Last but certainly not least- especially with today’s propensity for putting services in the cloud you will need to make sure that your connections are up to scratch.  Are you designing a stretched cluster?  You’ll need to make sure your latency is low enough to cater.  Backing up data to the Cloud?  You’ll need sufficient bandwidth to cope with the load.  Is Remote Access a key part of your environment?  Probably wise to scope for a standby method of access then, diverse and eliminating any SPOF.  Bandwidth, protocols, bursts- and also things like DDOS protection may need to form part of your vDesign so make sure you ask the right questions.


So there it is, a whistle-stop tour briefly in a nutshell of the universal facets of virtual design.
Whether your design does indeed need to factor all these in will depend on the project, but asking the questions at least will make sure there are no surprises when it comes to trying to get sign-off or even implementation.  Part of the job will be to advise the business, client or stakeholders on what needs to be considered so they can decide whether it’s important to them or not.  It’s all about defining the requirements, assumptions constraints and risks- but maybe that’s a separate post entirely.


As always I hope this has been helpful.



Related posts