This is part 3 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.
3. The catalog system is more than a document, it’s also used to manage the life-cycle of the resource
What’s great about VM’s is how fast and easy they are to provision, but sometimes they are hard to kill.
I see the emails going around that say: “no one is touched that instance, who owns it?”
Back when resources were scarce, our hunter gatherer customers in Application Development and QA learned to never let go of a server. Like woolly mammoth’s they were hard to catch and came only sporadically; in the summer of ROI funding, or when great migrations came. Most of the time, QA was starved for resources. So they hoarded.
And while executing the initial request for a server environment through the service catalog gives you a nicely documentation and speed, over time changes happen and configurations drift.
This process of managing a server or environment from “as offered,” to “as agreed,” to “as built,” and then managing the change requests against it, is what I mean by lifecycle management.
The service catalog, being the source of “as offered,” “as requested” and “as built,” contains the whole lifecycle for your VM, plus information on who owns it, for how long they need it, and any other relevant data that went into the build sheet.
Unlike a static spreadsheet, when looking at a server, you can see what the maintenance hours, SLA’s and OLA’s are. The lifecycle system an tell you what types of requests can be made against that VM (like add memory, for example).That server can be started, stopped, snapshotted, upgraded. Notice they are all verbs against a thing, the VM instance.
The result is we have complete business context information about the server, the history of requests about it, subscription information and of course the proper technical build sheet, including workload requirements. As one VMware admin recently said, “I wish I’d known that you can only work on that server on Saturdays after 5pm.”
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.
It’s time for EMC fans to gather from across the globe for this great event: EMC World in Las Vegas started today!
It’s also an opportunity to learn about Cisco’s cloud management solutions, designed to deliver end-to-end unified management and an intelligent approach to IT automation — complementing intelligent infrastructure such as UCS, Nexus, EMC storage, and the Vblock platform.
You may have heard that we recently introduced the new Cisco Intelligent Automation for Cloud Starter Edition. Here’s a brief overview and demo featured on TechWise TV:
Cloud is one of the big topics at Interop in Las Vegas, and we’re hitting the show floor with an exciting new cloud management solution! If you haven’t already heard, we recently announced the new starter editionof our Cisco Intelligent Automation for Cloud software.
If your IT department is planning to take the first steps to implement a private cloud – then this is the solution for you. The starter edition offers orchestration and automation software to enable self-service provisioning for both physical and virtual infrastructure, designed for rapid deployment on Cisco UCS and targeted at simple infrastructure-as-a-service use cases. It’s also configurable and upgradeable to help you on your journey to more advanced use cases in a private or hybrid cloud, including support for a heterogeneous IT environment.
The Cisco Intelligent Automation team will be on hand at Interop this week to talk to you about building private clouds with our software: