Runmodes best practices

This is a critical lesson for lead developers, sysadmins, and AEM architects: the proper use of Runmodes.

The key thing you must know for this to make sense is that you can target OSGI settings to runmodes, both at an individual level and in combination.

Best Practice 1: Have a Runmode for each environment.
That means that all servers that are part of your CI environment setup (authors and publishers) should have a dedicated runmode, e.g. “integration” or “ci”. Extending off of the built in author/publish runmode, that would mean that the author server has the runmodes “author, ci” and the publish server has the runmodes “publish, ci”

Best Practice 2: Have a Runmode for each different server type.
In many setups, an AEM installation will have active production servers and backups. For some of the projects that I’ve worked on that deal with a lot of imported content from other web services and systems, there are AEM installs dedicated entirely to that purpose. For each of these purposes beyond author/publish, servers should have a runmode.

• If you have backup servers, make sure they run with “backup” as a runmode.
• For servers dedicated to ingesting data, have e.g. “ingest”as a runmode. Resulting in something like “author, production, ingest” as the runmodes for a production environment content ingestion server.

Best Practice 3: Have a Runmode for each server location.
If you have servers located in multiple locations go ahead and add a runmode for this — it won’t hurt anything. But it means that if you have a reason to adjust settings because of that different hosting environment or possibly even a different hosting company, you can target that. This doesn’t (and shouldn’t) come up for the vast majority of customers but it won’t hurt anything and can make your life much easier for that one time it matters. See also best practice #5 for using this with logging.

Best Practice 4: Have a Runmode for the host OS, especially if you are hosting AEM on different OSes for the same setup.
Again, this is one of those things that “shouldn’t come up” but can and has. I do not recommend hosting AEM on different types of hardware, different OS versions, etc. This is terrible practice in terms of managing risk and trying to hunt down discrepancies in behavior. Yet, people do it. As an implementer of AEM you may not have a choice in this — but you can at least make it so that you can respond to these differences by targeting settings (and by extension, code) to these circumstances. Again, a setup like this should be flagged as a risk and avoided. But if you can’t avoid it, at least have these settings in place to help you mitigate the issue.

Best Practice 5: Have a Runmode for each server
For instance, if you have 3 author servers in a production environment, give each a unique runmode, e.g. auth1, auth2, auth3. This should be used for logging if you have a centralized logging system or log aggregator. You can use this runmode and the location runmode to setup pretty log messages that can help pin down server specific behavior. If you see a lot of resource not found errors, it’s VERY helpful if you can tell from the logs immediately that this only happens on Auth server 2, west coast, vs simply ‘happening’.

Using runmodes to target custom behavior
You might be asking yourself “why do all this?” The answer is that AEM will automatically target sling:osgiConfig nodes that follow a certain naming convention, allowing you to precisely target code fixes and behavior to servers operating under certain modes. For instance, running content ingestion code on non-ingestion servers, even if you set up that code to do little or nothing, still wastes resources.