Virtual Panel: Cloud Services Governance

SOA Governance has been around for many years and is considered a necessary (but not sufficient) condition for the success of SOA transformation. However opinions on successful SOA governance models have vastly differed. Also in recent years, with the introduction of Cloud Computing, the SOA delivery ecosystem is further complicated with shared services residing on shared infrastructure generally beyond the realm of the business's administrative domain. Earlier this year, InfoQ in a virtual panel discussion established the underlying relationships between SOA principles and Cloud Computing. InfoQ continues the discussion with six leading experts on the approach to cloud services governance and how it compares to the current state and future direction of governance models and solutions.

Our panelist lineup includes:

• Thomas Erl: Founder and CEO of Arcitura Education Inc.
• David Linthicum: Founder and CTO of Blue Mountain Labs
• Steve Jones: Global Head of Master Data Management at Capgemini
• Michael Poulin: Head of Business and Technology Architecture at consulting company BuTechCon Ltd
• Lawrence Wilkes: Director of R&D at Everware-CBDI
• Scott Morrison: CTO and Chief Architect at Layer 7 technologies

The questions are:

1. Why does one need governance in the cloud and how should governance architects derive and define requirements in this context?
2. What are the similarities and differences between SOA and cloud services governance?
3. What effect does public, private or hybrid offerings have on governance and how does it affect client/consumer governance in each case?
4. In the SOA world from a technology standpoint, reg/rep offerings initiated design time governance but in the cloud market, gateway vendors have developed cloud specific offerings thus making the first move in the market. Do you think design time governance is losing importance and should run time governance solutions be adopted first by cloud providers?
5. What are some gaps/concerns that cloud governance vendors should focus on next?

1.      Why does one need governance in the cloud and how should governance architects derive and define requirements in this context?

Thomas Erl: An absence of a governance system within a cloud environment will have significant consequences that will only grow over time as we build more solution logic and the resulting dependencies upon cloud-based IT resources. Well-defined governance controls help us not just regulate what we deploy within clouds, but also standardize how we use the features and resources offered to us by cloud providers. With regards to defining governance requirements, governance specialists need to factor in priorities and preferences dictated by the business and IT. There needs to be an understanding of how, why, and to what extent cloud-based IT resources will be utilized and in support of what architectural style, business solutions, and business goals. Then they need to look at the costs and functional limitations imposed by cloud providers, along with budgetary requirements and any anticipated reliance on external professionals with cloud expertise. In the aforementioned case of a hybrid cloud/on-premise architecture, there further needs to be an awareness of how services and other forms of resources need to communicate with each other and perhaps even requirements for future cross-deployment. These are common examples of what is input into the process of defining a custom governance system.

David Linthicum: Governance as related to services, or service governance, is most applicable to the use of cloud computing since we are basically defining our architecture as a set of services that are relocate-able between on-premise and cloud computing-based systems. SOA is the approach here, and thus SOA or service governance is the approach and the technology we’ll leverage to manage the services within the enterprise and cloud.

Policies in the context of SOA, and thus cloud computing, are declarative electronic rules about what can be done to a service and by whom. This includes:

• Who can access the service.
• What they can do to the service.
• How the changes to the service affects other services.
• How changes to the service affect applications.
• How governance works with security.
• How governance links into service testing.
• How governance works with service discovery.
• How governance works with service delivery.
• How to set and maintain appropriate service levels.
• How to manage errors and exceptions.
• How to enable online upgrades and versioning.
• How to perform service validation.
• How to perform auditing and logging.

Steve Jones: Cloud is fundamentally about the shared provision of storage and infrastructure, whether that is via a private cloud or public cloud the key is that its a dynamic shared environment.  This doesn't mean the answer is 'no' but that security and governance needs to assume infrastructures are shared.

Michael Poulin: It depends.If you want a business to consider and use the Cloud, try to find a business that would not want to govern the assets it deals with or, at least, would not want to be sure that these assets are governed properly by somebody else.

There are tons of publications loudly advocating, if not crying for the governance in/for the Cloud because the Cloud is not an Alias and it has to be governed as anything else around us. OASIS Reference Architecture Foundations for SOA (SOA RAF) states: “The primary role of governance in the context of a SOA ecosystem is to foster an atmosphere of predictability, trust, and efficiency” and “Governance is the prescribing of conditions and constraints consistent with satisfying common goals and the structures and processes needed to define and respond to actions taken towards realizing those goals.”
This means that if you look at the governance for the Cloud from the perspective of the company-client, your governance requirements should, first of all, reflect interests of your company and still demand the delivery of results promised by the Cloud. If you are the Cloud Provider, your governance requirements should represent your interests. The interests and needs of the company is the source of governance requirements.

Therefore, people who work in governance have to solve two tasks simultaneously: 1) define governance requirements to the Cloud preserving the interests of their own company, and 2) guarantee that their corporate governance requirements do not contradict with the Cloud Provider’s governance requirements.

Lawrence Wilkes: The first issue is that most organizations will be concerned with the increased risk of using cloud-based services. Whether it is real or just perceived, the threat to security, such as the loss of data, breaches of privacy or regulation,  or to business continuity can negatively impact the business far beyond any benefits that cloud computing can provide in terms of IT costs or agility. Secondly, the dramatic increase in the range of SaaS and IaaS cloud services now on offer increases the risk of what we term “service anarchy”, where a mish-mash of diverse, disparate 3rd-party services are used by line of business projects, which whilst well intentioned may not be in the best interest of the organization overall, and may themselves increase the risks to security and continuity.

Scott Morrison: In the cloud, governance is a first order problem because of the increased risk profile. In the on-premise SOA world, formal governance could be delayed simply because it was possible to rely on existing process and security practices. But in the cloud, applications and data are simply more exposed, and so demand at least minimal governance  before deployment. For example, a publicly accessible application in the cloud needs to be hardened with the rigour that normally would be applied to a DMZ-based application such as a Web server. This additional security requirement—which it is important to acknowledge is but one small part of a complete governance solution—cannot be ignored.

2.      What are the similarities and differences between SOA and cloud services governance?

Thomas Erl: That’s not the correct question for governance specialists to be asking. It makes about as much sense as asking “What are the similarities and differences between SOA and on-premise service governance?”. Comparing SOA to cloud computing is a common point of confusion in the industry. SOA is a distinct and formal architectural model that we adopt to achieve a specific target state. That target state can be achieved with or without cloud-based services. As SOA professionals, we proceed with incorporating cloud computing technology advances when we determine that they will help us achieve the goals of our SOA adoption effort more successfully. A more useful question is: “How can SOA governance systems (that have traditionally been applied to on-premise environments) be applied to cloud environments?” Or perhaps: “How should an SOA governance system be augmented to address relevant cloud computing technologies and environments?”

David Linthicum: They are very similar, if not exactly the same in many problem domains that I’m seeing. We do governance for the simple reasons that, once we get to a certain number of services, we won’t be able to keep track of them all and provide the control they will require. Those who build SOA will call this the “tipping point” or the point where the number of services under management becomes so high that’s it’s impossible to manage them properly without a governance model, approach, and service governance technology.

The number of services, as well as the complexities around using those services within the context of cloud computing, makes service governance even more compelling, including:

• Location of the services
• Service dependencies
• Service monitoring
• Service security

Many of the services are not hosted and owned by the business; they are cloud-based, and thus controls need to be placed around them to mediate the risks. What is important when leveraging on-premise SOAs is even more important in the world of cloud computing. In essence, it’s using the model of “trust, but verify,” placing a layer of processes and technology around the services so that anything occurring, such as a change to services or services not operating properly, will be quickly known, allowing you to take corrective action, or perhaps allowing the technology itself to self-correct.

Steve Jones:Cloud is about infrastructure, SOA is about business.  They are different things.  A single SOA piece could be considered as the provisioning and costing infrastructure which could lend itself to cloud but this doesn't mean the two are interchangeable.  Cloud is a security and infrastructure question, a deployment question.  SOA is a business value question.

Michael Poulin: Interactions between corporate users and assets and the Cloud are viewed as services. Whether they are real standardized services of just interfaces that pretend to be services is a different question. In the Cloud, the cloud services governance does not nor should much differ from the governances in SOA. However, the major difference between them is in the area of governed compliance. The differences are in 1) technical constraints, and b) operational transparency.

An example of technical constraints is a co-location of different services in the same hosting environment, as well as sharing of services between different client-companies. If one client-company requires modification to the platform or re-certification of the service in line with local legislation while another client- client-company wants these actions to be performed later or asks for other modification because of different legislation, the Cloud Provider has to have governing policies (released to the client-companies) for these cases. Described situation is not a case in SOA ecosystem because each service is totally independent, it collaborates with the other services only on the basis of Service Contracts and there are alternative/competing services available to the clients. In other words, if a Service Provider violates the Service Contract, then another Service Provider may be engaged.

An example of the operational transparency is set where a client-facing Service Provider does not operate in the SOA ecosystem and does not follow the practice of Service Contracts. This Service Provider can promise certain compliance but cannot guarantee it. For instance, an underwriter is obliged to check its clients against the Sanctions Lists but it works with hundreds of brokers and relies on them for checking their thousands of clients; whether the brokers do the checking or not cannot be controlled by the underwriter.

Lawrence Wilkes: If you accept that one of the key principles of SOA is that it separates the what (the service) from the how (the implementation) and from the who (the provider) as a means to enable agility, then there is little difference.  If a good part of SOA governance is about ensuring that separation is achieved, then it will equally apply to cloud services governance.
For me, the vision of SOA, and Web Services before that, was always about enabling the assembly of solutions from a federation of “cloud” services, and so the SOA governance framework and guidance we have developed has always accommodated cloud services as a sourcing and deployment option. Clearly additional emphasis may be placed on the sourcing and operational governance of cloud services because of the perceived risks, but as explained earlier they must also be considered throughout the whole life cycle. 

Scott Morrison: Cloud governance should be viewed as a logical extension of SOA governance. The mistake some organizations make is to believe that SOA was a failed experiment, and that SOA governance practices, processes, and infrastructure need to be discarded and re-invented for cloud. Cloud done right embraces what was good about SOA, and extends this to accommodate the differences in the cloud environment. Cloud prioritizes the governance requirement of SOA, but also recognizes that cloud brings specialized new risks, such as provider viability, transfer of control, and compliance questions, that need to be managed through a formal process.

3.      What effect does public, private or hybrid offerings have on governance and how does it affect client/consumer governance in each case?

Thomas Erl: The primary effect the chosen cloud deployment model has on a cloud consumer is the level of control they gain or lose over the definition, evolution, and administration of their cloud-based IT resources. The more you rely on public, third-party cloud providers, the less you need to invest in establishing your required infrastructure, but the more control you lose over the management and governance of cloud-based IT resources that you use and depend on.

David Linthicum: You really need to adjust your governance model and strategy depending on how you’re deploying your cloud solution, private, public, or hybrid. Private clouds are more along the lines of traditional SOA, considering that you still own everything. In the world of public cloud computing, the ability to link to APIs established as interfaces into your cloud computing-based resources will allow you to manage those resources as if the resources were local. This provides the capabilities to monitor the health of a service, including performance, up-time, and logging any issues as changes. Also, on the service governance side of things, you can make sure to control access to the service and specify who’s allowed to change it.

However, the ability to have management-level visibility into pubic cloud computing-based resources varies greatly from provide to provider. Some just provide their own Web page/visual interface for you, and can’t link your governance, monitoring, and security solutions at the single service level. Other don’t provide any monitoring at all, arguing that you should just trust them to manage your systems. A few offer well thought-out management APIs that can seamlessly interact with your service governance and monitoring technologies.

Steve Jones: Very little, the point is that governance needs to be able to consider all of these options and provision based on the security and cost restrictions.  Its the continuum that is important not fixing on a single option.

Michael Poulin: The effects on governance and, in particular, on client/consumer governance caused by public, private or hybrid offerings have some common and special aspects. The common aspects include:

1. A need for governing additional relationships with the Cloud hosting organization (even if it is internal, it is not necessary governed via the IT governance)
2. A need for governing across different ownership boundaries, even in the same enterprise
3. If the Cloud is hosted outside of the company, additional governance is needed for the IT function itself, since it is not any longer exclusively owned by the company

Here is a list of what a use of public Cloud requires to govern in addition to the governance tasks for the private Cloud:

• Legal risks (client may be incompliant with the local law where the service or client’s SW/data is physically resides and , consequently, may be fined)
• Risks from changes in jurisdiction (client might be unaware about the changes in jurisdiction in the places where client’s SW/data is physically held and , consequently, may be fined)
• Licensing risks (client license agreement may be violated by local service provider with no notification to the client)
• Undetected unauthorised access
• Recovery of the provider, continuity of service (disaster recovery means of every participant in the chain of the Cloud Providers affect the service to the client) 
• Legal compliance management (conflicts between the compliance requirements across corporate and geographical boundaries)   
• Lack of version control and integrity of updates and patching (different participants of the chain of Cloud Providers do not know what other participants have done)   
• Potential conflicts of interest  (a business interest of some participants of the chain of the Cloud Providers may be in conflict with the business interests of the client)
• Completeness of urgent changes (urgent changes in the service or in the deployed client’s SW/data are regulated by the service contracts. There is no guarantee that the Urgent Change terms of one contract are propagated to the other contracts with the participants of the chain of Cloud Providers)

Remember, in a service ecosystem there are two rules at work: “Service of my service is not my service” and “Client of my client is not my client".

Lawrence Wilkes: From many perspectives, the option of deploying to a public, private or hybrid cloud should have little bearing on governance. Policies should determine which types of capability, or which business domains, etc., are allowed to make use of each of these cloud deployment patterns. Ensuring security and continuity, or enabling innovation and agility ought to be just as much a concern for private cloud deployment as for public cloud.

Requirements for security and continuity, innovation and agility ought to be set for the service type, not the deployment option. That is for example, a core mission critical service that is deployed to a private cloud may require much more stringent governance than other less critical service types that are deployed to the public cloud.  It is the criticality of the service, or the sensitivity of the data that determines the governance requirements, which in turn defines the permitted deployment options.  Not the other way around.

That said, there is a risk that because what takes place behind the service provided is hidden from the service consumer, then the real risks involved may be hidden too.  In a private cloud the provider and consumer are parts of the same organization, so nothing is really hidden from those who need to know. However, in a public or hybrid scenario there is a much greater level of trust required and so it is natural that organizations are going to want to scrutinize cloud services more closely and apply greater governance.

Scott Morrison: Public and private cloud represent two extremes in terms of their impact on governance. Private cloud can be governed very similar to on-premise computing resources. Private clouds can often be viewed as a new and better approach to existing IT, with a focus on automation, self-service, pay-per-use, and leverage of commoditization. These qualities do not necessarily impact an existing strong SOA governance program.

In contrast, public clouds represent the other extreme, which demands significant extension of existing governance processes and technology. In the middle is hybrid, which can lean toward public or private depending on which of these provider styles is used to burst additional workload to. Hybrid using public clouds for additional capacity require public-cloud level governance; hybrid using private clouds can rely on existing good governance practices and infrastructure.

4.      In the SOA world from a technology standpoint, reg/rep offerings initiated design time governance but in the cloud market, gateway vendors have developed cloud specific offerings thus making the first move in the market. Do you think design time governance is losing importance and should run time governance solutions be adopted first by cloud providers?

Thomas Erl: Cloud providers need to establish a technology architecture for the cloud environments they invest in and build out in response to the demand they receive from their cloud consumer markets. Even though they often are focused on providing raw resources that can be used and configured individually by cloud consumers, the overall evolution of a given cloud’s ecosystem requires design-time governance attention. Maintaining a successful current state requires runtime governance, as does the on-going need to collect metrics that help chart the evolutionary direction of the cloud ecosystem (which brings us back to design-time governance).

David Linthicum: Today SOA is a huge reality as companies ramp up to leverage cloud computing or have an SOA that uses cloud-based services. Thus, the focus on runtime service execution provides much more value. Many of the existing runtime SOA governance players support enough design and implementation capabilities that separate design-time tools are not required. Cloud computing is simply accelerating the focus on the requirement for runtime SOA governance, and sooner or later design time will fall by the wayside.
Steve Jones: Only idiots think that design time governance isn't important.  Dating back to the Mythical Man Month its central that understanding problems first saves you time, fixing things in operations is the short cut to high costs. Of course you need run-time governance, but you can't get good at that without planning for it... the plan is design time.

Michael Poulin: I believe that registries/repositories help not only in the design time governance but also in discovering (not necessary automated or on-line) services suitable for the client needs. The given question collides two different realms – the realm of client’s SW deployed in the Cloud (private or public) and the realm of vendor services consumed by the clients as is. I do not see any problems between design-time and run-time governance because they target different concerns for different realms.

Also, I do not see any contradiction between the registries/repositories and the cloud specific gateways; these cloud specific offerings are just another type of service registries/repositories. I can assume only a problem with the cloud specific gateway such as the latter might not provide enough information to the clients to make their decisions about suitability of the service. In any case, if the Cloud Provider does not have its run-time governance, clients have to avoid such provider by all means.

Lawrence Wilkes: Given that organizations are deploying cloud-based solutions right now, if the failure of those solutions could have significant business impact then it is essential that they put the necessary run-time governance in place right now too. Vendors are reflecting, or encouraging, that demand.It was no different in the early days of Web Services, when many of today’s SOA governance products first appeared and were focused almost exclusively on the run-time aspects too. But logically this is going about it in the wrong sequence. It doesn’t help an organization if it has good run-time governance over cloud services, but they are the wrong set of services because of inadequate design governance in planning and architecture and as a consequence business requirements are not fully addressed, nor that the run-time failure of a cloud service is itself a consequence of poor governance over sourcing and implementation.

Scott Morrison: Absolutely. Run time governance is a first order problem in the cloud; on day one, you need protection and management of your applications and data—there is no safety net. This has inverted the traditional implementation order of design-time and run-time governance that had appeared in on-premise SOA.
This development actually makes better sense. Prioritizing run time governance fits much better with the agile development process that so many organizations are finally adopting. Good, frictionless run-time governance tools should contribute to the agile process. Design-time governance comes into play only when service and API development reaches a particular scale. Imposing too much big design up front is exactly what gave SOA a bad name, as it became a barrier to adoption rather than an enabler.

5.      What are some gaps/concerns that cloud governance vendors should focus on next?

Thomas Erl: My request is for cloud governance vendors to make a clearer distinction between governance and management. Governance is regulatory. Management is hands-on decision-making and operations within the confines of governance regulations. Too many IT professionals focus on the management of solutions and IT resources, assuming they are “governing” them, when in fact they aren’t. This confusion is not helped by vendors that group management and governance features within products labeled as governance tools.
David Linthicum: I see the service governance technology providing the following features in the future. Today, most provide some, but not all of these features.

Service discovery refers to the process of finding, analyzing, and detailing out an existing service and the use of a policy to govern that service. The great thing about this feature is that you simply enter in the location of the service (URL), and the runtime service governance technology does the rest, including entering aspects of the service into the repository.

Service delivery is the process of moving services from development to execution or production, either on-premise, or into the clouds.

Security encompasses the functions around protection of the services that are managed, and enforcement of the policies.

Setting and maintaining appropriate service levels refers to making sure that all of the services execute per the service agreements and preset levels. This is especially important in an architecture that leverages cloud computing since they may come with SLAs, or service level agreements, that must be managed too.

Managing errors and exceptions is a feature where any errors and exceptions that occur are captured, analyzed, and perhaps recovered from automatically. Typically this means that those who implement the policies define how errors and exceptions should be managed for a specific service, or group of services. The objective is to recover from most errors and exceptions without human intervention, if possible.

Enabling online upgrades and versioning refers to the process of placing new services and/or polices into service, and controlling the process around the upgrades made to services and/or policies, and controlling how services and/or polices are versioned. This is done by allowing the repository to track all services and policies under management, including the complete history of services and polices that have been created, tested, and deployed in either the on-premise or cloud computing-based systems.

As developers build new versions of services, or as policy designers design and build new policies, there needs to be a mechanism to insure that updating services and policies won’t break the existing system or systems. Runtime service governance is able to track any upgrades that are made, insuring that the applications, processes, and other services leveraging those services are made aware of the change, and alterations are made, and testing completed.

Moreover, if issues are discovered, there should be a mechanism to return to the previous version of the service and/or policy. Besides the use of policies to control access to services, this is one of the most important functions of runtime governance.

Service validation, as the name implies, is the feature of the governance technology that validates that the services are “well formed,” and prepared to go into production. Service validation asks the question: Is this service valid to the policies and to its expected behavior when in production?

Auditing and logging means that the governance technology will track the execution of the services and the policies, including what they do, when they do it, and who they do it with. This allows those who manage the holistic architecture to analyze auditing and logging information to determine why problems occurred, or better yet, prevent them. Auditing is required by many legal compliance standards, such as those imposed on public companies or those in regulated vertical markets, such as health care.

Steve Jones: TOSCA is a new standards effort at OASIS that aims to address problem of cloud interoperability.  If there isn't interoperability in the cloud then its just a proprietary solution that locks you in, its more critical in cloud than in SOA.TOSCA is where all cloud vendors should be looking, whether its the answer or not is to be decided but the key factor is that its part of the journey.

Michael Poulin: Some authors say that it is “virtually impossible to regulate cloud computing without regulating the Internet itself”. I do not think so. Nonetheless, if Cloud Computing wants to deliver on its promises, it has to accept business discipline of conducting business; having cool tools and “techy” gurus is not enough to gain business trust (no trust – no business). The Cloud governance vendors have to create controllable environment that can convince business they can rely on it. The failure of Amazon Cloud in April of 2011 has provided us with a lesson that the Cloud itself needs protection. Therefore, the Cloud governance has to target Cloud Designing for Failure as one of its top priorities. My last recommendation to the Cloud governance vendors is to avoid or help to fix so-called “pragmatic governance”. This kind of governance movement tries to “legalize” what people already do instead of what people have to do in order to reach business objectives and deliver business value.

Lawrence Wilkes: Design-time Governance: SOA governance products have been traditionally strong in terms of run-time operational governance, but less so in terms of design-time governance. Cloud governance can be expected to follow a similar pattern. If you consider the life cycle from business modeling through to software coding as “design time”, the challenge is that there is much less standardization on the plethora of different deliverables that are produced. Hence defining precise policies or exerting governance over them is more difficult. For example, just exerting governance over WSDL or software artifacts is well short of the requirement. It is too late if you are already building the “wrong” services.

Scott Morrison: Unified governance technology is going to be important in the future. At present, our cloud governance solutions are cobbled together from multiple vendors. We have single sign-on (SSO) from one vendor, IPS/IDS from another, virtual firewalling and isolation from another. Much of the value proposition of cloud is to automate and simplify deployment of resources. The basic cloud technology has begun to deliver on this, but governance is still left out of the stack. In the future we need to order governance services from the same console we order up and configure a virtual RedHat image with an LDAP server running on it. Governance needs to be part of the service portfolio offered by a cloud provider.

Conclusion

While there is wide consensus on the necessity of governance for the success of cloud adoption, the approaches continue to vary based on how one defines SOA, the value of SOA and other closely related concepts such as SOA governance vs SOA management. The relative importance assigned to design time governance ranging from completely unimportant for the rollout of services to absolutely essential highlights these differences. The good news is that there is agreement on the operational concerns of provisioning and consuming services in the cloud and its consequences for run time governance and management.

About the Panelists