Lack of Cloud Governance: A Potentially Fatal Flaw in Enterprise Cloud Adoption

Many enterprises realize that successful cloud implementations require the adoption of new IT capabilities, such as automated workload management, self-service provisioning, cloud security, and others. Yet, many of these organizations still don’t recognize a critically important challenge they must also address to avoid it becoming a fatal flaw in their efforts to deploy business workloads into the cloud. That fatal flaw is insufficient cloud governance. Even companies experiencing good results with their virtualization management efforts rarely have a solid understanding of cloud governance. That needs to change, because cloud governance ultimately enables many of the core business benefits of cloud adoption.

It’s About Time to Market

The real value of cloud computing is achieved when it can streamline the entire enterprise software development and deployment lifecycle, and dramatically reduce time to market for software projects. The agility that cloud computing creates for IT can then be extended throughout the organization to directly benefit business users. IT will be able to respond more quickly to their needs and deliver new applications and software updates rapidly, which in turn helps them achieve their business goals faster and reduce time to market for their products and services, significantly reducing opportunity costs.

IT-intensive industries and global enterprise are full of examples where IT agility equates directly to market share, revenue growth, and profitability. Examples include traditional insurance carriers that need to quickly roll out the latest policy rate/quote functionality to their websites to avoid hemorrhaging customers to more nimble competitors with a direct sales model; or the global bank that needs to rapidly roll out customized consumer and commercial services in a new geography faster than competitors to grab market share. Regardless of the specific example, it’s clear that business units stuck with slow moving IT organizations delivering in six or nine-month software development lifecycles can be at a huge disadvantage.

Many organizations are starting to recognize that cloud computing can provide self-service access and on-demand deployment of IT resources to increase agility and competitiveness. However, they tend to limit their view of governing these new capabilities in the context of their traditional IT operations, which often consist of partially automated virtual machine provisioning processes along with manual processes still in place for VM configuration and approvals. They may view cloud as a relatively simple extension of these existing IT operations, and believe they are already well positioned to deliver all the significant business benefits of cloud computing to their organizations.

But as cloud computing begins to support more diverse business workloads, the complex relationships among all the stakeholders and types of projects and workloads, along with multi-layered regulatory and cost constraints, create an intricate policy maze. Trying to enforce consistent policies on this complexity with semi-manual processes or inadequate governance tools can jeopardize the benefits of cloud computing we’re seeking in the first place including:

·         Immediate self-service access to cloud services. That is, exposing services to end users to achieve true self-service functionality, which requires automated policies enforcement to prevent unauthorized access, security breaches, and cost overruns.

·         Automatic configuration and scaling of cloud workloads up and down to meet changing demand. This requires the ability to impose policy-defined boundaries and restrictions around elastic scaling behavior to balance performance, costs, and risks.

·         Optimizing the placement of portable cloud workloads and leveraging an organization’s mix of internal private clouds and external private and public clouds. This requires the ability to restrict deployments to satisfy cost, performance, regulatory compliance, or other parameters.

Enforceable Business Policies

In addition to governing core capabilities above, an enterprise solution for cloud governance must be unified across all possible clouds, workloads and all potential end users to deliver consistent and uniform policy enforcement across the enterprise. It must also be extensible and flexible enough to meet the needs of any particular group or department within the organization.

The scope of policy-driven cloud governance includes:

• Security policies – This includes the ability to have pre-configured, zoned security models for different types of workloads. For example, prohibiting HR data from being stored on external public clouds.
• Regulatory policies – This includes the ability to impose geographic constraints, such as those required by EU regulations to restrict the storage of personal information about EU citizens outside of the EU. It also includes industry-specific policies, such as the requirement that sensitive personal financial or health-related information be stored only in data centers that meet specific security requirements.
• Organization-specific policies – This includes an unlimited number and form of specific departmental, business unit, or cost center requirements. For example, a particular cost center may need to rely exclusively on open source solutions because there is no budget allocated for licensed software alternatives. In a self-service environment, this cost center cannot be allowed to choose to have workloads moved onto a virtual machine running licensed software.

In many organizations, the demand for cloud computing is accelerating. One unfortunate consequence is that business units and departments frustrated with the slow response of corporate IT are bypassing them and accessing cloud services directly with their credit cards, resulting in dangerous ungoverned cloud usage and growth. IT organizations need to quickly get ahead of this trend before regulatory compliance and security risks catch up to them, and so they can lead the charge to delivering the full benefits of the cloud for their organization.

The Ideal Cloud Governance Solution

The only way to ensure that cloud adoption takes place with the required level of security, privacy, regulatory compliance, and cost controls is through a powerful policy-driven governance platform with the following characteristics:

• A policy engine that is flexible enough to support the myriad conditions and attributes across the organization, and that is also easy to use for business analysts who understand the relevant business drivers for these policies and should be directly involved in cloud management and governance efforts.
• Integration with an organization’s cloud management platform so that the policies created are directly enforceable at the level of the VMs and the workloads provisioned on them.
• An open platform that is able to connect with other tools and platforms in the enterprise to streamline and automate required activities such as identity management, accounting/chargeback, auditing/reporting, and more.

Cloud adoption is inevitable for large enterprises, and organizations must make a choice. They can allow adoption to occur in an ungoverned environment with policies that are unenforceable—then struggle to clean up the mess after finding themselves with cost, performance, and possibly embarrassing and expensive compliance or security violations. Or, they can get ahead of the problem and immediately begin rolling out fully governed cloud-based services that deliver the agility that software developers and business users need while controlling costs and ensuring compliance.

Enterprise Cloud Governance: Policies and Metamodels

By Dave Roberts on August 2nd, 2011 at 11:53 am EDT

James Urquhart wrote a good piece for CNET yesterday, titled Regulation, Automation, and Cloud Computing. In it, James comments on a blog by Chris Hoff discussing some of the downsides to automation. Originally, Chris had pointed out that heavily automated environments don’t leave a lot of room for human intervention when things go wrong and rapid automatic response can actually lead to cascading failure when the world fails in a way that was not expected by the automation creator. James then made the point that automation also interacts with the legal and regulatory spheres. James says:

If we are changing the very configuration of our applications–including location, vendors supplying service, even security technologies applied to our requirements–how the heck are we going to assure that we don’t start breaking laws or running afoul of our compliance agreements?

 

It wouldn’t be such a big deal if we could just build the law and compliance regulations into our automated environment, but I want you to stop and think about that for a second. Not only do laws and regulations change on an almost daily basis (though any given law or regulation might change occasionally), but there are so many of them that it is difficult to know which rules to apply to which systems for any given action.

 

In fact, I long ago figured out that we will never codify into automation the laws required to keep IT systems legal and compliant. Not all of them, anyway. This is precisely because humanity has built a huge (and highly paid) professional class to test and stretch the boundaries of those same rules every day: the legal profession.

Chris is right.

James is right insofar as he identifies the problem and then says that it’s impossible to codify every single law and regulation into the automation system.

But, while we can’t codify everything, that also isn’t an argument to avoid codifyinganything.

The basic problem is that with cloud, we’re no longer building control systems strictly for IT operations personnel. I believe that the whole BIG IDEA with clouds is that we can decentralize and democratize the control systems that drive IT resources. Right now, the IT department controls all IT systems. You want something done? You talk to IT. If and when IT can get around to it, you might get what you want. And ultimately, that’s a slow, inefficient way to run a railroad. There are many ideas that business units have that simply can’t be executed on because the amount of time and energy spent trying to get IT to deliver the right resources is too high. But with that slow inefficiency also comes a control point such that we can enforce enterprise governance requirements. Today, there are enough human review and approval processes in place to put the brakes on most ill-conceived ideas that would violate laws or regulations.

With cloud, however, we have the opportunity to make IT completely self-service. And that’s wonderful for creating increased business value because it means that business units no longer have to beg and plead with the IT department to execute on projects that are important to the business. Rather, the business can make use of self-service resources to do whatever they need. By cutting out the IT middleman from the daily requests, the speed of the solution delivery lifecycle (SDLC) increases, and, if the business is doing its job, so does business value creation.

The challenge with the self-service model is not technical. We can build all the automated systems to execute a self-service model fairly easily, and there are many examples. The big problem with self-service is governance.

If you’re running a large, multinational financial institution of the kind that ServiceMesh deals with every day, is it reasonable to expect every business-unit developer or mid-level manager in the USA to understand all the laws governing financial information in Germany or Hong Kong? Do users and developers in London understand the laws and regulations in Tokyo? The answer is most assuredly not. But with a single click, we could move a workload or dataset across the planet, violating the laws of multiple jurisdictions at the same time.

So, James says that it’s unreasonable to expect to codify the legal system into our automation systems. But it’s equally as unreasonable to expect non-lawyers (and frankly even lawyers) to understand the legal and regulatory posture of a company across all its geographies. So, what can we do?

Do we really have to achieve 100% fidelity between automated infrastructure and a constantly changing legal structure. And if we can’t, does that mean that any attempt at control is inevitably fruitless and should not even be attempted?

I don’t believe so. The ServiceMesh Agility Platform was constructed with a very richpolicy management system that goes far beyond simple user-based or role-based access control to individual resources. The Agility Platform policy management system was created to allow layering of possibly multiple conflicting policies, created by a diverse group of governance people. The policies are sorted out, prioritized, and the right things happen. The policy management system operates on a customizable meta-model which allows every high-level object type within the Agility Platform (applications, stacks, scripts, clouds, etc.) to be tagged with attributes that can then be inspected as part of policy decisions.

Thus, we can create policies as rich as something like, “Bob is allowed to deploy workload X into Cloud Y. But because X requires SSAE 16 (the follow-on to SAS 70), X can only be deployed into datacenter Z, which has SSAE 16 certification. And all network traffic to and from the workload must be encrypted. And all storage must be encrypted. And only into the non-production environment. And only on Tuesday.” And even more complex than that. Or a lot simpler than that. If you want, you can just specify that Bob is only allowed to deploy things in Cloud A and be done with it.

In short, almost anything can be expressed in the Agility Platform policy system — it’s that rich. And that’s critically important when, as James says, you’re trying to track the whims of lawyers across the world.

It’s another matter keeping all those policies up to date, however. James points out that the laws are constantly changing. That’s one reason it would be foolish to hard-code them into the automation system itself, whether that’s a standard management system, a low-level run-book automation oriented orchestration package, or a Perl script. With the Agility Platform, we made policies stackable and easily editable by mere mortals (AKA governance and compliance personnel) with a WYSIWYG graphical editor, rather than relying on coders. This means that the job of creating and maintaining policies can be delegated and distributed to those people who are in the best position to implement them. Policies are then checked at the appropriate times by the platform, automatically.

Is this a perfect solution? No. James is right in that the problem is hard and I can’t conceive of a 100% solution. We still rely on humans to codify laws and regulations and those must be kept up to date and applied correctly. But we’re not creating a brittle, completely unmaintainable system where the policies are “baked into” our scripting. We have a system where policies are stacked and interact correctly. In short, it’s built to scale and about as clean of a system that I can imagine.

Focus on Architecture First Before Moving to the Cloud

“The point of enterprise architecture is to look beyond the silos and create a blueprint for the business’ big-picture strategy.” Read more.

These guys are cool in the cloud

I just published a blog from the web site talking about a speaking op they gave at Cloud Expo NYC. Other Meshians might find it interesting, particularly if you have customer-facing roles. The blog links to the Cloud Expo presentation which was video taped.

Blog: http://www.servicemesh.com/posts/searching-for-the-big-win/
External link to the video: http://downloads.sys-con.com/download/wc_cc11e_servicemesh

VMware price war

Folks, as some of you probably know by now, VMware changed its pricing structure for vSphere 5 earlier this week. Whether a given customer is affected or not, this would be a good time to highlight the fact that ServiceMesh Agility Platform can help customers create contestability to in turn help isolate them from some of these changes. The cloud market (whatever that means) has a lot of evolution to go through and more of these shocks are certainly going to happen in the future. Agility Platform customers, while not totally immune to anything, will certainly be able to weather the storms better than those who bought into all-VMware or all-any-other-large-vendor solutions.

I just drafted a blog to describe some of the strategic thinking here and highlight this. Feel free to call your customer's attention to this:
http://www.servicemesh.com/posts/word-of-the-day-contestability

7 Self-Inflicted Wounds Of Cloud Computing

Don't let poor planning and half-hearted decisions doom your promising cloud projects.

By Charles Babcock InformationWeek
July 06, 2011 01:30 PM

Anthony Skipper at ServiceMesh assembled a comprehensive list of the common holes in companies' approach to cloud computing for his presentation at Cloud Expo in New York in June.
Skipper is VP of infrastructure and security at ServiceMesh, a supplier of IT service management and lifecycle governance. His presentation was titled, "Cloud Scar Tissue: Real World Implementation Lessons Learned From Early Adopters." It was also cited by cloud blogger Andrew Chapman.
Read more of the story here:

“What planning is needed for initial cloud projects?” – Q&A from the Trenches Series

rganizations typically conduct a lot of research on cloud providers and enabling technologies before making the decision to embark on their first cloud project. However, sometimes this extensive research and vendor selection effort gets confused with the actual project planning required for success of that initial cloud project.
After the decision is made to move forward with a cloud initiative, sometimes the urge to get our “stuff” on the cloud quickly is hard to resist. There hasn’t been a time in recent memory with more opportunity for IT but, with great opportunity comes great risk! We’ve all heard the saying that goes something like “automate a bad process and make bad stuff happen more quickly”. Cloud brings a myriad set of options for improving how your enterprise utilizes IT and executes its business objectives, but implementing it without sufficient upfront planning can bring serious risk and bring it very quickly.
Some of the biggest gaps I see in cloud project planning occur in the areas of Security, Policy and Governance. These are important considerations everyone should include in the review and planning portion of any project, before moving applications and workloads on to a cloud.
First let me say that I’m not an expert in security, policy or governance. If I have to be classified as an expert, it’s on the ownership and management characteristics of IT infrastructure. So, I’m not going to give you a detailed technical strategy for implementing your security or policy framework. Rather I’m going to focus on the planning and “ownership” point of view, both of which encompass having a clear set of goals and objectives for its implementation, management, and lifecycle.
Security: Planning here should include a well understood set of security requirements and usage characteristics for the project:
Who uses it?
Where and how will data be stored, shared, backed up, etc.?
Who will be supporting it?
What are the individual roles required?
Will it be a private cloud, hybrid cloud, or public cloud?
What are the characteristics of the network?
What experience does your internal network team have with cloud or highly virtualized environments? What are the current skill gaps & where can you get help?
What tools do you already have? Have you compared them against newer products/services on the market that are focused on security in a cloud?
Do your tools allow for automated policy enforcement on new instances?
What type of reporting and auditing will you have?
What about identity management? Is it integrated with your cloud management platform?
What are the partner requirements? Do you have the right partners, with appropriate experience? Should you audit current and proposed service providers? Have you evaluated team skills to identify gaps and training opportunities?
Where and how has security been factored in to your business continuity planning? Security, like an earthquake or a hardware failure, can be a threat to your availability. As such, your security strategy should match enterprise objectives for availability.
Governance and Policy: This includes governing how an instance is created, why it’s created, by whom, and under what restrictions it operates.
Governance and approval work flows should be well understood.
Document and enforce regulations/restrictions regarding data availability, storage location, and performance.
Establish a governance lifecycle that includes the creation and enforcement of policies for cloud workloads as they are planned, built, shared, and deployed.
Where will your instances reside and under what context or situations while they be put there or moved?
What is the performance criteria to determine right placement of workloads?
Define role-based access to assets and environments.
Ensure that automated approaches to scale, distribution and shutdown encompass enterprise policy controls.
What are the guidelines for allowing scale? How is scale approved?
How are Business Critical priorities mapped against threshold limitations
Change management strategy.
Roles and ownership
Who’s responsible for the delivery of cloud services
Who’s responsible for the cloud environment?
Are all the roles well defined?
Many times, the most valuable time spent on a project is the time spent during planning. Moving to cloud is no different. Make your move in a well-planned and controlled fashion so you can more rapidly benefit from new services, while not putting your team or the enterprise at risk.