AEM Multi-Tenancy Approach + RDE, Dispatcher

Question

In a AEM AMS to AEM as a Cloud Service Migration engagement, we are dealing with 40 applications (100+ AEM Templates, 4K AEM Components) each having its own repository. We are planning to follow AEM Multi-Tenancy Best Practices to have each application tenant as a submodule to the parent aggregator using Git submodule approach. From aggregator sync mechanism will sync the code artefacts into Adobe Cloud Git. These applications share resources in terms of assets, configurations (mutable) and baseline AEM components (immutable). These are currently hosted on different 6.* versions of AEM (6.4, 6.5) and couple of them use different Java versions to compile (Java 17). Other applications use Java 11. Applications come from different Business Units and have different release cycles.

We did think of taking this opportunity a reverse way - First optimize AEM Applications, increase reusability, align to same standards and then Migrate to Cloud. But there are other business constraints that leads us to go for Cloud Migration first.

On Cloud Migration we have thought about -

1. Grouping of applications by related Business Units into multiple (3 or 4) aggregators (multiple aggregators -> multiple Adobe Cloud Programs)

2. Mono Repo (each application -> 1 Adobe Cloud Program)

3. Single Aggregator which would have ALL the 40 applications (Git doesn't have an upper cap we believe on number of submodules that an aggregator can have, but concern is the deployment time which is more than 1 hour per deployment).

Queries -

Looking at resource sharing, more reusability of AEM Templates, Components, integrations gateway, cost for maintainability, Which one would you propose and why ?

How would AIO CLI Deployment work for each application team with feature development on RDEs ? We need that to be simple, quick-n-fast. If we plan for CLI to be executed on the aggregator then the whole purpose of RDE and quicker feature development is lost. There can be grouped aggregators but we are looking for something really quick and easy for developers daily dev activities so that the speed of delivery doesn't get affected significantly. Please share your thoughts.

Dispatcher. There can be only 1 dispatcher archive package which can be deployed on Cloud. We are thinking of a Common Repository with a Single Dispatcher Module on Client Aggregator Repository and Adobe Cloud Git where all dispatchers will need to be "merged" or "classified" as far as possible. Please recommend if this sounds fine, or if you have other ideas and Best Practices.

What will be your recommendations for Production Rollback approach ?

It's a tricky solution to harvest, but an interesting one for sure. Thank You so much in advance for all your views, advises, recommendations. These will only enrich us more and more.

Best Regards.

Saravanan_Dharmaraj · Accepted Answer

Hi @som_adobe  On Cloud migrationEven if you want to go to cloud first you still need consolidate all these applications which are running in diff AEM version and Java version into one version and be cloud ready in terms of code practice and fixing all the vulnerabilities to use the cloud manager for the deployment. Its not going to straight forward way to cloud without fixing CM compatibility I agree to Grouping application based on BU. Adding all 40 application in single aggregator and deploying will take long time. You need to think about pre prod scenario on how you can do quick deployment. There is no quick deployment with 40 sub modules. Or you need to give the application owner to deploy only their code directly DEV and QA. But use CM mono repo with sub modules for Stage and PROD. UI Apps4k components is nightmare &#128578; . Definitely you can consolidate the common components , you need to have central team to manage it and the deployment. DispatcherThere will one dispatcher repo and added as submodule and should be managed by central team but can separate the config files based on domain. I don’t know if all the 40 apps under same domain or multiple domains. RollbackBefore every CM deployment the backup is done. If you are in situation to rollback during deployment, that’s the best backup to restore. If only one application's submodule code is derailing & causing rollback to the entire deployment of other 39 Applications then it will be bad. That’s why you may need to think about grouping application by BUs and reduce this risk. You can have different topology altogether. That’s my 2 cents based on my experience of managing 10 applications with 5 domains. So many unknowns here to give to clear opinion, this is just a suggestion. Hope it helps!

joerghoh · Answer

I guess that the biggest issue will have is the consolidation of multiple applications; I think that the technical constraints are solveable, but the bigger one will the management aspect:

* Consolidate multiple development teams

* each of them operating under different constraints (e.g. budget, focus on feature vs maintenance)

* the coordination and prioritization of topics between these teams, especially when it comes to global initiatives like consolidation of components etc.

* you need to establish a proper quality program, because otherwise issues in one team have a direct impact on everyone else. And that quality program needs to convince every stakeholder, that quality is under control.

* 1 AEM CS program, and so many stakeholders. You need to find common ground regarding deployment dates etc, especially when stakeholders consider any change as a risk. Worst case: You end up paralyzed, because you will have exactly 2 weeks in a year, when there is no critical business event on any business unit. Not to mention the ongoing AEM CS maintenance releases.

You are driving a massive change, and I would equally focus on the technology part as well as on the change management part.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded