Customers only hear what is useful to them. There, I’ve said it out loud and now I’ll just wait for my lapidation to begin. Or perhaps you will bear with me while I try to explain?
As I wrote in previous blog posts we deliver a lot of our systems virtualized. You could call our VM implementation level a big hit, but we keep running in to the same problem, and it’s something that comes close to selective hearing. We have dozens of presentations, slides and info sessions that explain the benefits of a virtual server. And there are several benefits. Things like vMotion or the Site Recovery Manager can help you achieve a certain service level and add value by automating failovers or minimizing downtime due to planned maintenance.
The problem is the translation that is made by the customer. In our case the various internal teams are our customer, and the amount of knowledge around the operating system or the features that a virtualized landscape offers them are not always fully comprehended. You can tell a customer what these features do and how virtualization adds redundancy to the hardware stack. Usually all that arrives is “Less downtime because I can vMotion the virtual machine to a different piece of hardware.”, and the customer will automatically link this to a higher availability of the application that is running on this host.
The problem is this higher availability will not cascade through the entire stack. Sure, a vMotion might save you from a downtime due to hardware maintenance, but it won’t save you from the proverbial blue screen or kernel panic due to a defunct driver. You can write down everything in an SLA, but the thing that stuck in the customers head was the thing that he deduced from the presentation.
Fellow Blogger Storagebod already wrote a piece on “Asking the right questions“, and I fully agree with him that we as a service provider need to start asking the right questions to our customers. We have no other way to find out and offer the service he wants.
But, we also need to find out if the customer is certain that he understands the services we are offering. It’s not about leaning back in your chair and saying “we only offered a 99.5% uptime, it was there black on white”. It’s about going the extra mile and making it clear that “We offer an infrastructure that can give you 99.999% uptime, but your application isn’t laid out for that same uptime”. It’s about asking the right questions, but it’s also making sure that your customer heard the entire message, not just the parts he wanted to hear.
Virtualization is a tool or a way you can help your customer obtain higher uptimes. It can enable, but won’t guarantee availability of the entire stack.
1 thought on “Virtualization and the challenge of knowing what your customer understands”
You’re so right. Try explaining fault tolerance to someone not familiar with it. They always try to understand it in terms of clustering and failover, which is recovery technology, not downtime prevention. Failover is always an application availability threat, be it in a physical or a virtual environment. Fault tolerant hardware provides another layer of availability protection because there is no failover to standby servers. That is all managed within the server itself. In the interest of full disclosure, we make fault tolerant servers. If you want to read about VMware and an FT server working together, this may interest you: http://www.stratus.com/news/2010/documents/20100202.pdf