Service Catalog Community and Blog

Reading: Data Center Automation: Why It's Time To Move - Hardware - Data centers - Informationweek

This quote is an accurate representation of the benefits people implementing cloud self-service and automation get.

Faster response time to service requests is the top process automation impact, cited by 25% of tech pros surveyed who have fully deployed process automation tools. Others cited reduced errors and shifting staff to new activities--which means freeing IT to focus on higher-value projects. Cash savings, though, can be elusive: Just 11% cut staff, and 5% cite cost reduction as a key impact of process automation.

via www.informationweek.com

As you can read, the focus is not on cost-cutting, rather agility. Most of the case is not for staff reduction, but rather to deploy that staff on the long, long list of initiatives awaiting resources.

Time to be BRUTAL & RIGOROUS: How to Ruin a Cloud Implementation. Step 1 -- Leave Self-Service for Last

Self-service should not be an after-thought in cloud projects, it's the beginning of the journey.  Self-service drives the standardization of offerings and reduces the labor costs that arise from designing, specifying, ordering, procuring, and configuring computing, storage and network resources on custom basis. 

This standardization and automation also applies to application components, security and network services such as LDAP, DNS, load balancers, etc.  I say "drives" because the moment an organization decides to provide infrastructure on demand, three questions arise that are at the heart of the beginning of the cloud journey:   

1. Who are my customers? 
2. What are my offerings? 
3. What are my existing delivery processes?

Like any other business, the question of who are we serving, what do they want to buy, and how do we deliver,  leads to many other questions. These questions are at the beginning of journey to the cloud operating model.

But, haven't we answered these questions before when we built our ITSM catalog? 

Answer: NOT with rigor required by a self-service and automation program.

Once we decide to offer a cloud service, these questions need to be answered with a BRUTAL and RIGOROUS specificity to be codified into self-service choices.  Usually, until the decision to   deliver cloud services, these "customer" catalogs are often vague, warmed-over recapitulation of some well-intentioned static "service-catalog."  

In my experience, very little of that prior work is usable when confronted with the needs of the cloud project. I'm loathe to say it's useless; sometimes the project team that did the prior catalog is actually in the best position to understand the short comings of the prior work and can be a good contributor to the cloud project.

Getting back on point, once the decision to offer infrastructure as a service to the user community, At this point, the cloud teams faces three tasks:

FIrst, define the customer as a consumer of a set of offerings that address some activity the customer needs to carry out. For example, "test a patch to the scheduling system."  The team needs to figure out the proper metaphors, abstractions, rules for configuration, rules for consumption, and the choices allowed the customer. And this needs to be in the language and domain of competence of the customer.

This is hard for us technical people. We like lots of choices, we understand a lot of things our users won't.  The exercise of understanding the customer requires a lot of trial and error.

Sometimes I see some "cloud interfaces" that are really admin consoles to configure compute, network and storage resources. The UI's are targeted at unicorn users (they don't exist)  -- because developers, the real target of cloud-- are usually not network experts, or other than disk space, they don't know much about storage. Thus this is a unicorn customer--she doesn't exist!

Second, the cloud team now needs to break down the end to end service delivery processes into it's component processes, specifying all the hand-offs and activities, the tools and systems used, and the data required to both execute activities and make decisions.

This is where standardized offerings become the difference between success and abject failure as they simplify decisions and data gathering.

If every car is a Model-T, then manufacturing, supply chain, capacity management, procurement, planning are all much easier.  if you have a large variety of options, it's much harder.  Start small. Amazon web services first compute offering was small linux. That's it. "sm1.linus" (the original name) is the Model T of the cloud era.

Third, a good gap analyis and coverage plan is needed.   What we tend to find at this stage of cloud design is a gospel of gaps: rules in people's heads, governance rules that get in the way (hello CAB!), existing systems built for responding in days and weeks rather than minutes and seconds.  

Also there are missing systems. Sources of record are unstructured (like a word document or wiki's) rather than a database or a structured data model.  The few tools that make it lack API's, were built for a single tenant, do not enforce role-base-access control, or were not designed for consumer use.

Good process design needs to inventory these system and data gaps.

For example, take the task "Assign IP" address. Today, Jason the network admin gets an e-mail, and he opens his spreadsheet and sends it to someone who then assigns it to the virtual machine. Now, we need to enable the user to assign an IP address on self-service basis. So no Jason, no spreadsheet, no manual steps. But we do need to say Yes to a IP Addreses Manager, portlet, lifecycle manager, consumption and reclaim process. 

This one example.  If you don't have simple standards upfront, the number of rules and interactions reaches a complexity where it just doesn't work and it's a maintenance nightmare.

Sounds daunting, doesn't it? Well it is, if the cloud team doesn't do the proper gap analysis upfront. When they do, it's just a project like any other.

 

Reading: "How to best fight the rise of rogue IT services? Compete"

YUP. That's all.

There seems no way to stop it. And it’s no secret, yet it’s one of the more pressing issues IT departments face today. Workers are sidestepping their IT department altogether to find and procure the services they need, whether that be quick access to online storage, collaboration tools, a SaaS application, or a number of servers spun up within a public cloud.

This creates obvious security and regulatory compliance risks. But there are other risks and potential costs associated with users going “rogue” with their IT deployments. First, they risk not getting the type of service or depth and quality of services they expect. The services they choose may not be the best available for the objectives. And, with business units acquiring services one-off large companies lose much of their ability to negotiate optimal pricing and service Levels.

One can hardly blame workers for sidestepping IT departments at times. It can take weeks to get servers provisioned, new storage, access to collaboration tools, or other services. If the same, or better service is available in the cloud, requiring little more than a credit card and a username for instant access: why wait for IT?

via www.cloudcommons.com

The Value of Automation: What Did Captain Kirk Know That Scotty Didn't? & The Roach Motel Infrastructure Issue

Recently, a customer asked me what was the value of using automation to operate a private cloud?  It was a good question. Working  in the middle of the reality distorition field of the cloud industry I take it for granted that everyone knows automation's benefits.

Fundamentally, automation tools help to reduce labor costs, rationalize  consumption and increase utilization.

Costs are lower because the labor required to configure and deploy is eliminate. This automation is possible by creating standard infrastructure offerings. Standard infrastructure offering make possible a new operational model: to move from the artesanal approach of delivering infrastructure ,where every system and configuration is uniqe, to the industrialized approach, that ensures repeatability, quality and agility.  It's the difference between custom tailoring and standardized sizes at The Gap. Both have their place, but one costs more.

The Gap has a self-service catalog.The British bespoke tailor doesn't.  Self-service should not be an after-thought, it's the beginning of the cloud journey.  Self-service drives the standardization of offerings and reduces the labor costs that arise from designing, specifying, ordering, procuring, and configuring computing, storage and network resources on custom basis. 

This standardization and automation is also applied to the application components, security and network services such as LDAP, DNS, load balancers, etc.

Standardization also provides second order benefits through reduction  in the maintenance, procurement and support costs. After all, if the cloud has one management interface, and all compute blades are the same then the whole break/fix cycle gets simplified and procurement is streamlined. 

Automation is all about saving labor. First, the customer saves provisioning labor costs, additional savings are incurred  by reducing errors which means less time fighting fires (labor), and finally, on-going operations (day 2), like applying patch also result in  labor reduction.

The interesting metrics here are the number servers per administration and the number of errors before and after automation is deployed.. As you know, every incident/fire causes a hailstorm of work for a bunch of people.  Imagine if automation detected the error, and fixed it before it became a problem? Well that's what Cisco Intelligent Automation does for compute, network and even SAP.

Utlization: What did Captain Kirk know that Scotty didn't?

The third source of cost reduction, increasing utilization, is probably the biggest opportunity for cloud.  

Yet it is the hardest for IT professionals to achieve because it requires applying a combination of psychology, market dynamics and technology. 

Two big costs in the datacenter are the over-provisioning of capacity and the hoarding of infrastructure by application teams. Introducing service-tiers with different capabilities, costs and delivery options underpinned by automation can be very effective in changing user behavior.

Over provisioning happens because without the ability to quickly and automatically provision services, it’s safer for both IT and the user to deploy the requested capacity. The result is that a lot of VM’s sit there idly at 3% and the operations staff can’t intelligently manage consumption because they don’t have the original request specification and service tier committed. 

As to what did Captain Kirk know that Scotty didn't?  He knew how to balance engine utilization and the mission. Sometimes, Scotty, she can take Warp 10.

In fact, a lot of upfront friction in the design, estimating, specifying happens because the infrastructure teams are trying to ascertain (guess) the real needs of the application, i.e. the mission, so they don't over or under provision.  

Meanwhile, the application teams don't want to get caught short because a) they'll get yelled at by the customer if the app is a great success, and b) it takes so long to deploy additional capacity that to be wrong is exactly like an outage.

That's how workloads becomes gold plated. Every one's happy, but the CFO.   The CFO then makes the CIO suffer, and that's how IT and the business get out of alignment. Automation is the infrastructure chiropractor; it helps bring back IT operations and the customer back in alignment.

Self-service and automation start to change this situation. It starts with Introducing a few service offering with standardized service tiers, backed by self-service and automation changes the dynamic of the conversation.

A bronze level service for QA and  development, available in a few minutes, with minimum support might be better than a whole production stack that takes 8 weeks. (It is: that's why people go to Amazon!). 

Over the last ten years, newScale, now part of Cisco,  worked with hundreds of customers and we learned psychology and market forces can be used to shape demand.  Getting something NOW, and cheaper turns out to be a better choice for many users over "perfect later." Introducing quotas and leases, makes the customer a more engaged partner in managing capacity. Putting coss and prices, even in the absence of chargeback decreases demand. Why? Because human beings are wired that way.

And the technology has changed. Converged infrastructure like Cisco Unified Computing platform or VCE's vBlock or NetApp's FlexPod offering when paired with automation and the service catalog keeps the mission and the service level "unified" from the customer view to the operations view down to the actual hardware. This is new and it's getting wide adoption by infrastructure groups.  The ability to

Hoarding: The roach motel of infrastructure management

Hoarding has similar dynamics. When it’s difficult and burdensome to obtain infrastructure resources, when  the process takes months, there’s a tendency to want to keep the resources forever as the customer knows they might those servers them again.So like the proverbial roach motel, resources go out to customers, but never come back.

Automation changes this dynamic: once the customers see they can get resources get provisioned in minutes, the psychology changes. A user now starts to think: "why spend time renewing a lease for an app I'm not using if I know I can get it back in minutes next time I need it? Plus my boss will get the bill and she is going to ask me if I'm still working on that old project?"  

Show them the money!

The final costs savings come from introducing metering and charging. It changes customer behavior and reduces over provisioning to begin with. With dedicated virtual or physical infrastructure, the business paid for it upfront though capital expenditures, the equipment was used and now it sits there idle wasting power, space, licenses and labor. 

And from the point of view of the users Infrastructure is "free" so why do anything about? Plus what could be done? Nothing.  In a capital expenditure model driven by business unit P&L, there really wasn't that much IT people could do.

Subscriptions up-end this model.  A cloud subscription becomes an on-going operational expense that goes on forever unless it's turned off. This changes the psychology and behavior of the organizations.

To get a sense of the emotions unleased by showing the money, please click here.

(On a personal note, this forever subscription would cause my colleagues and I sometimes to go on hunting expeditions on the Amazon cloud, looking for machines to terminate.  Someday, I'l make a game out of it.)

To end, over provisioning and hoarding are holding hostage a large chunk of a datacenter’s resources. When the user has confidence they can get infrastructure on demand they tend to hoard less, and when leases, quotas and lifecycle visibility is available more infrastructure is freed up.

The Cisco Cloud Portal shows the user exactly what they are consuming, shows the boss what the team is consuming and it shows up in the P/L, the behavior changes. Quickly.

 

Need to Explain Benefit and Cost Reduction of Cloud to Your Boss? 2 Slides You Can't Live Without

Sorry for the Cosmo-like title. Found an issue of Cosmopolitan on my plane back chair and my brain still processing the ridiculous titles. But the story is real.

Our team was at Oracle World, and they presented this deck.

If you are looking for a simple, compelling explanation of the value of a private cloud, Slide 11 is the one that makes the most sense to people. And if you need to explain the cost savings slide 12 is super compelling.

And now, here's a "Private Cloud Sure to Drive Him Wild."

Infrastructure Management in a Cloud Environment

View more presentations from Cisco Data Center

The Cloud Psychiatrist is In. Be a Cheese Mover, not a Cheese Chaser

I spend a fair amount of time presenting our cloud vision and technology to our customers. In thes conversations, we often end up talking about transformation and the people and process angle of this transformation.  Sometimes I feel my role is that of a Cloud Pyschiatrist, and not a technologist.

Often he conversations turns towards managing the fear of change, the anger that other people don't get it, the exasperation with customers that demand impossible service levels, don't pay and yet are not smart to know they need help.

And the myriad of policy changes needed: Is a patch a change and does it need to go to the CAB? (yes,no). Why is that user running his CPU at 100%? Is that other user even looking at box, because it's running at 3%? Will we run out of capacity if provide self-service?

What about security? What about security? Is it insecure?

And so goes another day at the Cloud Psychiatrist's office. Change is hard. That cheese ain't going to move itself. So a healthy dialog about change is required. And that's something, we can help with.

And as I was thinking this, this piece, by my friend Bernard Golden, on overcoming cloud anxiety is published on CIO.com. 

And remember, anxiety about change is normal. Be a cheese mover, not a cheese chaser. Because that cheese ain't gonna move itself

 

After seeing a number of these promising beginnings turn into stalled launches, my friend concluded that some kind of organizational anxiety was preventing them from taking concrete steps. He believes a "defogging" service designed to help IT organizations clearly understand their options would help them move forward with confidence.

His experience mirrors my firm's. At speaking engagements, I interact with people who are intellectually convinced that aggressively moving toward cloud computing is necessary, but seem hesitant and even confused about what to do

 

 

Great Article on Innovation Starvation by Neil Stephenson

One of my favorite authors writing on Innovation Starvation... I love this quote, because I've seen it happen.

Most people who work in corporations or academia have witnessed something like the following: A number of engineers are sitting together in a room, bouncing ideas off each other. Out of the discussion emerges a new concept that seems promising. Then some laptop-wielding person in the corner, having performed a quick Google search, announces that this “new” idea is, in fact, an old one—or at least vaguely similar—and has already been tried. Either it failed, or it succeeded. If it failed, then no manager who wants to keep his or her job will approve spending money trying to revive it. If it succeeded, then it’s patented and entry to the market is presumed to be unattainable, since the first people who thought of it will have “first-mover advantage” and will have created “barriers to entry.” The number of seemingly promising ideas that have been crushed in this way must number in the millions.

What I know about innovation is that it's pain the ass. Most of the time people are focusing on all the "issues" -- I want to ban the word issue for next 100 years -- the problems, the obstacles, the risks.

People think they are being "realistic" but they are simply being limited.  It turns out that not everyone can hold two contradictory beliefs at the same time and explore the consequences of each. Like anything, it's a skill that requires practice.

Frankly, innovation requires optimism and an ability to do away with reality for a bit. Not to focus on how hard the road up the mountain is, but imagine what would happen if you crossed the mountains.

via www.worldpolicy.org

The New Bronze Age. Make an SLA Too High and It Prevents Innovation, Too Low and It Prevents Operation

Where I grew up, you could buy individual cigarettes. While I played ball at the park, I'd see the young men approach the paper kiosk to get a cigarette. Not a pack, just one lonely stick. The customers overpaid on per-cigarette basis but it helped them manage their budget.  I'd watch them and think nothing of it. It was normal.

People also could buy shampoo in ketchup-sized packages. Unilever still sells them in India. I grew up in the third world, it was the bronze age, but only only on good days. 

We're back to bronze with cloud computing, and I'm hyper ready.

For me, the biggest invention cloud computing brings about is unreliable level services. And how important it is to have low quality service levels available on a metered basis. A metered basis the customer can manage. 

Today, Amazon's block storage is unpredictable for databases. The latency in the network is funky. Machines fail to start. Machines don't fail to fail. Service levels in the cloud don't exist.

This is not your typical datacenter. It's a bronze age datacenter. No great expectations, but diminished expectations.  And for a young segment of the market, it's just right and couldn't be be better.

I sat down with a young start up and asked them why do they use cloud computing if it's so unreliable, if it requires so much more coding.

Answer: They have more time than money. And the money they have, they have to be parsimonious, avaricious and cautious on how they spend it. They are ok coding more to deal with the cloud's weirdness. But running out of cash would kil them. The bronze age suits them just fine.

So all the cool kids in Silicon Valley are super excited about writing software for "Designed-to-Fail' infrastructure. We can't wait for a chaos monkey to spank us. Well...  that's a San Francisco thing.

So what's the lesson of this meditation? It's that service levels are important. Too high and they prevent innovation, too low and they prevent operation.

Here's how somebody is going through the process of figuring it out. They were kind enough to write about their thinking, so be sure to say thank you. Here it is:

If you think about combining these primitives in customer-friendly ways, you'll probably recognize that it's often the case that most file shares don't require real-time remote replication and failover.  It's also usually the case that transactionally-intensive applications can't get by with only a daily backup.

The goal is to combine performance and protection attributes into something mere mortals can understand.  You might end up with something that looks like this:

• File Share Class 1 - base offering for generic file storage 
  (low bandwidth, moderate latency, "business support" availability)
• File Share Class 2 - if you need something special 
  (moderate bandwidth, moderate latency, "business critical" availability)
• Decision Support Class 1 -- best for running departmental reports
  (moderate bandwidth, moderate latency, "business support" availability)
• Decision Support Class 2 -- bigger data marts and small warehouses
  (high bandwidth, moderate latency, "business critical" availability)
• Transaction Support Class 1 -- logging requests or events
  (moderate bandwidth, moderate latency, "business critical" availability)
• Transaction Support Class 2  -- the bigger OLTP apps
  (high bandwidth, low latency, "mission critical" availability).

Ideally, you could move a data set between, say, Class 1 and Class 2 (or back!) non-disruptively.  Broadcasting your ability to do so would help keep people from over specifying up-front, or having a place to put that oh-so-important project when it ain't so important anymore.

via chucksblog.emc.com