Part 1: 10 Things Vmware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management
This part 1 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 few weeks–I hope! (The boy is nothing if not ambitious).
1. The service catalog is a tool for driving users to standard configurations.
To get the operational efficiencies we hope to achieve from virtualization and / or cloud computing, we need to establish standard configurations. This is tough, for a couple of reasons.
First, the challenge is the gap between the language of the customer, and the detail needed by the operations group typically generates a lot of back and forth during the “server engineering” process. Instead of having “pre-packaged” configurations, every thing is bespoke.
Instead of having useful abstraction layers and levels, the customer has to invent their own little bit of the data center. This made sense when the new app meant a whole new hardware stack to which the app would be fused to and the concrete poured on it. It doesn’t make sense now.
Second, there’s resistance from customers to adopt standard VM builds. Sometimes the reasons are valid, other times less so. The issue arises because the technical configurations have not been abstracted to a level the user can understand what they get and what’s available for configuration. Nor can they compare one template to another in ways that are meaningful to them.
The service catalog is the tool to help deal with these two obstacles. The service catalog is a useful tool to communicate, in the language of the customer, the different options available from IT for hosting environments.
A service catalog will support multiple views (customer, technical, financial, etc) so that when the customer selects “small Linux” for testing, this generates both a bill of materials and standard configuration options. Once that base is selected, self-service configuration wizards provide both guidance and gutter-rails so the customer is both helped to the right thing and prevented from making errors.
From this customer configuration, the environment build sheet is generated which will drive provisioning and configuration activities or to execute any policy automation in place.
And the catalog allows the VM admins to figure out what their “market” is buying; which is very useful for capacity planning.