Cloud Front Office

Cisco: Service Catalog is Critical to Private Cloud Strategy

Last I attended a very interesting live webcast with John Manville, VP of IT networks and data center services for Cisco, on their implementation of a private cloud, CITIES--Cisco IT Elastic Infrastructure Services. (The webcast is not available but the slides are.)

There are two things I took away:

1. Cisco has similar challenges to other large IT shops.
2. The IT Front Office is central to their internal cloud deployment of CITIES

First, the picture below shows their internal adoption phases.

 The roadmap has several phases, starting with MIST and going all the way to CUMULUS, each phase taking 4-6 months. In that sense it's both aggressive and pragmatic. If you see the bottom phases, it's where self-service and service catalog show up as basic enabling infrastructure.

1. Self-service requests and request catalog is pretty central to their internal adoption of virtualization. This encompasses:
2. Basic requests for Virtual machines
3. Bare metal requests
4. Service level and access control requests
5. Full service catalog integrated with other operations.
6. Integration with orchestration.

In the blue boxes, the outcomes for each phase are listed. From these outcomes, requirements can be derived for this "front office" infrastructure. For example, the first phase includes automated provisioning of virtual machines (VMware). This means that the catalog will need to have both a marketing front end and a back end that connects to vCenter or another management platform.

Later on, the catalog will track consumption, subscription in order to report SLA and cost allocation. Every one of the bullet points in the blue boxes needs corresponding Front Office functionality.

During the webinar John was asked:  How important is a self-service catalog?  He said,  "It's critical to CITIES. We are moving to a service oriented framework. The service catalog is a major part of that."

I have now seen more than a few plans for data center virtualization, and all of them have some sort of catalog and self-service in them.  What I like about Cisco's is that they are pretty clear the catalog is as important as a hypervisor if you are to achieve the economic impact of private clouds.

Second, the slide below shows the business pressures and operational realities that result in the typical IT squeeze.

This is another way to view the typical pressures newScale IT customers face from the business.

The goal of CITIES is to deliver operational efficiency and flexibility at a lower cost than today. Their goal for virtualizaton is that as of August any x86 request will go virtual, and the all refreshes will go on UCS. So over the next 2-3 years they'll be 70-80% virtualized. This is very aggressive goal: most companies have about 15% of capacity delivery by virtual servers.

When asked what was exciting about creating this private cloud, they said, "I'm excited about not getting beat up for lacking capacity." I love this quote!

I don't think most people building virtual data centers get the depth of requirements and work building that Cloud Front Office yet.  It's not only a technical problem, but a business model change as well.

Cloud Computing: A System of Control?

Cool discussion going on. Bryan Doerr,  chief technology officer for Savvis. wrote:

By embedding more flexibility in service deployments, cloud services can increase control of IT costs in ways not previously available. I refer to this new control paradigm as “deployment control,” by which I mean the active management of IT capacity aligned with application value using the features of cloud services.
Cloud Computing: A System of Control.

Virtual servers profits not enough to buy coffee: First quarter worst in 12 years

Or could it be all that virtualization means fewer boxes?   It's certainly true in my QA labs.  It had to hit somewhere, no?

IDC: First quarter worst for servers in 12 years • The Register. The volume server market (machines that cost under $25,000) took the biggest hit in Q1 2009, with revenues falling 30.5 per cent. Midrange machines (which cost between $25,000 and $500,000) held up relatively well, with only 13.6 per cent revenue decline. High end systems, despite all the blathering about the benefits of running virtual and logical machines on big iron, nonetheless saw a 19.5 per cent revenue decline in the quarter.

Private cloud may be a better option for public agencies -- Government Computer News

Private cloud may be a better option for public agencies -- Government Computer News.

At present, Red Hat has more than 50 enterprise customers with private clouds. "They are seeing huge benefits [by] running clouds themselves," Whitehurst said. He mentioned that one customer he spoke with, a chief information officer of a large organization running 25,000 processors, told him that public-cloud services such as Amazon would not provide much of a cost advantage to his organization, as his company could obtain servers at almost the same cost as those providers.

To set up a private cloud, an agency would pool all of its servers and offer the processing power to each department. It could enjoy the economies of scale that clouds could provide, and not worry about the privacy and security concerns that dog public-cloud providers, according to Whitehurst. It could also sign agreements with other agencies or organizations whose peak processing times are different from its own in order to have extra computing capacity on hand for those periods with the heaviest workloads.

Cloud Front Office or No Catalog, No Cloud

Welcome to my new blog: CloudFrontOffice.  I'm still writing my service catalog blog. 
Cloud computing and virtualization represent a moment of opportunity and also of crisis for IT datacenters. 

The opportunity is big: to deliver to the business computing resources on a fully variable basis, scalable both up and down, orders of magnitudes more agile to business demand.

The  crisis is also large if IT doesn't embrace these new models. IT will get outsourced, or the cost structure will kills margins, or the lack of agility will allow competitors to run circles around the enterprise's cycle time.

I don't need to scare you, but we are living in times where great companies and brands disappear weekly. Which is I'm going to focus mostly on the opportunity in this blog. 

My fundamental thesis is that the private and public cloud revolution requires two organizational and technical structures to come together.  One is the IT Factory or BackOffice of IT, and the other is the IT E-Commerce Operations or FrontOffice of IT. 

The back office is where a lot of action is centered today. VMware, Citrix, Microsoft, Sun, EMC, NetApp, Novell, RedHat, and many others have delivered what is essentialy a new computing platform that is an evolution of Linux, Windows, and Unix.  This has grown fast due to its compelling cost and operational advantage. 

This evolution has happened on the back end.  Simultaneously, a revolution has emerged in the front end, called cloud computing.

The two aspects that I believe are revolutionary about cloud offering are the predictability of IT infrastructure costs and the variability of that cost structure.  Neither of these is true today for IT organizations. You may have predictability but not variability, and that predictability often comes at high costs. 

Why is this revolutionary?  Ask your CFO:  if our sales are down 20%, how important would it be to lower IT infrastructure 20% real-time. And be able to scale those up as soon as sales grow? I'd say he'd be pretty interested.

And how will this new IT communicate with its customers?  Through an actionable service catalog that specifies the standard configurations, allowed variations and unit costs.  This catalog will provide for  self-service configuration, subscription and account management, provisioning integration and billing / consumption reporting are critical elements of the Cloud FrontOffice.

This catalog belongs to a suite of capabilities that will include things like service lifecycle management, to help us understand our offers and what customers want; it will include strategic views, that allows us to understand coming demand, our own capacity to deliver, and to prioritize our resources based on business strategy. 

This is what I'm calling the Cloud Front Office.  Whether you are now deploying virtualization as first step towards building a private cloudd, or planning to use public clouds, the Cloud FrontOffice is critical.

No catalog. No cloud. Join me in this new exciting journey.

Using Cloud Computing to Build Your Technical Service Catalog

Cloud computing can be extremely useful to help build your technical service catalog.  I read this short but very illuminating blog post by Gary Orenstein, The Enterprise Impact of Cloud Computing that supports this viewpoint.

Cloud computing brings two major aspect of a service catalog to light: Price transparency and how our customers will interact with our Data Center services. 

A couple of quotes from Gary's post. 

Pricing Transparency — Prepare Your Pencils
Whether businesses jump into cloud computing right away or later on, the pricing transparency from cloud providers completely changes enterprise practices for benchmarking IT costs. Companies routinely spend big bucks to understand IT expenses and effectiveness.
...
Now you can understand exactly how much it costs to rent an x86 server, a terabyte of storage, or a content delivery service with just a few clicks to Amazon Web Services or a host of other providers.

Which is exactly what we hope to achieve with a service catalog, have the customer understand what they are getting and the unit costs they are incurring.

And as to how our customers will interact with IT from now on, Gary writes:

It used to be that deploying a new application meant days or weeks of research, approvals, budgeting, planning and setup. Now it means that individuals outside the enterprise IT domain can pick a service offering of their choice, select a plan, and pay for it themselves. The barriers to start are low, the benefits of scale are high, and the decision gets boiled down to the simplicity of a free trial or impulse purchase.

I agree except that it's not days or weeks, but rather months and quarters. 
How long does it take to get a server into production?  Most enterprises it's 3-4 months, many even more?  How long to configure? Months?  How easy is it for the customers to order, track, understand options, costs?  Very difficult.

This is why I say the IT service catalog is CENTRAL to the next generation data center whether it's virtual, a private cloud or a public cloud.

Without a catalog that defines standard environments, allowed configurations, easy ordering, some sort of provisioning and self-service, customers are going to go their own way, as I've written before on 16 digits to freedom and Amazon has written your technical services catalog.

What do you guys think?  Is it all new, all old, or is there a nuanced view between hype and cynicism?

Cloud computing can be extremely useful to help build your technical service catalog.  I read this short but very illuminating blog post by Gary Orenstein, The Enterprise Impact of Cloud Computing that supports this viewpoint.

Cloud computing brings two major aspect of a service catalog to light: Price transparency and how our customers will interact with our Data Center services. 

A couple of quotes from Gary's post. 

Pricing Transparency — Prepare Your Pencils
Whether businesses jump into cloud computing right away or later on, the pricing transparency from cloud providers completely changes enterprise practices for benchmarking IT costs. Companies routinely spend big bucks to understand IT expenses and effectiveness.
...
Now you can understand exactly how much it costs to rent an x86 server, a terabyte of storage, or a content delivery service with just a few clicks to Amazon Web Services or a host of other providers.

Which is exactly what we hope to achieve with a service catalog, have the customer understand what they are getting and the unit costs they are incurring.

And as to how our customers will interact with IT from now on, Gary writes:

It used to be that deploying a new application meant days or weeks of research, approvals, budgeting, planning and setup. Now it means that individuals outside the enterprise IT domain can pick a service offering of their choice, select a plan, and pay for it themselves. The barriers to start are low, the benefits of scale are high, and the decision gets boiled down to the simplicity of a free trial or impulse purchase.

I agree except that it's not days or weeks, but rather months and quarters. 
How long does it take to get a server into production?  Most enterprises it's 3-4 months, many even more?  How long to configure? Months?  How easy is it for the customers to order, track, understand options, costs?  Very difficult.

This is why I say the IT service catalog is CENTRAL to the next generation data center whether it's virtual, a private cloud or a public cloud.

Without a catalog that defines standard environments, allowed configurations, easy ordering, some sort of provisioning and self-service, customers are going to go their own way, as I've written before on 16 digits to freedom and Amazon has written your technical services catalog.

What do you guys think?  Is it all new, all old, or is there a nuanced view between hype and cynicism?

Building an internal cloud

Great write up from James Schwartz, CIO of Sybase about building the business end of a private cloud.  I think this quote is super important:

Turning Your Virtual Datacenter Environment into an Internal Cloud

Introducing processes and tools that are similar to those provided by external cloud vendors can turn your virtual datacenter environment into an internal cloud.

This is the part where self-service, service catalog, delivery automation, account management, billing, etc become really important. 

More...

By first developing tools to handle life cycle management of virtual machines, a user can request a virtual machine using a menu to specify resource requirements (CPUs, memory, storage), operating system details, lease period (no more than 12 months) and other miscellaneous configuration information. The request then goes through an IT approval process, that once approved, is assigned and the virtual machine is rapidly provisioned from templates. 

I love how that menu -- a service catalog plays a key role in establishing and communicating standard. In many ways, we need to think of both the server lifecyle and the SERVICE Life cycle together. Both need tools to manage them.

And some great benefits

A requisition process that used to take weeks is now completed in just days and urgent requests can be handled within hours. To further avoid server sprawl problems and to maximize resource utilization for legitimate purposes, it is recommended that the virtual machines either get a lease extension in three month increments or are retired when a lease period expires. 

See the rest here: Building an Internal Cloud.

I need a new logo for the community

Until then, enjoy the picture of clouds from my home. These are my private clouds

Why We are Here. My Manifesto.

Today, I'm announcing, CloudFrontOffice.com, a new blog and professional community for cloud and data center virtualization people dealing with the business and customer aspect of public and private clouds. Everyone is free to join.

 

Just like the consumer Web 2.0 gave rise to enterprise Office 2.0, I see virtualization and cloud computing giving rise to a new IT Front Office for the Cloud. I am calling this the Cloud FrontOffice, the place where business demand meets IT supply.

I want to explore and engage in conversations with a community a whole set of questions that cloud computing gives rise to:

 

From strategic questions, such as:

* What are the new IT operational models we should be thinking about?

* What are the key service management processes I need to revamp, revisit or re-engineer?

* How do I communicate to senior management the options available?

 

To tactical questions, such as:

* How do we charge and what do we charge if we are not providing computing power?

* What rationale do we use to choose when to leverage internal resources and external resources?

* What should our catalog, account management and billing strategy be?

* What's the best self-service strategy?

 

Amazon Cloud to DataCenters: Did You See What I Did To BookStores? You are Next.

I went for a walk on telegraph Avenue to pick up the new Arcade Fire DVD - very awesome - and had a real desire to check on my favorite bookstore, Cody's. But it's not there anymore.  Nor could I stop by my old haunt, Tower Records; also gone.  So while I wrote this a while ago in my other blog, but it really belongs here too.

July 2008.

I've been playing around with Amazon's Elastic Computing Cloud services for a bit now to assess its utility as software deployment environment. I found it's a game changer for data center and a great model for a service catalog. And it's likely to do to datacenters the same thing Amazon did to bookstores, Tower records, and other retailers. Put them out of business.

The two aspects that I believe are revolutionary about Amazon's cloud offering are the predictability of IT infrastructure costs and the variability of the cost structure.  Neither of these is true today for IT organizations. You may have predictability but not variability, and that predictability often comes at high costs.

Amazon has a different offer for their customers.  And how Amazon communicates with its customers?  Through a service catalog.  Let me give you  a tour of their offering. The whole page can be found here.  I broke this down into Structure, Benefits, Pricing and Actionable for simplicity.

Structure

The whole structure looks like this:

• Functionality
• Service Highlights (Benefits)
• Instance Types
• Operating Systems and Software

• Pricing
• Resources
• Detailed Description
• Intended Usage and Restrictions

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. Here are a few that I've highlighted.

Elastic – Amazon EC2 enables you to increase or decrease capacity within minutes, not hours or days. You can commission one, hundreds or even thousands of server instances simultaneously. Of course, because this is all controlled with web service APIs, your application can automatically scale itself up and down depending on its needs.

Completely Controlled – You have complete control of your instances. You have root access to each one, and you can interact with them as you would any machine. Instances can be rebooted remotely using web service APIs. You also have access to console output of your instances.

Flexible – You have the choice of multiple instance types, operating systems, and software packages. Amazon EC2 allows you to select a configuration of memory, CPU, and instance storage that is optimal for your choice of operating system and application. For example, your choice of operating systems includes numerous Linux distributions, Microsoft Windows Server and OpenSolaris.

Reliable – Amazon EC2 offers a highly reliable environment where replacement instances can be rapidly and predictably commissioned. The service runs within Amazon’s proven network infrastructure and datacenters.

Secure – Amazon EC2 provides web service interfaces to configure firewall settings that control network access to and between groups of instances.

Inexpensive – Amazon EC2 passes on to you the financial benefits of Amazon’s scale. You pay a very low rate for the compute capacity you actually consume. Compare this with the significant up-front expenditures traditionally required to purchase and maintain hardware, either in-house or hosted. This frees you from many of the complexities of capacity planning, transforms what are commonly large fixed costs into much smaller variable costs, and removes the need to over-buy “safety net” capacity to handle periodic traffic spikes.

It absolutely delivers their unique differentiator which 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 your 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. 

Pricing

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

• Small Instance (Default) 1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of instance storage, 32-bit platform
• Large Instance 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of instance storage, 64-bit platform
• Extra Large Instance 15 GB of memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform

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. 

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.
• Account management functions.
• Consumption management and billing.

In other words, your complete service catalog experience.  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.  There's a lot more I'll be writing about this.