Hosting Multiple Tenants on AEM
Implementing Adobe Experience Manager usually is a strategic investment.
Naturally, you want to get the most out of your investment and host more than a single website on the platform to create synergies in development and operation costs.
So, what is the best way to host multiple sites or multiple tenants on a single platform?
It depends!
This is the first in a series of articles on the topic “Multi Tenancy”. We will define a baseline on common terminology and outline what exactly your decisions depend on.
For the sake of this and the following articles we want to agree on some basic definitions of terms. You might use these terms differently in your organization, and this is fine. But to avoid misconceptions, we need to agree on a common terminology:
Multi-Site: Hosting several sites using the very same code base (backend and frontend). Typical use case: Localization and translation.
Multi-Brand: Hosting multiple sites that look different but share a common logical structure and back-end code base.
Multi-Tenant: Hosting multiple sites with individual and isolated code bases
This can be seen as a continuum, where multi-site requires the lowest amount of isolation and multi-tenant the highest.
In addition, we have the terms
Multi-Vendor: Platform allows multiple independent teams or vendors to contribute.
Multi-Environment-Platform: A set of independent environments, each hosting a number of tenants.
These can be seen as different dimensions supplementary to the continuum above.
Multi Site and Multi Tenancy
Simply put, a web site consists of code and content. Content is what you want to display (text, images). Code defines how the content is rendered and delivered (structure and layout).
Multi-Site Platform
On a multi-site platform, you have multiple sites with individual content typically served from multiple domains. The content is maintained by different teams or roles. Content can be either isolated or inherited from a global content master. Think for example of a brand website, that is translated into multiple languages and adapted to local markets. The content differs, but the basic structure and layout of all sites are basically the same.
Content in AEM is organized in a hierarchical tree. Access control can be defined at any level of any node in the tree. Isolation of content is straight forward. In AEM, roles can be defined that restrict or allow access to certain paths in the content tree. If a role does not have access to a certain sub-tree, it simply appears to be not there at all.
Note however, this is virtual only, and not “true” site isolation: If you have multiple roles, you might see multiple sites at once. Nevertheless, access control based isolation is a good approximation, and often this is even desired. Super users often do want to see all sites in their domain without having to switch context.
Under this definition, all sites share the same code base: Templates, components, business logic and styles.
Multi-Brand Platform
In the multi brand scenario, also the design of multiple sites can differ. Templates and components are shared, but each site can have a different skin attached.
Multi-Tenant Platform
Multiple tenants in contrast means, each site can bring their own individual code base for rendering or integration. Isolation happens at code- and content level.
Think of an enterprise that has a portfolio of different use cases like B2B, B2C, intranet, extranet, public website, etc.
These kinds of differences make it necessary to have — at least partly — different code bases.
“Partly” — because you don’t want to start from scratch for each use case but still want to leverage synergies where possible and only implement custom functionality where necessary. So — not only content needs to be isolated per tenant — but also the code.
Note: A platform could host multiple sites that behave differently based on configurations set at runtime. The platform could offer feature flags to turn on several functions for selected sites. As of the definition above, this falls into the category “multi-brand” as the code base is shared and configuration happens at runtime.
A similar argument can be made for multiple sites sharing the same backend-code but allows individual skinning. As this can be configured at runtime, this is multi-brand management.
We will see in subsequent articles that AEM does not support strong code isolation at runtime. There is always a necessity to control isolation at build-time with additional governance, and that requires some measure of good citizenship of all tenants.
You can use one tenant code to rollout multiple sites. For example, you would have different types of sites like Brands, Investor Relations and Intranet — each hosting one or more sites.
The illustration below shows seven sites based on three tenants.
Multi-Vendor or Multi-Team approach
The code for different tenants can be implemented by either
- a single team
- multiple teams of the same partner or
- multiple partners / multiple vendors
- A mix of internal / partner teams
Delivering all tenants by one team requires less governance and chances are, that code can be shared between tenants. Also, chances, that one tenant impacts another tenant is reduced: A single team knows the whole platform and could avoid side-effects — if the same team remains constant over a long time. If team members change, you would not consider it the same “one” team any longer.
A single team is capable of delivering one tenant a time, only. If your rollout strategy is linear — one tenant at a time — this might be a good fit.
Most likely, you want to implement multiple tenants in parallel. In that case, you end up with multiple teams or multiple vendors.
Multiple teams make it harder to find synergies. Each team is committed to their own tenant and finding synergies is creating cross-project dependencies and impediments.
You will have to balance speed of implementation at the risk of implementing the same functionality twice and leveraging synergies at the cost of longer implementation duration due to additional coordination.
Vendor isolation
It is advised to define a set of rules what individual tenants can do and must not do to prevent cross-site side-effects. So, a minimum of governance is required in any case. More on that in a later article.
Multiple independent vendors create an extra challenge: Coordination between the teams does not come naturally. And if something breaks, it could be hard to pinpoint who is responsible. If you consider a multi-vendor approach, you should prepare for an extra level of governance and make sure deliverables are cross-examined by a central team before rolling out onto the platform.
Multi-Environment Platform
True physical isolation in AEM can only be achieved with a multi environment setup.
A multi environment platform consists of more than one AEM system. While it requires more effort and costs to host and maintain multiple systems, it does provide benefits with regards to isolation and removing dependencies between different teams and organizations.
In fact, we have seen both cases: Organizations who consolidate their tenants on one AEM system to reduce costs and organizations who split up a formerly shared platform to provide a greater level of autonomy and independence to each department and reduce the need for coordination.
Multiple environments improve the performance: Before you scale out one environment by adding more servers you could think of grouping tenants into independent units and host them on multiple, isolated systems.
There is no right or wrong. The system you build needs to resemble your organizational structure.
Sharing resources on a Multi-Environment Platform
Having multiple physical AEM environments does not necessarily mean that every department fights on their own. There is still enough opportunity for synergies, i.e.
- Environments can be maintained by a single ops team
- Projects can use the same Application Lifecycle systems (documentation, project planning, version control and continuous integration)
- Knowledge can be shared between teams.
- 3rd party applications can be shared (CDN, Firewall, PIM, chatbot, mail server…)
- Services requiring special knowledge can be shared (Web server configuration, DNS, certificate management, …)
Even team resources can be shared. Running on multiple systems does not mean each system is implemented by individual teams. Sometimes there are hard reasons to run multiple platforms, i.e. you may not want to run the intranet and the public website on the same server. Or you want to locate the backend server closer to editors to reduce latency.
So far, we have leveled the ground with some common terminology. You should have a good feeling for how multi tenancy requires a number of strategic decisions to be made on multiple dimensions.
Multi Tenancy on AEM
Hosting multiple brands requires a different approach than hosting an intranet and an extranet on the same platform. The former have a higher degree of similarity, the latter can be quite different. This requires different technical approaches.
Similarity / dissimilarity is a continuum. On one end of the spectrum, we have sites that are 100% identical in structure — only layout and colors differ. A new tenant can be defined as a simple set of style definitions.
On the other end, you have sites that have nothing in common. Tenants are defined by completely isolated sets of backend- and frontend code. We will provide guidelines for each in a follow-up article.
For the time being, it is sufficient to recognize there is no one-size-fits-all multi-tenant approach.
A word of warning: Enterprises often assume they are on the lower end of the continuum: They assume that sites can use the same structure and same components. In our experience, this is rarely the case. Brands often have autonomous brand management departments. And coordination between departments can become an impediment.
A pure “skinning” approach is only indicated, where global brand management is strictly centralized and local brands have advisory roles, only. Typically, enterprises with decentralized brand management are better off with approaches that are somewhere in the middle of the continuum sketched above.
Content Management Paradigms
Related to the discussion above is the differentiation of two content management philosophies or paradigms:
- generic website builder approach and a
- structured / semantic content management approach
Note: These two paradigms are endpoints of a spectrum. In practice a solution lands somewhere in between, and you will have a hybrid approach borrowing ideas from both ends. It still is a good exercise to define a major paradigm in your project to provide a consistent editing experience.
The website-builder approach, tries to define generic components that are applicable in all tenants. Components therefore provide a larger number of options to make them applicable for more use cases. Layout of pages is not defined by standardized templates.
The website builder approach offers more flexibility. Pages are designed individually, which requires a more thorough training of the authors.
The content management approach is on the other end of the spectrum: Capabilities of individual components are reduced, and components are specialized for specific use cases. Also, you have special purpose page templates, which define the layout and capabilities. You’ll have more components and templates — but you’ll define rules how to combine them to keep the component library manageable.
Example: If you are an automotive company, a “generic” component could be a hero banner, whereas a “specialized” component could be a component to display the key facts of a car model (price, seats, range) in a structured manner.
Authors in content management system require less training and the content editing process is faster and cheaper because the creation process is guided and can be outsourced to lesser trained staff.
On the other hand, you’ll end up developing more components, and gathering requirements needs more diligence.
On multi-tenant platforms you might be tempted to aim for the “generic” approach, because generic components provide a higher re-usability among different tenants. This might be the proper choice. But we want to raise awareness that this has to be a conscious decision, balancing all pros and cons:
Choose the structured approach, when
- Content is produced in high volume at high frequency
- Authors have a low level of knowledge about layout/design
- Staff changes frequently and cannot be trained decently
- Corporate design and homogeneity are a primary requirement
- Focus is on content and to a lesser degree on individual page layouts
- You want to re-use the content on secondary channels
Choose generic approach, when
- Content does not change frequently
- You have a low number of static pages to manage
- Content is authored by a web agency
- Authoring staff remains consistent over a longer time
- You have time for elaborate briefing and QA on individual content pages
- Creativity is required, e.g. layout requirements change from page to page for seasonal campaigns
- Web is the only channel
To illustrate further, a structured approach could be chosen for a brand site, the generic approach is suitable campaign sites with a shorter live span and no to little changes after launch.
As always, these are the extreme endpoints on a spectrum of philosophies and there are nuances in between. Be aware there are these different philosophies, and you choose the right for your use case.
Note, that in the comparison above, multi-tenancy is not among the primary drivers for a decision for a paradigm. In our opinion, there are additional important factors to consider.
You might be tempted to choose a generic approach if you are planning to launch hundreds of websites in the next years. While this reduces IT costs, it will increase the editing costs.
Often, we implement hybrid approaches, where the generic components are used for editorial contents and structured pages for structured data like products.
Key to a structured content-management approach is a good working relation with the development team and a well-oiled requirements/delivery pipeline. When your requirements/delivery process is slow and inflexible, you might be better off with generic/flexible components to reduce external dependencies.
AEM-specific challenges with Multi Tenancy
AEM can host multiple independent tenants — in a cooperative manner. That means, tenants are not “physically” isolated by the system, but the tenants have to mutually agree on rules and boundaries and make sure they are not overwriting other tenants’ code- or content structure. System-wide, tenant-crossing features and configurations are handled in a dedicated module and are not to be set by individual tenants.
This requires that you define some rules upfront what each tenant can do and must not do. A central governance to supervise compliance with these rules is a good idea, too. This can be implemented as part of the QA process or implemented in Code Quality rules in a build pipeline.
Typical cases where tenants have to be actively confined to their boundaries are:
Namespaces
- Where can tenant store their artifacts? Their source code, libraries, configuration files and default content.
Global services and configuration
- Individual tenants should not be allowed to configure global services such as out-of-the box OSGi services, path-mappings, servlet filters, etc.
Access control
- Tenants should not be allowed to define Access Control Entries. ACLs provide a means to isolate tenants. These ACEs must be defined centrally to prevent tenants to escalate their privileges.
Excessive use of resources
- AEM does not maintain quotas for tenants. All use the same resources, such as CPU capacity, memory, I/O bandwidth and thread pools. Tenants should keep their own footprint reasonably small and should not excessively use the above resources. Indexing content, proper caching and memory hygiene is key here.
We will elaborate on technical details in a later article.
Consolidation projects
Before we wrap up, one last piece of warning on the strategic level: Multiple tenants are often related to consolidation projects. You already have hundreds of sites scattered on dozens of individual Content Management Platforms and you want to consolidate them on a single platform. Consolidation and migration are much harder than the hosting itself. Even if you have defined and implemented a platform to cover all future requirements, this does not mean that you also cover all past requirements.
The legacy platforms likely have been developed in isolation and have little to nothing in common. Your future vision probably does not consider all (undocumented) special cases from the legacy systems.
In consequence, squeezing the legacy content structure into a now unified structure often is not possible. The structural mismatch between the legacy content and the to-be content often is too large for automatic content migration. Plan for semi-manual migration and extensive content re-editing. Content migration — in our experience — is the most underrated task. It should begin as early as possible in the project.
Sometimes starting afresh is also not a bad idea, as it gives you the chance to also re-visit and re-evaluate content.
Wrapping up
Initially, we wanted to write a single article on “best practice” for multi tenancy on AEM platforms. But when we started the discussion, it turned out, that multi tenancy has so many aspects and dimensions. There is not one best practice, but a range of strategic decisions to be made up-front to derive the ideal solution for your use case.
We hope that we have sensitized you a little bit for the key aspects to consider and convinced you to define strategic and architectural paradigms first before starting the implementation.
Key takeaways:
There is no one best practice - the best approach for you depends on
- the nature of the content
- the frequency of site launches and content changes
- the skill profile of your editors
- the organisational setup, e.g. central vs. distributed and in-house vs. external development
A couple of sites are implemented and changed quickly in AEM. But if you are planning to host dozens of tenants on your platform, the impact of each unfortunate decision will be multiplied. Carefully planning is key to scale the platform.
This was the first article of a series on multi tenancy. The following articles will among others cover the following topics:
- Isolating tenants on AEM
- Sharing and separating tenant implementations
- Content management vs. Web site builder.
- Governing multiple tenants
- Scaffolding sites and tenants
- Multi-environment strategies
- Muti-vendor strategies
- Migration and consolidation
