Monday, February 20, 2012
In an SAP-sponsored post on ZDnet, SAP employee Eric Lai attempts to identify "four big problems" with multitenancy in cloud applications. As I am writing a soon-to-be published research report on cloud ERP, I was interested to hear Eric's take on the subject.
By way of definition, in a software-as-a-service application, the term multitenancy refers to an application architecture where a single instance of the system's application code and database serves multiple customers.
Please read Lai's entire post, as, in the interest of space, I will not quote from it extensively.
Lai gets off to a good start:
Anyone can see how much more efficient [multitenancy] is versus the old server hosting model, where the ratio of server:customer is 1:1. Even using today’s Red Hat-type virtualization, each server can cram fewer users/customers onto itself than a true multitenant service.No argument there. But then he quickly goes downhill. He first draws a distinction between consumers and enterprise customers, which have "much more rigorous requirements." He then presents his four objections to multitenancy.
Besides their efficiency, multitenant services can scale easily. Both of these mean lower costs for the hosters/software vendors, and, potentially, lower prices for customers.
1. "It's Inflexible."Here, Lai doesn't really make a flexibility argument as much as a security and privacy argument. He points to privacy laws in some European regions that require data in some circumstances to be stored locally. But this is not an argument against multitenancy--it's an argument in favor of local data centers. A single-tenant system provider will need to build local data centers in the regions it serves, just as a multitenant provider will need to do so.
He then argues that multitenant systems might allow competitors on the same system to see each other's confidential information. I agree that IP theft is an increasing problem, especially with organized gangs of cyber-criminals in Eastern Europe and Asia, who in some cases may have the endorsement of their governments. (See, for example, this report.) But I do not know of a single cases where one tenant on a multitenant system was able to access the data of another customer on the same system. Tellingly, Lai provides not a single reference of such a confidentiality breach.
2. "It's Less Secure."He now makes the security argument again, from a different angle. Here he argues that a multitenant database gives a careless database administrator, or a malicious hacker, the opportunity to compromise, with one breach, the data of multiple customers rather than just a single customer. He overlooks the fact that if a DBA is careless with one database, he or she would probably be careless with multiple databases. Likewise, if a criminal is able to gain access to a single customer's database in a secured data center, he or she will probably be able to gain access to many or all of the customer databases in the same data center.
3. "It's Less Powerful."Here the argument is that the capabilities of the platform-as-a-service providers do not match the capabilities of traditional database tools. He points to Salesforce.com's database.com, Google App Engine, and Windows Azure as examples. Here, I find Lai's argument similar to that of Larry Ellison, head of SAP's arch-rival, Oracle.
In response I would point to the testimony of the head of development of one new enterprise SaaS provider. This individual came from a traditional enterprise software development and has now built sophisticated enterprise applications on both NetSuite's platform and on Force.com. He told me recently, "Frank, you wouldn't believe how easy it is to develop on these platforms. Things that used to take us months [at vendor X], we can now do in weeks or days."
Although I am no longer into software development, I am willing to stipulate that the newer cloud platform-as-a-service (PaaS) environments do not have all of the features and functions of traditional on-premise application development environments. (So also, in the old days we couldn't do as much with third-generation procedural languages, such as COBOL, as we could in assembler language. And, we couldn't do as much in 4GLs as we could in third generation.) But a PaaS removes an enormous amount of development work, by abstracting database, middleware, and user-interface functions, allowing the developer to focus on business logic. Furthermore, if (as I believe) PaaS is a disruptive technology, we should expect its capabilities to improve over time, and increasingly able to take on jobs that formerly could only be done by traditional tools.
4. "It May Be More Costly."Here he doesn't mean the cost to the customer, but the cost to the ISV who wants to move from a traditional on-premises software product to a cloud offering. He is arguing, in essence, that it is cheaper for the vendor to simply host his traditional product as a single-tenant offering (i.e. changing nothing) than to rewrite it as a true multi-tenant SaaS offering.
As an advocate for enterprise IT buyers, I have to ask, will that hosted offering will be less costly for customers? Lai doesn't say. But in his introductory paragraphs (quoted earlier), he indicates that multitenancy offers "lower costs for the hosters/software vendors, and, potentially, lower prices for customers." So he has contradicted himself in his own post.
A Puzzling PositionFinally, what I find strange about this SAP-sponsored blog post is that it seems to contradict SAP's own position relative to Business ByDesign (ByD).
ByD is a full multi-tenant ERP offering for SMBs. It is a well-known fact that SAP's first attempt at ByD employed a single-tenant architecture, similar to that proposed by Lai in his blog post. That iteration was not successful in that, according to SAP spokespeople, they could not get that approach to scale cost-effectively. So, SAP took an extra two years or so and rewrote ByD as a completely multi-tenant application. The system is rolling out in multiple geographies worldwide, in local data centers where required, presumably with security and privacy measures commensurate with SAP's high standards for customers. The system is cost-competitive with other SaaS ERP offerings and has grown quickly to over 1,000 customers at the end of 2011.
SAP now has such confidence in its ByD platform that it has made it the platform for developing its line-of-business applications, such as Sales OnDemand and Travel OnDemand, for its large enterprise customers--presumably the ones with the most demanding security and privacy requirements.
Now, at the top of the post, ZDnet does make the disclaimer, "Eric's views are his alone and do not necessarily represent those of SAP." Still, as I mentioned, I find it puzzling that Lai's views appear to be closer to Larry Ellison's than those of his employer.
I am waiting for SAP's rebuttal to its own sponsored post.
Update: Eric Lai responds in the comments below.
Update, Feb.23: Please read the more detailed response on SDN by Sybase's Eric Farrar.
Related PostsCutting Through the Fog of Cloud Computing Definitions
SAP in Transition on Mobile, Cloud, and In-Memory Computingby Frank Scavo, 2/20/2012 08:43:00 AM | permalink | e-mail this!
Reader Comments:Hi Frank - agreed, Eric's post does portray a muddled view of multitenancy. A company called Kinetic Data has done some interesting work in this area, presenting services in a way that doesn't require code changes in the underlying enterprise platform (SAP, Oracle, whatever). Here's a relevant link if you're interested: http://kineticdata.com/Markets/ServiceProviders.html
Hi Frank - I do appreciate your taking the time to read and respond to my post, as I enjoy an honest debate.
First of all, I do indeed think multitenancy is a great thing for cloud applications, both for the vendor (due to increased efficiency) and for enterprise IT (due to resulting lower prices).
My critique of multi-tenancy was aimed purely at cloud data platforms and platforms-as-a-service (PaaS). And not just any cloud-based platforms, but ones that sacrifice features and/or customization in favor of one-size-fits-all scale.
My understanding is that is the case today with the biggest names in the PaaS space. But I'd love to hear about ones that are exceptions to the rule.
Also, this blog was aimed at enterprise ISVs and in-house enterprise developers, who are wrestling whether to move from on-prem or single-hosted platforms.
For them, I truly believe that many multitenant cloud platforms today lack the flexibility to account for their security/regulatory requirements. Or that the benefits of a new platform don't justify the cost of porting an app.
Apologies if my imprecise language caused any conflation/confusion. This was not meant to be an inadvertant criticism of SAP's own products like ByD or Successfactors.
Would welcome comments from any and all, esp. the SAP mentors like Messr Reed and/or Messr Howlett.
Glad to see that Eric responded. The concept of multi-tenancy is a black and white definition. You either have it or not. In this case, SAP needs to deliver it.
Now here's an interesting fact, when I go back to my old architecture friends, it appears that core R/3 was architected for MT. It supported about 100+ tenancies. Not sure who's idea it was to take it out in the future versions but that person must be kicking themselves by now!!!
It's good of Eric to take the time to respond to Frank's spot-on analysis. But really this is such a tiresome debate.
It seems from Eric's comment that his criticism of multi-tenancy is that it's not identical to conventional on-premise architectures: "My critique of multi-tenancy was aimed purely at ... cloud-based platforms ... that sacrifice features and/or customization in favor of one-size-fits-all scale."
Correct, cloud trades custom features for scale, because it enables an economy of operation and rapidity of feature refresh that more than makes up for having to do one or two things a little differently. If you don't understand this, then you really shouldn't waste your time drafting a critique.
If there's a custom feature that you simply can't afford to miss out on, then shop around and if you can't find it in the market today, wait a few months until a suitable provider adds it in their next feature refresh. Don't use the lack of that feature as a straw man you can knock down to self-justify your set prejudice against the multi-tenant model.
If you're an ISV, make a careful analysis whether you should build your own multi-tenant platform or use someone else's. But only choose to remain single-tenant if you plan to retire sometime in the next five years.
Eric, thank you for the response. I do see now that you are talking about PaaS rather than SaaS.
However, now you have gone from simply being wrong to being incoherent.
Your position appears to be that "multitenancy is a great thing for cloud applications" (e.g. SAP's Business ByDesign), but not for "cloud data platforms and platforms-as-a-service." This makes no sense for the following reasons.
1. The benefits of multitenancy for SaaS (which you list as "increased efficiency" and "lower prices") must be the same as for PaaS.
2. It is hard to imagine why a software developer would want to build a multitenant SaaS application (which you say is a "great thing"), but do it using a single-tenant development environment. It might be because no commercially available PaaS has the ISV's desired feature set. But that points to the immaturity of the PaaS market, not to an inherent disadvantage of multitenancy.
3. Finally, the advantages of MT PaaS are seen in the thousands of applications written on platforms such as Force.com and NetSuite's Suitecloud. As my developer friend said, "These platforms are a dream." This, coming from a developer with decades of experience as a traditional ISV.
Do the cloud platforms require a rewrite for a traditional on-premises ISV? Of course. Should every ISV invest the time and effort to do such a rewrite? Of course not. It all depends on the business case for the ISV. As Phil writes above, if you are thinking to retire in the short term, maybe not.
But to turn that business decision into a general argument against cloud platforms simply makes no sense.
Good of you to engage here.
I've been struggling with your blog post a bit for a couple of reasons.
One is how you framed the discussion. Another is the fact that you work for SAP so readers are inclined to assume that your views on this topic do tie into SAP's own.
On the second point, the shame of it is that SAP has done a better job than they are given credit for in terms of committing to multi-tenant archictures. This actually gives them a nice talking point against Oracle. As Frank points out, your post had the effect of blurring those lines and adding more fuel to the skeptics who think SAP has missed the boat on multi-tenancy across the board.
It's too bad, because aside from some questions on HANA and mult-tenancy SAP has yet to sort publicly, SAP has come a long way on multi-tenant apps since the early ByDesign days. I don't think you got that across in your post - some clarity there would have helped the reader.
I realize you were trying to frame the multi-tenancy talk a bit more narrowly. I thought your comment to Frank post made your position much cleared than your own blog post, which left a lot open to interpretation.
Typically, I see this debate framed as private versus public cloud, rather than multi-tenancy, and I believe that there is a definite worthy debate on the merits of private clouds for data where regulatory issues involving cloud storage come into play.
Most reasonable people accept the idea that customers will make their own value (and in some cases, regulatory)-based decisions on hybrid cloud landscapes so I'm not sure there's a huge discussion to be had there.
However, when you expanded things to multi-tenant PaaS, things got muddier. I guess it's how you look at PaaS, but for ISVs looking to develop on a platform, there is a big value in a multi-tenant architecture that will bring their solutions to scale.
A more critical issue for you is that SAP's own PaaS plans are clearly aligned with multi-tenant approaches. Your post made me wonder if you've had a chance to talk with SAP's own PaaS team about what they are up to. The Mentors had a meeting with them today and I again got a clear sense that multi-tenancy is a very important architectural consideration across SAP's ABAP and Java PaaS solutions.
This would make sense, since the idea is to allow ISVs to develop industry and add-on solutions that complement products such as ByDesign, Sales OnDemand, and eventually, on the Java side, StreamWork, SuccessFactors, etc.
If you disagree with SAP on this point, fine, but I think it behooves you to make that as clear as possible so that readers realize not only your position but in this case (PaaS multi-tenancy) how you deviate from SAP's. Instead, in my opinion, too many readers left your post thinking SAP "just doesn't get multi-tenancy."
I don't think that was your intent, but when you blog about mobility, you are much more clearly aligned with SAP and Sybase, so readers have a tendency to think the same this time around. At any rate SAP could help your cause by being more painfully clear about their own PaaS plans and I expect after SuccessFactors is pulled into the roadmap we'll have our answers.
My Sybase colleague Eric Farrar explains what I meant to say about Multitenancy and PaaS and ISVs, only much much better.
I'd also recommend this blog by SAP Mentor Richard Hirsch, who explains how he views SQL Anywhere On-Demand in relation to other Platforms-as-a-Service, including SAP's.