Cisco Blogs

Adding Governance and Controls to Multicloud

- October 17, 2017 - 1 Comment

Believe it or not, there are some interesting books about IT governance and controls. Before you doze off, let me oversimplify. IT Governance is all about having a system that determines who gets to make decisions. IT Controls provide a framework to make sure things are done a certain way.

This is important! Who gets to decide if and when a server gets patched? Who verifies it was actually patched? Who decides how much budget is available for cloud spend? How is spending controlled? Who gets to decide which firewall rules and port settings are applied? Who decides who can do what at different stages of the application development and release process? Who gets to decide if an application with customer or patient data can be deployed in the cloud?

Today there are more cloud options — including both application architectures and deployment environments – than ever before. That means there are more choices than ever before. But at the same time, more cloud options have changed IT consumers’ expectations. They expect to get what they want when they want it.

Policies that lay out who can do what, where, when and for how long are critical for balancing agile operations with risk mitigation practically. Applying these policies can’t introduce too much friction into the IT consumption process, or else people will actively work around the control system.

So, how do you help users make good decisions while ensuring things are done the right way every time? In a word: automation.

Automation with Guardrails

It’s generally recognized that in the current agile, digitally transformed, multicloud DevOps environment, you should automate everything. Automation saves time and money. It makes things move faster.

But it also makes things consistent, repeatable, and predictable. Automation helps solve for the decision/control/policy problem. With automation, policies can be codified and simplified so they are consumable by both humans and the computers executing the automation.

There are many different tactical options for automating the deployment and configuration of workloads in multicloud environments, including scripts, workflow orchestrators, JSON blueprints, configuration management tools (both declarative and imperative), and other cloud vendor offered tools.

Most of these options don’t provide governance guardrails on the automation that works consistently across multiple environments. As a result, applying a single set of governance and control policies across multiple environments that have different automation tools and processes can be hard. And implementing automation without guardrails leaves IT open to significant risk.

Multicloud Governance with CloudCenter

Here’s where a multicloud management tool like Cisco CloudCenter is different. It abstracts Infrastructure as a Service (IaaS) APIs that are different in each environment and uses a unique and patented architecture to allow a single deployable blueprint to be used in a user’s choice of target environments. Under the hood, a simple object model defines relationships between users, deployment environments, and deployable blueprints (called Application Profiles).

As a result, a single set of policies can implement governance and controls across users, applications, and multiple target deployment environments. That gives CloudCenter a governance wrapper around everything. That makes both IT and IT consumers’ jobs easier.

The simple “Who, What, Where, When, How” model can be used to understand how the CloudCenter policy model can apply consistently across multiple virtual data centers and private and public cloud environments.


Can access and execute automation? (e.g. deploy a workload to user’s choice of environment). Who determines what standard services are included in each blueprint? Who updates, quality controls, version controls, and releases each automation artifact for broad use?

Who has project authority at different stages of development and release cycle?


What can be deployed? For Dev? Test? Production? What port settings? What configuration? What scaling policies?


Can customer, credit card or patient data be deployed in the cloud? Which cloud? At what stages of the application lifecycle? Can workloads be migrated? To the cloud? Or split between on premises and public cloud?


Are all self-service deployments pre approved? Or only if there is budget? When do workloads get suspended to cut costs? Or Deleted?

How much?

Are self-service pre approved deployments unlimted? Can users choose any instance size they want? Is autoscaling unlimited? Are bugets unlimited? (rhetorical question). Unlimited in cloud, but limited on prem to a specific resource pool? Or limited to project budget? Department budget? Or user specific budget?

How long?

Are deployments forever? What triggers workload deletion? Suspension?

With multicloud governance, there are many choices. And there are a wide range of controls required to mitigate risk. And you may have a long list of policies.

The good news, is with CloudCenter you can make it easy for self-service multicloud users to make good choices and do the right thing every time.

To see CloudCenter in action, register now for this 30-minute demo webcast where I’ll walk through the CloudCenter features that implement a who, what, where, when, how model for multicloud governance and control in a IT consumer friendly way.




In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


    This is SUCH a great description of the differentiation points of CloudCenter! Another one is the benchmarking tool that lets you determine which deployment is the most cost-effective, and the ACI/UCSD Integration. The CloudCenter with ACI demo in dCloud offers a great look at these features, and also shows UCSD integration - you can see the user role, the Architect role, and the Admin role all in the same demo. Great blog, write more!