Steve Watkins, Guest Blogger
Steve Watkins is a Consulting Systems Engineer for Cisco Intelligent Automation for Cloud. He came to Cisco as part of the newScale acquisition in 2011. He has been helping customers manage the migration to IT as a Service (ITaaS) since 2004.
Showback and Chargeback have become increasingly hot topics for IT, especially infrastructure teams. This is fuelled at least in part by the general acceptance of cloud computing, including private clouds and SaaS applications. Chargeback (and even Showback) are great ways of affecting behavior of the consumers of IT. It keeps consumers from demanding an unreasonable amount of services, and encourages them to use of what has already been invested in. There is also a growing mandate from Finance to make IT accountable for its spend, or at the very least to justify any requests for further investment. So infrastructure teams find themselves in the unexpected position of defining prices for the services traditionally offered. Most have no idea where to start.
Several vendors have produced offerings to help manage the showback/chargeback business case. This post will not discuss any vendor in detail. Instead, I want to talk about philosophy.
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:
1.INFLEXIBLE – Utility pricing is asset based, and therefore assumes that the assets will remain more-or-less the same. The model breaks down when you introduce changes, like renting infrastructure from public providers or changing service levels. What about if I offer VDI next year? That may mean two different types of pricing models, which gets even more complex. A service-based pricing scheme works with all services.
2.POOR CAPACITY MANAGEMENT – by only charging for the CPU cycles you actually consume, it encourages users to stand up systems and leave them in place.. which is exactly what we don’t want. Think of renting a car: you rent a car for 4 days but only drive it for a total of 3 hours, you still have to pay for all for days. If I just paid when I actually drove it, I would keep it all the time. We want to encourage users to return unused assets. Which leads to..
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.
Welcome to San Francisco for one the most exciting events of the year!
Here’s a short blog post that will help you connect with the Intelligent Automation team at VMworld and learn about new solution developments and releases. In particular, you will be interested to see a brand new demo featuring Virtual Network Management Center 2.0. VNMC is a centralized device and security policy management software, which works together with Cisco Virtual Security Gateway (VSG) and the Cisco ASA 1000V firewall to manage security on Nexus 1000V virtual switch series.
And make sure you mark your calendar to attend one of these theater presentations to learn more about what Cisco can offer your organization:
• My First Cloud Get Started with Cisco Cloud Management from Cisco Data Center
This session will discuss how Cisco Intelligent Automation for Cloud enables IT to move from manual to flexible automated provisioning of physical and virtual resources, while maintaining existing processes and governance, increasing IT efficiency. Monday, August 27 10:30am Cisco booth
• Private Cloud Case Study with Cisco Management and Orchestration from Cisco Data Center
Join this session to learn about the challenges Cisco IT has solved by implementing cloud management and orchestration technology to provide internal private cloud services. Tuesday, August 28 11:30am Cisco Booth #1213
Cloud is a journey. This post discusses our approach to crawl, walk and run.
A cloud architecture has multiple facets and requirements, a key part of which is the need for cloud orchestration and provisioning, coupled with a self-service end user portal. Let’s call this “Cloud Automation” for now. If you are designing and/or building a cloud, then, part of your work will be to deliver a cloud automation solution to deliver on that promise. How do you plan to go about that? One approach is to define your extensive list of requirements, based upon your business needs and current capabilities, and go about building out that solution.
Another approach is what I’ll call “Crawl Walk Run”. The incremental approach.
Cloud is a change to the operational model: a change in behavior, accounting, process and people. You can’t do it overnight. Trying to deliver every service doesn’t work.
It’s very important to set a roadmap of where you want go with your cloud services so you don’t get stuck in the VM Azores — this is where all the focus is on VM provisioning and then you deploy technology that does that. And only that.
You need that roadmap of services and a technology platform that supports your vision. Even if all you first is crawl.
Recently, I wrote an article on PaaS for IT BusinessEdge entitled the road PaaS, understanding your post IaaS options. Here’s an excerpt.
The Road to PaaS
PaaS is an enticing proposition that has generated a lot of market buzz.
But PaaS forces tradeoffs and it shouldn’t be seen as a one-size-fits-all proposition.
To understand, I like to draw the distinction between what I call “Silicon Valley PaaS” and “Enterprise PaaS.” The majority of the discussion in the market today revolves around the Silicon Valley PaaS pattern, which is a truly abstracted “black box” approach to software platforms.
This form of PaaS exposes a set of standardized services to which you write your applications, completely sheltering developers from the underlying complexity below the PaaS abstraction.
It makes a lot of sense for brand-apps built with modern frameworks like Python and Ruby in greenfield development environments that are highly standardized.
The basic premise of the post is that PaaS for an enterprise is VERY different from PaaS for a Silicon Valley start up. And nowhere is it more different than in the network requirements.
The PaaS customer is a developer who will code an application, use the underlying services offered by the PaaS stack, such a database, storage, queueing, etc. The developer deploys the code, selects a few options and code is live.
So what’s going on with the network? Well, the PaaS layer will need to auto-scale, fail-over and deliver performance at some level. It may need it’s own domain as well. That PaaS layer will need to talk to underlying network services such as firewalls, switches, etc. That PaaS really needs access to infrastructure models that deliver network containers to whatever PaaS abstraction the PaaS layer has.
Hard enough to do when all the containers are the same, as it would be in a Silicon Valley PaaS offering.
It doesn’t work with the existing enterprise platforms. This is a big opportunity for innovation