Listen to my conversation with Rick Nucci, chief technology officer of Boomi, a SaaS integration vendor, who we last interviewed here in April 2009 on the topic of SaaS Integration, Simpler through Sharing.
In this podcast, learn why multi-tenancy is such a crucial ingredient for software-as-a-service and other cloud services, and find out how ISVs can use platform-as-a-service to get to multi-tenancy faster.
Listen to or download the 10:51 minute podcast below:
PW: Rick, I thought it would be good to have a chat, because both of us, in fact, have been blogging a lot recently about the cloud which has become much more accessible this [past] year, much more mainstream, there's lots of businesses and developers moving onto the cloud. But both of us I think are worried that they're not all moving onto the cloud in the right frame of mind.
RN: Yeah, absolutely. And it's dangerous, frankly, a little bit. I think cloud, and software-as-a-service as a subset of that term, has enough proof points and track record behind, that the hype is not going to outweigh the benefits. But nonetheless, while technologies like Amazon are fantastic in what they can enable you to do, they also can enable you to take very dangerous shortcuts, in terms of the way you deliver your cloud service, which can have very consequential long-term effects.
Yes, and specifically we're talking about people who take an application or develop some software, put it onto the cloud using some kind of virtual machine capability and then what they've actually done is, they've taken an application that wasn't built for the cloud and they've just put it in the cloud. And that's when they encounter problems, isn't it?
Yeah, exactly. If I rank from greatest offender to least offender, the greatest offender doesn't even host it for you on Amazon. They build the image and frankly, any cloud where you can build a virtual image and just provision it they build the image and they say like, here you go, go install it. I don't know that that's like that much different than giving you a CD. I mean, yeah, you don't have to manage the server yourself and that's great. But that's like, I don't know, one-tenth of the overall benefit of doing this in the first place.
And so, if that's the most egregious offender, the next-rank offender is the person who says, 'Okay, well, I'm going host it for you' but behind the scenes, for every customer, they're provisioning a dedicated instance for that customer.
And the argument, or the con, that you'll hear from the folks who are trying to downplay the significance of multi-tenancy will say, 'What does it matter if the customer has this nice web experience and the vendor's managing their upgrades?' And the answer to that is well, that's the exact point, the vendor's managing the upgrade and they're launching now when they have no customers and they're thinking about their first dozen customers. Well, what happens when they have a thousand customers, right?
And we've heard folks who've architected this way from the beginning and I won't even use Salesforce because they're the obvious example. SuccessFactors recently gave a speech, [by CEO] Lars [Dalgaard], talking about their architecture and their approach. They have something like over a thousand customers per physical server when you net it all out and aggregate it. And that's the marginal utility, that's the scale that you need to get to because you need that op-ex in your business as a SaaS ISV to be in the five percent type of range. And it's not going to happen if you're doing a per-customer expenditure.
Yes, but Rick, we're talking about companies that have been delivering SaaS for many years, that have had the opportunity to really sit down and hone their platform. For a lot of ISVs, they don't have that background and there's a way that they've done things that they're very comfortable with. What is the point of them learning to do things in a completely different, unfamiliar way? What are they actually losing by not going the multi-tenant route?
Yeah, it's a very important point. So I think what they're losing is, if you take a look at the problems today of the enterprise software space, if you take a look at the status quo today and the reason why SaaS emerged. Nobody adopts SaaS because it's cool or neat, they adopt it because it has real, meaningful business benefits.
Let's just take, like, one example. And everybody likes to beat up on the fact that you can't customize SaaS. Well, in fact, it's the exact opposite. Not only can you customize SaaS, you can customize it to the point that you don't even have to involve the vendor for any customizations that you want to make. And a systems integrator or the end customer can do it themselves.
And so, if you contrast that to the way the enterprise software used to be customized: you'd have to bring the vendor in, they'd have to change their code, then that version of the software gets revision locked, meaning it becomes very expensive to then try to upgrade that software package. And so the customer's stuck. They're stuck on the version of software, they're not able to get any of the benefit of the innovations, they still have to pay the maintenance over and over again, right? And customer after customer would raise their hand and go, 'Yes, that's me.'
So that one reason alone and there's a bunch of them but that one reason alone is why that vendor, who has that old way of doing things like you said, why do they need to invest and learn. That's a great reason.
Because you know what? If you spin up single tenants, you're going to single-tenant customize, you're not going to think through a multi-tenant API which means you're not going to be able to have a scaleable way to integrate, and you're going to be back in that same position where you're going to have customizations and integrations that lock your customers into revisions. You're going to eventually start allowing your customers to decide when they can upgrade their version their instance of their quote-unquote "cloud application". And you're going to be in the same mess you were in only now you have to manage it all, out in your data center. So I think that's a pretty compelling reason why it does have to be rethought.
And I think you mentioned something there which I think is quite important, the question of APIs. I think as more and more enterprises are putting some of their IT assets in the cloud, or using multi-tenant services from the cloud, of course a lot of them are still going to have legacy assets as well as on-premise, and the integration becomes an issue. And if you're not using multi-tenancy in any part of that infrastructure whether it's on-cloud or off-cloud then you're going to have more of a headache getting the integration to work, aren't you?
You are, yes. There's a couple of reasons why, but there's a very specific one that I want to hone in on that gets lost a lot. When you architect multi-tenancy from the beginning okay, let's contextualize what that means for integration. So I'll give an example. So everybody typically needs to customize their business app, per our last discussion, because there's some nuance to your business that's unique to you. Whether that's perception or reality it doesn't really matter. That business wants to feel they have that level of control. So they're going to go in and they're going to make that customization.
Well, in a multi-tenant environment, if you go in to that app and you add that custom field, and you go to the API and you do a browse or a discovery process through that API, that customization shows up in real time. That's a very powerful concept. The vendor didn't have to do any work in order to then take that customization and have it manifest in the API, it just happened. That concept of real-time discovery dramatically improves the ability to integrate with that app and creates a very, very compelling opportunity.
You know, it's ironic that the impediment of SaaS adoption is perceived complexity of integration. There certainly are headaches and things that need to be thought through in terms of integrating, like you said, on-prem assets with SaaS assets, and that shouldn't be underestimated.
But the SaaS app, compared to the on-prem app, it creates this fantastic opportunity. It's another benefit of multi-tenancy, but again it comes down to this idea of, in the old world, when you customized the app, you'd then have to go into the API and do the same thing again. There was no concept of that metadata discovery. Some of the later-stage applications eventually got to that point. But the broad, the vast majority, have no concept of that. Or you end up having to go and integrate with the database, which has a whole 'nother set of issues associated with it. Whereas in the SaaS world, there is no database. You can't go and integrate the database. So the vendor's forced to put that discovery process right into the API, which creates a really, really powerful opportunity for integration.
Yeah, and I think that, of course, is why developers are hesitant about doing multi-tenancy, because it does mean that they have to actually work harder on the architecture to start with. Because that's one of the points about multi-tenancy, that it's an architecture that is designed to be ready for whatever happens. Instead of the old way of developing, when you tried to foresee everything and custom-build for all those things that you could foresee, the multi-tenancy environment precisely because it doesn't know what people are going to be doing and what they're going to connect to has to build in that readiness for the unexpected, which I think is one of the differentiating features.
Absolutely. Absolutely, it is. And you're right. It is a you're making a huge upfront investment for a hopeful payoff and that is definitely a scary thing to companies. One of the things that is emerging to offset that and even, it may be emerging, it's been emerging, but is building on a platform; building on a platform that has multi-tenancy baked in.
Even looking beyond Force.com, which again they've been visionaries in a lot of that capability where just take the API discussion I just had if you build an app [to be] Force-native, the API is just available inherently as part of the app you're building. And that's a really, really nice benefit that you don't have to think about. But a lot of the commentary back on the platforms guys is, 'Well, you're locking me in.' And that's fair, and that's a perception that folks are going have, and it's a real point of contention, it's something that has to be thought through.
But there's also platform players that are emerging that are taking what they're doing and they're building a multi-tenant infrastructure. And they're building the ability for you to leverage that and build something that is multi-tenant but leverage their platform so you don't have to rethink transaction isolation, and security, and a lot of the things that are really hard to do when you build multi-tenancy leverage that platform, but they're also thinking, 'Okay, how can I also make this platform portable?'
So you've got guys like Apprenda with their SaaSGrid, where you can run that SaaSGrid in Rackspace, but you can also run it in Amazon, and you can also run it in GoGrid. And it's not a single instance being provisioned, it's that they have a cloud, they have a platform running in each of those places, and each one of those can host a number of tenants.
And so, I think there's definitely some really innovative things happening there that will hopefully hopefully encourage folks that are coming to the cloud to take a look and go, 'Okay, well' to your point Phil 'to go and build all this stuff, this is really going to be hard and this is a big upfront investment.' Okay. Well, maybe that platform can get me some of the way there, out of the gate, and I don't have to look at it as such an uphill climb.