Sunday, February 19, 2012

Cloud FUD on Multitenancy

A recent blog post from Eric Lai titled Multitenancy and Cloud Platforms: Four Big Problems (Note: the post also appeared on as well) had some big problems itself.  I wouldn't normally write a blog post on something like this as the entry was an obvious sales pitch for a new Sybase product however...... the article just got a little to much air time.  To summarize the article: PaaS vendors have issues with security, globalization/localization, developer productivity and inflexibility.  I'll walk through the "Four Big Problems" as presented by Eric and give you the perspective of a corporate IT architect versus a vendor.

Big Problem #1 - "It's inflexible"

The example used here mixed up PaaS and SaaS.  Google's email system was the target of the inflexible which doesn't allow the user to specify where their data will be stored potentially violating industry or governmental regulations.  It also goes on to mention Coke not wanting to store their secret formula within the same instance of a something as Pepsi.  PaaS is then brought up as not being flexible enough to handle these situations.

Google email's system would be an example of a SaaS and not PaaS as implied.  Localization of data has absolutely nothing to do with multitenancy.  Google's email system is a bad example to use when discussing PaaS because it's not one however for the sake of argument let's just say that localization of data would be an issue in a dedicated hosting scenario as well.   Multitenancy does not preclude you from directing where your data will be stored, the geo-locations of your cloud provider may or if you went the dedicated hosting route, same issue.

By the way Pepsi and Coke both use Azure which is a PaaS offering from Microsoft.  I doubt they store their secret formulas there or anywhere else that has network access.  Not a multitenancy issue either, just common sense.  To sum this up most PaaS providers have regional datacenters across the  globe and have extremely flexible ways of directing where your application and data spin up.

Big Problem #2 - "It's less secure"

The big example used here is a common one which is if a hacker manages to get into a multitenant database then all the data is compromised.   I would encourage anyone contemplating PaaS solutions to do their due diligence when selecting a provider.  Ultimately you and your security folks have to be comfortable with the safeguards put in place by the vendor.  But there is a lot of FUD here so let's address some it.

If you have discussions with the PaaS vendors and compare their security protocols and procedures you will mostly likely find that they are light-years ahead of what you are doing or would be capable of doing.  It's really a fairly simple concept, a vendor such as Amazon or Microsoft or Google can afford and do hire the very best security personnel available.  It does not mean they are incapable of making mistakes but the odds are with them versus you. Do your homework on this one but you will be impressed and more secure.

The second thing to keep in mind is that there is more to multitenancy than the article would leave you to believe.  There is more separating your data from Pepsi in a multitenant database that a username and password.  There are multiple layers of protection to isolate you from the other users in those multitenant environments.   Your data is not more or less secure because of multitenancy.  PaaS does a lot to help you out and abstract away some of the complexity but it's still up to you to make sure your data is secure and that would be the same for a single isolated hosted instance.

Big Problem #3 - "It's less powerful"

This one was a little strange.  It really didn't explain why a PaaS would be less powerful than a standalone instance of an application or database other than say doesn't use standard SQL and Microsoft might not have a datacenter in your region.   I think common sense would suggest otherwise.  How elastic can your standalone application or database be?  How easy is it to deploy your standalone application or database to multiple datacenters/regions around the world taking into account globalization and localization issues without specific version of your application to handle each?  Somehow a standalone instance of something wouldn't have scalability issues? Or wouldn't have localization issues?

Big Problem #4 - "It may be more costly"

ROI is always a tricky one and the point made by the author here is that you may have to rewrite you application to run in a PaaS space.  I happen to agree with the author on this one.  You have to weigh the benefits versus the cost of any application you do.  If the cost benefit does work out ten you have to question the project.  This however has absolutely nothing to do with multitenancy.

To summarize I think the author missed a chance to promote his product with more rational set of arguments.  PaaS has some issues but multitenancy isn't really one of them.  When comparing a potential cloud solution for an application you are really looking at IaaS, PaaS and SaaS.  They all have their benefits and drawbacks.  The big one I think the author missed his chance on was the potential vendor lock-in with PaaS which could be a very real issue.    IaaS, PaaS and SaaS all have degrees of lock-in but that's the subject of another post.


Conneva said...

I'm here at VMWare Partner Exchange 2013 (PEX). Looks like there will be some cool new announcements on the Pivotal Initiative and Cloud Foundry coming in the next "few weeks".

One new product that I encountered here was Application Director which would let those of us who do enterprise architecture for a living draw our logical / physical diagrams but then deploy the infrastructure (VMs, app servers, database servers) and the application itself in an automated fashion.

It reminded me of the old webMethods Deployer but with a slicker web-based interface and the ability to deploy the server infrastructure as well as the app components.

Link for demo video here:

Mark Griffin said...

It's a slick interface and I like where that kind of functionality is heading. Probably competes with AWS's recent OpsWorks release, but the interface here is more robust.