Are Appliances SaaS?
Posted by Bob Warfield on October 13, 2007
I’ve been cogitating on this one since I read a SaaSWeek post on the subject.
Ben Kepes and the UnreasonableMen have held forth on the subject. Ben says SaaS has to be in the clouds and the UnreasonableMen say it does not. This all hinges on the question of whether an appliance that can be remotely managed by it’s vendor to include all updates and admin chores provides all the benefits of SaaS or whether there is something about having the machine be in the cloud that “real” SaaS requires.
I’m in the camp that appliances are not SaaS, but I do view them as better than “regular” on-premises software. What do they lack vis a vis “real” SaaS? Here is my list:
Appliances Need Maintenance of Some Kind
What if a hard disk or power supply goes bad in the appliance? Fixing it is going to be more painful than a SaaS vendors hot failover where you should not even have to know it ever happened. Granted, dealing with these things is a (hopefully) rare occurence, but it is nevertheless something to keep in mind.
You have to find a spot in your datacenter for the box, and feed it electricity and cooling. Again, this may be a small enough thing, but it is overhead you don’t deal with on a true SaaS vendor.
This is a small collection of tasks that your IT group has to take on with appliances that they wouldn’t deal with if the computing were in the cloud.
At the SaaS vendor’s end, it’s more expensive for them to maintain a bunch of remote appliances too. They have to either buy hardware, or ensure that if you use your own hardware it gets properly configured. Configuring and shipping out boxes is painful, and talking your IT staff through installation on your own box is painful.
Lastly, if a fault develops in the appliance software that makes it impossible to remotely debug, you’re dead in the water. If it’s in the SaaS vendor’s data center, they can always get inside the guts to fix things. Such faults can happen. Imagine the consequences of accidentally sending out a patch that renders all the appliances that download the patch deaf to further patches. That would be an expensive mistake for all concerned!
Economies of Scale Don’t Exist for Appliances, So They’re More Expensive
SaaS vendors use multitenancy to amortize multiple customers into their hardware. There is cost savings in this that is impossible to capture for an appliance. In addition, SaaS infrastructure has an easier time arranging bulk multi-location backups and the like. We talked about failover above. If you start shipping backups from the appliance to some SaaS cloud datacenter, why bother with the appliance in the first place?
When Might an Appliance Make Sense?
Given these disadvantages which equate to more cost and trouble, one wonders whether there are advantages to the appliance that offset the disadvantages, at least for certain applications. I see two advantages, one perceived and one real.
First, some customers may simply be more comfortable having the data and application inside the firewall. This is a perception issue that has changed tremendously in recent years and will continue to be less and less an issue as the SaaS world matures and customers get more experience with it.
Second, there may be real technical reasons why the application works a lot better inside the firewall. I can envision security and high bandwidth LAN connection to other systems as being examples of this. There may be regulatory issues for certain kinds of applications that require the data stay put.
Conclusion
SaaS is a slippery subject. It means many things to many people. Rather than argue there is only one definition of “real” SaaS, or that SaaS is associated with some technology such as multitenant, it probably makes more sense to recognize that SaaS is a continuum of service levels. I happen to think that placing the software in the cloud is the least requirement to have before you can call the offering “SaaS”, hence my feeling that appliances don’t qualify. I’ve pointed out some of the advantages that accrue to any cloud-based offering. In a later post, I will discuss what some of the other levels might be to move you on to “better” SaaS. I also want to take a look at where the current crop of SaaS apps can do even more.
5 Responses to “Are Appliances SaaS?”
You must log in to post a comment.
sbobrowski said
Bob,
Although you don’t explicitly state so in your post, you are addressing several valid points that are applicable to hardware appliances, which I agree with wholeheartedly. However, the link in your post a SaaSWeek post leads me back to an article about virtual appliances. In the case of virtual appliances, there are replies to every one of your arguments against appliances.
“What if a hard disk …” : A virtual hosting platform with pooled resources and high availability options (e.g., VMware Infrastructure 3, VMware HA, VMotion) provides for automatic failover. No clustering or manual configuration required. It’s simple.
“You have to find a spot in your datacenter for the box …” : Not if you already have a virtualized data center – you just load the VA on and existing infrastructure and start using it. Major IT analyst data shows that more and more companies have already or are planning to commit to x86 virtualization platforms.
“At the SaaS vendor’s end, it’s more expensive for them to maintain a bunch of remote appliances too …” : No configuration or very little configuration is necessary with well-designed virtual appliances. Check out how easy it is to get MediaWiki up and running on Amazon’s EC2 with the rPath/MediaWiki. Same for things like SugarCRM, BEA Weblogic, and others.
“Lastly, if a fault develops in the appliance …” : Users actually have a great degree of control for the patch/upgrade process with leading-edge products like rPath. For example, users can snapshot their production virtual appliance, automatically apply the patch from the rPath repository to the test appliance, test for a while, and then apply the patch to their production appliance when they are sure the patch doesn’t break anything. This is very unlike traditional SaaS, where you are forced to upgrade with everyone else, according to the vendor’s schedule. What if a mission-critical data integration plug-in fails after a SaaS version release happens? My data integration process is now “dead in the water” until someone comes up with a fix.
“Economies of Scale Don’t Exist for Appliances …” : Some vendors appear to be discovering that a virtualization approach is an economical way to offer SaaS without the time-consuming and complex need to (re-)architect for multi-tenancy. While I do believe that multi-tenancy is the correct choice for some types of applications, it’s certainly not the correct choice for all types of applications.
So, while I agree with you that hardware appliances are an inefficient way of providing SaaS behind the firewall, virtual appliances are different altogether. Like SaaS, virtual appliances are a great way for enterprises to free themselves from the cost and complexity of traditional on-premises solutions. But unlike SaaS, virtual appliances allow enterprise customers the ability to retain control of their processes and data behind their firewall.
sbobrowski said
Sorry, I forgot to href “While I do believe that multi-tenancy” in the end of my previous post to http://saasplay.blogspot.com/2007_10_01_archive.html. Thanks.
smoothspan said
Steve, welcome. I assume you’re CSC’s CTO for SaaS?
Despite all the benefits of virtualization, the folks I talk to (including some SaaS vendors who rely on virtualization in lieu of multitenancy) don’t paint quite so rosey a picture. The scenario you describe around the hard disk addresses the failover, but that’s just a short term stop gap. Somebody still has to work in data center ops and replace the disk. Moreover, that’s just one of hundreds of tasks oriented around maintaining the hardware, network infrastructure, and (where most of the cost lies) the application. If it’s in the customer’s data center, those costs and pain will bear on the customer. However familiar they may be with the hardware, which is a commodity, they won’t be familiar with the software for a long time. It all has particular idiosyncracies that the SaaS vendor can afford to be much more on top of.
When you say multi-tenancy is not the correct choice for all applications, I would be curious to see where you think it falls down. The best examples I’ve seen so far are for non-SaaS vendors to use virtualization in lieu of multitenancy during transtion so they can get up and running quicker. A much less satisfactory example would involve customization, and problems supporting it such as I wrote about recently for Workstream. In either case, it would be hard for me to say that multitenancy wasn’t best, only that for the short-term, it wasn’t feasible.
I’ll stand by my critique of the virtual appliances. Whatever you choose to call what you put inside the customer’s data center, it involves cost and pain that SaaS is designed to eliminate.
Cheers,
BW
sbobrowski said
Bob,
Yes, I am CTO of CSC’s SaaS Business unit. And thanks for the good discussion here.
I certainly agree with you that there continue to be pain points for those folks that go with what I refer to as “on-premises lite,” or virtual appliances within the corporate data center versus traditional SaaS (completely outsourced services). Enterprise and high-end mid-market folks, especially in industries like banking, health services, etc., don’t seem to mind a little pain to retain control of important processes and data behind their firewall. At the same time, virtual appliances allow them to enjoy simplified software deployment and maintenance similar to traditional SaaS. What’s more, it’s trivial for the customer to migrate a virtual appliance between outsourced and in-house hosting, or from one hosting provider to another – in other words, no hosting lock-in required. If you wanted to, you couldn’t do that with Salesforce.com’s CRM business model. (You could with SugarCRM because of their architecture and product offerings.)
This freedom of choice that can be offered to the customer is something, I believe, that makes the virtual appliance model attractive to software vendors specifically targeting SaaS consumption by the enterprise.
1. Build a virtual appliance from single-tenant application.
2. Provision virtual appliances (from clones) on-demand when customers want to “try before they buy”, just like with traditional SaaS.
3. When a customer likes the service and wants to continue using it for a fee:
a. For customers that don’t mind having the appliance hosted, it stays put off-site.
b. For customers that prefer having the appliance behind their firewall, they simply download their appliance and plug it in to their hosting infrastructure.
4. In either case, the vendor that delivers the appliance provides automated mechanisms that each customer uses to maintain (patches, upgrades) their appliances autonomously.
Let me focus again on item 4 above. As I pointed out in my previous comment, patches and upgrades to the appliance (on-demand or on-premises lite) are applied at the discretion of the customer once it’s confirmed that no problems arise. This is very different than with traditional SaaS, a point which I think you forgot to answer to in my previous comment.
For everyone’s information, here’s an oldie but goodie that provides a lot of background on issues surrounding SaaS. It backs up many points I’m trying to make — as well as many of Bob’s — see, I’m fair-minded. 🙂
In your previous reply, you asked “When you say multi-tenancy is not the correct choice for all applications, I would be curious to see where you think it falls down.” Here are a just couple of good blog posts (disclosure: one is at my blog). If you want more, just Google “SaaS multi-tenancy”.
– Multi-tenancy Myths
– The Multi-Tenancy Myth Exposed
And some noted analysts like Dave Linthicum recently seem to agree with my viewpoints.
– Virtual Appliances: A Worthy SaaS Alternative
But back to the question in the original title of your post – “Are Appliances SaaS?” Simple answer: it depends. “Yes,” if they are hosted on-demand, outside the customer’s firewall. “No,” if they are hosted on-premises for those customers that explicitly want the advantages of retaining certain levels of control.
Interesting times in the software industry — now that’s something that I think we all can agree on!
— Steve
smoothspan said
Steve, a couple of thoughts:
– Regarding the customer’s desire to maintain control over patches (your point 4), I’ve lived both sides of that coin. What I’ve concluded is that it is a false economy and a false sense of security for customers to be in control of the patching. It’s a long discussion I won’t bring out here, but I will touch on two salient points. First, I have surveyed a number of Enterprise Tech Support groups with a simple question:
How many product problems being reported in your ticketing system were fixed in the latest release available at the time of report?
The answers ranged from 40-70%. What that means is customers could have avoided 40-70% of problems entirely with a good SaaS vendor rather than having to scramble after the problem is discovered and likely during some critical time when the system is under stress and therefore exposes the issue.
Second, countless customers talk themselves into not taking patches one patch at a time, only to wake up years later and wonder why they’re now running on an unsupported release and why it is going to be so costly to upgrade. They’re unhappy, and they blame the vendor, but they also have themselves to blame. SaaS avoids this entirely and keeps things incremental, because they have to be. A SaaS vendor can’t launch a hugely incompatible version the way many conventional vendors do because it is the SaaS vendor responsible for the upgrade. Funny how that changes the perspective.
– I read your Multi-tenancy Myths post. The other link goes nowhere and can’t be found on Google. Amazing how few listings there are that combine “multi-tenancy” and “myth”, perhaps that tells us something right there. On reading your post, I personally had a hard time attributing the specific problems you had with your implementations of multi-tenancy with multi-tenancy in general. MT is not a particular architecture as your article seems to prescribe. Rather, it is more properly a set of benefits to the SaaS vendor and the tenants. There are many ways to deliver those benefits, but I have frequently seen multi-tenancy dragged down into some specific implementation detail such as your partitioning and load balancing examples. This is confusing enough that I think I will write a post addressing it directly rather than responding here.
Cheers,
BW