multisite vs yass

[jamie]

Hi all,

We're supporting a multisite installation and it's been a bit painful. Not because of multisite problems (there have been a few but we've been able to figure them out) but just because it's different from the other sites we are maintaining so our workflow is thrown off.

The main  reason we are using multisite is because we are working with a national organization that has several local affiliates and the national wants to be able to aggregate all the contacts from the locals without having each local access other local's contacts.

We've recently read about YASS (https://github.com/totten/yass), which is a library for synchronizing data between two CiviCRM installations.

In theory, with YASS, we could accomplish our goal without multisite.

We're trying to decide between fixing our tools (aegir) to work with multisite or ditching multisite and trying to use YASS instead.

The advantages to YASS seem to be:

• Keep complexity out of CiviCRM. YASS is complicated, but at least it is isolated from CiviCRM core, meaning we can make fixes without risk of breaking CiviCRM core.
• It has an interesting future. If YASS is well supported and developed, it could be used for a lot of other things (I'm thinking specifically about synchronizing with Salsa or any other CRM with a remote API)
• We no longer have to worry about weird multisite corner cases.

The disadvantages to YASS

• It's complicated. Synchronizing data is hard and if we get it wrong, it can lead to lost data.
• Adding multisite support to aegir would be helpful to a lot of people beyond us
• YASS is new and a bit unknown - it could be a can of worms making us regret leaving multisite

What do others think? How has your multisite experiences been? Has anyone tried YASS.

jamie

[totten]

Thanks for posting this, Jamie. Those are all good points.

This is probably a tough choice. To my mind, both approaches represent an extreme: with a single-database approach (eg CiviCRM ACLs), you can start out with a "share everything" policy and then erect new barriers/partitions until you get the right amount of sharing; with a multi-database approach (eg YASS), you start out with a "share nothing" policy and then put in new integrations until you get the right amount of sharing. In both approaches, there are some tools to help along the way (domains, ACLs, YASS, etc), but both will involve weird corner cases and development work.

For me, some questions to ask when choosing between a single-database and multi-database approach are:

 * Administratively, who's in charge? If the national organization dictates most policy and funds the customizations (themes, modules, email templates, membership types, profile forms, etc), then single-database will probably be better (because it's easier to provide consistency across all the chapters). If the national organization is a loose federation of autonomous chapters, then multi-database will probably be better (because it's easier to add separate customizations for each chapter).

 * Which entities (contacts, activities, groups, email templates, profile forms, custom fields, etc) need to be shared or not-shared? For example, look at the CiviCRM menu (esp "Administration") to get a list of major screens/resources -- which screens should have shared data and which shouldn't? (FWIW, ACLs/domains have been tested more thoughtfully and with more entities than YASS, but I think YASS makes it easier to pick and choose which entities to share.)

 * What level of security do you need between the chapters? In a multi-database approach, you can have separate MySQL users, separate www-data users, separate file trees, etc. for each chapter -- we know that the only data sharing occurs through YASS.

 * How quickly does information need to be shared? With single-database, it's instantaneous. With multi-database, there's a delay and some throughput limitations. Also, during that delay, there's a risk that national+chapter DBs might make conflicting data changes. (The risk can be mitigated but not entirely removed.)

As a final note, I want to expand on your point about sync'ing with other systems. In addition to sync'ing with third-party CRMs, YASS's design also aims to support off-line access (laptops/smartphones) or geographically distributed servers (eg one in US for an American chapter; one in EU for a European chapter). In all these scenarios, you have similar issues vis-a-vis delays, broken connections, change-conflicts, propagating merges+deletions, access-control, etc. I'm not saying YASS is currently a working solution for these, but those are some scenarios it aimed for.

EDIT: To clarify the last statement, YASS is not a finished solution for the scenarios of off-line access and geographically distributed servers -- however, regarding the listed features (change-conflicts, etal), it does have working components. The known gap is largely in evaluating and testing those specific scenarios.

[jamie]

Thanks TIm for the thoughtful response and suggested criteria. I'm sharing with other members of our team to evaluate for our particular use case. I'm certainly leaning toward YASS for the site in question.

[Eileen]

One more issue around the who's in charge is : who has the budget. Sometimes an argument for multisite is that it makes it easier for poor cousin chapters to ride on the financial coat-tails of the chapters with the cash to splash on improving things.  It's an argument that very much depends on the organisation.

One of our customers has been looking at how to set up another layer of permissioning where the permissions are applied to groups -e .g group A might have edit Contribution permissions on Group B but only view Contact on group C. The code implementation is probably not going to be something that is useful to others but it could be a useful ACL concept in future.