Increasing Freedom and Confidence in Software as a Service

by Andrew Oram

September 7, 2011

What's restraining the spread of cloud computing? The trend bears the promise to lower data center costs, reduce energy use, give impetus to application development, offer more support for ever-popular mobile devices, and elasticize the deployment of systems. But a number of impediments, mostly related to security, reliability, and fear of vendor lock-in, have been cited by business managers and IT staff who are reluctant to move their systems into the cloud, whether Infrastructure, Platform, or Software as a Service (IaaS, PaaS, or SaaS). This article points to an architectural and organizational change in cloud services—especially Software as a Service—that would make them open in ways that have not yet been tried, and that would go a long way toward alleviating the concerns just cited.

Reasons for holding out against use of cloud services are detailed in an appendix, Objections to Use of the Cloud. Here I will lay out my solution and suggest how it can be brought to life.

An introduction to a new architecture

Projects in use by the scientific research community, notably notably Globus, provide a model for a freer SaaS. These projects are driven by collaboration and resource sharing rather than commerce. The scientists engaging in these activities have compute resources to share through grids and clusters, as well as data sets to share. The result is powerful systems that tie together clients, but involve a radical shift of choice and control to the periphery.

Globus allows data to be segregated from applications. The user can choose an application offered by a developer, and link a data set to it.1 This data set may belong to the user running the application, or be offered by someone else. Moreover, data can be replicated for the sake of reliability or to facilitate access. The user is also empowered to search for alternative services that can meet his or her needs, because the underlying requirements such as resource discovery and security are supported by low-level building blocks of Globus (service implementations and containers).

Globus is not likely to form the basis for new SaaS implementations, because it uses protocols (such as SOAP) and frameworks (such as the WS-* Web Service standards) that are not popular in the world of commercial web development. But the projects can serve as inspirations. The appendix Common Solutions to Lack of Freedom in the Cloud summarizes other suggestions for enhancing confidence and competition.

The architecture proposed here for SaaS would provide a slow-changing platform with a standard interface and faster-changing applications that could accommodate the changes that developers like to make on a weekly or even hourly basis to popular SaaS services. The applications would be open source, so that users could make changes, and would be under version control so that users could choose older versions if newer ones fail to offer the features or performance they need. The platform should also be open source, so that multiple organizations could deploy it and to make the integration of platform and application more reliable. (Proprietary implementations of standards tend to introduce incompatibilities, because the wording of the standards is often ambiguous.)

The physical separation in the architecture is nothing unusual. A huge number of SaaS sites already run their services on an IaaS provider. Furthermore, open-source code is available for a few forward-looking services, including identi.ca from StatusNet and Talend. However, no service offers the experience being promoted in this article, where average Internet users can maintain their own data sources and choose among alternative versions of a service. The next step is to build on the separation between platform and open-source application to unleash competition and consumer choice. A loosening of control over the offerings can shift power to the end-users and give them more confidence in the services they contract with.

To reproduce the simple experience currently enjoyed by SaaS users, a site could offer an application along with data storage so that no choice is required on the user's part. But alternatives should also be offered.

A sophisticated user who is unsatisfied with the default offering would start by choosing a site to visit. Multiple sites could offer the same software or variants of it, competing on the basis of response time or reliability. The user would then choose an instance of the software to run. Finally, the user would submit a data source and specify a data sink, which might or might not be the same as the source. The software would process data from the source and would store it back into the sink. Figure 1 illustrates the complete architecture; the main points are the separation of functions and the potential for redundancy.

Data, user, multiple SaaS instances, multiple platforms

Figure 1. Architecture of an open source cloud

Suppose a site wants to provide its users with the simplest option by default: an option corresponding to how SaaS is currently offered, with only one instance of software and with all data stored on the provider's servers. The site also wants to offer a range of other versions, however, and has chosen a list of its own versions along with third-party versions that seem popular but that it does not offer official support for. The site also wants to give the users the choice of providing input data from, and storing the output in, repositories of their choice. A start-up screen might look like Figure 2.

Alternative versions of our service

Data options

Figure 2. Mock-up of form for choosing free SaaS options

This architecture would combat lock-in and would permit quick recovery if one service failed. It would prevent governments or others from snooping on user data, except for the time it was being actively processed by the software. It would provide guarantees against data loss, and assure that data formats are standardized and readable.

The dividing line between platform and application should permit a platform to support a wide range of applications while providing a very slow-changing interface. Elements of the platform can be deduced by looking at Globus and at the IaaS and PaaS cloud solutions currently on market. We can assume that, as the market for platforms evolves, more and more functions will be identified that can be standardized and moved into the platform, to make the applications more lightweight, more robust, and faster to develop. Some of the following services might be offered by platform (IaaS) providers, while others might be built by SaaS providers:

Migrating an entire industry

Would SaaS providers tolerate an open architecture, and would they make money within such a system? I believe so. The SaaS sites provide a hardware, software, and networking infrastructure that is worth paying for. They can also enhance their offerings with superior user interfaces that can be protected through copyrights and trademarks. Software is getting easier and easier to produce, thanks to a proliferation of scripting languages and libraries, so the value of services lies increasingly in the robustness and convenience of the experience that sites offer.

A segment of an earlier article covers the benefits of opening code, and of the proposed architecture, for SaaS providers. Certainly, moving from a closed development shop to an open one is a wrenching change for organizational reasons, but any SaaS manager who claims that there is no business case for doing so should read the article and rethink his or her assumptions.

The architecture in this article does not address every concern of potential cloud users or provide iron-clad guarantees. Table 1 suggests where the architecture could help. It would go a long way toward creating a system that produce income for service providers and reassurance for their users. This sense of reassurance is in itself a reason for providers to move to it.

How can we get there from here? Clearly one must work from the bottom up. What we need is to assemble some SaaS providers who are sympathetic to open source and who appreciate a deep, walk-the-walk level how it would benefit them to go open. They should then contract with an IaaS or PaaS provider, or create one as a consortium, that could develop basic elements of a platform. If it follows standards (which are rapidly being developed), it does not have to be open source, but the benefits of the architecture are greater if the platform is. SaaS providers can then take the steps to opening their software and offering old versions or variants to customers in order to stimulate a market for variations in SaaS.


1 Chervenak, A., Foster, I., Kesselman, C., Salisbury, C., Tuecke S. The Data Grid: Towards an Architecture for the Distributed Management and Analysis of Large Scientific Datasets. Journal of Network and Computer Applications 23 (2001), 87-200 (based on conference publication from Proceedings of NetStore Conference 1999)


Andy Oram is an editor at O’Reilly Media. This article represents his views only.

Author’s home page
Other works on this topic
Other articles in chronological order
Index to other articles

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.