Part 2: 10 Things Vmware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management
This is part 2 of the series “10 Things Vmware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management” that I’ll be publishing over the next couple of weeks.
Number 2. The service catalog is the place where your user can document (communicate) their request
Let me show you an example.
If you go to an e-commerce storefront and choose to look at Cisco UCS servers, they are broken down their servers into classes (Rack, Blade, etc), which then provides different models, which can then be customized within the parameters allowed for that model. I’m not saying this makes sense for your environment, but the break down between classes, models, and then self-service configuration is a useful construct for thinking about your templates.
What are your standard classes of environment you provide? Could it be production, development, QA? What about models? Could those be on-line transaction processing, extranet, intranet HR, basic web server, basic database?
We would want to ask entirely different set of questions and configuration options for an extranet, high transaction database than for a personal development environment, wouldn’t we?
It’d also make our job much simpler and faster if we know what parameters were involved for that particular request.
The service catalog is key to enable your customers to:
- Discover what’s available me
- Guide me based on my high level needs,
- Help me compare models, then
- Assist me in customizing my configuration.
And of course all the tracking, workflow and life-cycle management that the service catalog enables. This is what makes a service catalog different from a “web form front-end” to a help desk — automation is the big difference.