SiteAccess vs multiple standalone ez instance, pros & cons, feedback

Previous topic

Setup & design

Next topic

Author	Message
Pablo Pernot	Saturday 02 January 2010 3:10:32 am Just noticed the topic about siteaccess : http://share.ez.no/forums/setup-design/multiple-siteaccess-design-solution I wonder what is your advice about site access versus multiple standalone ez instance. These days I face a huge ezpublish instance (with around ~30 siteaccess, and for each one 3 translations). Every siteaccess have his own content, but nodes with multiple locations are spread within multiples siteaccess. Some workflow copy new publication from one subtree to another (every siteaccess has his own subtree I forgot to mention). It works well, so it's ok for me. If I should start this project again I really wonder If it will be more smart to use multiple ezpublish standalone instance for every siteaccess. Pros : maintenability simplicity of code (=> maintenability) simplicity of database management (right now everything is within the same db) I can disable/enable siteaccess more easily, All the roles, policies and workflows are centralized, it's a pain for modularity etc. Cons : It works ! why should I change it ! It's easy to setup multiple locations for the same node It's easy to copy object within subtrees. All the roles, policies and workflows are centralized, it's easier. etc. Your advice ? your feedback ? What about server load ? thanks Happy new year, hope to meet you in Switzerland in january Pablo Pablo Pernot http://www.smartview.fr http://www.areyouagile.com
Nicolas Pastorino	Monday 01 February 2010 8:26:03 am Hi Pablo, For security purposes a total isolation of applications may be required. Meaning no single line of code, nor any resource shoul dbe shared. In this case you need to have separate instances. As well, when one eZ Publish instance hosts say 2 applications, which have different evolution paces, the tie-in of the 2 applications being on the same instance may reduce flexibility and prevent from having 2 very different evolution/maintenance paces. I think we should enhance the initial thread with these considerations, should bring up useful points: http://share.ez.no/forums/setup-d.../multiple-siteaccess-design-solution My 2 cents, cheers, -- Nicolas Pastorino Director Community - eZ Member of the Community Project Board eZ Publish Community on twitter: http://twitter.com/ezcommunity t : http://twitter.com/jeanvoye G+ : http://plus.tl/jeanvoye

Author

Message

Pablo Pernot

Saturday 02 January 2010 3:10:32 am

Just noticed the topic about siteaccess :

http://share.ez.no/forums/setup-design/multiple-siteaccess-design-solution

I wonder what is your advice about site access versus multiple standalone ez instance.

These days I face a huge ezpublish instance (with around ~30 siteaccess, and for each one 3 translations). Every siteaccess have his own content, but nodes with multiple locations are spread within multiples siteaccess. Some workflow copy new publication from one subtree to another (every siteaccess has his own subtree I forgot to mention).

It works well, so it's ok for me.

If I should start this project again I really wonder If it will be more smart to use multiple ezpublish standalone instance for every siteaccess.

Pros :

maintenability
simplicity of code (=> maintenability)
simplicity of database management (right now everything is within the same db)
I can disable/enable siteaccess more easily,
All the roles, policies and workflows are centralized, it's a pain for modularity
etc.

Cons :

It works ! why should I change it !
It's easy to setup multiple locations for the same node
It's easy to copy object within subtrees.
All the roles, policies and workflows are centralized, it's easier.
etc.

Your advice ? your feedback ? What about server load ?

thanks

Happy new year, hope to meet you in Switzerland in january

Pablo

Pablo Pernot
http://www.smartview.fr
http://www.areyouagile.com

Nicolas Pastorino

Monday 01 February 2010 8:26:03 am

Hi Pablo,

For security purposes a total isolation of applications may be required. Meaning no single line of code, nor any resource shoul dbe shared. In this case you need to have separate instances.
As well, when one eZ Publish instance hosts say 2 applications, which have different evolution paces, the tie-in of the 2 applications being on the same instance may reduce flexibility and prevent from having 2 very different evolution/maintenance paces.

I think we should enhance the initial thread with these considerations, should bring up useful points: http://share.ez.no/forums/setup-d.../multiple-siteaccess-design-solution

My 2 cents,
cheers,

--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board

eZ Publish Community on twitter: http://twitter.com/ezcommunity

t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye