Runmode migration - AMS to AEM Cloud

[_CL]

Hi Guys,

I have the below problem statement -

"The AMS Environment has runmodes for dev (1 to 6), stage (1 to 4), qa (1 to 3), performance (1), integration (1) and production (1). All these environments have their runmode configurations". These environments are used by multiple business teams spread out geographically and divided along business units.

We need to find a mechanism to retain all these runmodes on AEM Cloud - The least viable option being we add 10 dev environments and tying each environment to one runmode in AMS which even then would be tricky as the runmode for instance config.author.dev6 and config.author.dev5 in AMS would still have to be put under config.author.dev in AEM Cloud.

Thanks in advance,

CL

[_CL]

@arunpatidar- Do you think that previous ID based approach can work for this use case?

[narendiran_ravi]

Hi @_CL ,

In AEM as a Cloud Service (AEMaaCS), we have only the dev, stage, prod, and rde runmodes are available - https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/dep... . Configuration can be set under the dev runmode, with environment variables used to distinguish between different dev instances.

1.  Define base configurations in config.dev, and adjust instance-specific values through environment variables in Cloud Manager 

[_CL]

Hi @narendiran_ravi,

Is there no other way to logically separate my dev3 and dev4 instances other than environment variables?

Because each instance has 100s of configurations which are uniquely different it will be messy to have them under environment variables with no source control to track the values being changed.

[narendiran_ravi]

Hi @_CL ,

Yes, managing numerous environment variables can be challenging. I recommend:

• Create a JSON file in your code repository for each environment to store these variables.
• Use the Cloud Manager API to add or update environment variables programmatically.

Refer to the Cloud Manager API documentation for details on updating environment variables.

[_CL]

Hey @narendiran_ravi , thanks for the response!
However, there is a limit of 200 environment variables per environment in the cloud!
I am afraid we are exceeding that limit! Any alternate approaches considering this fact?

[Tethich]

Hi @_CL 

I believe you will find your answers in some previous thread opened on similar topic: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/handling-runmodes-ams-to-a...

To sum up:
In AEMaaCS you only have Dev, RDE, Stage, Prod.

You can spin off multiple Dev envs and use them as QA, INT or whatever. Usually are those couple two.

And if you need a logic to distinguish them by something you still name "runmode", you need to leverage the environment variables to make a logical difference between them and accommodate your solution/code to work with those.

[_CL]

Hi @Tethich, thanks for your reply but the problem with using environment variables is they can't be tracked in git history and then secondly I have 100's of configuration which differ my dev3 and dev4 environment for instance. Replacing these with environment variables will make them not easy to manage.

[_CL]

any insights into how to handle 200+ environment variables in runmodes for a particular environment? 

@EstebanBustamante@daniel-strmecki @arunpatidar @SureshDhulipudi @Rohan_Garg 

[EstebanBustamante]

Your best option is to open a support case with Adobe and explain your use case. They may be able to help you with the limit. Sorry, I didn't fully read all the responses, but IMHO it is clear that a redesign needs to happen. You cannot simply 'lift and shift'; there are business strategies that need to be aligned with AEMaaCS.

[daniel-strmecki]

@_CLI am working on an AEMaaCS project running for 4+ years, supporting different development teams and hosting 100+ websites. In that setup, we have around 35 environment variables. I think your on-perm solution needs redesigning and major refactoring as part of the migration to the Cloud.

Good luck,

Daniel

[arunpatidar]

Hi @_CL 
We had same situation due to bad architecture where we had 500+ environment variables and on AMS.

we had to implement a custom solution to only deploy correct config based on environment without replying on AEM.

Here is the blog, not sure if its gonna help in your case or not - https://medium.com/@arunpatidar26/secrets-manager-aem-configs-1c2a23124f7a 

[Rohan_Garg]

I agree with all, you need to refactor your run mode configurations.

Ideally not everything needs to be configured as env variable but only those values which differ for different environments. 
Even for a multi-tenant setup, the values shouldn't be exceeding 200 in any normal scenario.

Source - How to Choose the Appropriate OSGi Configuration Value Type?

Can you maybe post your configurations here for which you are trying to replace them with environment variables?

Hope this helps!

Rohan Garg

[_CL]

I have sent you the configs on chat @Rohan_Garg for your reference

[Rohan_Garg · Accepted solution]

Hey @_CL, Had a chance to review your configs.

Let me break it down for others on the forum too. Here's the sample configuration - 

{
"a": "/x/dev2/y/x",
"b": "/abc/dev2/x/y",
"c": "/x/dev2/a/b",
"d": "/x/dev2/a/y"
}

Instead of converting the entire values for keys (a,b,c and d) - you want to just set one environment variable for dev2. 

In your case the source system for REST API endpoint is Hybris where the endpoints for multiple environments are still same only the /dev2, /dev3 will change.

You can set an EnvironmentID variable which will replace the config as below - 

{
"a": "/x/$[env:API_ENV;default=dev2/y/x",
"b": "/abc/$[env:API_ENV;default=dev2/x/y",
"c": "/x/$[env:API_ENV;default=dev2/a/b",
"d": "/x/$[env:API_ENV;default=dev2/a/y"
}

This will replace your previously 4 environment variables with just 1.

And as @daniel-strmecki mentioned, you probably should not be using so many environment variables.

Hope this helps!

Rohan Garg

[kautuk_sahni]

@_CL Did you find the suggestions helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!