Part 4! 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.

4. There’s a lot more to setting up environments than provisioning servers, the service catalog provides access to all the other required services.

It’s great that you can quickly get a server instance going. Awesome, really. But that’s not an application hosting service. It’s important to understand the “whole product” requested. Is it a raw computing power w/ an OS? or is it an application stack? Or particular integration points, network, storage and security?

There’s a need to really think from a whole product perspective. What ancillary services need to go be coordinated to deliver an environment. Typically we’ll need to consider

In talking with VM admins, sometimes there’s a bit of the “not my problem” mentality — it’s those other jerks who are slow. But if the think about our job as delivering environments that can work in a data center or in the cloud and as we virtualized the network and storage, there’s more and more need for having a catalog of individual server request as well as complete environment

The service catalog contains all the other services that the customer needs in to deploy their application.

Another Cisco Live is just around the corner! Are you going to be in San Diego? I can’t think of a better backdrop for what will be a packed week full of learning opportunities and the chance to network with peers from across the globe. IT pro’s will converge on the San Diego Convention Center and take in rich, interactive, and educational content in areas ranging from Video, to Networking , Security, Mobility, Collaboration and Data Center. Read More »

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.

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.”

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.