SaaS appliances, SaaS data centers, and customer-premises SaaS
Conclusions
I think that most sufficiently large enterprise SaaS vendors should offer an appliance option, as an alternative to the core multi-tenant service. In particular:
- SaaS appliances address customer fears about security, privacy, compliance, performance isolation, and lock-in.
- Some of these benefits occur even if the appliance runs in the same data centers that host the vendor’s standard multi-tenant SaaS. Most of the rest occur if the customer can choose a co-location facility in which to place the appliance.
- Whether many customers should or will use the SaaS appliance option is somewhat secondary; it’s a check-mark item. I.e., many customers and prospects will be pleased that the option at least exists.
How I reached them
Core reasons for selling or using SaaS (Software as a Service) as opposed to licensed software start:
- The SaaS vendor handles all software upgrades, and makes them promptly. In principle, this benefit could also be achieved on a dedicated system on customer premises (or at the customer’s choice of co-location facility).
- In addition, the SaaS vendor handles all the platform and operational stuff — hardware, operating system, computer room, etc. This benefit is antithetical to direct customer control.
- The SaaS vendor only has to develop for and operate on a tightly restricted platform stack that it knows very well. This benefit is also enjoyed in the case of customer-premises appliances.
Conceptually, then, customer-premises SaaS is not impossible, even though one of the standard Big Three SaaS benefits is lost. Indeed:
- Microsoft Windows and many other client software packages already offer to let their updates be automagically handled by the vendor.
- In that vein, consumer devices such as game consoles already are a kind of SaaS appliance.
- Complex devices of any kind, including computers, will see ever more in the way of “phone-home” features or optional services, often including routine maintenance and upgrades.
But from an enterprise standpoint, that’s all (relatively) simple stuff. So we’re left with a more challenging question — does customer-premises SaaS make sense in the case of enterprise applications or other server software?
Why would a customer actually want on-premises SaaS, as opposed to the standard remote version? The first ideas that come to mind are:
- Security and/or privacy considerations, real or imagined. This is in fact the motivation behind the single case of on-premises enterprise SaaS I have confirmed, namely one that Cloudant told me about.* (I don’t have similar levels of detail about Glassbeam’s one on-premises subscription customer.)
- Similarly, a less specific desire for isolation …
- … and/or control.
- Avoiding the expense of data movement to/from a remote location. For example, an enterprise might use SaaS OLTP (OnLine Transaction Processing) apps whose results it wants to stream to an on-premises data warehouse. Or the enterprise might have lower-volume but also lower-latency — and hence more costly — data integration needs, perhaps between different OLTP application suites, or with some MDM (Master Data Management) in the mix.
And, um — that’s about all I’ve got.
*Yes, I know Cloudant is DBaaS — but to me that’s a kind of SaaS, in which the S just happens to center around a DBMS.
Confusing matters further, there’s a middle option as well. salesforce.com and HP just announced that salesforce.com apps will, for the first time, run on dedicated customer-specific racks. But this will only be within the same data centers and operation groups that handle the rest of salesforce.com’s system. Notes on what’s being called a “pod” strategy start:
- This suggests a perceived demand for isolation.
- If these pods are offered to accounts large enough to saturate a bunch of servers each, they need not be much more expensive than the multi-tenant version of salesforce’s offering.
- Other than (fully-loaded) cost, it’s hard to see a downside to this vs. multi-tenant SaaS.
Notwithstanding ever-increasing levels of comfort with SaaS and cloud computing, I’d guess that a number of enterprises will find the cost of single-tenant SaaS more palatable than the queasiness they feel about multi-tenant alternatives. And so I think there’s a place for single-customer enterprise SaaS stacks somewhere; the main remaining question is where they will be located.
Ducking that question a bit longer, let me note that:
- In any scenario, we’re most likely talking about something like SaaS appliances. Customer-premises server SaaS that isn’t in some kind of appliance form is madness (unless the SaaS vendor is paid for on-site support as well), because no SaaS vendor wants to support hardware it can’t specify or control.
- Some enterprises in some countries will surely insist on keeping data within national borders, for reasons of geo-compliance. Hence there will be a need to deploy SaaS appliances either literally to their premises, or else to an in-country co-location facility, perhaps managed by a big telecom firm. Of course, that need can only arise if vendors first overcome issues of software nationalization — language, regulations, other business customs, whatever.
- The final point in my recent SaaS discussion post was about lock-in. If you use something that only runs in the supplier’s data centers, your lock-in is even worse than it is with most enterprise IT technology.
- I can’t currently think of many examples in which SaaS appliances need to be located directly in the customers’ main data centers. When you get to data flows and volumes big enough for that to matter, you’re likely talking about the kinds of internet applications that probably shouldn’t be on-premises in the first place.
And that finally brings us to the opinions I copied up top.
I think that most sufficiently large enterprise SaaS vendors should offer an appliance option, as an alternative to the core multi-tenant service. In particular:
- SaaS appliances address customer fears about security, privacy, compliance, performance isolation, and lock-in.
- Some of these benefits occur even if the appliance runs in the same data centers that host the vendor’s standard multi-tenant SaaS. Most of the rest occur if the customer can choose a co-location facility in which to place the appliance.
- Whether many customers should or will use the SaaS appliance option is somewhat secondary; it’s a check-mark item. I.e., many customers and prospects will be pleased that the option at least exists.
Related link
- Naomi Bloom is a SaaS purist, who would presumably deplore the whole concept of “customer-premises SaaS”.
Comments
6 Responses to “SaaS appliances, SaaS data centers, and customer-premises SaaS”
Leave a Reply
If you are talking appliances for enterprise software, the only way to go is software appliances based on VMWare or emerging private cloud standards like OpenStack. Add phone-home and other “appliance” features and this model is a real winner.
My own experience selling in the DBaaS market is that only a small fraction of customers is willing to pay the extra $$$ for a hardware appliance that pops into the rack rather than using their favorite commodity hardware–by small fraction I mean 1-2% of the prospects I have encountered over the last 5 years. The hardware-appliance business model has worked out poorly for vendors in the MySQL market, where most of its proponents have ended up roadkill or shifted to the cloud, like Clustrix.
Hardware appliances currently seem to make sense only at the low end (e.g., consumer or small-business devices) or the high end, such as Exadata. It would be interesting if you could come up with an example that really works for enterprise software.
[…] In theory and occasionally in practice, certain SaaS benefits, namely the outsourcing of software maintenance and updates, could be enjoyed on-premises as well. Whether I think that could be a bigger deal going forward will be explored in future posts. […]
When our company shifted from on-premise software deployment, we explored the appliance approach as it would have been easier for us (at least initially) than full-on SaaS. In our initial exploration of the idea, we found that it was actually harder to sell than SaaS itself, as customers didn’t like the idea that they wouldn’t be administrating the box, we’d need firewall tunnels and remote shell access to it, we’d broadcast upgrades to it (which seemed scarier than us doing it in our SaaS datacenter), the need for site visits to upgrade the hardware occasionally, etc.
We ultimately went full-bore SaaS with a multi-tenant datacenter, and now that we’re established that we can do SaaS, we’ve seen no reason to revisit the appliance approach. Other vendors may have different requirements where on-prem appliances make sense, but not for us, at least for now.
This is a good competitive differentiator. But this assumes that the infrastructure is reducible, that an appliance (or private cloud) provides the same quality of service, that it still can meet minimum SLAs, that the peak resource needs are predictable, and that the customer can scale to the peak. It therefore loses the cloud advantages of pay-as-you-go scaling. It restricts vendor and customer to predictable activity. It restricts the vendor from relying on geographically redundant sub-systems, or from switching to a more performant or scalable sub-system as they see fit: decisions that then may force the vendor to choose whether to split its customer base.
We need to deal with lock-in and data security. We need revised legal frameworks. But an appliance takes away too many advantages. If there’s a market among customers that cannot find their way to a public cloud, then an appliance will be competitive.
I’d be reluctant to take the level of resistance to SaaS as measures of a market for appliances. While there are reasons (control, security, regulation, etc) not to move to SaaS, they are not all good reasons. And for the good reasons, an appliance is a significant compromise.
So some companies truly can’t take advantage of a SaaS model. If it’s a worthwhile competitive move to support an appliance, then an upstart SaaS vendor can leverage this niche. Until that happens and a large SaaS vendor is threatened, I say it’s not worth the effort, risk, complexity or the compromise to large established SaaS vendors.
Google’s Enterprise Search Appliance option looks like a proof case. http://en.wikipedia.org/wiki/Google_Search_Appliance
SAP HANA appliance option looks more like a hobby.
http://help.sap.com/hana_appliance