Cisco Blogs


Cisco Blog > Data Center and Cloud

Part 5: A service catalog will help Vmware admins get ready for cloud computing, public or private.

Part 5 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.

5. A service catalog will help VMware admins get ready for cloud computing, public or private.

When I first came up with the concept of a service catalog to drive fulfillment process back in 1999 (Yep. 10 years ago. Time flies when you are having fun.) it was obvious that internal shared services like IT needed to emulate the likes of Amazon.

Well, here we are in 2009 and the wheel of time has brought us back to the same place.  Now it’s the data center that is being disrupted rather than end user services.   Customers are beginning to ask:  Why can’t you be more like Amazon EC2? Why can’t you provision fast, at guaranteed cost?

Let’s look at how Amazon EC2 uses the concept of a service catalog and lifecycle management to deliver cloud computing in consumer-like experience.

There’s a lot of talk about the technical aspects of cloud computing, and little the customer side:  Amazon communicates with its customers through a service catalog and lifecycle system.  The brochure part of the catalog is found here.  (I wrote this in more detail in my post: Amazon has written your technical services catalog).

To see the full functionality of this service catalog in action, I broke it down into Structure, Benefits, Pricing and Actionable for simplicity.

Structure

The whole structure looks like this:

It covers what it does, what benefits (hightlights), details, major options and pricing! Then what I call the fine print (aka SLA’s).

Benefits

It doesn’t skimp on benefits.  In fact, benefits and outcomes are front and center. We can do the same with with our virtualization offerings.

They tout their unique differentiators are variable (elastic) cost, while re-assuring that you have complete control, flexibility and of course, it’s inexpensive. In fact, if you read that section, it draws a comparison against an internal data center!  And it gets to heart of what customers don’t like about IT costs; highly fixed, over-bought, hard to plan for, etc.

It also covers the OS, database software and middleware choices. This is an example of going beyond the server.

What are your benefits? What are your unique differentiators?

Pricing

Next, the catalog outlines the main packages: Standard and High CPU.  Two choices, and then some three sub-choicess.

There’s a lot more description, links to explanation, FAQs, etc.  It’s the way they standardize these formerly complicated configurations that is a useful take away.

Pricing follows and there three aspects to highlight.  First, it’s completely and easily understandable as a unit of measure. They use per hour.

Standard Instances Linux/UNIX Windows
Small (Default) $0.10 per hour $0.125 per hour
Large $0.40 per hour $0.50 per hour
Extra Large $0.80 per hour $1.00 per hour

Think of all the complexity of running a datacenter: people, machines and facilities, etc. Amazon gets it down to controllable unit of of measure, hours. As a customer, I can choose to consume and hour or not.  That’s a level of control that’s appealing to me.  Is this the right unit of measure for every customer? No. It will depends on your customer and the benefit they want to buy. (More in future postings).

Second, they include all the pricing units for network, storage and servers.  Your complete datacenter (almost) configuration.

Third, some charges like data transfer charges are harder to map to controllable costs, so Amazon provides a pricing calculator to help translate these costs into the potential bill. And they provide sample configurations and estimates.

Except for chargeback, which you are doing or not, every leson is directly applicable to how we present virtual environments.

How does the catalog play a role? In two ways, it establishes the standards which enable self-service and then uses those to meter and report to your account what your consumed.

Actionable!

Finally, this catalog is NOT STATIC. It’s completely actionable.   If you have an account and log in, Amazon provides:

  • Self-service ordering, configuration and deployment. This request management against known, vetted standards is core to making cloud computing work. Think if Amazon had to go back and forth for weeks with a user about their configurations?
  • Account management functions. The customer can perform a variety of actions on their own to manage the lifecycle of virtual instance.
  • Consumption management and billing.  The customer gets clear, hourly consumption metrics.

In other words, Amazon delivers a very complete service catalog tool set to enable cloud computing. I like that they have brought the ease of their regular catalog to a more complex environment. And ease wins.

Amazon has redefined the expectations and pricing for data center services. Make no mistake, they are your competitors. Now the challenge is to respond with your own service catalog and differentiated service definitions.

So if your plans are to provide private cloud computing to your users, or at least behave as one, you need to consider a service catalog very early on to help you establish standards, service levels, and provisioning processes.

This time, we ought to know one thing: No Catalog, No Cloud.

Tags: , , , , ,

Part 4: 10 Things Vmware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management

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

  1. Network
  2. Storage
  3. Security
  4. Middleware
  5. Data
  6. Applications

Sometimes we can create complete application stacks such as: “Small Linux / JBoss / Oracle for standard development.” Other times, these items required hand-offs between teams.

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.

Tags: , , , , ,

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:

  1. Discover what’s available me
  2. Guide me based on my high level needs,
  3. Help me compare models, then
  4. 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.

 

Tags: , , , , , , ,

Part 3: 10 Things Vmware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management

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

 

Tags: , , , , ,

Can it be Self Service without Automation?

Leading IT shops like to have a single pane of glass that is the IT storefront to all employees.  This is a very noble goal.  Having worked at a few large companies this is indeed a moving target as supporting the end user employee can mean a lot of different entry points, contexts and presentation technologies.  When it comes to have a central location for ordering services it is very important to on board all of the employee based and data center services in a consistent fashion.   Some of the key use cases include employee on boarding (and off boarding), virtual desktops, virtual machines and physical servers in the datacenter and access to applications.  Typical IT departments may have several hundred orderable services, many of which are bundled (think of employee on boarding).

Interestingly some organizations first drive towards a common catalog and then automate what they can afterwards.  At first you can take orders through the service catalog and then work the tasks to fulfill the request through manual process tracking.  Alternatively I have seen some shops say that they will only put services in the catalog that can be automated.  Then there are all the intermediate cases.  Organizations deploying automated request management have many issues to consider and standards to be set.

Can we declare victory when a process is mostly manual but yet orderable from a catalog in four clicks?  Perhaps…

Your end users are happy.  They can see where their request is in the process flow.  Kind of like going to fedex.com and seeing where that DVD is on its journey to your house.   But that package took 3 days to traverse its journey.

Considered an automated fulfillment or provisioning process.  In my above analogy, you are no longer dealing with DVDs shipping to your house but on demand video streaming.  A simple click sets into motion many automated processes that deliver the movie to your device.  For end user services this means your remote access is provisioned with a simple click, your Linux server and application stack is delivered in less than 15 minutes for use.  Key to making that happen is a full automated process.  Is that achievable in all cases?  Perhaps….

In most cases what we are provisioning requires a northbound API (an programming interface above the fulfillment system) to accomplish the instantiation of the service.  Oftentimes, in legacy environments the target system is so dated or under invested-in that an API does not exist.   It is pretty hard to automate a process that can only occur through a human interfacing with the system.

People ask me the question:  So What? We have found that by automating processes we can save on average 30% of the process cost.   Multiply that by tens of thousands of requests and it will really add up.

Investing in Self Service requires investing in automation and in some cases, wrapping an API around a legacy environment in order to get the desire result:  IT as a Service, delivered at the speeds needed by  our end users.

Tags: , , ,