The technology of the cloud has been evolving fairly quickly, in fact faster than many people expected, this author included. The number of serious market players and their sheer size (including companies such as Amazon, Google, IBM, and Microsoft) attests that we have passed the point of no return: this new model is here to stay. Indeed, no selection process for an IT capability is complete today unless it includes cloud-based solutions. Even government entities have embraced the trend, in part because of the usual promise of cost savings, flexibility, and scalability, but also with a view toward creating more employment in the private sector rather than in already large government agency staffs. The US federal government, as well as the governments of some other countries, actually now mandates that cloud solutions be the preferred choice, not the exception, for new systems.
When organizations consider a cloud option, they always look first at functionality and cost. They realize that a cloud offering must also meet other capabilities without which an IT service is not viable: performance assurance, resilience, disaster recovery, notification schemes, security, privacy, and so on. Much needs to improve in terms of how to negotiate, ensure, and/or verify those capabilities. This part of the discussion between suppliers and clients is not very rational or balanced: we are still at a stage where cloud providers tell you, “These are our standard terms and conditions and the (very) few promises we make to you. Take it or leave it.” In this ecosystem, it seems that the big fish are the large providers named earlier; the small fish are niche-oriented or regional cloud providers, the brokers, and the contractors; and the plankton are the customers. Should it not be the other way around or at least better balanced?
An Emerging But Incomplete Ecosystem
First, let’s address the question of scope. I personally believe that the phrase “private cloud” is often used to make a fairly modest architecture change — consisting of data center consolidation accompanied by virtualization — sound like a bold step into the future. Whether one agrees with this criticism or not, a private cloud does not create a complex interaction between multiple partners. The partners (an organization’s users, its IT department, and its equipment and software suppliers) are continuing to function in essentially the same way they were before such a program was put in place. If the consolidated data center is outsourced to a hosting provider, the relationship is a little more elaborate and is based on a service-level agreement, but this is still not as complex as a public cloud service; the client has just subcontracted the management of a dedicated infrastructure. Therefore, as is often the case in discussions about the cloud, I will only write here about public clouds (or, in the case of hybrid clouds, about the public part of those clouds).
The “conceptual reference model” from the NIST Cloud Computing Reference Architecture defines five actors in cloud computing (see Table 1):
- Cloud consumer
- Cloud provider
- Cloud auditor
- Cloud broker
- Cloud carrier
Table 1 — Actors in Cloud Computing (Source: NIST)
|Cloud consumer||A person or organization that maintains a business relationship with, and uses services from,cloud providers.|
|Cloud provider||A person, organization, or entity responsible for making a service available to interested parties.|
|Cloud auditor||A party that can conduct independent assessments of cloud services, information system operations, performance, and security of the cloud implementation.|
|Cloud broker||An entity that manages the use, performance, and delivery of cloud services and negotiates relationships between cloud providers and cloud consumers.|
|Cloud carrier||An intermediary that provides connectivity and transport of cloud services from cloud providers tocloud consumers.|
In reality, the roles of cloud broker and cloud auditor are rarely filled today — although NIST includes cloud aggregation, a separate emerging value-added service, in the offerings of a cloud broker instead of identifying aggregators as distinct actors. And while there are always telecommunications carriers involved, they are not explicitly part of the deal, since public cloud services are usually accessed over the Internet using whatever ISPs the provider and the consumer already contract with. As a result, most deals explicitly mention only the consumer and the provider.
The consumer’s own users, who may be its employees but may also be external customers or partners, are also missing from this list. They typically don’t participate in any of the discussions between the five actors listed in Table 1, but they are clearly impacted by the cloud service, and their own behavior may on occasion impact the service. They should also be consulted about their requirements when a provider is chosen and about their satisfaction once the service is delivered.
Finally, the NIST model omits the regulatory bodies and agencies that strongly influence the use of cloud services in both the public and private sectors. For example, HIPAA regulations impact the potential uses of the cloud for patient data storage, and financial regulations impact the use of cloud solutions by banks.
Seeing cloud adoption as an activity involving just two of these multiple players (providers and consumers) significantly limits the “ecosystem” view of the cloud world. This is something that should evolve as the industry matures — with new classes of service providers emerging to play the roles of brokers, aggregators, auditors, and regulators — and as the NIST model is, one hopes, further revised to acknowledge the role of end users. As for the carriers, they will become more important when consumers of large, mission-critical amounts of computing or storage start requiring dedicated high-speed links with quality-of-service guarantees that the public Internet may never offer.
Once a more complete model is in place, with its full range of actors, we will need to define better than we have done so far the relationships between these participants. You may think of these relationships as food chains, to pursue the ecosystem metaphor, or as value exchanges, to follow a value stream analysis approach. One way to formalize this is to draw a RACI (Responsible-Accountable-Consulted-Informed) matrix. Table 2 shows the classical definition of the RACI roles.
Table 2 — RACI Definitions (Source: Wikipedia)
|R||Responsible||Those who do the work to achieve the task. There is typically one role with a participation type of responsible, although others can be delegated to assist in the work required.|
|A||Accountable||The one ultimately answerable for the correct and thorough completion of the deliverable or task, and the one from whom responsible is delegated the work. In other words, anaccountable must sign off on (approve) work that responsible provides. There must be only one accountable specified for each task or deliverable.|
|C||Consulted||Those whose opinions are sought, typically subject matter experts, and with whom there is two-way communication.|
|I||Informed||Those who are kept up to date on progress, often only on completion of the task or deliverable, and with whom there is just one-way communication.|
We can now associate each role of the NIST model to certain RACI levels with respect to each aspect of a cloud service. To take a few examples:
- Cloud consumers are accountable for timely bill payment and for complying with terms of service (e.g., for not using a service to spam others or to distribute illegal content).
- Cloud auditors are accountable for providing a fair assessment based on the information they were able to collect.
- The service quality manager of a cloud provider is accountable for the contracted uptime of the service.
- The IT operations staff of the cloud provider is responsible for that uptime.
- Cloud consumers are consulted by a cloud provider who needs to schedule some downtime for maintenance reasons.
- Cloud consumers are informed about the anticipated recovery time from an unexpected service interruption.
- A cloud carrier is accountable for the throughput and latency of a circuit.