The Cisco Process Orchestrator has very rich integration capabilities, yet we often hear the question, “Does it integrate with…” or “Does it work with” [insert product]. The Cisco Process Orchestrator is a primary component in the Cisco Intelligent Automation for Cloud management solution.
The fact is that in modern environments with modern orchestrators the answer is always yes. The reality is that cloud automation requires a Process Orchestrator tie into a variety of different systems in order to start offering cloud services. Remember, Cloud is an operating model, not a product. This means that to deliver self-service, on-demand services requires all the elements of the service be orchestrated.
The graphic below shows the components in the deployments. You see integration with Cisco UCS, VMware and storage, as you would expect. It also orchestrates IP address management (that IP won’t provision itself), Remedy incident, CMDB, ActiveDirectory (so tenants can log in), image management and a few other things such as Service Assurance.
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.
What is vPath? Well, if VXLANs can set up secure tunnels over a shared, multi-tenant virtual network, vPath is a feature of the Nexus 1000V virtual switch that can redirect traffic to virtual application services before the switch sends the packets down into the virtual machine. Very important stuff, but how does it do that? I find that my blog posts are more popular the less I type, and the more I embed cool TechWiseTV videos that illustrate the concept, so I’m dusting off this classic from the TWTV team on just how vPath does that with our Virtual Security Gateway (VSG). Take it away Robb…
This is part 2 of the series “10 Things Vmware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management” that I’ll be publishing over the next couple of weeks.
Number 2. The service catalog is the place where your user can document (communicate) their request
Let me show you an example.
If you go to an e-commerce storefront and choose to look at Cisco UCS servers, they are broken down their servers into classes (Rack, Blade, etc), which then provides different models, which can then be customized within the parameters allowed for that model. I’m not saying this makes sense for your environment, but the break down between classes, models, and then self-service configuration is a useful construct for thinking about your templates.
What are your standard classes of environment you provide? Could it be production, development, QA? What about models? Could those be on-line transaction processing, extranet, intranet HR, basic web server, basic database?
We would want to ask entirely different set of questions and configuration options for an extranet, high transaction database than for a personal development environment, wouldn’t we?
It’d also make our job much simpler and faster if we know what parameters were involved for that particular request.
The service catalog is key to enable your customers to:
Discover what’s available me
Guide me based on my high level needs,
Help me compare models, then
Assist me in customizing my configuration.
And of course all the tracking, workflow and life-cycle management that the service catalog enables. This is what makes a service catalog different from a “web form front-end” to a help desk — automation is the big difference.
This part 1 of the series “10 Things Vmware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management” that I’ll be publishing over the next few weeks--I hope! (The boy is nothing if not ambitious).
1. The service catalog is a tool for driving users to standard configurations.
To get the operational efficiencies we hope to achieve from virtualization and / or cloud computing, we need to establish standard configurations. This is tough, for a couple of reasons.
First, the challenge is the gap between the language of the customer, and the detail needed by the operations group typically generates a lot of back and forth during the “server engineering” process. Instead of having “pre-packaged” configurations, every thing is bespoke.
Instead of having useful abstraction layers and levels, the customer has to invent their own little bit of the data center. This made sense when the new app meant a whole new hardware stack to which the app would be fused to and the concrete poured on it. It doesn’t make sense now.
Second, there’s resistance from customers to adopt standard VM builds. Sometimes the reasons are valid, other times less so. The issue arises because the technical configurations have not been abstracted to a level the user can understand what they get and what’s available for configuration. Nor can they compare one template to another in ways that are meaningful to them.
The service catalog is the tool to help deal with these two obstacles. The service catalog is a useful tool to communicate, in the language of the customer, the different options available from IT for hosting environments.
A service catalog will support multiple views (customer, technical, financial, etc) so that when the customer selects “small Linux” for testing, this generates both a bill of materials and standard configuration options. Once that base is selected, self-service configuration wizards provide both guidance and gutter-rails so the customer is both helped to the right thing and prevented from making errors.
From this customer configuration, the environment build sheet is generated which will drive provisioning and configuration activities or to execute any policy automation in place.
And the catalog allows the VM admins to figure out what their “market” is buying; which is very useful for capacity planning.