The question is: is it worth keeping it? To answer this question, perhaps we need to perhaps look at the pros and cons
pros of keeping multi-tenancy: - less memory consumption. - less storage consumption. - single deployment (less effort) cons of keeping multi-tenancy: - Inflexibility: all tenants are stuck with the same code base. - risk: if one tenant goes down, all tenants go down. There is less redundancy and recovery. - lock-in: splitting out tenants to a new separate instance is hard and time consuming. - code complexity: The multi-tenancy feature in OFBiz is making nearly every critical artifact in the system complex. It is hard wired in tomcat, components, data loaders and many other places. I stopped counting the "if" conditions to handle the multi-tenant corner cases all over the code base. - alternatives less complex: the advent of new technologies like docker and containerization makes the need for multi-tenancy less desired. Also, storage and memory is getting cheaper all the time. So the pros listed above are getting less valuable over time. So for all the above, I find myself leaning more towards removing multi-tenancy from the code base. On Tue, Sep 4, 2018 at 5:49 PM Mike <mz4whee...@gmail.com> wrote: > > My opinion is to just completely ditch the multi tenant code since it seems > to be more trouble than it's worth. Anyone serious about designing a > system to support a similar concept would do it their own way anyway, most > likely using completely separate DBs. Face it, using a common DB and share > between separate companies is a dangerous concept, let alone the scaling > issues involved. > > > > > On Sun, Sep 2, 2018 at 1:33 AM Jacques Le Roux <jacques.le.r...@les7arts.com> > wrote: > > > Hi, > > > > Note: this conversation started on the dev ML: > > https://markmail.org/message/hb2kt5nkodhwnkgw > > > > The multi-tenants feature in OFBiz only allows a dozens or maybe even few > > hundreds tenants, after it begin to be a lot of DBs! > > I faced that with a startup which wanted to handle thousands, if not > > millions (actually they failed), of tenants, obviously OFBiz can't do that. > > > > I don't break any secret to say that I was working with David (and Andrew) > > on a project in 2010 when David had to quickly answer to the client's > > demand who wanted to have tenants. David brilliantly and quickly > > delivered, but it was only a start. > > > > After many improvements, this feature still have some issues > > https://issues.apache.org/jira/browse/OFBIZ-6066 > > https://issues.apache.org/jira/browse/OFBIZ-7900 > > https://issues.apache.org/jira/browse/OFBIZ-6164 > > https://issues.apache.org/jira/browse/OFBIZ-6065 > > > > Also this is somehow related > > https://issues.apache.org/jira/browse/OFBIZ-6712 > > > > And most importantly > > https://issues.apache.org/jira/browse/OFBIZ-7112 > > https://issues.apache.org/jira/browse/OFBIZ-7754 > > > > I recently read this article > > > > > > https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/ > > > > and, after my experiences with multi-tenant as is in OFBiz, it made me > > wonder if we should not think about how it's done now in OFBiz in 2018 with > > the > > clouds being everywhere! > > > > Before sending this email, I quickly exchanged with David about how Moqui > > handles that now. And we are on the same page, see > > > > https://www.linkedin.com/groups/4640689/4640689-6180851287941201924 > > > > > > https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1 > > [1] > > > > [1] Initially David gave me this link > > > > https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/ > > > > but it seems LinkedIn has lost it, as said in the stackoverflow comment. > > > > So IMO why not deprecating the multi-tenants as is now and rather push a > > multi-instances way? > > > > Opinions? > > > > Jacques > > > >
