On Mon, Jan 3, 2011 at 12:53 PM, Ivo Ladage-van Doorn <Ivo.Ladage-vanDoorn at gxsoftware.com> wrote: > Hi Marcel, > > My biggest concern is that if we now choose that one OSGi container can only > host one tenant, there is no way back. If we follow that path we will not > design Amdatu to be tenant aware in its core, as there is always only one > tenant hosted by the container. If for any reason (including the ones we do > not oversee right now) we come to the conclusion that this was not a good > choice later on, it will be quite a challenge to fix it. If on the other hand > we design Amdatu in its core to deal with the fact that one container may > host multiple tenants, we can have it both ways. > > One of the use cases in which 1 tenant per container could be an issue is a > customer we developed a solution for last year. The customer I'm talking > about is an 'umbrella organization' for the catering industry. The > organization provides services to catering entrepreneurs. One of those > services is the hosting of their (basic and internal) website. Each > entrepreneur may request such a website and will be provided with logins for > he and his employees. The entrepreneur can provide a logo, add some text, > define open and close times, etc. Such an entrepreneur is a good example of a > tenant. > Of course, there are many entrepreneurs (in this case, we agreed to support > up to 5000) and each one of them may request this website. The amount of data > stored for each tenant is very limited; a logo, some text and some logins, bu > tthat's about it. And so this was all hosted by a single application server. > Many entrepreneurs requested such a website, but are not effectively using > it. The single app server can host thousands of tenants without problems. > So assume in the Amdatu case we would launch a container for each tenant > (including the ones that requested the site once but never actually use it). > In this case most functionality is shared by all tenants, only a small piece > of the application is tenant specific. So we would probably end up putting > the tenant unware services on a separate container, and remote service calls > would be all over the place as almost each method invocation needs to be > remoted (or we install the service locally, but that would increase waste of > resources). > There would be a lot of overhead starting separate containers for each tenant > and remoting service calls as opposed to just one container with a few tenant > aware services. Also managing (provisioning, updating) 1 container instead of > 5000 seems much easier, faster and less error-prone to me. > So by just looking at this use case I would say that one container serving > all tenants would be the best solution, which is exactly the way we > implemented it in this project.
Thoughts on this use case: 1) Is this a valid use case for 'Platform level Multi-tenancy' (http://www.amdatu.org/confluence/display/Amdatu/Multi-tenancy)? Where is the line between tenant and user? Obvisouly it would be ridiculous to spawn 5000 tenants in one runtime if they are inactive 9 out of 10 times, even in a single container scenario this would raise my eyebrows as you are spawning tens of thousands of services into one registry. As there is no apparent difference in (software) configuration between the entrepreneurs is this not just customization that could be handled with a single tenant? 2) I think the 'single server' argument is kind of void. We are not designing the most efficient single server non clusterable use case specific app server, rather the opposite. The real question is whether we could cope (by scaling) with the valid use cases especially beyond an a prio 5000 non functional. Wether that is by scaling out at 10 or 10 thousand tenants will largely depend on the particular application characteristics. 3) Note that a container per tenant does NOT mean a container for every tenant has to be active all the time per se. The tenant lifecycle could include a sleep state to be awakend by the resolver upon request (or whatever). This is probbably true and something to be considered for both scenarios when we are talking about large numbers of tenants. Regards, Bram
