Handling Runmodes - AMS to AEMaaCS

[NageshRaja]

Hey folks,

I am working on a project migration in AEM from AMS to Cloud.

The AMS codebase has an awful lot of runmodes and runmode based configurations.

They have Dev, Dev1 to Dev6 - 7 DEV runmodes; 5 QA runmodes and more of Stage and Prod runmodes.

Currently they are using a sandbox program which has 1 RDE, 1 Dev, 1 Stage, 1 Prod environment configured.

We are targeting 1 Dev runmode to map to RDE; 1 QA to Dev, 1 Stage to Stage and 1 Prod to Prod config mapped.

Once the customer moves out of sandbox after testing the cloud environment - should we look at a way to reduce the runmodes defined in AMS or should we simply spin off more instances in Cloud for Dev?

They have separate instances for performance as well hence a whole lot of code written on basis of runmodes.

So couple of questions here -

1. Is RDE a valid runmode? Is it possible to map configs from one of the dev explicitly to RDE?

This query because RDE does deployment by aio plugin and isn't really deployment pipeline based.

2. The site is multi-tenant based. So we have multiple domains. Is it possible to set the hostname as an environment variable and then use it dynamically for each domain? Does RDE also allow domain setup?

3. For a large project with so many runmodes, what is the best way to simplify?

[daniel-strmecki]

Hi @NageshRaja,

my thoughts on this:

1) You should for sure look to reduce the number of runmodes. The decision if you need an additional environment should not be based on legacy code and legacy ways of working. In case you do have good reasons to add additional DEV environments and the client can afford it, then go for it. Some examples that make sense are: separate DEV and QA testing, have INT for integration testing where code from multiple teams gets merged and tested.

2) RDE is a valid run mode, so you can use the config.author.rde folder for example

3) Why would you set a hostname as an environment variable? You can have different domains that map to different content trees in AEM. Then you can use either Sling Mapping or Dispatcher to map different domains to the correct content.

4) I think that a lot of the stuff that is currently managed via runmodes will need refactoring and moving things to environment variables. Please keep in mind that is case you add additional DEV environments and use them as QA or INT, they will still only support the DEV runmode, so the only solution to differentiate their config is by using environment variables.

Hope this helps,

Daniel

[NageshRaja]

@daniel-strmecki - I have a system configuration defined for each run mode in cloud - config.author.rde, config.author.dev, config.author.stage and config.author.prod

There are about 25+ set of configurations defined out of which only 5 differ based on runmode.

In this case is it better to put the base configuration of 20 in config.author and only put the delta difference of 5 configurations in each runmode based on environment?

[daniel-strmecki]

Hi @NageshRaja,

yes, put the common configuration in the most generic config folder and then only the differences in the more specific config folders. Keep in mind OSGi configurations can also contain environment variables as values, so maybe you don't even need different OSGi configurations, just set different environment variables on the specific environments:

{
  "connection.timeout": 1000,
  "api-key": "$[secret:server-api-key]",
  "url": "$[env:server-url]"
}

Good luck,

Daniel

[arunpatidar · Accepted solution]

Hi @NageshRaja 
Please check following links, where 1st one allow you to setup your own runmode whereas second links obsolete that because In AEMaaCS env variable can be used instead of multiple/runmode config.

https://blog.developer.adobe.com/custom-runmodes-on-aem-as-a-cloud-service-79b757f51a6b 

https://medium.com/@achimkoch/dont-use-osgi-configs-in-aemaacs-18ed91053dee

[NageshRaja]

@arunpatidar- I have a system configuration defined for each run mode in cloud - config.author.rde, config.author.dev, config.author.stage and config.author.prod

There are about 25+ set of configurations defined out of which only 5 differ based on runmode.

In this case is it better to put the base configuration of 20 in config.author and only put the delta difference of 5 configurations in each runmode based on environment?

[arunpatidar]

Hi @NageshRaja 
Check response here : https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/run-modes-precedence-in-cl... 

[Tethich]

Hi@NageshRaja 

In addition to what have already been said, please also consider to put down on paper all the original reasons for which your project initially needed to have multiple runmodes. Could be technical reasons, could be business reasons. Either way, they should be revised. Then you will have two ways to go:

- See which ones can be dropped, communicate that to all parties involved and come to a common ground.

- See which ones still apply and make sense to keep and find a way to maintain the solution and behavior, as much as possible of course, in the context of AEMaaCS (which is entirely another beast). 

And always remember, Less is More !

[NageshRaja]

@Tethich  - I have a system configuration defined for each run mode in cloud - config.author.rde, config.author.dev, config.author.stage and config.author.prod

There are about 25+ set of configurations defined out of which only 5 differ based on runmode.

In this case is it better to put the base configuration of 20 in config.author and only put the delta difference of 5 configurations in each runmode based on environment?

[Tethich]

I believe this is something you can go with yes. Keep it as simple as possible. Meaning that if you can reuse something, including configs, then that is desirable.

(A) So if those 20 configs are common for all envs, then you can put them in configs based on author or publish, but not based on specific env:

- config.author

    - (20) files

- config.publish

    - (20) files

(B) The question is how you want to handle those 5 delta configs. Initially you said you have They have Dev, Dev1 to Dev6 - 7 DEV runmodes; 5 QA runmodes and more of Stage and Prod runmodes.

(a) If your codebase can accommodate to work on default cloud setup of 1 Dev, 1 Stage, 1 Prod, then is enough to have those 5 configs in each config for each env:

- config.prod

    - com.domain.project.core.listeners.MyListenerExample1.cfg.json

    - com.domain.project.core.listeners.MyListenerExample2.cfg.json

    - com.domain.project.core.listeners.MyListenerExample2.cfg.json

    - com.domain.project.core.listeners.MyListenerExample2.cfg.json

    - com.domain.project.core.listeners.MyListenerExample2.cfg.json

- config.stage

    - (5) files

- config.rde

    - (5) files

- config.dev

    - (5) files

(b) But if your code still needs to work based on different old runmodes, then you will probably need to leverage the cloud environment variables to logically differentiate them, and in parallel spin off the new envs in cloud. So you can have a QA or INT or Dev(1..n) envs, all being Dev envs from cloud perspective. And then you can have different env vars within your configs, to apply them based on your needs. So let's say that you still need to have 3 Dev envs and 2 QA envs, in this case you will need to create these e Dev envs in cloud, then add an env variable in each of your config files, smth like:

"runmode": "$[env:RUNMODE]"

, then configure read this runmode property in your codebase, and have your logic run based on it.