In several recent posts I have argued about the importance of cloud-based platforms, and Michael Feldstein has written some insightful analysis on the subject. Quite often the terms Cloud and SaaS (software as a service) are misunderstood, or at least used differently as the terms get redefined, which is common in technology markets.
Last week I wrote a post that included a comment about Desire2Learn and their usage of cloud and SaaS terms.
The terms cloud and SaaS, as used in Desire2Learn’s and NEA’s descriptions, tend to blur the distinction between Desire2Learn’s enterprise software virtualization model and multi-tenant platform models. Desire2Learn has made great strides in developing a virtualized cloud hosting model that is not multi-tenant (where all or most clients run on the same defined application instance on the same version). There are arguments that this issue only matters to the provider. I’ll write more on this subject in a subsequent post, but for now I’ll just point out that the cloud model used by Desire2Learn has significant differences with the model used by Instructure’s Canvas LMS, Pearson’s OpenClass, Lore’s platform, and the majority of new learning platforms coming out.
John Baker, CEO of Desire2Learn, did not agree with this statement as shared in the comments.
One key correction is that our Cloud or Software-as-a-Service (SaaS) solutions are multi-tenant. Multi-tenancy has been part of our solution for over a decade. It may also be important to point out that approximately 90 percent of our clients use our SaaS offering. We’d be happy to share more infromation with you and others on how we have evolved over the years.
For the record, I would like to be more precise in my usage of these terms. I realize that the definitions are somewhat slippery, so at the very least, I owe it to readers to explain my argument.
Multitenancy is the concept where multiple customers run off of one live instance of software, such that the software application and database design handles the separation of customer data and functionality. There are varying degrees of multitenancy, but the common theme is that there is one software code version and each software instance supports multiple customers. Due to sheer scaling of core technology, there might be more than one instance – e.g. Salesforce.com runs roughly three dozen worldwide instances, but each instance is fully multi-tenant.
With this model the multiple tenants share a software instance, which means that they run the same software version.
Virtualization is the concept in which a computing environment (database, operating system, application) is abstracted into a virtual machine that can be allocated to share the same physical servers with other virtual machines or even shared across multiple physical servers. The software application must allow virtualization, but it is not aware of nor does it manage the multiple customers and runs as a single tenant on its own virtual instance.
With this model each customer – the single tenant – has its own software instance, allowing for different versions and configurations.
When I talk about cloud-based platforms, I am specifically referring to platforms that are both SaaS (automatically provisioned, available as an as-needed subscription) and multi-tenant. Virtualization is a fine strategy for scaling and managing enterprise applications, but it is not the same thing as multi-tenancy.
To verify my understanding of Desire2Learn architecture, I contacted several customers of Desire2Learn’s SaaS offerings. Each one told me the same story, that they control when and if they should take an upgraded version of the Desire2Learn software on their own specific instance. In fact, I found examples using v9.1, 9.2, 9.4 and 10.0 – all at the customer’s discretion. A multi-tenant architecture (at least using the definition I use, which excludes virtualization as the method of scaling) would not allow each customer to choose their own version. Customers run the application together, and application upgrades roll out to everyone, automatically (there are methods for the customer to control when to enable new features).
The best source of discussion on cloud and SaaS concepts, in my opinion, is Phil Wainewright’s blog at ZDNet. He addresses the question of why this distinction between multi-tenancy and virtualization matters to customers. Both methods can lead to scale, and in a theoretical sense it should not matter. But in reality it matters in terms of evaluating software providers, as described in his recent post:
Ultimately, you shouldn’t have to ask about multi-tenancy when evaluating a cloud application or service because it will just be there in the infrastructure. But until we reach that level of cloud maturity, buyers of enterprise applications must be ready to evaluate the multi-tenant credentials of vendors as part of their due diligence. If a cloud application provider has single-tenant components in its infrastructure as a hangover from a previous architecture, it’s likely that choice has been made because of its history, rather than after a full evaluation of the economic, performance and change management implications for the cloud service. What really matters is whether the cloud provider offers economical operation, rapid innovation and competitive operational performance. Providers will be judged on their track record. Until they’ve established that track record, it’s a case of caveat emptor; buyers must make their own judgement.
I’ll leave out for now any discussion on the benefits of either approach. It is important, however, to understand and be clear on the distinction.