What’s the difference between deploying a service versus installing a software technology?
A lot!
For example think about what you expect from companies that provide you with water, electricity, and telephone services (now you’re getting close).
What’s ITSM for Virtualization?
As an infrastructure manager, over the years I’ve had virtualization admins and engineers tell me how quickly they can install a new technology such as VMware View…
… and for the most part they were telling the truth.  Heck, even I can follow the instructions to set up VMware View.
But that’s not delivering a quality service, its installing software.
And the difference between service delivery and software installation is huge!
Here’s what I mean…
Using our example of VMware View, delivering a VDI service goes well beyond installing a couple of packages on a server and then deploying a few virtual desktops.
Moreover, it’s about assessing the scope and use cases that may require various tweaks and alterations for each business unit (or department).
It’s about matching the look and feel of the existing physical desktops so users are not confused.
And it’s about testing and validating the application stack to ensure all the applications will still work once they are running on a VDI instance verses physical hardware with dedicated memory, CPU, hard drive and a network adapter.
No! A service is much more than installing cool software.
Consider our VDI example again.
In a proper service delivery project, a network traffic and storage assessment would be performed to determine if switch ports and storage LUNs would be oversubscribed by desktop traffic from heaving hitting applications.
User traffic is not static and can quickly eat up IO and cause potential problems. This needs to be determined before (not after) to ensure service levels are maintained.
Also, security needs to be considered since desktop users are now operating behind the firewalls because virtual desktops are now sharing the same back-end space where servers are.
Hardware drivers and agents need to be removed from standard desktop images and antivirus scans and other services that could thrash storage or network IO need to be tested, remove, or rescheduled.
And maybe new processes for virtual desktop provisioning or support requests need to be created so virtualization admins are not held responsible for 1st and 2nd tier desktop support. (This step could be followed by training for help desk support staff on how to deploy and support VDI.)
Then there are software installation processes that need to be created because untested installs could result in performance issues that impact the entire environment hosting the View Desktops.
And if that’s not enough!
You need to ensure you have a capacity management plan in place for scaling the VDI service quickly once it’s outgrown the initial build out, which is sooner than most businesses plan for.
Do you understand the difference now? Let’s keep going.
ITSM for Virtualization Big Picture
It’s easy to run a setup.exe file and install a software technology, but deploying a service needs to be thought through so the customers and the support staff are properly supported with good and best practices, and reliable service levels.
In this example guide on IT Service Management for virtualization, I used a VDI service but the same is true for building out a vSphere service for server deployments used for App, Web and Database servers to ensure the SLA.
Why?
Because standing up a couple of ESXi 5.1 hosts is easy, and deploying vCenter is easy, too.
But how will you scale it, monitor it, and back it up?
Think beyond the basics…
A vSphere service manager thinks beyond the basics of the installation and looks at the long term service the customers of the vSphere will want but they didn’t asked for in the beginning…
ITSM is the bigger picture that needs to be considered to ensure long term health and performance of virtual servers and virtual desktops.
Conclusion:
Here are 5 important take-aways to consider for service managers:
- What are the use cases to build the service for? Don’t just build and try to make it fit the users.
- What are the service levels you want to achieve? SLA|OLA (set clear expectations early).
- What are (and how will you) monitor service levels? Health and Performance are key metrics.
- Will the design scale easily when more capacity is required? Build is unit of capacity rather than sprawl.
- Is the support staff trained and educated on supporting and maintaining the service? No cowboys allowed.
Don’t be fooled by sales people who pitch how easy it is to install something they want to sell you!
If you want a quality service, then it needs to be approached as a service and follow best practices for service delivery – not just following a how to install instruction guide.
