Until recently, if you weren’t in IT (or even in the division of IT that handled server and storage provisioning) and you needed machines to launch an app or analyze some data, you typically had to wait days, if not weeks, for that to happen. And even when you did get it, you had no clue whether the IT person who provisioned it gave you enough CPU or storage space to handle your needs, nor could you check up on these issues yourself. Generally you discovered application glitches when your help desk lit up with complaints — and then you were at the mercy of an IT department that didn’t know how to prioritize your problem.
One hears the modern answer is automated “service orchestration,” but – until last week – I’d never seen that done. It feels better being able to say (with a straight face): “yeah, I’ve seen that done, and I know what it takes.” It’s no longer a mystery. In fact, it’s so simple and obvious now that it makes me think “why weren’t we doing that all along?” You can get the play-by-play on provisioning resources in a private cloud, and then you can lord it over your friends & colleagues (like I will).
Zenoss’ Kent Erickson and Gerard Berthet co-hosted the walkthrough with Wayne Greene of Cisco, using the product of a [cloud project they built in a week last December. At the beginning of the week, they started with a FlexPod with VMware, and ended it with an IaaS cloud “where a cloud tenant could order a VM and get automated service management.”
I attended the working session last week on Private Cloud Service Orchestration with Cisco UCS, hoping to see how these guys succeeded in dropping service provision from an average of 43 days back in 2005 to 15 minutes, as Greene said during the webinar. They did this by orchestrating Cisco Intelligent Automation for Cloud (Cisco IAC) with Zenoss Cloud Service Assurance (ZCSA)Â to provision, discover, and manage it within a virtual infrastructure.
Rather than detail how Gerard provisioned in real time a new VM on a FlexPod in Dubai, I suggest you watch the webinar for yourself. Why is this joint effort between Cisco and Zenoss such a game-changer?
Automation for Elvis
Cloud consumers (anyone from application developers to business analysts) can’t safely create their own VMs unless certain best practices, service-level agreements (SLAs), templates, role-based access, and other parameters already have been embedded into a virtual data center’s (VDC) automation framework. Properly-configured automation can centralize such controls and governance so that there are no disconnected processes among the server, storage, virtualization, networking and other teams, let alone end users.
For example, how do you keep an end user like “Elvis” from configuring a virtual server willy-nilly without regard to where that server may end up, or what firewall it’s within (or without!)? Greene (who came up with the Elvis example) explained you do so by implementing role-based access controls using Cisco IAC to restrict Elvis to just the “Rock Stars” Virtual Data Center. Within the parameters of “Rock Stars,” Elvis may have access to specific virtual server templates to ensure that certain governance requirements and best practices are baked (or in Elvis’s case, deep-fried) into them, so that operations folks no longer need to fret about damaging configurations.
Flexible Provisioning on Demand
It’s one thing to provision a virtual server. But how do you figure out the amount of processing power or storage space your application may need? And will that application always need that amount? Will it need a lot during a big event, but not so much on the run-up to the event, and quite a bit less after that?
Back when manual provisioning was the only option, worried consumers (like my friends in the marketing department) used to ask for extra infrastructure, just in case. After all, when it already took days if not weeks to get their resources provisioned, they’d be S.O.L. if they failed to ask for enough up front.
But in this self-provisioning model, app developers no longer have to supersize their VMs, Greene said. If they discover they need more of anything, they can just adjust it themselves with the help of Cisco IAC – and do so within minutes. And, as Kent pointed out, they don’t have to be precise in figuring out capacities because re-provisioning for varying workloads is just a matter of going to the Cisco IAC dashboard and making some adjustments that will be processed within minutes.
This sort of elasticity translates into competitive advantages, as well as cost savings. For example, let’s say you are using a charity app, that multiplies your usual site traffic x105 for an 8-hour period. Provision and spin up however many VMs you need to run this holiday app for that amount of time. Then, when that’s over, downsize it for stragglers, so that unneeded resources immediately become available to another division (that needs to analyze a large set of year-end, setting the company up for big gains in the New Year).
From Events to Services
Of course, all of this self-provisioned awesomeness becomes problematic if the person who ordered it can’t tell how it’s doing. Visibility has always been a bugaboo of virtual environments because it’s much easier to provision VMs than to keep track of them.
As demonstrated in the webinar above, Zenoss is so tightly integrated with Cisco IAC that it discovers ordered resources and reports back to the person who placed the order as part of the delivery process. “Here,” it seems to say, “is the stuff you ordered – now have at it!” It’s like the time I ordered school clothes for both my sons, and Land’s End called to make sure everything arrived in time for school. I’ll never forget that attention to detail.
But this tight coupling does more than give you “a router’s point of view,” as Kent described it. With Zenoss, the operations people can see the service I ordered, and can automatically get alerted if my service experiences glitches. A non-IT Ops person like me can go to the “Services” tab and check out the infrastructure underpinning my order. I can scan a dashboard to see if my resources’ performance and availability levels are acceptable. If my customers complain, I can point to the dashboard and MY people and the IT people are both looking at the same screen.
Moreover, the ability to focus on services means that IT Ops folks don’t waste time on “red” events that don’t impact customers. Sure, that VM in the Timbuktu VDC may be down, but if it isn’t being used (and should have been decommissioned six months ago), you can rest assured that it’s a lower priority than Elvis’s interactive tour of Graceland that handles 100,000 worldwide users on a given day.
Zenoss and Cisco may describe this project as “private cloud service orchestration,” but collaboration seems a better word. Together Cisco and Zenoss set up an environment that facilitates collaboration between divisions to accomplish great things (or at least align themselves toward mutual business objectives). Who would have guessed that automation could make collaboration look so good?
