The Third Alternative : For developing a SaaS product or application
After reading analyst reports on SaaS, you generally get a feeling that there are only two alternatives :
- Use traditional / regular application development platforms such as .Net or Java to develop a normal (single tenant) application and then use virtualization or dynamic grid for multitenancy and scalability
- Or use proprietery SaaS enabled Application Platforms (example Force and Longjump) to build your SaaS applications.
The possibility of building your own Multitenant SaaS application, using industry standard programming models such as .Net or J2EE is not discussed often. There are many reasons for this. It is not as simple as building an on-premise application. SaaS brings it with many additional requirements (over and above what is required for the business functions)
- Customizability : The product admin and the tenant admin should be able to customize and configure the product on the fly (UI, skins, themes, forms, grids, custom fields, pick-up lists, data model extensions, business rules, reports)
- Security : The tenant admin should be able to customize and manage roles, privileges and access controls at the page level, data level and field level.
- Audit Trail : Maintain an audit trail of all changes by tenant admins and their users.
- Administration : Setup and manage system settings, admin data and master data screens for each tenant
- Metering : Meter usage criteria of any billable entity and link them to usage limits and access control restrictions
- Subscription : Product admin should be able to create product packages, enable disable various features for each tenant and link the subscription packages to access controls.
- Scalability : Support for both horizontal and vertical scaling
- Share all multitenancy : The three layer architecture should support “share all multi-tenancy” with different types of data isolation schemes between tenants
Add to these, plumbing components such as caching, exception handling, logging, notifications, performance instrumentation etc (which were required even on Non – SaaS applications), you have a solid engineering layer to build, before you build your first business functionality.
You can build your own SaaS framework / SaaS enabled Application platform with all the above capabilities, extending the capabilities of .Net or J2EE. But it is expensive and time consuming and requires extensive expertise. Probably that is why, no one ever talks about this.
But not any more.
With productized SaaS frameworks such as cellosaas, available off the shelf for a one time license fee, it is time to start considering what I call the third alternative.
What cellosaas (delivered to developers as a product) does is to take traditional platforms such as .Net and Java and makes them SaaS enabled, supporting share all multi-tenancy and a three layer MVC application architecture. But while doing so, it retains the programming models and standards of the underlying technology stack, so that there is no learning curve for the developer and she gets absolute flexibility and control like in Custom development. This solves many problems associated with PaaS: One, there is no vendor or platform lock in. Two there is no recurring monthly cost. Three you get the flexibility, control and the power of the entire .Net / Java ecosystem.
Architects and developers can save all the headaches, costs, risks and overheads of building and maintaining their own SaaS engineering stack and instead focus on building their business functionalities.