June 16th, 2008
Many degrees of multi-tenancy
For SaaS purists, multi-tenancy — the architectural model that allows them to serve multiple customers from a single shared instance of the application — is an article of faith, the one thing that marks them as a tribe apart from traditional software vendors. Suggesting that they’re anything other than fully multi-tenant, then, is tantamount to questioning a man’s virility or impugning an American’s patriotism. It’s not the done thing.
Perhaps, therefore, Milan Thanawala (pictured), director of platform products at Oracle, might have chosen his words a little more carefully in a panel session last week at the SIIA OnDemand Europe conference in Amsterdam [disclosure: I was a keynote speaker at the conference and participate in agenda planning for the SIIA’s SaaS events. I spoke — for a fee — at an Oracle event in January, and Salesforce.com, mentioned below, is also a client].
In the midst of a discussion of security, Thanawala made a passing comment that multi-tenancy isn’t a prerequisite for SaaS. Panel chair Bill McNee, CEO of analyst group Saugatuck Technology, immediately challenged this assertion with his own observation that multi-tenancy was fundamantal to SaaS. Now under pressure to defend his position, the Oracle spokesman responded that SaaS ISVs in Oracle’s partner network employ a range of different architectures. He went on to cite Intacct in support of his case, saying that the on-demand financials vendor runs its customers on separate pods, each with its own separate Oracle database.
It was a fateful example to choose. Incarnating every conference speaker’s worst nightmare, up stepped conference organizer David Thomas, executive director of the SIIA’s software division, taking a microphone to flatly contradict Thanawala: “I’m the former CEO of Intacct and I can tell you for a fact that’s not the case. Intacct’s architecture is completely multi-tenant,” he said.
Having participated in a webinar only the previous month with Intacct’s CTO Aaron Harris, Thanawala was disconcerted by Thomas’ intervention but held his ground — as did Thomas. In the coffee break afterwards, the two of them could be seen locked in discussion as they sought to settle their differences.
The simple explanation for Thanawala’s discomfort is that there are many degrees of multi-tenancy, whereas he was using the term solely in its purest sense, as implemented by Salesforce.com. Intacct’s model — espoused by many leading SaaS vendors including NetSuite — is equally valid (although not in Salesforce.com’s eyes). There are lesser-degree variations below these purist implementations. Here’s a rundown of the main differences between the Salesforce.com model, the Intacct model and Oracle’s own preferred ‘pod’ approach:
Salesforce.com: First-degree multi-tenancy. In this model, all customers are served from a single infrastructure in which every component is shared, all the way down to the tables in the database. This is often called ’shared schema’ multi-tenancy because the database structure is defined by the schema and if everyone’s data is stored inside that structure then by definition, everyone is sharing the same schema. In an ideal world, a first-degree multi-tenant architecture runs on a single logical system or instance. But in the real world, when you get to the size of Salesforce.com, not even Oracle can offer you a database that’s capable of scaling that big. So Salesforce.com replicates its architecture across (currently) five instances in North America, plus separate instances in Europe and Asia.
Intacct: Second-degree multi-tenancy. Like many SaaS pureplays, Intacct uses replication much more broadly than Salesforce.com to distribute its shared-schema instances across large numbers of server clusters. This means it can use commodity hardware rather than big-iron systems, and has less exposure to a single system failure, while still remaining true to the shared-schema model. Within each Intacct cluster, a single Oracle database instance serves a shared schema to a minimum of 10 customers. The main difference from the Salesforce.com model is one of scale: Salesforce.com operates just eight instances (for more than 43,000 customers, a ratio of 1:5000) whereas Intacct operates a hundred or so ten (for around 2,500 clients, a ratio of 1:250). But there’s another critical difference that purists see as a major dilution of the multi-tenant principle: Intacct allows customers to choose when they upgrade between releases (within a three-month time window), whereas Salesforce.com upgrades everyone simultaneously at a time of its own choosing. [UPDATE added June 18th: I have since learnt that this is wrong. Intacct upgrades all its customers at the same time, so is closer to the Salesforce.com model than I’d realized — see Why multi-tenancy matters.]
Oracle and others: Lesser-degree multi-tenancy. There are a lot of terms floating around for these lower levels of multi-tenancy, including isolated tenancy, mega-tenancy or hybrid tenancy. Many purists will be scandalized that I even continue to use the term multi-tenancy for this type of implementation. There are many variations, but the primary characteristic is the abandonment of the shared-schema principle. There’s still some element of shared-server infrastructure, but each server cluster (Oracle calls them ‘pods’) is configured somewhat differently from the next. Although this makes it easier to fine-tune each pod to different customer needs using conventional customization processes, it adds immense complexity when co-ordinating the roll-out of new software releases — as SAP recently discovered with its Business ByDesign project.
It’s not only the upgrade process that benefits from the consolidation achievable at the massive scale delivered by Salesforce.com’s top-degree multi-tenancy model. It makes it far less complex to monitor application performance and thus to hone aspects such as security, availability, response times and other service quality characteristics. It’s also much easier to collect aggregate data about customer behavior and to establish benchmarks for best practice. Finally, integration is simpler to shared back-end infrastructure, such as identity management systems, APIs and interfaces to third-party services. The more clusters a vendor has, and the more variation between clusters, then the more middleware and management software it will have to buy.
Perhaps that’s why Oracle likes to promote the multiple pod model — especially at lesser degrees of shared tenancy, where the management and oversight challenges expand exponentially — Oracle not only gets to sell lots of database licenses, but also lots of different technology infrastructure product licenses as well.
Purists argue that, even if in principle you’re prepared to pay the cost of managing multiple implementations, there comes a point at which there are so many variables it’s simply not technically feasible to deliver the same degree of oversight they’re achieving with large-scale shared-schema instances. In the long run that means their performance, security and reliability will just pull so far in front of their competitors that their model will triumph.
A much larger number of SaaS vendors prefer the slightly more hybrid model pursued by Intacct, either to take advantage of commodity hardware or to allow a degree of customer flexibility when implementing upgrades (which is more of an issue for transactional applications like financials than it is for data management applications such as salesforce automation). [UPDATE: for more on this, see the follow-up post, Why multi-tenancy matters.]
Both camps, however, agree on the principle of shared schema. Their differences of opinion are around implementation of shared-schema multi-tenancy. Any lesser form of multi-tenancy — such as, for example, having shared application servers but housing each customer’s data in separately customizable database instances — is a quite different architecture. Be warned: in the SaaS world, pretending or assuming otherwise may cause offense.
Phil Wainewright is a commentator and strategist on emerging software industry trends. See his full profile and disclosure of his industry affiliations.
| 06/17/08
