Going for a single app instance per customer requires a lot more maintenance, you would need to have a very smart deployment system that could update all instances when you update your code, however you could do this using something like apache ant or phing and some bash scripting maybe rsync or svn mirroring. Though having an instance per customer would make it possible to customize per customer and also if you use something like amazon ec3 you could easily scale out as each customer could have their own ec3 instance.
I think a unified application would take less time to create, so it may be down to time and money. 2009/1/24 mguthrie <[email protected]>: > > That's fair. It would pretty much be a specialized Customer Relationship > Manager (CRM) geared toward a specific industry. The application would > probably be used by office personnel and not by the public at large. So > most customers would probably only have about 4 office people who would be > using it, maybe more but probably not much. Each customer should only be > able to manage their data. > > Does that clarify the question a little more? > > > > Martin Martinov-2 wrote: >> >> 2009/1/24 mguthrie <[email protected]>: >>> >>> I'm working on a project that I would like to make available as a >>> subscription service. I've worked in other frameworks and have asked >>> this >>> question but I thought I would see what would be a good route for doing >>> this >>> in ZF. >>> >>> My question is: What would be the best design for hosting, scalability, >>> and >>> reducing development overhead for a web application? Would it be better >>> to >>> have 1.) a single installed instance per customer each with its own >>> separate >>> db/files OR 2.) design the application so that the whole application >>> works >>> under one installation with each customer having a username, password, >>> and >>> some type of organization ID to limit access to just their data? >>> >>> The second solution would need some way to extend Auth to provide >>> checking >>> the organization ID (possible?). >>> >>> I'd be interested in hearing the different opinions on which would be >>> better. It seems to me like my overhead would be less just to manage one >>> big application but upfront design would be more complex. To go the >>> other >>> route would make it easier to design but I would have to manage each >>> installation separately which would be a lot of work. The ability to >>> grab a >>> copy of just one customer's database seems like it would be nice though. >>> >>> Other projects like Wordpress-mu have argued that one big single app is >>> the >>> way to go as it is more scalable but others have argued that it's easier >>> working with many installations. >>> >>> Thanks in advance for any feedback and I apologize if this was asked >>> somewhere else on this list. I couldn't find anything easily. >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Design-Question-tp21644511p21644511.html >>> Sent from the Zend Framework mailing list archive at Nabble.com. >>> >>> >> >> I think it's impossible to choose one way or the other without knowing >> a little more about the application and what it does. What kind of >> information those companies you write about are going to work with, >> how many users has each organization, etc. >> I need a vehicle. What should I buy - a family car, a bike or a truk? :) >> >> -- >> Regards, >> Martin Martinov >> http://mmartinov.com/ >> >> > > -- > View this message in context: > http://www.nabble.com/Design-Question-tp21644511p21646826.html > Sent from the Zend Framework mailing list archive at Nabble.com. > > -- ---------------------------------------------------------------------- [MuTe] ----------------------------------------------------------------------
