One thing you may want to take into consideration, if you plan on having many sites run through this codebase, is NOT giving each site a unique application name. (as in <cfset this.name = "#cgi.server_name#">). I once worked on a MSOC system that ran somewhere around 2700 websites, and each site had its own application name. So, every time we cached a CFC in the application scope, we had 2700 separate instances of it, even though they were all identical. We had 2700 "application.dsn" variables stored in memory, even though they were all identical. We had multiple CF servers each trying to store and manage the same 2700 separate applications, all of which were completely identical. And the worst part was, there was no passing "?reinit=1" if we made code changes and needed to reset the application scope, we had to restart each CF server and take all 2700 sites offline in order to reset all of the applications. To me, this always seemed inefficient, and a gross waste of CF processes and memory.
Just some thoughts I wanted to throw out there. Definitely something to think about if you're planning on having a large number of sites on your system. Thanks, Eric Cobb ECAR Technologies, LLC http://www.ecartech.com http://www.cfgears.com On 2/17/2011 8:59 PM, Rick Faircloth wrote: > Your approach at Broadchoice sounds exactly like what I'm > anticipating implementing... > > > -----Original Message----- > From: Sean Corfield [mailto:seancorfi...@gmail.com] > Sent: Thursday, February 17, 2011 5:58 PM > To: cf-talk > Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) > > > On Thu, Feb 17, 2011 at 10:21 AM, Robert Harrison > <rob...@austin-williams.com> wrote: >> 1. Your relationship with the client changes and the client wants to > take the site and move. Now you are faced with either holding the client's > site hostage or giving away your multi-site base code framework (possibly > even to a competitor). Neither of those is an attractive option. > > It really depends on how you set up the contract and the expectations. > Broadchoice (where I worked in 2008) has a software-as-a-service CMS > which hosts a number of high-profile client sites. It's very clear to > the clients that they're using a multi-tenant SaaS platform and > therefore they know upfront that this isn't a site they can just "take > over" (although there is an option to license the codebase for an > internal installation). > >> 2. Also, assume one or more clients keeps coming back to you to make > adjustments and additions. Now your code is getting more and more mucked up > with custom-code exceptions. That's also not cool. Eventually that will > make your framework really difficult to manage and upgrade. > > At Broadchoice we tackled this by designing a pluggable, modular > architecture for "applications" that could literally be dropped into > the (single) codebase and then configured to be available on any > client sites. The nice thing about this is that one client may pay for > the module to be developed but it's still provided to them as a > service - they're not purchasing the code - and then it can be offered > to other clients, as a paid option if appropriate. > > The key is really in deciding whether you're "just" hosting a number > of sites or whether you're offering a "website platform" in a SaaS > model. > > You might also want to read Steve "Cutter" Blades blog series about MSOC: > > http://blog.cutterscrossing.com/index.cfm/MSOC > > At World Singles, we have about 50 sites all running on a single > codebase. Mostly the sites differ in branding and look'n'feel but > there are functional differences between many of the sites, managed > with a similar model to what we used at Broadchoice. > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342425 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
