As we predicted earlier in the year, cloud computing is starting to take hold, especially if you believe the marketing literature of vendors and consulting firms. Yet, we are seeing an increasing number of Cloud success stories, ranging from simplistic consumption of utility Services and offloading of compute resources to the sort of application and process clouds we discussed in a previous ZapFlash. Perhaps the reason why usage of the Cloud is still nascent in the enterprise is because of an increasing chorus of concerns being voiced about the usage of Cloud resources:

Cloud availability. Cloud security. Erosion of data integrity. Data replication and consistency issues. Potential loss of privacy. Lack of auditing and logging visibility. Potential for regulatory violations. Application sprawl & dependencies. Inappropriate usage of Services. Difficulty in managing intra-Cloud, inter-Cloud, and Cloud and non-Cloud interactions and resources. And that’s just the short list.

Do any of these issues sound familiar? To address these concerns, we have to return to a topic we’ve hashed over and again on the SOA side of things: governance. The above issues are primarily, if not exclusively, governance concerns. Thankfully, in many ways, we can apply what we’ve already learned, implemented, and invested in SOA Governance directly to issues of Cloud Governance. However, SOA and Cloud, while complementary, are not equivalent concepts. There are a wide range of patterns and usage considerations that are either new to the SOA Governance picture or ones that we were able to gloss over. To make Cloud computing a success, we need to make Cloud governance a success. So, what can we apply from our existing SOA governance knowledge, and what new things do companies need to consider?

Design-Time Cloud Governance
Designing Services to be deployed in the Cloud is much like designing Services for your own SOA infrastructure. In fact, that’s the point – most Cloud infrastructure providers, whether they are third-party Cloud providers like Amazon.com, or self-hosting Cloud infrastructure vendors, pitch the simplicity of Cloud Service development and deployment. However, within this simple mode lurks an insidious beast: if you thought it was hard to get your developers on the same page with regards to Service development when you owned your own SOA infrastructure and registry, try it when you have little visibility into the Service assets built by unknown developers. Like the early days of Web Services-centric SOA development, companies faced developers hacking out a wide array of incompatible “Just a Bunch of Web Services (JBOWS)” style Services thrown willy-nilly on the network, now to face the same issue in the Cloud. Of course, JBOWS doesn’t a SOA make, and neither does it a Cloud make.

Furthermore, with the simplicity of Cloud Service development, deployment, and consumption, developers can use Cloud capabilities undetected by IT management. It’s not unusual for a developer to dabble with an Amazon Machine Image (AMI) for a project.

Don’t want your sales and marketing folks using Cloud services? Good luck trying to prevent that. I wish you even more luck trying to get visibility into what they are doing.

Simply use a personal Amazon account and credit card and off you go! And to make matters worse, not everyone creating or consuming Cloud Services will even be from within the IT department. In a previous ZapFlash, I admonished IT to become more responsive to the business lest they become disintermediated. Don’t want your sales and marketing folks using Cloud services? Good luck trying to prevent that. I wish you even more luck trying to get visibility into what they are doing. Without adequate design-time Cloud governance, you’re up a croc-infested river without a paddle.

Making matters worse, SOA governance tools are often missing in the Cloud Computing environment. There’s no central point for a Cloud consumer/developer to view the Services and associated policies. Furthermore, design-time policies are easily enforceable when you have control over the development and QA process, but those are notoriously lacking in the Cloud environment. The result is that design-time policies are not consistently enforced on client side, if at all. Clearly, SOA governance vendors and best practices need to step up to the plate here and apply what we already know about SOA registries/repositories and governance processes to give the control that’s needed to avoid chaos and failure. This means that IT needs to provide the enterprise a unified, Service-centric view of IT environment across the corporate data center and the Cloud.

Run-Time Cloud Governance
Making matters worse are a collection of run-time and policy issues that are complicated by the fog of Cloud computing infrastructure. Data reside on systems you don’t control, which may be in other countries or legal jurisdictions. Furthermore, systems are unlikely to have the same security standards as you have internally. This means that your security policies need to be that much more granular. You can’t count on using perimeter-based approaches to secure your data or Service access. Every message needs to be scrutinized and you need to separate Service and data policy definition from enforcement. The Cloud doesn’t simplify security issues – it complicates and exacerbates them. However, there’s nothing new here. Solid SOA security approaches, such as those we espouse in our LZA Boot Camps have always pushed the “trust no one” approach, and the Cloud is simply another infrastructure for enforcing these already stringent security policies.

In addition, Cloud reliability is pretty much out of your hands. What happens if the Cloud Service is not available? What happens if the whole Cloud is unavailable? Now you don’t only need to think about Service failure, but whole Cloud failover. Will you have an internal SOA infrastructure ready to handle requests if the Cloud is unavailable? If you do, doesn’t that entirely kill the economic benefit of Cloud in the first place? An effective Cloud governance approach must provide the means to control, monitor, and adapt Services, both with on-premises and Cloud-based implementations, and needs to provide consistency across internal SOA & cloud SOA. You should not keep your business (or IT) Service consumers guessing as to whether a Service they are consuming is inside the network or in the Cloud. The whole point of loose coupling and the Cloud is location independence. To make this concept a reality, you need management and governance that spans SOA infrastructure boundaries.

Yet, there’s more to the runtime Cloud governance picture than management and policy enforcement. Data and compliance issues can be the most perplexing. Most third-party Cloud providers provide little, if any, means to do the sort of auditing and logging that’s demanded from most compliance and regulatory requirements, let alone your internal auditing needs. Companies need to intentionally compose all Cloud Services with internal

One way to solve this problem is through the use of network intermediaries and gateways that keep a close eye on traffic between the corporate network and the Cloud.

auditing and logging Services deployed on the Cloud (or preferably) local network, negotiate better access to logging data from the Cloud provider, and implement policies for Cloud Service use to control leakage of private information to the Cloud. Furthermore, companies need to implement usage policies to control the excessive, and potentially expensive, use of Cloud Services in unauthorized ways.

One way to solve this problem is through the use of network intermediaries and gateways that keep a close eye on traffic between the corporate network and the Cloud. Intermediaries can scan cloud-bound data for leakage of private or company-sensitive data, filter traffic sent up to cloud platforms, apply access policies to Cloud Services, provide visibility into authorized and unauthorized usage of Cloud Services, and prevent unsanctioned use of Cloud Services by internal staff, among other benefits. Of course, these benefits do not extend to intra-Cloud Service consumption, but can provide a lowest common denominator of runtime governance required by the organization.

Change Management and Cloud Governance
Finally, the last major Cloud governance issue is one of change management. How do you prevent versioning of Cloud Services or even Cloud infrastructure from having significant repercussions? Proper Cloud governance techniques need to lift a page from the SOA governance book and deal with versioning at all levels: Service implementation, contract, process, infrastructure, policy, data, and schema. If you can deal with these inside the network and in the Cloud, you’re golden. If you have any gaps, you’re just itching for trouble.

But the biggest bugaboo here is testing. There simply aren’t many good approaches for testing a Cloud-implemented Service other than to do it in the live, Cloud “production” environment. Indeed, we usually get rotten tomatoes thrown at us when we teach in our LZA boot camps that it is increasingly ineffective to test SOA implementations in a QA environment as the SOA implementation becomes more mature, but now we just get blank stares when we ask if there’s such thing as a Cloud “QA” environment. Of course not. The same approach applies to SOA testing as Cloud testing: test your Services in a live environment by making sure that failures are self-contained and that automated fall-back mechanisms exist. If it can work in your own SOA environment, it can work in the Cloud… and vice-versa.

The ZapThink Take
SOA is an architectural approach and philosophy guiding the development and management of applications. Cloud is a deployment and operational model suited to host certain types of Services within an existing SOA initiative. The Cloud concept within the SOA context is one of Service infrastructure, implementation, composition, and consumption. The SOA concept within the Cloud context is one of application-level abstraction of Cloud resources. Therefore, think of Cloud Governance as evolved SOA governance.

Companies with a proper SOA governance hat on should have few problems as they move to increasingly utilize Cloud services, but those who have failed to take either an architectural perspective on Cloud or have glossed over SOA governance issues will be forced to quickly get a SOA perspective to get things right. In order for these both to work together, companies need to have a consistent SOA and Cloud Governance strategy. To address these issues, ZapThink recently launched our SOA and Cloud Governance training & certification workshops. By addressing each of the issues and potential solutions discussed above, we plan to dive deeper than anyone else has into this topic. We hope to see you there and continue the conversation and movement to SOA and Cloud success!