Multi Tenancy Issues

Multi-tenancy means different things to different people, and in AEM there are multiple variations that need to be thought about.

Multiple sites
This really means using MSM for rolling out content to subsites.

When using MSM as it is a quite intensive part of AEM it is recommended to not roll out content to many levels i.e. "master → site → language" is good but if you put more levels in such as "master → regional master → main site → language" with a side relation of "master → regional master → main site → second site → language" while it will work, when you get a significant number of sites you will notice that your AEM instance will start to slow down as AEM tries to work out the inheritance of content and where it should get the values to display.

Multiple Applications
This is the main multi-tenancy issue and requires a careful coding of the applications installed. There is a lot of configuration available to the application that can be modified, however, some of that configuration is global so it will affect all applications that are using the server.

The biggest ones I have seen modified that cause problems are the LoginSelector and RootMappings. While these are handy to modify so your application handles security and default pages nicely, these are all controllable at the content level so should be avoided.

A lot of the code that can be created in AEM does not understand that there could be multiple applications running. i.e. if you write an event listener, it will get events for your application as well as every other application on the server, including messages that AEM itself is generating. When building code like this you need to be very careful that your code understands where your content will be and the only process for content it is supposed to work with.

Queues are the same if you add messages into a queue that is used by another application it is possible that you won't get the messages that you are expecting.

Multiple Applications in the same domain space
This is a secondary issue and comes more down to design. If you have multiple applications that all run in the same content space you should take advantage of the knowledge of what other applications are available so that you don't duplicate code. i.e share base page structure or components. Don't duplicate services that are doing the same thing.

Multiple publishers
While this is usually the smallest of the multi-tenancy issues, if as part of the application you are storing data in the jcr:repository, or updating the user's profile you will need to do some replication work to make sure the content is replicated across to the other publishers. There are multiple ways of doing this.

Reverse Replication
You can reverse replicate the data. Any data that is user-generated should be stored in /content/usergenerated/<app> so that it can be replicated. Set up a workflow launcher that will run on the publisher and monitor any change or create events in that folder and call the reverse replication workflow. You will then need to create a workflow on the author that replicates the content down to the other publishers.

One thing to note, this will not replicate user/group data.

Tunneling
For user/group data you can use sling tunneling as described in the Adobe documentation.

As I haven't done much work around this I can't explain it fully but it allows the user content to be passed up to the author and back down to the other publishers.