Re: Should we keep the multi-tenants feature in OFBiz?
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 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 > 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:p...@marcospec.com] > > Sent: Friday, September 7, 2018 1:27 PM > > To: user@ofbiz.apache.org > > 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 > > deplo
Re: Should we keep the multi-tenants feature in OFBiz?
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 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:p...@marcospec.com] > Sent: Friday, September 7, 2018 1:27 PM > To: user@ofbiz.apache.org > 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
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:p...@marcospec.com] Sent: Friday, September 7, 2018 1:27 PM To: user@ofbiz.apache.org 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 > 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
Re: Should we keep the multi-tenants feature in OFBiz?
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 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:gil.portensei...@nereide.fr] > Sent: Friday, September 7, 2018 11:07 AM > To: user@ofbiz.apache.org > 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 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 > > > > > > 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 > > > > > > > > > > > > h
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:gil.portensei...@nereide.fr] Sent: Friday, September 7, 2018 11:07 AM To: user@ofbiz.apache.org 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 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 > > > > 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
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 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 > > > > 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?
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?
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 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 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 was referring to a situation where multi tenancy was not used Original Message Subject: Re: Should we keep the multi-tenants feature in OFBiz? From: Taher Alkhateeb Date: Tue, September 04, 2018 9:23 pm To: user@ofbiz.apache.org 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 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 > Date: Tue, September 04, 2018 9:12 am > To: user@ofbiz.apache.org > > 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 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
Re: Should we keep the multi-tenants feature in OFBiz?
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 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 > Date: Tue, September 04, 2018 9:12 am > To: user@ofbiz.apache.org > > 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 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 > > > > > > >
RE: Should we keep the multi-tenants feature in OFBiz?
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 Date: Tue, September 04, 2018 9:12 am To: user@ofbiz.apache.org 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 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 > 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?
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 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 > 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?
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 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 > >
