Multitenancy hype is getting out of control
I posted recently on SaaS-data-integration-in-the-cloud, and a couple of vendors stopped by the comment thread to shared what they do. One was Boomi, which has a blog that does a good job of spelling out its opinions. What the Boomi blog is not so good at, however, is giving any good reasons why one should share those opinions.
I refer specifically to a couple of posts claiming that multitenancy is somehow crucial for SaaS data integration to work. To this I can only say — huh? A decent data integration system should be able to handle many parallel threads at once, connecting many pairs of databases at once. So the hard part of multitenancy is pretty much “free.” If, even so, the integration provider chooses not to go fully multitenant, whose business is it but theirs?
Yes, I know the argument “We have lower costs and more agility because we’re multi-tenant, and we pass that along to our customers.” But the cost side of that is just an economies-of-scale argument, and what really matters for economies of scale is having a lot of customers to scale them over. As for the agility side, that makes even less sense. The vendor making this argument also usually claim that multitenancy is fairly hard, which is why it’s so special that they do it, blah blah blah. So how does that degree of difficulty add to agility?
Boomi even claims
each customer must buy, install and maintain its own copy of the product and must do so at every location where integration is to occur.
I have great trouble connecting that assertion with reality. Perhaps my friends at Pervasive Software or Cast Iron Systems can jump in here, but it’s my strong impression that in the cloud version of their services, they take care of product upgrades on their users’ behalf.
Comments
7 Responses to “Multitenancy hype is getting out of control”
Leave a Reply
It is very interesting to note that an integration vendor would make a big deal out of the multi-tenant work they do when providing hosted integrations. It shouldn’t be news, it should be expected.
In fact, the Pervasive DataCloud is multi-tenant. But the DataCloud is only one way to deliver integration solutions, which is what Curt is really talking about. We have been delivering integration for over 20 years, we can deliver integration as an on premise architecture for large IT shops connecting traditional data sources, as an embedded solution for ISV’s both traditional and SaaS, and with the introduction of Pervasive DataCloud we now offer integration as a true service in a true cloud delivery. The best part of the story is that all of these come with connectivity to over 150 distinct data sources out of the box (you can even build your own connector if one of those 150 doesn’t fit) and our technology is not only multi threaded, but we have robust multi-core technology that can be used in these scenarios to leverage the latest processing architectures.
However, since the subject is open, Pervasive goes a step further than just multi-tenant delivery on the Pervasive DataCloud; we provide multi-dimensional-tenant architecture. Translated, it means that a single user on Pervasive DataCloud can access the same integration as other users in the cloud (multi-tenant), but even more importantly a single user can own multiple integrations (the added dimension) on the same cloud. It’s like having multiple applications with a universal login. And though we (Pervasive) provide for this in a true cloud (expanding and retracting hosted resources), we do not consider this the big story; we consider it part of the basic requirement set of cloud based architecture for integration resources (there’s that word again, integration).
Our goal is not to boast about what should be expected, but to produce a platform that is scalable, adaptable and robust enough to provide integration services to a wide variety of customers.
And while we have already been delivering packaged integration solutions on DataCloud, we recently demonstrated that the technology delivers custom OnDemand integrations for our partners. (Google Ryma and Pervasive).
I tend to agree with Curt, if multi-tenant capabilities are a large part of your story, then possibly you have overlooked the core problem you are solving, it’s Integration…the multi-tenant problem was solved a long time ago, I think one of our engineers did a college project on it in the 1990’s. What continues to be a problem for businesses is connecting their data (integration), we focus on that problem at Pervasive. Just because a small portion (but growing) of that data is now hosted does not mean that the only tool to solve the problem must be a multi-tenant hosted integration platform, but if it does require that, we have that as well.
I agree that multi tenancy really is really back room business of the service provider. If you have the customer base then maybe it helps your scalability model, but by its very nature should be transparent (and therefore irrelevant) to the user. But is being sold on this aspect any different to being sold on the fact that removal of relational concepts such as data models, transactions, referential integrity etc is a good thing (as most of the cloud databases in beta at the moment are doing). Necessary to achieve the desired large scale multi-tenant scalability maybe, but a good thing? Seriously?
Thanks Curt for the invitation to respond. We at Cast Iron agree with your assertions and our own experience shows that internal architecture discussions are just not that interesting to Cast Iron’s customers. What our customers care about are business benefits, not technology epistles. Key among business benefit considerations are speed, simplicity, and cost – benefits that will impact the top and bottom lines. All else tend to become irrelevant to customers. In fact, based on some other recent blog activity on this topic (see “I can’t believe we are still talking about whether saas == multi-tenancy…”) it seems that the larger community is done with this as well. And for the record, the Cast Iron Cloud is a multi-tenant service and product upgrades are automatically taken care of on our customers’ behalf.
I fully agree with the comments regarding multi-tenancy and it’s importance for customers. The multi-tenancy is rather interesting for providers of on-demand apps than their customers. Being on the provider side of the game, I believe that the internal product architecture (and thus multi-tenancy) is important for the final user experience. I tried to explain what we (GoodData) mean by multi-tenancy in this post http://zsvoboda.blogspot.com/2008/11/good-data-rest-api-demo.html . My post contains a demo video that shows the underpinning of the demo.gooddata.com platform. The demo tries to outline how the Good Data architecture differ from the standard on-premise BI products.
Isn’t there a downside with multi-tenancy when it comes to configuration management? My experience in the ETL world in financial services makes me wonder. Once data integration jobs were built and tested, all components had to be “locked down”. They had to be auditable and changes documented. This was often important because the results of the data integration task was used to summarize revenue, calculate risk, etc. The business had to have a repeatable, deterministic, documented process. With multi-tenant data integration, the vendor controls the code configuration. What if the bendor makes a change that causes an error when the customer is closing books at month end? I am interested to hear other’s opinions on the loss of control one gives the vendor who has a multi-tenant environment.
Bob
Bob,
Isn’t that a SaaS/in-house issue more than it’s a question of single-tenant/multi-tenant?
CAM
[…] in the purest sense, is inessential to SaaS. It’s simply an implementation choice that has certain benefits for the SaaS provider. And by […]