In my last column, I discussed the convergence between the SaaS contracting model and the outsourcing contracting model. In this column, I wish to explore a strongly related topic: the increasing trend of using cloud elements in outsourcings.
There is some overlap between software-as-a-service (SaaS) services and cloud services. Before the cloud became the marketing buzzword we know and love today, a SaaS service referred to a contracting model where software features were provided over the Internet. From a legal perspective, there was not much of a difference between SaaS and the application service provider (ASP) model that preceded it. SaaS came in as the mot de jour, and ASP went the way of the service bureau and mainframe computing, borne back ceaselessly into the past.
Now, SaaS has a slightly different meaning in a cloud context. SaaS is used alongside infrastructure as a service (IaaS) and platform as a service (PaaS) to refer to different types of cloud services. I use the term “cloud” to refer to a technological model of enabling network access to a pool of configurable computing resources, where: i) the hardware is abstracted from the end user, and ii) capacity is scaled in response to increased demand.
Some folks will also want to add that cloud services are only offered on a subscription basis, but I can think of several examples where it is not. However, I agree that if a software service is offered on a subscription basis over the Internet, then it is definitely a traditional SaaS service. If that same service is readily scalable to meet increased demand, then it should be called a cloud SaaS service.
A cloud SaaS Service, when enhanced with some of the customized and service-based features (discussed in more detail in my last column), becomes an attractive alternative to a services outsourcing. But it does not have to be either a cloud SaaS service or an outsourcing. The solution can incorporate elements of both models.
For example, in a larger outsourcing, it may be desirable to host at least some of the outsourced services on a cloud infrastructure. If the infrastructure is provided by a third party, then this is an IaaS model incorporated into an outsourcing. The outsourcing provider is providing highly customized services for the customer on a cloud provided by a third party. In this hypothetical example, the outsourcing provider creates the software applications, maintains the databases, and provides the troubleshooting and support for the outsourcing to the customer, while the IaaS provider contracts with the outsourcing provider to provide the infrastructure upon which these services sit. There would still be considerable capital costs for the customer, since the customized applications would need to be developed on their dime, but at least the customer is not paying for the capital costs to provide a scalable private data center as well. Instead, the infrastructure costs can be passed through to the customer as an ongoing expense, lowering the capital costs significantly while allowing the customer to scale the services predictably to manage increased demand later on.
No doubt large outsourcing providers already manage private infrastructure clouds of their own upon which they provide their outsourced services. Vast numbers of virtualized cloud instances can be managed on an infrastructure like this, where the needs of different customers are balanced within one large cloud without disclosing any hardware details to each customer. The use of these private clouds may be disclosed to the customer, and the customer may be billed for usage accordingly. Alternatively, the use of a private cloud could be entirely hidden from the customer, and instead be a matter of network architecture and management for the vendor alone.
If cloud services are incorporated into an outsourcing arrangement, in addition to the considerations raised in my last column, counsel for the customer should consider some cloud specific concerns:
- Security and Privacy of Data: It is still up for some debate whether the cloud model is any less secure than more traditional models. Some recent articles on Slaw and Lawyers Weekly highlight the debate. In my view, it depends on the technology actually being implemented. One needs to pierce the cloud and understand what is behind it to properly answer questions relating to privacy and security. Without taking the time to understand the technology, one cannot reasonably appreciate whether the steps being taken to secure it are reasonable and will actually work. In an outsourcing context, counsel will almost certainly require technically assistance.
- SLAs: The service levels provided by IaaS providers are typically fixed and non-negotiable. Take, for example, Amazon’s EC2 cloud SLAs:
- Amazon will use reasonable commercial efforts be up only 99.95% in a year (which is 4.3 hours of downtime a year). Downtime is defined as the percentage of time that the entire region is unavailable (i.e. the entire US East (Northern Virginia), US West (Northern California), EU (Ireland), Asia Pacific (Singapore), or Asia Pacific (Tokyo) zone is down).
- Downtime excludes Force Majeure events, and downtime that result from failures of individual instances, other than the entire region being down. This essentially means all of your instances in a region are down, and you cannot start new ones.
- A 10% credit on your bill is your sole and exclusive remedy, assuming you ask for it.
These standard EC2 terms would not be acceptable for any sensitive or mission critical applications. Other IaaS providers offer similar fixed service levels. For larger usages, there may be room to negotiate with the cloud provider. However, since the underlying architecture will likely not change based on these negotiation, it would simply be an exercise in moving financial penalties around, not improving uptime or incenting improved performance by the cloud provider.
- Potential for Third Party Impact: In a shared IaaS environment, as in any shared environment, there is the potential for third party users of the shared environment to have an impact on the customer’s experience. There are two considerations which flow from this.
- The first consideration is whether a financial penalty, such as an SLA credit, would be sufficient if there is chronically poor performance of the cloud services. It may not be if, for example, the application is so important to the customer’s business that it cannot tolerate any sustained period of poor performance. If the customer cannot tolerate poor performance then a shared cloud may be too risky, and therefore not a suitable model for that customer. Some cloud providers manage this risk for customers on shared clouds by capping each user’s usage of the cloud, but this also limits the inherent flexibility and scalability of the cloud, and so is not a perfect solution.
- The second consideration is whether the customer wants to be down at the same time as everyone else on the cloud. From a business perspective, if you and your competitors share a same common point of failure, then when that failure happens, there is no advantage to either of you. However, if you are tolerant of that failure, and your competitor is not, then you are able to capitalize on the failure and grow your business. A shared cloud represents a single point of failure for competitors that all use it.
The cloud offers vast potential for lowers capital costs and improving the financial attractiveness of outsourcings, but a customer should be certain that the resulting solution is right for them, both from a legal and a technical perspective.