Cloud and Service Catalog Blog

Reading: "How Much is This Gonna Cost? Price Models for IT Infrastructure" - A Critique

My colleague Steve Watkins has written a good critique on pricing models.

 

Broadly speaking, there are two major approaches to creating a price model for IT.  There is the Utility-based model, in which pricing derived from actual consumption of CPU cycles, RAM, bandwidth, storage, etc.  In this model, if you stood up a virtual machine for one week you would only pay for the actual amount CPU cycles and storage you consumed.

Alternately, there is Service-based pricing, which advocates a fixed price based on either the service itself or some other unit of measure such as hours, etc.  In this model, if you stood up a virtual machine for one week you would pay for how many hours the VM was active, whether you used it or not.

I always council my customers to adopt service-based pricing.  I think utility-based pricing is the wrong approach for IT departments, especially infrastructure teams.  Here are my reasons:

via blogs.cisco.com

Cisco Intelligent Automation for Cloud - Openstack Support

In support of our Openstack Edition, Cisco Intelligent Automation for Cloud (IAC video) is introducing a community supported "Multi-Cloud Acceleration Kit" (MCAK) that extends IAC Starter Edition to enable provisioning of OpenStack clouds as well as vCloud, Amazon EC2 as well as vCenter and UCS blades.

IAC provides both a real service catalog and an orchestration tool that help OpenStack be adopted by the enterprise. IAC provides rich Role-Based Access Control,physical provisioning and adapters to a large variety of back IT systems including help desks, CMDB's, directories and many other systems.

For newScale customers, this means that you can use your service catalog to provide cloud services to a variety of clouds from the same familiar interface.

This SlideShare presentation gives you the highlights,

Cisco Cloud Management and OpenStack from Cisco Data Center

Some important details Support alternative virtual infrastructures in Starter Edition, including:

• VMware Virtual Center
• VMware vCloud Director
• OpenStack Nova Compute
• Amazon EC2

What we are providing:

• Create supporting orchestration abstractions to make it easy and transparent to extend to any cloud
• Use a common model, where possible, to represent cloud objects, properties and methods
• Provide extensions, where necessary, to accommodate VI-specific objects, properties and methods

To achieve this, we provide generic support for multiple virtual infrastructures only. MCAK dDoes not account for hypervisor-specific features (not that they are used in cloud environment. For example, OpenStack supports KVM, Xen or Hyper-V in generic way-- commands are reduced to the common denominator of instantiating instances, managing power state, managing configuration, image snapshots and removal. This table is useful to see the main concepts of CIAC Starter Edition and how they map to different clouds

Platform Type/Property	Vmware vCenter	vCloud Director	OpenStack	Amazon AWS (EC2)
Customer VDC	Full Path	Organization	N/A	N/A
Tenant VDC	Resource PoolDatastore	Organization VDC	Tenant	Account
VLAN Instance	vCenter Network	Org Network	Network ID	Network ID
VM Template	Full Path	VM Template HREF	Image ID	Image ID
Flavor (new)	Server Size Values	Server Size Values	Flavor ID	Flavor Name
User	vCenter User	user@system	Keystone User	Access Key
Password	vCenter Password	vCloud password	Keystone Password	Secret Key

So you can see that in order to support multiple clouds, it's important to find commonalities and account for differences when needed. You can see a full demo video of IAC Starter Edition   MCAK is available now for Cisco IAC Starter Edition 3.0 and 3.0.1. Support for 3.0.4 will be available at the end of the month in this community site.  

Workplace Services. A Brief Personal History of the Service Catalog and Its Evolution

This is a repost of something I wrote on my Cisco blog. I've added some personal comments.

When Cisco acquired netwScale (my company), in addition to our cloud portal, it also brought in the Cisco Workplace Portal (formerly RequestCenter).

There was a lot of curiosity as to what Cisco would do with an ITIL style service catalog and what the future of such product would be within Cisco.   Well, it's 18 months later and it is doing quite well, with an exciting roadmap and some new things already shipped and some in the wing.

In this post, I want to discuss what are workplace services, how they have evolved, how they are evolving and what it means to the service catalog.

Workplace services are those services that employees need in order to do their jobs. They include computers, phones, offices, new employee set up, terminations, access to applications and anything else you can imagine.  I have seen tens of thousands of service definitions both common and unusual.

Common ones are the desktop computer variety, but even these sometimes have an unusual bent. For example, banks have different workstations for tellers than admin staff.  Other have engineering workstations that are  different salespeople. Role definition becomes a pretty important aspect of a service catalog implementation.

Unusual ones were "Report chemical fire", "Order Executive Sedan", "Inter-factory mail", and "File patent idea". Patent as a service, if you will

If it was something that could be requested, it went in the catalog. Today some customers have 1,500+ service definitions in their catalogs with user bases in the 350,000 employees.

But over the years, the workplace has not stayed the same. There have been many changes in the emphasis and priority of service definitions customers prioritized or cared about. The why they decided to use a service catalog has changed through the years and continues to evolve.

A brief history of the service catalog

From 2001-2004, the customer focus  on why implement a service catalog was driven solely by cost reduction. Using self-service to eliminate calls to help desk (order, status, close, delays, problems, escalations generated many calls per service request). 

Personal note: I still remember convincing VC's that, YES, services could be put in a catalog. And everyone else that this is not a procurement.

So my team spent a lot of time doing ROI calculators in those days. There wasn't much integration required as few had automated processes and Cisco Workplace Portal has a powerful web based work manager that was better for process management than the the fat client help desks of the time. 

ITSM vendors took a long time to recognize the need for self-service because they kept talking to help desk managers rather than the consumer of the service itself. This is a pattern that we are also seeing with cloud services.

2004-3007. Sarbannes-Oxley (SOX) compliance became critical. The service catalog became a crucial component for documenting services, executing standard processes for account access and employee on-boarding and off-boarding a.k.a. hiring and firing. 

The burning issue was that many people had more levels of access to applications that regulations permitted, and accounts would remain active after they left their jobs. This created a potential risk for the company.

So two new uses cases arose: application access and the automated provisioning of identities from our service catalog, and the use of the catalog to control outsourced service delivery.

Personal note:  A couple of funny stories come up. One where the service catalog was used to order carpet cleaning for offices. They put a price of $200, but didn't actually bill anyone. Requests fell by 40%.

The first led to connecting the catalog to tools like IBM Tivoli identity manager and Sun's too. The latter sometime necessitated B2B interconnections between client and provider. 

This may not seem like a lot but there were hundreds of apps, very complicated rules on what roles could do what. It's a very complex problems. So the service catalog brought down the cost of provisioning and improved performance from days to seconds, while maintaining controls.

This tension between providing self-service and maintaining control is also a pattern with cloud services.

Personal note: Sometimes it feels like groundhog day. In cloud, this is even worse. Sigh.

Also, by 2006-2008, the focus had shifted to employee satisfaction with IT. ROI were not required. Most customers did enjoy cost savings; I remember one case where the legacy tool was costing $24,000 per service definition.  Also, a lot of people woke up ITIL and ITIL mandated the use of a service catalog to do Service Level Management.

Personal note: I spent a lot of time with ITSM professionals and leading courses. Fun times engaging one on one with practioners.

2007 - 2009 saw three things happen. The great recession, the birth of cloud computing and the maturation of ITIL change processes. The great recession changed IT operations in many ways: more desire to use SaaS, moving non-mission critical workloads to virtualized infrastructures. My favorite quotes from that time: "We are forklifting anything we can out of our datacenter", "we are consolidating down two datacenters from 30", and the winner "Those resources (Websphere admins) are gone and they are never coming back".

Also, by then change management processes and tools were in place  so integration with the ITSM stack became a must have requirement.  But also integration with virtualized infrastructures like Vmware vCenter or Citrix XenServer.

Personal note: Large ITSM vendors finally acknowledge the service catalog is not a feature, but a whole category. But then made it a feature by tying to a help desk. Oh oh. The cloud was about to kill that strategy.

And every customer had punch list of  integrations required: CMDB's, software distribution, single sign-on, procurement and many other tools became part of the majority of service catalog projects.

The service catalog was at the center of a vast web of tools, unifying the user experience that a bunch of processes and tools stitch together.  Same pattern exists today with cloud services: lots of infrastructure and software abstracted up the catalog to deliver a unified experience.

2009-2012 saw the advent of the self-service and automated datacenter era and its cousin, the cloud.  The new requirements are to provide complete control of resources in a self-service manner.  Out goes the help desk as the primary integration point and in comes integration with cloud API's such Amazon and automated orchestration of all activities instead of manual activities.  This in a way is a sequelae of the Great Recession: one way to do more with less is to provide it via automated self-service.

The outcome of these new requirements for cloud based services meant that now lifecycle management, subscription management, and orchestration would become core to the Workplace portal.

Which is what we have been busily doing for all our customers

• We added a complete portlet system so now customers can extend the portal with new pages and new portlets. True to its flexible nature, the new Portal includes a Portal Designer and a Portlet Designer. And it's Java JSR 168 compliant so you can bring those types of portlets into the portal.  For newScale customer, this capability is now part of the standard license.
• We added a basic license to the Cisco Process Orchestrator in order to leverage its superior integration and extensive number of adapters.
• User experience is very important so we have some new widgets, called Grid Controls, that enable much more dynamic forms. Whether you need the ability to on-board a number of new employees, or specify an indeterminate number of IP addresses, the Grid Control vastly simplify the user experience.
• We also have made significant changes to the rules system.  Now you can select whether rules execute in the client or on the server. This helps improve performance and security which results in a better user experience.
• New for our workplace portal customers are "Directory tasks" which enable easy manipulation and updating of directory information from workflows - a very common pattern in workplace services.
• And cloud services require API's so brand new REST based API's that enforce policies are available.

But that's the past. The future looks even better.

 The Future of Workplace Services - Back to the Future?

A funny thing about the future is that one can often see the what, but not the when. So take this with a grain of salt for the when.

Workplace services are fundamentally being altered by three phenomena:

1. Rapid adoption of SaaS services
2. Bring your own device (BYOD) and VDI/VXI
3. The rise of social collaboration outside the enterprise

Saas will require the evolution of the service catalog into a "service broker" role focused on provisioning of ID's, roles, and vendor management. In my view, the 2004 use cases with emphasis on goverance will make a comeback. And the use cases for outsourcing will also be relevant in this space. The new wrinkle will be the emphasis on automation, agility and subscription management.

Also, I believe that while the category of software called "Cloud Service Brokers" (CSBs) will be relevant, the very hard use cases that underpin Enterprise class applications will be be served by a traditional service catalog better than by the CSB's. It is one thing to provision Google Apps for an employee, quite something else to provision access to "Time card system in the role of regional manager supply chain."

Personal note: Why do I believe this? We have 21st century problems and 19th century management. Most organizations work from risk avoidance (for good & bad reasons). Hence tons of governance is required.

BYOD moves provisioning beyond the physical device to the virtual desktop, applications access and communications capabilities to employees.  This requires excellent orchestration as VDI/VXI as a service requires a rather large number of systems to be activated in close coordination.

So just like in 2001, desktop provisioning was the main service and integration with help desk and procurement were needed, now integration with a variety of virtualization, communication and network services are required.

Personal note: My life is like the movies: Back to the future! Groundhog day! Looper! Rodrigo and newScale excellent adventure.

Finally, the rise of the social web and cross-company collaboration will bring in new requirements for defining the control boundary for data.  Wikis, shared space, instant messaging, activity streams are all very cool new capabilities.

But if that's tracking a potential contract, who should see the amount of the contract? That will require a service catalog of access management which deals with new ways of communication and collaborating beyond the walls of the enterprise.

Personal note: it's been a hell of a ride, hasn't it? :)