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. 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. 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. Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] 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
