On the Trustworthiness of SaaS Components

Marc Andreessen has an intriguing classification of Software as a Service (SaaS). He writes that there are three levels of internet platforms today:

1. "Access API" - A platform's apps run elsewhere, and call into the platform via a web services API to draw on data and services -- this is how Flickr does it.
2. "Plug-In API" - A platform's apps run elsewhere, but inject functionality into the platform via a plug-in API -- this is how Facebook does it. Most likely, a Level 2 platform's apps also call into the platform via a web services API to draw on data and services.
3. "Runtime Environment" - A platform's apps run inside the platform itself -- the platform provides the "runtime environment" within which the app's code runs.

SaaS architectures are naturally evolving from monolithic fixed services to architectures that permit pluggable customization by its users. The primary differentiator between SaaS and conventional software lies in who is operationally responsible for the service. That is, the day to day upkeep of the service is the responsibility of the SaaS service provider and not the licensee¹ of the software. What's new about Andreessen's classification is that it emphasizes the distinction of which party has the operational responsibilities of each component in an architecture.

Dividing up operational responsibilities is nothing new. What is new is how responsibilities are distributed to other parties that you can't absolutely trust. In other words, SaaS services cross trust boundaries and have to ensure that all participant components behave in a controlled manner. How then does it ensure this at the same time allow a participant unfettered programmatic flexibility?

It is common understanding on how to secure a web accessible API. But how does one secure an executable environment that can allow third parties to run code? The conventional way is to provide a kind of virtual environment or machine with a limited instruction set. Web hosting environments already do this, so there's really nothing new about Andreessen's 'Runtime Environment'. What is new is where the line is drawn between the SaaS and the hosted customers plug-in.

The selling point of a SaaS is that it provides sufficient value added service beyond a hosted virtual machine that a limited restricted runtime environment is an acceptable situation for the customer. So rather than providing the unrestricted x86 machine instruction set (à la Amazon ec2), a more limited instruction set is provided. Or put another way, a Domain Specific Language (DSL) is usually provided by the SaaS provider. Examples of these are the FBML markup from Facebook, the VXML markup for IVR hosting providers like Voxeo and the Linden Scripting Language of Second Life.

These environments mirror the security environment of a Web Browser. A Web Browser must be secure from non well behaved code that is injected by a Web Server. In the analogous manner, a SaaS service must be secure from non well behaved code that may be injected by a hosted plug-in.

The real twist here, that Andreessen may have completely overlooked, is that the plugin code runs within the environment controlled by the user and also in the hosted environment. What this implies is that you can have controlled code have unfettered access to private data. This is remarkably different than just providing a virtual machine or a DSL in a hosted environment. In the Runtime Environment there is additional effort to define and likely constrain remote access to one's own data. In this execution model, one actually writes server side code that that returns a representation that is rendered by the hosted environment.

Andreessen comments about the complexities in building a Runtime Environment:

What are some of those issues? To list a few: You have to provide a runtime environment that can execute arbitrary third-party application code. You have to build a system for accepting and managing that code. You have to build integrated development tools into your interface to let people develop that code. You have to provide an integrated database environment suitable for applications to store and process their data. You have to deal with security in many different ways to prevent applications from stepping on one another or on your system -- for example, sandboxing. You have to anticipate the consequences an application succeeding and needing to be automatically scaled. And you have to build an automated system underneath all that to provide the servers, storage, and networking capabilities required to actually run all of the third-party applications.

It certainly is a lot of complexity, but is it really necessary? The Plug-in API model in addition to addressing the security issue is also more loosely coupled. That is, think of how SaaS services are continuously upgraded unbeknownst by users. Furthermore, the same Plug-in may render varying representations for the same data allowing its capability to be exposed in multiple SaaS environments. Runtime Environments will eventually demand portability, however portability is achieved by providing a restricted API and this is done by best via a DSL (see: Mega-Component Reusability)

In summary, the Plugin API model is actually richer than the 'Runtime Environment' that Andressen seems to prefer. It is an order of magnitude easier to implement and it is more loosely coupled from the hosting platform. The 'Plugin API' can execute code in either the hosted environment and on its own. Furthermore, its trustworthiness is ensured on both sides of the equation.

I for one would avoid unnecessary complexity and lean toward simplicity. This is all and good, after all, web developers are well acquainted with this style of execution.