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 servers for business 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.
Well I hate to confuse things even further, but I would argue the description of cloud-based platforms as “both SaaS (automatically provisioned, available as an as-needed subscription) and multi-tenant” actually muddies the waters further.
First, please look at the June 24, 2010 EDUCAUSE Quarterly article “Cloud Computing Explained” by Rosalyn Metz. This is simply the best explanation (with examples) of “the cloud” I have seen. Ms. Metz references The National Institutes of Standards and Technology (NIST) definition for the cloud, “…a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.” She then provides examples of each of these “five essential characteristics, three service models, and four deployment models”–please take a look.
The cloud is a resource strategy for addressing limitations in local data centers, “I don’t want to buy a bunch of server and networking hardware, ah, I’ll use cloud resources.” Software as a service is a hosting strategy for addressing local staffing, infrastructure, resource constraints, “I don’t have the staff with the experience to host the software, and I don’t want to pay for it, ah, I’ll use a service provider.” Multi-tenancy is an architectural strategy to reduce local support, administrative and maintenance requirements, “I don’t want to run 25 instances of the software, ah, I’ll implement a multi-tenant solution.”
I’ve seen press releases where software companies serving institutions of higher education, tout their “cloud services.” However, while they very well may provide remote hosting for campuses using cloud services like EC2 to serve up their software, they do not allow the campuses they support to spin up new virtual server environments to run whatever applications they may want.
At UMassOnline we use several strategies to address various resource constraints that align with the “essential characteristics,” “service models” and “deployment models” in the EDUCAUSE Quarterly article:
a multi-tenant LMS allowing us to serve 15 domains through one instance. This reduces administrative overhead in patching and upgrading by only having to manage one installation;
virtualization to provision server capacity and resources on-demand for that LMS. This allows us to better resource needs to capacity, while also reducing risk (redundancy, fail-over, headroom etc.);
software as a service for “commodity services” like email, document management, help disk ticketing, transaction monitoring, so we don’t have to bother with it ourselves, and;
the cloud to deploy various server environments to assess, develop and scale pre-production applications.
To cite Ms. Metz again, “The more informed IT departments are about the cloud, the better the position they will be in when making decisions about deploying, developing, and maintaining systems…” Each approach has value, but I begin to cringe when I hear about, “vertualized-multi-tenent-cloud-based-software-as-a-service.” The only thing better, I guess, would be to make is “open” and “green.”
Patrick
Patrick, thanks for the link and comments. I had not seen that article, but it is very useful, and I certainly agree with the need for informed IT departments. I would also argue that non-IT departments actually need to understand distinctions, as the different models affect more than just IT support (e.g. how often features come out, ability to lock down a system, business model and ability for partner to scale).
Given the 5 characteristics mentioned, I’m not sure where the usage of SaaS and multi-tenancy “muddies the water further”. It seems to me that her characteristics of “On-Demand Self-Service” and “Resource Pooling” would also fit this inclusion of SaaS and multi-tenancy. I realize there are other forms (e.g. IaaS and PaaS), but the discussion here is about applications. Perhaps I should describe this as “cloud-based applications are both SaaS and multi-tenant”?
The item that is missing in the article (and NIST?), in my opinion, is the scale and connections that occur in the marketplace. In other words, how does the cloud change the possibilities of software providers to produce and deliver new applications and features. Cloud is not just about how to host and access a stable set of applications, it is also about how applications change / upgrade over time and how efficiently new applications can be developed.
phil,
the market appreciates your analysis. cloudwashing is quite common nowadays. It’s easy to confuse the old ASP (application service provider) model from 10 years ago, with cloud applications – but the sure fire way to tell is if it has a software version.
Gmail, Facebook, Salesforce – all of these are true cloud applications, and note that none of them have a software version number! if software has a version associated with it, and it’s hosted (even if it’s hosted on AWS) then it’s simply an ASP model in disguise. they still have to deal with version specific security patches, upgrades, bugs, new version migration and obsolescence. that’s the old way to do it, and it’s a mess – no wonder so many vendors are trying their hand at revisionist history and cloudwashing their software.
Thanks for comments, both to previous post and this one. Based on a Twitter conversation as well as involvement of vendors in the comments, I want to be clear on one point. I am not endorsing any one model (and therefore any vendor). I am attempting to clarify language, at least mine, and call out a distinction between different methods to achieve scale with a SaaS solution.
I’ll also add the point that institutional vendor selection should start from specific institutional needs, and then evaluate which vendor has the best solution for their needs. One of the points, along with many others, to evaluate is the match between the vendor’s hosting model (and therefore a projection of its future upgrades and support) and the longer-term needs of the institution.
Retweeted on DS >> https://twitter.com/Database_Scene
Thank you Phil
I guess this is where we disagree. Cloud, is, just about hosting and not about application development, architecture or features/functionality.
I’ve been an advocate for “versionlessness” (see Michael’s e-literate post from 2005), or service oriented, applications for a long time. Indeed while at SUNY, again as Michael puts it (boy he’s been riding my coat tails for a long time), “Our goal was to use technologies like web services to swap out the legacy system one piece at a time.” [BTW, the link to Christina Smart’s JISC article referenced in his post is broken. It should be: http://elearning.ac.uk/features/masson.html]
The concept here was much like what Pearson’s OpenClass is working toward today, integration and interoperability with various niche tools and technologies (e.g. Google Apps for Education, which did not exist at the time) as well as content, from internally or externally developed and managed services. But while all of these services would be scalable (both in size–the number of users–and scope–the number of integrations) and remotely served, allowing more connections though the marketplace than could ever be delivered by one organization (open source community or commercial developer), how the “computing resources (e.g., networks, servers, storage, [administrative] applications, and services)” themselves were to be delivered was insignificant to us as developers/architects and transparent to the end-users.
I agree wholeheartedly with the concept of a loosely-coupled framework for aggregating, disparate, best in class and/or niche tools, that can be provisioned and managed on demand by individual users, but such an application itself would not be–by definition–a cloud-based service and would not technically or specifically even require cloud computing.
Looking at this from the other way around (i.e. is any application delivered through cloud computing a cloud service?), just because an application in served up from a cloud computing service provider (e.g. Amazon EC2 offing “on-demand network access to a shared pool of configurable computing resources”), I fail to see how that makes the application itself a cloud service. I believe Instructure develops(?) and delivers Canvas through Amazon EC2. But just because a campus is a customer of Instructure using Canvas, they could not spin up a new LAMP or WIMPy environment on EC2. So while Instructure’s value proposition for campuses assessing their services may include overall savings from reduced hosting costs realized through EC2, Canvas is not a cloud service (it uses cloud services), and I would fail to see how Canvas, as an application provides better features because it is hosted by Amazon (please, this is not a statement on the quality of features or functionality in Canvas versus any other LMS, my point is that the hosting environment plays no role in what tool set–features and functionality–are possible or not.)
Even examples like Bluehost and Hostmonster, where I can deploy a variety of applications (WordPress, WikiSpaces, etc.), should not be considered cloud services,nor should the applications they offer. I do not know if they are hosted on cloud services like Amazon, but even if they are, I do not see how these applications become cloud services simply because they are hosted “in the cloud.” If I installed Moodle on EC2 versus. in my data center or on my laptop, would that elevate Moodle to a cloud service? If I started a company, and offered Moodle on demand (Moodleroom, RemoteLearner, Unicon, etc.) through a internally hosted data center, would that make Moodle a cloud service?
If one wants to include efficiencies in acquiring and provisioning development and hosting resources as part of the software development and deployment lifecycle, I’d offer that is a bit of a stretch (cloudwashing?). I’m sure even the normally adversarial camps of system admins and software architects would agree on that point.
Thanks,
Patrick “exact words Greg Brady” Masson
Phil,
You’re a bold man for tackling this one. I recently completed a lengthy selection process, and we’re now moving into implementation. It was tricky negotiating the language around this with my stakeholders. While I tried to focus on our needs and platform functionality, there was definitely an ongoing tension around the, ‘cloud.’ There were some who felt our legal team would never approve a true cloud platform. I provided our executives and external counsel with a lot of resources, including the EDUCAUSE NACUA sample contract.
In our case, we’ve got outsourced IT on site, and a locally hosted ANGEL instance. However, I knew local hosting for the ANGEL replacement was not a sustainable strategy. Most vendors presented multiple hosting options. It was extremely difficult to evaluate the hosting strategy that would work best. Hosting was definitely a lower priority than usability. However, faculty were definitely seduced by promises of automated provisioning, no down time for upgrades or maintenance, and the perceived security of the Amazon brand.
If I had to do the process all over again, I think the only way to develop a true understanding of how the architecture impacts institutional needs, would be to fully load a system with a year of content, and run a full-scale quarter-long pilot. What I’m seeing in industry now, is that sandbox testing bears little relation to how a system functions with a full load of courses and users. I’d like to think relevant data could be collected from client reference checks, but ours were inconsistent for all vendors.
Thank you for tackling the big questions, and helping us learn more about the things we should consider. I appreciate your thorough attention to an industry that’s growing more and more complex.
Jen
Greg (Brady), thanks for the comments and clear examples.
To be clear, I have never intended to imply that just because a software application uses cloud services, the application itself is a cloud application. I will be more careful in future posts avoid this assumption, because that is not my point.
My argument in this post is that the application should be both SaaS and multi-tenant in some reasonable form. By definition the application would be served remotely, but the application itself might or might not be SaaS or multi-tenant. One could write an application that spun up a new single-tenant instance on EC2 for each customer, and allow unique versions to proliferate. Long story short – I think we agree more than you realize.
I assume we both would consider Salesforce.com a cloud-based application, and agree that it was SaaS and multi-tenant. I argue that the architecture and software development that leads to the Salesforce.com application and business model does matter, in my mind. It goes beyond just hosting.
Your comment helps me understand that there are two parts of my argument – 1) it does matter whether the end-user application is based on cloud services such as Amazon Web Services or Microsoft Azure of Google App Engine, etc, and 2) it does matter whether the end-user application itself is SaaS and multi-tenant. As you mention, in case 1) one impact is whether the application benefits from the scaling model of cloud services, but there are other impacts – the elastic, on-demand scaling, the automatic provisioning possible, etc. In case 2) the software architecture itself of the application, and the software development tied to that development, matters a great deal.
Keep in mind that I’m not arguing that everything should be SaaS and multi-tenant. I would like to see more clarity of terms used, and I do think the potential and attributes of cloud computing go well beyond hosting models.
Jen, thanks for the note and case study. I think you raise a very good point about the need for translation between cloud (and other technical) claims and institutional needs. I would hope that the ed tech industry will develop better methods to help institutions understand the impact on their needs, without having to resort to a full pilot.
What I do like about the pilot idea is that it would shift much of the effort in vendor evaluation away from (mostly) fruitless proposal reading and into actual evaluation of software functionality and performance. Despite the back-and-forth comments between myself and Mr. Brady, I really like the framework Patrick has used at UMassOnline to shift the emphasis from procurement regulations to actual evaluation of applications. It’s well worth checking out.
Little did I know that Gartner must have been reading this post and the comments :}
Like Patrick aludes, Gartner also builds off of NIST as the basis for understanding cloud computing (and I’m becoming a convert). Gartner also adds 5 myths re. cloud (mostly around private cloud): http://m.networkworld.com/news/2012/091312-gartner-cloud-262433.html?page=1
– Cloud is not just virtualization
– Cloud is not just a money saver
– Private cloud is not always on-premise
– Private cloud isn’t just in the infrastructure layer
– It may not always be private