Given that we are heading toward microservices architectures wherein isolation of data to bounded contexts is of critical importance, I think that the kind of multi-tenancy we're talking about here is on the decline.
We're probably well off going after single tenant or departmental grids for now and not complicating life too much by trying to deal with competing concerns from multi-tenancy. -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: 631-835-4771 On Mon, Jan 9, 2017 at 7:57 PM, Kirk Lund <kl...@apache.org> wrote: > I have some questions from the previous discussion thread about adding in > some sort of application isolation feature to Apache Geode. > > "application code" -- defined as a Function or plain old application code > that uses the Geode APIs including Cache and Region > > There is more than one level of code in which a user might expect this > isolation. > > 1) Shared Cache and Region > > This is the case where the user wants to have two different realms of > "application code" deployed but share the same Cache and Regions. For > example, one Function could use different versions of the same domain > classes used by another Function. > > Class loader isolation would wrap around "application code" only. > > To provide correct behavior, Geode would have to provide a mechanism to > always store Region entries in serialized form. Some current behavior would > have to change. For example, if you do a put into a non-PR region that is > in the local JVM, it will be stored in deserialized form if that's the form > that was passed into the put operation. A different Function with a > different version of the domain class couldn't do a put without changing > the semantics in some way. > > 2) Separate Cache and Region > > This is the case where the user wants "application code" to use the same > Region name and its own Indexes without sharing data or conflicting with > each other in anyway. > > Class loader isolation would wrap around the Cache, its Regions and all > Geode code that interacts with the data or the "application code." > > Existing behavior would remain unchanged but the distribution layer would > have to change in order to handle multiple Cache instances. > > 3) Separate cluster membership > > This is the case where the user wants each application to have its own > membership in the Apache Geode cluster. > > Class loader isolation would wrap around everything in Apache Geode > including membership. > > Two different applications could be different members in the same cluster > or they could be members of different clusters. One could be a client and > another could be a server. > > Which of the above scenarios was everyone envisioning during the discussion > about deploying multiple versions of domain classes and 3rd party > dependencies? > > Thanks, > Kirk >
