[Thanks to all of you who have emailed whether i will cover about the frameworks we may use while SaaS-ifying. I might not be able to cover frameworks for all the technology platforms myself but i am pretty sure the contributors to this blog definitely would!
I would request all of you to post your questions as blog comments here instead of mailing me. :)]
Now on to todays' post...
Today, i am going to start discussing on one of the most "hyped" concerns which most of the saasification teams have to handle - The Multi-tenancy.
Almost all the stakeholders are concerned about
"What does it really take to convert an app to a multitenant one?"
Multiple ways to Multitenancy
Woefully, Multi-tenancy has multiple routes and that is what is creating the whole confusion in the current market. Everyday you would hear sure shot ways to "automatically" convert an app to a multitenant app.
While some of the solutions being offered, ingeniously scan your code and try to "hook" your application to their Multitenant Servers (WORM-Write once read many approach), while others offer APIs to your re-engineering teams for the purpose. Still others use patterns for redirecting the service requests to the relevant modules in your code representing the various tenants.
While some of the multitenancy providers offer just server virtualization as the solution (to start with), others redirect you to heavily verbose set of articles demonstrating how scores of their middleware servers could eventually enable multitenancy for you in an easy way!
All of these solutions have their own pros and cons and i plan to discuss these in my blog here, though not today [later]! Today i really want to start off with the evolution of Multitenancy for your product/application.
The Evolution
Yes! Its an evolution path which most of the successful conversion projects are taking. Re-Engineering itself is an evolutionary concept where you can bulldoze your way through factoring and refactoring various engineering elements as per the comfort level of the engineering team and the agility by which you are sometimes "coaxed" to release the code to the market!
Those who plan to take an EXPRESS ROUTE will have to find easy though bit risky a route - in the Multi-Tenant Server approaches which a few companies are providing.
Preparing your existing app for the evolution
Separation of concerns, decoupling (or loosely coupled system), layering are the most important architecture principles required as a first step towards readying your application to multitenancy.
Best practice is to use MVC (or its variants) architecture pattern where some frameworks(Eg: Athena) which provide a very effective ORM model which at the core try to enable multitenant db access.
will be continued...
I would request all of you to post your questions as blog comments here instead of mailing me. :)]
Now on to todays' post...
Today, i am going to start discussing on one of the most "hyped" concerns which most of the saasification teams have to handle - The Multi-tenancy.
Almost all the stakeholders are concerned about
"What does it really take to convert an app to a multitenant one?"
Multiple ways to Multitenancy
Woefully, Multi-tenancy has multiple routes and that is what is creating the whole confusion in the current market. Everyday you would hear sure shot ways to "automatically" convert an app to a multitenant app.
While some of the solutions being offered, ingeniously scan your code and try to "hook" your application to their Multitenant Servers (WORM-Write once read many approach), while others offer APIs to your re-engineering teams for the purpose. Still others use patterns for redirecting the service requests to the relevant modules in your code representing the various tenants.
While some of the multitenancy providers offer just server virtualization as the solution (to start with), others redirect you to heavily verbose set of articles demonstrating how scores of their middleware servers could eventually enable multitenancy for you in an easy way!
All of these solutions have their own pros and cons and i plan to discuss these in my blog here, though not today [later]! Today i really want to start off with the evolution of Multitenancy for your product/application.
The Evolution
Yes! Its an evolution path which most of the successful conversion projects are taking. Re-Engineering itself is an evolutionary concept where you can bulldoze your way through factoring and refactoring various engineering elements as per the comfort level of the engineering team and the agility by which you are sometimes "coaxed" to release the code to the market!
Those who plan to take an EXPRESS ROUTE will have to find easy though bit risky a route - in the Multi-Tenant Server approaches which a few companies are providing.
Preparing your existing app for the evolution
Separation of concerns, decoupling (or loosely coupled system), layering are the most important architecture principles required as a first step towards readying your application to multitenancy.
Best practice is to use MVC (or its variants) architecture pattern where some frameworks(Eg: Athena) which provide a very effective ORM model which at the core try to enable multitenant db access.
will be continued...
No comments:
Post a Comment