The software-as-a-service world used to be straightforward. If an application was built on a multitenant architecture and paid for by subscription, it qualified as SaaS. Now there are at least four different architectures on the market. While the proliferation might not seem to matter when SaaS consumption is relatively simplistic, it has long-term implications for the integration and management of mixed services when those services are based on different architectures.
The SaaS descriptor refers to the combination of software and its delivery method. In the short history of SaaS, the software was built on a multitenant architecture. It was delivered over the Internet, and paid for by ongoing subscriptions. While the delivery channel and subscription model remain constant, the architectural model is changing. But it is not splitting into a one-or-the-other choice and there is no outright winner.
In a multitenant architecture, multiple users share the same application and database on the same back-end server, usually running out of a large data center. This centralised model is cost effective for the provider because the set-up and running costs can be spread across multiple users. It also makes for easy maintenance and updates. It works for the user because it provides rapid access to applications without up-front license fee and infrastructure costs or ongoing maintenance requirements.
The downside is that the accompanying per user/per month subscription means that after several years, large implementations can cost as much as licensed on-premise applications. Also, with multiple users relying on a single server and database, failure means widespread disruption. While a one-user failure is as serious as multi-user failure for the company concerned, the overall business impact of a multiple failure is magnified. There is also the theoretical risk that activities by one user could adversely affect others, or that peak periods of usage could have an impact on performance.
There are also business issues. In industries such as banking, regulations prohibit the storing of competitor data on the same system.
Vendors who do not provide multitenancy argue that it represents a monolithic architecture because it is built on a single-system environment where customers share a single database, application server and hardware platform. But the monolithic accusation does not entirely stand up when you start to consider server virtualisation and the reality of grid technology usage within data centres.
It is also suggested that the use of big iron in the data centre means it lacks flexibility and potentially scalability. Certainly no one knows just how big a data centre can scale. There again, there have been no reports of data centres or SaaS provision reaching their limits.
Multitenancy is the choice of the original SaaS players: Salesforce.com, RightNow, and NetSuite, plus later entrants such as Siebel and Microsoft. With the exception of Salesforce.com and to an extent Microsoft, each of these vendors uses a third-party data centre provider. They leave the data centre decisions to the data centre experts.
SAP offered an alternative architecture when it dipped its toe in to SaaS, which it said bridged the gap between single tenancy and multitenancy environments. Its isolated tenancy model aims to combine the low-risk/low-cost aspects of single tenancy with the efficiencies of multitenancy architecture.
Under this model, customers do not share databases or memory although they do run off the same hardware platform. Each customer has its own instance of a centrally deployed and managed application, running on its own database. Dedicated resources have the potential to reduce the risk of disruption due to the activities of other customers at the database level, although the risk remains at the hardware level. The model also gets around regulatory problems concerning shared data storage. Centrally distributed and managed software enables the cost efficiencies associated with multitenancy.
As with multitenancy, the architecture suggests a world view based on the use of big iron, but the reality may not necessarily reflect that. Isolated tenancy is potentially more costly and complex to manage from the provider's perspective, although unless it puts the price point out of kilter with the rest of the market it is not something consumers need to worry about.
The architecture says more about SAP than SaaS. Launched at the start of 2006, it indicated SAP's ambivalent attitude to SaaS at that time. With each customer accessing their own application instance, SAP should have been able to provide significant customisation capabilities, but this was not the case. The approach gave the impression the company was just dallying with SaaS.
SAP is due to launch a new SaaS business application suite and accompanying business later this month. It has said nothing about the architecture yet, so it will be interesting to see whether it has made any changes. At the least we would expect it to embrace grid technology at the back end.
Hybrid multitenant/single tenant
Oracle has developed a hybrid architecture for the bulk of its SaaS offerings. It offers customers their own application instance running on their own database, which is similar to a single-tenant architecture and to SAP's isolated tenancy design. Its twist is that it inserts an administration layer on top of the database, and this is where it is multitenant. Essentially it applies multitenancy at a difference level of the stack. Oracle said it believed this approach allowed for better scalability and reliability. At the back end it runs on a large, horizontally scaled grid.
Its stance is that multitenancy is irrelevant from the customer perspective because the issue of whether all customer data is loaded into one database or multiple databases is of no value to the customer. It argues that multitenancy works for vendors because of cost and manageability benefits. While that is true, it is also what allows the providers to offer business software services at commodity prices.
Like SAP, Oracle is adding to its existing application architecture rather than building a complementary one. It has taken this approach because of its investment and vested interest in its technology and installed customer base. Another driver is its desire to offer a range of services that are interchangeable from a customer perspective.
For that to happen, SaaS has to comply with Oracle's mainstream direction.
Multi-instance architecture is based on a 'spread the servers, spread the risk' approach. Still in the process of being introduced by the commercial open source provider SugarCRM, details are sparse, but under this model each customer receives its own instance of the application. As with the SAP and Oracle approaches, this will address issues such as regulatory data-separation issues. At the back end, Sugar has ditched the idea of a small number of large servers in favor of commodity-priced servers, a grid architecture, and systems-management software.
The Sugar approach springs from its open source roots, whereby it is applying the horizontal scale-out capabilities of open source software platforms to SaaS architecture. It aims to eliminate what it sees as the trade-offs associated with previous generations between deep customisation and upgrade ability.
With hardware costs down at the commodity level, and open source technologies available, SugarCRM argues that it is cost-effective to use multiple small servers in a grid formation instead of large servers. It cites companies like Google and Amazon that use grid technology to support their services and are SaaS providers in all but name. Grid technology does not preclude multitenancy however. Yahoo and eBay are reported to use a multitenant model on grid architecture.
Multitenancy sounds similar to the old ASP approach whereby providers took standard applications and hosted a single instance per server, per customer, but Sugar maintains that it represents the third generation of on-demand architecture. It argues that original ASP operations were not cost-effective and were unable to scale because they ran applications on proprietary application servers and expensive hardware and had to cover the cost of the software license plus the hardware when charging customers. Today, open source software, commodity hardware, and subscription-based pricing has changed the business and technology model, making multi-instance viable. The advent of management tools is also a contributory factor. However, SugarCRM may be underestimating the manageability issue.
Multitenancy represents the second-generation on-demand architecture, according to SugarCRM which argues that it is built on a single-system environment, which translates to limited flexibility. It believes multitenancy is no longer a necessity for on-demand because although it has the benefit of being well understood, it is still an expensive architecture and lacks the flexibility of grid architecture. One of the benefits of the multi-instance, grid-based architecture is that customers will not all have to move to the next version of the application. It also spreads the risk in terms of server failure.
The design of each architecture reflects the various agendas and competencies of the respective providers but also has its own merits and demerits. As such there is no right or wrong architecture.
Each potential customer needs to marry its individual business and technology needs against what each architecture can offer.
Multitenancy may be suited to highly distributed businesses and/or resource-strapped ones, while those offering single application instance and their own database could suit banking organisations that require data separation but still want to use SaaS.
In some senses the architecture should not matter because that is a matter for the provider and it should be transparent to the customer. This is true in the short term but it could become an issue in the longer term. The depth of integration a customer requires with existing on-premise IT systems will have an impact on architecture choice, as will the amount of value the customer wants to add to the application.
The real issue will probably not emerge until customers start stringing together multiple SaaS offerings from different vendors, based on different architectures. Web services, open APIs, and XML might not be enough to overcome compatibility issues. There is also the potential to recreate the integration tangle that client-server technology created. The degree varies but each vendor is promoting its own development platform and partner ecosystem to minimise the risk. However, the reality is that there will be mixed environments, not just on-demand to on-premise but on-demand to on-demand. Organisations need to consider data models, architecture, cross-architecture integration, and management before going too far down the SaaS path.
The way this is resolved will determine how SaaS progresses. It is not an issue yet as many SaaS systems are point systems or integrated to selected on-premise applications. But SaaS cannot become a replacement model for on-premise or even gain equality until there is some direction.