Some would say that cloud has passed the peak of inflated expectations. After that stage in the development of a new technology or trend the tough work begins. We in the Cisco’s Cloud and Systems Management Group have done just that in releasing Cisco Intelligent Automation for Cloud Version 3.1. In the past four weeks I have presented this cloud self-service and orchestration platform to well over 30 existing customers and others interested in what all the noise is. The response has made me extremely proud of our team.
One: Our UI is so intuitive that you don’t need a manual. The Cisco Cloud Portal delivers a uniquely intuitive experience for the roles of cloud administrator, organization technical administrator, and end user. Private cloud can be as easy as Amazon Web Services.
Just the other morning, my 3.5 year old daughter said “Daddy, can you make me a waffle?” And like any self-respecting parent, I of course responded with “Poof. You’re a waffle.”
It reminded me of something we frequently hear from customers: they effectively ask us to “make my data center a cloud.” Now we could wave our arms and say “Poof. It’s a cloud.” But it’s not that easy. Despite what some cloudwashers may say, virtualizing your data center does not mean you have a cloud – and self-service provisioning of VMs is not cloud computing. Real clouds require much more.
Fortunately, we have solutions to help our customers deploy real clouds – with market-leading compute, network, and management products in our Unified Data Center portfolio as well as our cloud enablement services. In fact, today we introduced yet another innovation in our Unified Computing System (UCS) portfolio with Cisco UCS Central.
I’m pleased to also announce the latest release of our cloud management software solution today: Cisco Intelligent Automation for Cloud version 3.1. This release introduces several exciting new features, and I’ve highlighted a few of these new product capabilities below.
Virtual Data Centers – In simple infrastructure-as-a-service use cases, virtual machines and other resources may be provisioned from a shared pool of resources on-demand. In more advanced infrastructure-as-a-service use cases, virtual data centers (VDCs) can be established to provide project teams or departments with a dedicated resource pool of compute, storage, and network capacity for their own organization. I’ve written in the past about this concept of a virtual data center and this is what Cisco IT deployed for our own internal private cloud.
This week on Engineers Unplugged, we’re joined by EMC’s Caroline Yap Orloff (@cloudofcaroline) and VMware’s Massimo Re Ferre (@mreferre) as they take on the mythical single pane of glass. Can one architecture solve all of your problems? Watch and see.
My users are happy: Having clearly identified and targeted my end users (did I focus on business application owners, trusted business IT folks, IT solutions team, or my administrators?), I can see that the adoption of the cloud automation is growing. This does not mean they are able to do everything they want in my first cloud deployment, but it means they are getting value out of it and I can see the anticipated number of physical and virtual servers provisioned. I also see deprovisioning occurring. After a few months I might still see three times to the provisioning going on as deprovisioning. I also have other teams beyond the first deployment angling for their turn.
IT Operations / the Cloud Command Center are cautiously monitoring the people, processes and technology: Let’s face it, getting into production was intense and we had to make tradeoffs. We did not get everything we wanted in the first deployment. We cut the tape and users jumped in the cloud pool. We got lots of feedback. We tweaked one or two things; we got even more feedback. We breathed a sigh of relief. We looked forward to chapter two and built long lists of what we wanted. We adjusted our roadmap. We reviewed the success, learnings and failures with our management. We identified and quantified the ROI. We realized that we had lots of work to do. Our Data Center operational processes were so spread out among our staff. We had to think very clearly about managing the change from routine to strategic and how our workforce needed to transition to new roles.
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..