This document outlines some of the differences between AEM on-premises/ Managed Services Vs AEM as a Cloud Service.
| Parameters | AEM on Prem/Managed Service | AEM as Cloud Service |
|---|---|---|
| License Cost | Depends on Infrastructure & Users based | Depends on Usage |
| Upgrades | Need manual intervention & it’s costly | Automated upgrades are available |
| Architecture | Built like monolith application, requires custom development & cost to set up the instances & integrate with external services. It has fixed number of AEM images which has to be decided and installed at beginning of project. |
Built on Micro service-based architecture & doesn’t need extra cost for setting up instances etc like On Prem. It has variable number of AEM images and they are used as per need. |
| Security | Security fixes need to be deployed manually & it takes time to deploy till prod as proper testing is needed before that. | Security fixes can be deployed automatically on daily basis. |
| Code repository | Any code management repository can be used | In standard process, only Adobe Git repository has to be used. |
| Code Deployment | Any CI tool can be used for this. | Cloud manager has to be used |
| User Management | It has to be controlled through Author Instance User Management page. | It has to be controlled via admin console. |
| CRX Management, Indexing, Runmode & OSGI configurations | CRX can be accessed for any environment and same. Configurations, Indexes can be configured and maintained anytime. Configurations, Indexes can be configured and maintained anytime. Custom Runmodes are possible at any time. |
On Prod, CRX is not accessible. OSGI configurations & Indexes has to be managed as a part of code only. There is no alternative to control the configurations directly on any environment. Custom Runmodes are not allowed. |
| Mutable & Immutable Content | No constraint for mutable & immutable content. | Mutable & Immutable content are strictly managed. |
| Dispatcher & CDN | Dispatcher configurations can be organized in any folder structure. Any CDN can be used here, mostly Akamai or fastly are used. |
Dispatcher configuration follows standard structure as per cloud manager. Adobe managed CDN is used here, if customer goes for own CDN then that CDN has to point to AEM managed CDN. |
| Key Features |
|
|
| AEM Publish Changes & Replication agent | Changes are possible on AEM publish instance directly. We’ve OOTB replication agents available for publishing and we can create custom replication agents as well. | On Cloud, changes in publish instance are not possible. Here, we’ve Sling Content Distribution for publishing content. There is no option to create or use replication agent. |
| Identity Management | AEM community, CUG etc can be used as identity management. However, the same doesn’t hold applicable in case of cloud. | A major change to AEM as a Cloud Service is the fully integrated use of Adobe IDs for accessing the author tier. This requires use of the Adobe Admin console for managing users and user groups. |
| Authoring User Interface | AEM touch ui and classic ui can be used here. | AEM touch UI is only allowed. |
| AEM Sites | Many changes are available like Page operations, website reference, i18n & developer mode are not available in cloud . https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/sites/sites-cloud-changes.html?lang=en |
|
| AEM Assets | 1. Experience Manager uses direct binary access principle to upload and download assets and uses asset microservices to process asset. See overview of microservices 2. The default workflow DAM Asset Update in previous versions of Experience Manager is no longer available. Instead, asset microservices. 3. Many other features have changed a lot , have a look at :https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/assets/home.html?lang=en Asset microservices for cloud-native processing. |