Over the past 2 months or so, I’ve been blogging on Cisco Domain TenSM, Cisco Service’s framework to guide you on your path to data center and cloud transformation. We are just over half way through the discussion on Cisco Domain Ten, so I thought it worthwhile, especially for anyone reading about this concept for the first time, to write a quick refresher and summary of the articles I’ve written so far. So forgive the brevity and please do dive into the links/URLs for more information if indeed you missed these articles first time. And if you’ve read every article -- thanks!
One of the most exciting things about Cisco Intelligent Automation for Cloud (Cisco IAC) is its ability to deliver the self-service agility and flexibility that a business requires to drive its success. Capacity is instantly available when needed, enabling creative innovation to bear fruit much faster (think research institutions executing millions of computations, software engineers developing new applications, or retailers launching holiday marketing campaigns.)
The benefits of cloud computing are obvious but what about the costs? For example, how do you know which resources a particular project is tied to and whether it makes good business sense? How do you make sure your users shut down services when they’re no longer needed? And how do you implement a cost model to charge back IT costs to the proper business unit or project?
These are questions that are bubbling to the surface of many enterprise cloud discussions, which is why I’m particularly excited to announce our new partner, Cloud Cruiser. Cloud Cruiser has integrated their financial management system with Intelligent Automation for Cloud, enabling enterprises to take control of their IT spending and use the granular cost information it gathers to drive better business decisions.
By implementing a financial management solution designed for the cloud, enterprise IT becomes a partner to the lines of business, providing valuable insight into the IT costs associated with the projects and applications they deploy. Chargeback gives business units the advantage of only paying for the resources that they use, resulting in both a reduction of waste (who wants to pay for those VMs that are no longer being used?) and more educated IT spending decisions, such as whether to use internal or external IT resources for a particular project. Self-service budgets and reports make users more fiscally responsible for the resources they deploy, driving costs down and productivity up.
In short, Cloud Cruiser and Cisco Intelligent Automation for Cloud work together to help enterprises make the most of their enterprise private cloud by delivering better service at lower cost.
To see how Cloud Cruiser for Cisco Intelligent Automation for Cloud works, view this short video:
Read the joint solution brief and web page to learn more about Cloud Cruiser for Cisco Intelligent Automation for Cloud.
Service Financial Management is the focus of Domain 6 in Cisco Services‘ DomainTenSM Model for Data Center and Cloud Transformation. Closely related to the User Portal (Domain 4) and Service Catalog and Management (Domain 5), service financial management is one of those organizationally challenging topics for the data center management team -- although with the advent of cloud services, is becoming more widely appreciated and in many cases (e.g. a service provider offering cloud services to businesses, a public sector organization offering services to other regional public service organizations), a mandatory part of your offer. So let’s discuss this area and I’ll point you to a technical white paper from Cisco Services experts on this topic.
Cisco Domain Ten -- Domain 6 -- Service Financial Management
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..
Of cloud computing’s three service models, software as a service (SaaS) is deployed most often. But that trend is shifting: A recent Yankee Group survey revealed that 24 percent of U.S. enterprises with cloud experience are already using infrastructure as a service (IaaS), an additional 37 percent plan to adopt it, and planned deployments are accelerating.
Cisco, too, is seeking to benefit from dynamic cloud service models, using models that offer reduced provisioning times and usage-based chargeback systems. We’ve gotten started by deploying the same unified computing and virtualization solutions we recommend to Cisco customers in our own private IaaS cloud. We call our internal cloud Cisco IT Elastic Infrastructure Services, or CITEIS.