Should we keep the multi-tenants feature in OFBiz?
Locked
Should we keep the multi-tenants feature in OFBiz?
 
Administrator
|
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 |
|
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 <[hidden email]> 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 > > |
|
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 <[hidden email]> 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 <[hidden email]> > 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 > > > > |
|
Banned User
|
This post was updated on .
In reply to this post by Jacques Le Roux
CONTENTS DELETED
The author has deleted this message.
|
|
|
The automation of multi tenancy setup could happen through deployment
scripts instead of OFBiz itself. So yes the tenants would have their own install, but I don't see why they'd have their own server farm. On Wed, Sep 5, 2018, 4:15 AM <[hidden email]> wrote: > So if you don't have multi-tenancy does that mean every tenant has their > own install of OFbiz, their own install of Postgres SQL, and their own > server farm? > > -------- Original Message -------- > Subject: Re: Should we keep the multi-tenants feature in OFBiz? > From: Taher Alkhateeb <[hidden email]> > Date: Tue, September 04, 2018 9:12 am > To: [hidden email] > > 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 <[hidden email]> 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 < > [hidden email]> > > 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 > > > > > > > |
Re: Should we keep the multi-tenants feature in OFBiz?
|
Administrator
|
In reply to this post by taher
Thanks Taher for sharing your thoughts,
This remembers me I once referenced an article from 2006[1]that I can resist to resurrect because I believe the analysis there is still relevant and complete yours. It's no longer available but in web.archive.org[2] Like other threads I recently started on dev ML, I'd like this thread not to fade out but to lead to actions or at least clear decisions, hopefully by consensus, else by vote. I'll try to focus on that in a near future. Jacques [1] https://markmail.org/message/vow3t626t6tsb4cq [2]https://web.archive.org/web/20170530080303/https://msdn.microsoft.com/en-us/library/aa479086.aspx Le 04/09/2018 à 18:12, Taher Alkhateeb a écrit : > 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 <[hidden email]> 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 <[hidden email]> >> 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 >>> >>> |
Re: Should we keep the multi-tenants feature in OFBiz?
|
|
In reply to this post by Jacques Le Roux
Hi there,
On Tue, 4 Sep 2018, Taher Alkhateeb wrote: > ... 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. ... This alone should make the decision a no-brainer. -- 73, Ged. |
Re: Should we keep the multi-tenants feature in OFBiz?
|
|
In reply to this post by taher
Hello,
Very nice analysis, I got the same feeling about multi-tenancy, and prefer using separate instances encapsulated within VM. Gil Le mardi 04 sept. 2018 à 19:12:20 (+0300), Taher Alkhateeb a écrit : > 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 <[hidden email]> 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 <[hidden email]> > > 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 > > > > > > |
RE: Should we keep the multi-tenants feature in OFBiz?
|
|
I find it interesting every single pro and con point is made from a
technical perspective. In reality if there is no business case, there is no need to do a technical analysis unless you are in academia. Carlos -----Original Message----- From: Gil Portenseigne [mailto:[hidden email]] Sent: Friday, September 7, 2018 11:07 AM To: [hidden email] Subject: Re: Should we keep the multi-tenants feature in OFBiz? Hello, Very nice analysis, I got the same feeling about multi-tenancy, and prefer using separate instances encapsulated within VM. Gil Le mardi 04 sept. 2018 à 19:12:20 (+0300), Taher Alkhateeb a écrit : > 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 <[hidden email]> 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 > > <[hidden email]> > > 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 > > > > > > 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-618085128794120192 > > > 4 > > > > > > > > > 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 > > > > > > So IMO why not deprecating the multi-tenants as is now and rather > > > push a multi-instances way? > > > > > > Opinions? > > > > > > Jacques > > > > > > --- This email has been checked for viruses by AVG. https://www.avg.com |
|
|
Hi Carlos,
It would be great to get your perspective on this topic if you desire to share it? I tend to be technically oriented but others are business oriented.. I guess that's the beauty of being in a community to enjoy this variety of opinions and perspectives. On Fri, Sep 7, 2018, 7:15 PM Carlos Cruz <[hidden email]> wrote: > I find it interesting every single pro and con point is made from a > technical perspective. In reality if there is no business case, there is no > need to do a technical analysis unless you are in academia. > > Carlos > > -----Original Message----- > From: Gil Portenseigne [mailto:[hidden email]] > Sent: Friday, September 7, 2018 11:07 AM > To: [hidden email] > Subject: Re: Should we keep the multi-tenants feature in OFBiz? > > Hello, > > Very nice analysis, I got the same feeling about multi-tenancy, and prefer > using separate instances encapsulated within VM. > > Gil > > Le mardi 04 sept. 2018 à 19:12:20 (+0300), Taher Alkhateeb a écrit : > > 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 <[hidden email]> 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 > > > <[hidden email]> > > > 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-618085128794120192 > > > > 4 > > > > > > > > > > > > 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 > > > > > > > > > > > --- > This email has been checked for viruses by AVG. > https://www.avg.com > > |
|
|
In reply to this post by Jacques Le Roux
I agree we should pursue making containerization a first-class citizen in the OFBiz world. It will hasten adoption, reduce development startup headaches, and leverage the multi-billion dollar investments that companies like Docker and Amazon have been making in the space.
Caveat: I’m not fully knowledgeable of the detailed implementation of the multi-tenant functionality, but it appears it was developed before containerization technology hit it stride. Modern web architecture design is container-oriented- spin up and down containers (which could be configured as tenants) as needed. With postgres database hosting platforms like Amazon Aurora enabling instant spin-up of any database size, it would make better architecture sense to publish an official OFBiz docker container architecture which would implement the multi-tenant functionality and push down the different tenant configs via configuration files/docker images. Then the entire deployment of a multi-tenant system can be managed at the dockerfile/composer level in source code control. Moving in this direction makes ofbiz directly compatible with modern hosting platforms and makes it super easy to deploy and manage, and also leverages the large devops community that’s already built around this use case for monitoring, scaling, backup, protection, and all the other day-to-day production headaches that come with managing scaled web application. The multi-tenant approach prolongs the monolithic nature of OFbiz which eventually slows down and cripples development as changes and upgrades become exponentially more difficult. —P > On Sep 2, 2018, at 03:33, Jacques Le Roux <[hidden email]> 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 > |
RE: Should we keep the multi-tenants feature in OFBiz?
|
|
These are my personal opinions and no way shape or form a criticism of anyone especially the developers.
this premise is not correct. I think we are mixing apples and oranges. Docker itself relies on some sort of multi-tenant (broadly speaking and being generic) architecture. A Docker container cannot run independently, Docker containers need some sort of management system (ie Kubernetes or Swarm) therefor right there you have a "multi-tenant" asset to manage the Docker containers. Another example in a very broad way aren't Tomcat and Apache HTTP, MySQL, MS SQL, etc. "multi-tenant" systems? If you're running a server at the back of your shop, running one instance of OFBiz running your one ecommerce site, yes multi-tenant is perhaps an overkill. On the other hand if a company is running OFBiz for its own multi-company needs or hosting needs of many clients, the costs of running many instances of OFBiz will very quickly become prohibitive. The idea the risks associated with a "multi-tenant" environment is any higher than running a Container environment is also incorrect, whether you're running, multi-tenants, VMs or Docker containers you still need to have some sort of redundancy except it becomes more complex and expensive. If the goal of OFBiz is to serve the needs of QuickBooks (figurative) sized clients, yes it should forgo the burden of its "multi-tenant" architecture, on the other hand if it wants to be a true ERP system, then there are many companies that require a "multi-tenant" architecture. Abandoning OFBiz's "multi-tenant" architecture would go against the trend taken by most major ERP solutions like SAP and MS Dynamics. If anyone wants to run OFBiz as a SaaS solution no way around it, economically speaking you NEED to have "multi-tenancy". For an ERP system a Docker implementation in my opinion is a compromise, and one of the reasons I don't prefer Moqui. I personally think OFBiz's mutli-tenancy does not go far enough, for example I think the Login into OFBiz should be more aware of its tenants, and not require a Tenant ID. Again very, very, very broadly speaking Google, Amazon, Microsoft (i.e. Azure) Facebook, IBM (i.e Watson cognitive analytics) and many others are all able to track the last time you said hello to your special friend and recommend you step into the closest flower shop by running some sort of monolithic natured multi-tenant software. Carlos -----Original Message----- From: Paul Mandeltort [mailto:[hidden email]] Sent: Friday, September 7, 2018 1:27 PM To: [hidden email] Subject: Re: Should we keep the multi-tenants feature in OFBiz? I agree we should pursue making containerization a first-class citizen in the OFBiz world. It will hasten adoption, reduce development startup headaches, and leverage the multi-billion dollar investments that companies like Docker and Amazon have been making in the space. Caveat: I’m not fully knowledgeable of the detailed implementation of the multi-tenant functionality, but it appears it was developed before containerization technology hit it stride. Modern web architecture design is container-oriented- spin up and down containers (which could be configured as tenants) as needed. With postgres database hosting platforms like Amazon Aurora enabling instant spin-up of any database size, it would make better architecture sense to publish an official OFBiz docker container architecture which would implement the multi-tenant functionality and push down the different tenant configs via configuration files/docker images. Then the entire deployment of a multi-tenant system can be managed at the dockerfile/composer level in source code control. Moving in this direction makes ofbiz directly compatible with modern hosting platforms and makes it super easy to deploy and manage, and also leverages the large devops community that’s already built around this use case for monitoring, scaling, backup, protection, and all the other day-to-day production headaches that come with managing scaled web application. The multi-tenant approach prolongs the monolithic nature of OFbiz which eventually slows down and cripples development as changes and upgrades become exponentially more difficult. —P > On Sep 2, 2018, at 03:33, Jacques Le Roux <[hidden email]> 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 > --- This email has been checked for viruses by AVG. https://www.avg.com |
|
|
Very interesting input Carlos. Thank you for sharing.
Are you a current user of OFBiz multi-tenancy? Do you find it adequate and reliable in its current form? Regards, Taher Alkhateeb On Fri, Sep 7, 2018, 10:12 PM Carlos Cruz <[hidden email]> wrote: > These are my personal opinions and no way shape or form a criticism of > anyone especially the developers. > > this premise is not correct. I think we are mixing apples and oranges. > Docker itself relies on some sort of multi-tenant (broadly speaking and > being generic) architecture. A Docker container cannot run independently, > Docker containers need some sort of management system (ie Kubernetes or > Swarm) therefor right there you have a "multi-tenant" asset to manage the > Docker containers. Another example in a very broad way aren't Tomcat and > Apache HTTP, MySQL, MS SQL, etc. "multi-tenant" systems? > > If you're running a server at the back of your shop, running one instance > of OFBiz running your one ecommerce site, yes multi-tenant is perhaps an > overkill. On the other hand if a company is running OFBiz for its own > multi-company needs or hosting needs of many clients, the costs of running > many instances of OFBiz will very quickly become prohibitive. The idea the > risks associated with a "multi-tenant" environment is any higher than > running a Container environment is also incorrect, whether you're running, > multi-tenants, VMs or Docker containers you still need to have some sort > of redundancy except it becomes more complex and expensive. > > If the goal of OFBiz is to serve the needs of QuickBooks (figurative) > sized clients, yes it should forgo the burden of its "multi-tenant" > architecture, on the other hand if it wants to be a true ERP system, then > there are many companies that require a "multi-tenant" architecture. > Abandoning OFBiz's "multi-tenant" architecture would go against the trend > taken by most major ERP solutions like SAP and MS Dynamics. If anyone > wants to run OFBiz as a SaaS solution no way around it, economically > speaking you NEED to have "multi-tenancy". For an ERP system a Docker > implementation in my opinion is a compromise, and one of the reasons I > don't prefer Moqui. > > I personally think OFBiz's mutli-tenancy does not go far enough, for > example I think the Login into OFBiz should be more aware of its tenants, > and not require a Tenant ID. > > Again very, very, very broadly speaking Google, Amazon, Microsoft (i.e. > Azure) Facebook, IBM (i.e Watson cognitive analytics) and many others are > all able to track the last time you said hello to your special friend and > recommend you step into the closest flower shop by running some sort of > monolithic natured multi-tenant software. > > > Carlos > > > -----Original Message----- > From: Paul Mandeltort [mailto:[hidden email]] > Sent: Friday, September 7, 2018 1:27 PM > To: [hidden email] > Subject: Re: Should we keep the multi-tenants feature in OFBiz? > > I agree we should pursue making containerization a first-class citizen in > the OFBiz world. It will hasten adoption, reduce development startup > headaches, and leverage the multi-billion dollar investments that companies > like Docker and Amazon have been making in the space. > > Caveat: I’m not fully knowledgeable of the detailed implementation of the > multi-tenant functionality, but it appears it was developed before > containerization technology hit it stride. > > Modern web architecture design is container-oriented- spin up and down > containers (which could be configured as tenants) as needed. > > With postgres database hosting platforms like Amazon Aurora enabling > instant spin-up of any database size, it would make better architecture > sense to publish an official OFBiz docker container architecture which > would implement the multi-tenant functionality and push down the different > tenant configs via configuration files/docker images. Then the entire > deployment of a multi-tenant system can be managed at the > dockerfile/composer level in source code control. > > Moving in this direction makes ofbiz directly compatible with modern > hosting platforms and makes it super easy to deploy and manage, and also > leverages the large devops community that’s already built around this use > case for monitoring, scaling, backup, protection, and all the other > day-to-day production headaches that come with managing scaled web > application. > > The multi-tenant approach prolongs the monolithic nature of OFbiz which > eventually slows down and cripples development as changes and upgrades > become exponentially more difficult. > > —P > > > > On Sep 2, 2018, at 03:33, Jacques Le Roux <[hidden email]> > 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 > > > > > --- > This email has been checked for viruses by AVG. > https://www.avg.com > > |
|
|
Thanks Carlos.
I run a saas Payroll system on ofbiz for my mid size customers, and appreciate the multi-tenancy. I even added another level of multi-tenancy: Very small customers : same db Bigger customers have their own db All running on same code. Regards Mohammed Le ven. 7 sept. 2018 à 22:38, Taher Alkhateeb <[hidden email]> a écrit : > Very interesting input Carlos. Thank you for sharing. > > Are you a current user of OFBiz multi-tenancy? Do you find it adequate and > reliable in its current form? > > Regards, > Taher Alkhateeb > > > On Fri, Sep 7, 2018, 10:12 PM Carlos Cruz <carlosd @nbtbizcapital.com > <[hidden email]>> wrote: > > > These are my personal opinions and no way shape or form a criticism of > > anyone especially the developers. > > > > this premise is not correct. I think we are mixing apples and oranges. > > Docker itself relies on some sort of multi-tenant (broadly speaking and > > being generic) architecture. A Docker container cannot run independently, > > Docker containers need some sort of management system (ie Kubernetes or > > Swarm) therefor right there you have a "multi-tenant" asset to manage the > > Docker containers. Another example in a very broad way aren't Tomcat and > > Apache HTTP, MySQL, MS SQL, etc. "multi-tenant" systems? > > > > If you're running a server at the back of your shop, running one instance > > of OFBiz running your one ecommerce site, yes multi-tenant is perhaps an > > overkill. On the other hand if a company is running OFBiz for its own > > multi-company needs or hosting needs of many clients, the costs of > running > > many instances of OFBiz will very quickly become prohibitive. The idea > the > > risks associated with a "multi-tenant" environment is any higher than > > running a Container environment is also incorrect, whether you're > running, > > multi-tenants, VMs or Docker containers you still need to have some sort > > of redundancy except it becomes more complex and expensive. > > > > If the goal of OFBiz is to serve the needs of QuickBooks (figurative) > > sized clients, yes it should forgo the burden of its "multi-tenant" > > architecture, on the other hand if it wants to be a true ERP system, then > > there are many companies that require a "multi-tenant" architecture. > > Abandoning OFBiz's "multi-tenant" architecture would go against the trend > > taken by most major ERP solutions like SAP and MS Dynamics. If anyone > > wants to run OFBiz as a SaaS solution no way around it, economically > > speaking you NEED to have "multi-tenancy". For an ERP system a Docker > > implementation in my opinion is a compromise, and one of the reasons I > > don't prefer Moqui. > > > > I personally think OFBiz's mutli-tenancy does not go far enough, for > > example I think the Login into OFBiz should be more aware of its tenants, > > and not require a Tenant ID. > > > > Again very, very, very broadly speaking Google, Amazon, Microsoft (i.e. > > Azure) Facebook, IBM (i.e Watson cognitive analytics) and many others are > > all able to track the last time you said hello to your special friend and > > recommend you step into the closest flower shop by running some sort of > > monolithic natured multi-tenant software. > > > > > > Carlos > > > > > > -----Original Message----- > > From: Paul Mandeltort [mailto:[hidden email]] > > Sent: Friday, September 7, 2018 1:27 PM > > To: [hidden email] > > Subject: Re: Should we keep the multi-tenants feature in OFBiz? > > > > I agree we should pursue making containerization a first-class citizen in > > the OFBiz world. It will hasten adoption, reduce development startup > > headaches, and leverage the multi-billion dollar investments that > companies > > like Docker and Amazon have been making in the space. > > > > Caveat: I’m not fully knowledgeable of the detailed implementation of the > > multi-tenant functionality, but it appears it was developed before > > containerization technology hit it stride. > > > > Modern web architecture design is container-oriented- spin up and down > > containers (which could be configured as tenants) as needed. > > > > With postgres database hosting platforms like Amazon Aurora enabling > > instant spin-up of any database size, it would make better architecture > > sense to publish an official OFBiz docker container architecture which > > would implement the multi-tenant functionality and push down the > different > > tenant configs via configuration files/docker images. Then the entire > > deployment of a multi-tenant system can be managed at the > > dockerfile/composer level in source code control. > > > > Moving in this direction makes ofbiz directly compatible with modern > > hosting platforms and makes it super easy to deploy and manage, and also > > leverages the large devops community that’s already built around this use > > case for monitoring, scaling, backup, protection, and all the other > > day-to-day production headaches that come with managing scaled web > > application. > > > > The multi-tenant approach prolongs the monolithic nature of OFbiz which > > eventually slows down and cripples development as changes and upgrades > > become exponentially more difficult. > > > > —P > > > > > > > On Sep 2, 2018, at 03:33, Jacques Le Roux < > [hidden email]> > > 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 > > > > > > > > > --- > > This email has been checked for viruses by AVG. > > https://www.avg.com > > > > > Envoyé avec Gmail Mobile |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |