Tuesday, July 24, 2012

About SaaS

This time I'd like to share my views about different approaches to SaaS. Remember from my previous post - SaaS (just) scales on demand, and when executed, it is somehow isolated from other tenants of the "same" software.

1) PaaS Ready, i.e. software that is ready to be installed/deployed to PaaS. This can be for example a Ruby on Rails application ready to be deployed to Heroku, or java web application to be deployed to Jelastic. It means Software Instance per tenant. E.g. origin code can be hosted on GitHub, you clone it, customize and deploy to PaaS. This is not much different from classic hosting. Beside the fact that it will scale!

Oh, I should have mentioned the simplest approach, used at some of existing SaaS marketplaces. A SaaS markeplace company lets you use a software without being bothered with its installing and deploying. It does not necessarily need to be SaaS actually. I think this is very close to Amazon Marketplace, when they sell pre-configured Amozon Machine Images (AMI). Interesting, but something different. Or non-SaaS approach to SaaS :)

2) Business SaaS, let's call it. SalesForce, WSO2 and may be many others, allows to build SaaS at their platform online. WSO2 has somewhat better case, when one can deploy special type of application - carbon application, but you still need to configure resources needed for the application, like database or web services. Well, how is it different from the first case? At Heroku or Jelastic you may also need to setup resources needed for the application. Is it different because SalesForce and WSO2 applications share execution environment? In my thoughts, difference is rather that you don't have standalone codebase that you can just deploy into PaaS, you build your software with their online tools.

Well, with WSO2 it's not so bad (from software developer point of view, of course). Developers create carbon applications "offline".  Also, what's interesting, setting carbon.enable.saas=true in web.xml, WSO2 application becomes multi-tenant. But looks like WSO2 tenant context can not be leveraged in the application. Developer still needs  to have a multi-tenant architecture for his application, like multi-tenant data store , or anything else. Also it's not clear if only super tenant can run saas enabled carbon application.

Note, I was trying hard to understand whether SalesForce allows to create multi-tenant application. Looks like not. Also it does not seem possible to deploy any redistributable package.

3) Multi-tenant SaaS - tenant aware application, such that each tenant will share the instance of running software. It may look the same for tenants, but technically it will be one deployed instance, serving needs of different tenants. Isolation happens on application level, similarly to WSO2 all resources are shared, but everything is executed isolated. Why it's needed? For better resource utilization. Notice, it comes from previous case. It also can be PaaS Ready application.

Well, the latter is actually area of my research, for those curious why I'm thinking so much about cloud computing. Hopefully next post(s) will be about programming model(s) of multi-tenant applications in Java. Though don't expect it to be "ready" for any PaaS yet.

Off-topic, it could be interesting to talk about sharing revenue between PaaS provider developer of SaaS. It's clearly possible in non-SaaS case, like being an AMI vendor. It's also likely possible in second type. And it's completely up to software developer in third case.

In 2nd case, it rather depends on how billing works in WSO2-like saas enabled case. Will tenant be billed for using super-tenant resources, and/or will he have his own resources?

I'm rather inclined to 3rd type, multi-tenant SaaS, which leaves revenue sharing out :) And hope to write about it. Is there someone excited?

And picture!




No comments: