Hi all, On Tue, Nov 9, 2010 at 11:08 AM, Ivo Ladage-van Doorn <Ivo.Ladage-vanDoorn at gxsoftware.com> wrote: > Hi Marcel, > > Some comments regarding your alternatives: > > 1) Although this seems like an interesting approach, I don't see how we could > support full "Tenant awareness" this way. Especially in a SaaS environment > where the cloud runs the application of many tenants, I think this approach > would lead to major issues. In SaaS I would expect that one Amdatu node hosts > an application accessible by a particular set of tenants that bought a > license for that application. I wouldn't want to be forced to boot 100 OSGi > containers running exactly the same application components since 100 > different Tenants are licensed to use it. Instead I would expect each node in > the Amdatu cluster running a single Amdatu instance (OSGi container) hosting > a particular set of application components for a particular set of Tenants. > When 1 tenant expands its license, there would be no need to setup an > additional OSGi container/Amdatu instance.
I'm not sure how we should address this either, but I agree with Marcel that the current model seems rather complex allready and will probably become more everso (/me thinking about security and software versioning) while at it is providing no (real) isolation (at all) or even security. Also note the "booting 100 OSGi containers" really sounds like something but please note that for example felix is only 300K and you can boot it in under a second. On the plus side this would simplify the programming model, it would provide a nice natural boundry for (some) isolation and gives us the concept of a "Tenant Lifecycle"? > In a SaaS environment hosting the application of many many tenants, running > an OSGi container on each node in the cluster for each tenant would > significantly increase memory footprint/CPU usage/maintenance costs and so on > per tenant. Especially when a node runs a very heavy application which is > only used occasionally, the overhead of running this app for each tenant > would be enormous. And so, I don't think this is the way to go. I think you might be jumping to conclusions. Please note the comment about sharing through remote services which sounds like an elegant way to wire things up. Note that I agree about not wanting to deploy and boot 100 times 100mb of application code, but I like to keep on open mind on this one :) > 2) I didn't attend ApacheCon so it's not very clear to me what this is really > about, but so far I don't see it as an alternative, more as an extension to > our way of thinking about Tenant awareness. I like it and IMHO QoS should be part of our model, but the bottomline is that we should think about what we mean by saying "Amdatu is multi-tenant" in terms of isolation, security, QoS and flexibility(!) before pursuing or dismissing mechanisms. Regards, Bram > > -----Original Message----- > From: amdatu-developers-bounces at amdatu.org > [mailto:amdatu-developers-bounces at amdatu.org] On Behalf Of Marcel Offermans > Sent: dinsdag 9 november 2010 10:21 > To: amdatu-developers at amdatu.org > Subject: [Amdatu-developers] Multi Tenancy... > > I'm not quite sure if we're doing multi tenancy the right way yet. I'm still > considering a couple of alternatives here: > > 1) Running each tenant in its own OSGi container. This does not imply each > OSGi container actually runs in its own JVM, as it's easy to create a single > JVM that runs multiple, isolated containers. Advantages of this system would > be mostly a vastly simplified programming model as you don't need to worry > about tenants in your application. If services would need to be shared > between tenants, we could use remote services to "deploy them to each > container". > > 2) Using a notion of a tenant that is a bit more abstract, where each tenant > (or customer) gets not only simply isolation but also a specific quality of > service linked to that tenant. Paul Fremantle talks about this in his > ApacheCon presentation on "building cloud native software" (see > http://pzf.fremantle.org/2010/11/building-cloud-native-software.html) where > he discusses the merits of having "coach, business and private jet" service > levels. > > Greetings, Marcel > > > _______________________________________________ > Amdatu-developers mailing list > Amdatu-developers at amdatu.org > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > > _______________________________________________ > Amdatu-developers mailing list > Amdatu-developers at amdatu.org > http://lists.amdatu.org/mailman/listinfo/amdatu-developers >
