Which method do you prefer? (SaaS)

Portal Home > Knowledgebase > Articles Database > Which method do you prefer? (SaaS)

Posted by mg-, 01-26-2012, 01:43 PM
When building a deployable php app - what method do you prefer in terms of design? Ie; shared central files with alias set to each user domain/sub, seperate database based off domain/subdomain (easy updating/changes). virtualization, everything seperate, controlled by saas panel and some sort of update process for each virtual app when doing changes. allowing for customization.. Database design? Seperate databases, or shared database with 'system_id' or something similiar in each row. I'm curious to see how other people prefer to build their saas apps.
Posted by bdowne01, 01-30-2012, 07:52 PM
We have a customer that sells SaaS as a photo sharing site of sorts. They've gone through multiple iterations of their platform, and we'd been consulted as the network/server engineers of the group many of those times. If I had to sum up the years of experience it seems they've always reverted back to the shared/alias domain/subdomain approach. Mainly because the versions that were heavy into virtualization (either the cloud approach or doing all domain-content 'logic' in the application) seemed to require a bothersome amount of development time, and when it did work, it was unreliable and buggy. Also didn't handle extreme loads really well. I'm sure everyone's situation and application is different of course, but I think it comes down to pinpointing where your people's skills are at and using those. In their case it was having a bunch of long-time server guys and network engineers (us) to work with, in your or someone else's case it could be a wickedly sharp PHP or Ruby guy.
Posted by richardhay, 01-31-2012, 09:23 AM
I've designed and deployed several SaaS programs, and they all share the following structure. One program in certain has over four thousand separate "instances" of the product: * Separate subdomains for each instance. * Separate files for each instance. * Separate databases for each instance. The reason for this is due to the program itself. The program can be customized (extensively) for each client. That selling point requires separate packages. Another product that I am developing, though, will have a shared file base except for separate databases and config files located in separate domains. That product isn't offered as a completely customizable product, so the product dictates a different structure. I hope that this helps!
Posted by mg-, 01-31-2012, 12:33 PM
With the heavy customization, did you find it difficult to keep bug fixes or additions up to date through out your client base? Or was it heavily modulated so your customization ran off extensions of the base app?
Posted by richardhay, 01-31-2012, 12:36 PM
You've hit on the hardest part of the structure. Since our clients paid on a subscription basis, we had to role out new features, bug fixes, and version upgrades on top of heavily customized programs. And, unfortunately, there isn't a good way to do this. Except for urgent fixes, we rollout features about once a month, automated the process as much as possible through scripting, and test and manually install where needed. But, we price the subscriptions at the level that accounts for this work.
Posted by mg-, 01-31-2012, 12:45 PM
Yeah.. That seems to be my dilema right now, I've worked on saas in the past where extensions/customizations weren't much of an issue.. It was essentially the "here it is, enjoy" apps. Though with something coming up, your scenario is exactly what I'm looking at. Trying to maximize on efficiency on maintenance work down the road.

Add to Favourites Print this Article