AEM as a Cloud Service | Fact Sheet for Beginners

Adobe released AEM as a Cloud Service which is the cloud-native way of leveraging the AEM applications. It's very powerful but has some limitations too in comparison to conventional AEM product which is again for the better reasons. In this article, I am going to present a fact sheet which can act as a short hand guide to understand various capabilities and limitations of AEMaaCS.

Top Features:

1. Inbuilt CI/CD- Provides Continuous Delivery and Continuous Integration for updates with zero downtime. The build pipelines comes with code quality check, performance testing and security checks ( via automated tests to scan for common vulnerabilities). Code quality check is done through a combination of SonarQube and content package-level examination using OakPAL.
2. Zero Downtime- Follows green - blue deployment model so your application never goes down even while deploying code or going through maintenance tasks.
3.  Inbuilt CDN- It has built-in Content Delivery Network (CDN).
4. Auto-scaling- It is based on a dynamic architecture that autoscales (up and down both) the infrastructure vertically a well as horizontally based on site load.
5. Always Optimized- Performance topologies optimized for maximum resilience and efficiency. No need to run compaction and maintenance on server as it trashes itself once in a day and replaced by newer and healthy nodes.
6. Always current and evolving- Comes with automated updates up to several times a month.  By keeping you always on the most recent version, it solves a critical challenge of AEM applications: Eliminating need to worry about upgrade to next AEM Version. Evolves on a daily basis, based on the projects implemented by customers. Content, code and configurations are constantly reviewed and vetted against best practices.

Development Guidelines

Code running in AEMaaCS must be aware of the fact that it is always running in a cluster. This means that there is always more than one instance running. The code must be resilient especially as an instance might be stopped at any point in time. During the update of AEMaaCS, there will be instances with old and new code running in parallel. Therefore, old code must not break with content created by new code and new code must be able to deal with old content.

1. State in Memory- State must not be kept in memory but persisted in the repository.
2. State on the Filesystem- The instance's file system should not be used in AEMaaCS. The disk is ephemeral and will be disposed when instances are recycled. Publish tier should ensure that any data that needs to be persisted is shipped off to an external service for longer term storage.
3. Observation- With everything that is asynchronously happening like acting on observation events, it cannot be guaranteed to be executed locally and therefore must be used with care. This is true for both JCR events and Sling resource events. At the time a change is happening, the instance may be taken down and be replaced by a different instance.
4. Background Tasks and Long Running Jobs- Code executed as a background tasks must assume that the instance it is running in can be brought down at any time. So the code must be resilient and most importantly resumable. That means that if the code gets re-executed it should not start from the beginning again but rather close to from where it left off.
   - To minimize the trouble, long running jobs should be avoided if possible, and they should be resumable at a minimum.
   - For executing such jobs, use Sling Jobs, which have an at-least-once guarantee and hence if they get interrupted will get re-executed as soon as possible.
   - For scheduling such jobs, it is best to use the Sling Jobs scheduler as this again the at-least-once execution.
   - The Sling Commons Scheduler should not be used for scheduling as execution cannot be guaranteed.
5. Outgoing HTTP Connections - It is strongly recommended that any outgoing HTTP connections set reasonable connect and read timeouts. For code that does not apply these timeouts, AEMaaCS will enforce a global timeouts. These timeout values are 10 seconds for connect calls and 60 seconds for read calls. Use the OOTB provided Apache HttpComponents Client 4.x library for making HTTP connections.
6. No Classic UI Customizations- AEMaaCS only supports the Touch UI for 3rd party customer code. Classic UI is not available for customization. 
7. Avoid Native Binaries- Code will not be able to download binaries at runtime nor modify them. For example, it will not be able to unpack jar or tar files. 
8. No Streaming Binaries- Binaries should be accessed through the CDN, which will serve binaries outside of the core AEM services. For example, do not use asset.getOriginal().getStream() , which triggers downloading a binary onto the AEM service's ephemeral disk. 
9. No Reverse Replication Agents- Reverse replication from Publish to Author is not supported in AEM as a Cloud Service. Instead, use an external persistence store that is shared amongst the farm of Publish instances and potentially the Author cluster. 
10. Forward Replication Agents Need to be Ported- Content is replicated from Author to Publish through a pub-sub mechanism. Custom replication agents are not supported. 
11. Logs- On Cloud environments, developers can download logs through Cloud Manager or use a command line tool to tail the logs. 
12. CRX/DE Lite and System Console-
    - For local development, Developers have full access to CRXDE Lite ( /crx/de ) and the AEM Web Console ( /system/console ).
    - Note that on local development (using the cloud-ready quickstart), /apps and /libs can be written to directly, which is different from Cloud environments where those top level folders are immutable.
    - For AEMaaCS customers can access CRXDE lite on the development environment but not stage or production.
    - A set of tools for debugging developer environments are available in the Developer Console for dev, stage, and production environments. The url can be determined by adjusting the Author or Publish service urls as follows: https://dev-console/-<namespace>.<cluster>.dev.adobeaemcloud.com
    - As a shortcut, the following Cloud Manager CLI command can be used to launch the developer console based on an environment parameter described below:
    aio cloudmanager:open-developer-console <environmentid> --programId <programid>
13. OSGi Configuration Files - Configuration changes are placed in code packages(ui.apps) with .cfg.json extension under runmode specific config folders: /apps/example/config..
    - Runmode Resolution is supported by specific OSGi configurations in the following format: Create config folders under /apps/example (where example is your project name), in the format: /apps/example/config.<author|publish>.<dev|stage|prod>/. No other custom run modes are supported.
    - The format of OSGi configuration files are JSON-based format defined by the Apache Sling project. OSGi configurations target OSGi components via their Persistent Idenity (PID), which defaults to the OSGi component's Java class name. For example, for this class: "com.example.workflow.impl.ApprovalWorkflow.java" an OSGi configuration file is defined at: "/apps/example/config/com.example.workflow.impl.ApprovalWorkflow.cfg.json".
14. OSGi Installer Configuration Printer - Use this tool to generate OSGi configuration file in .cfg.json format. This tool can be found in AEM SDK Quickstart Jar's AEM Web console. Go to OSGi > OSGi Installer Configuration Printer
    There are 3 type of OSGi configuration values - inline, environment specific and secret values.
    Sample configuration:
    

    {
    "connection.timeout": 1000,
    "api-key": "$[secret:server-api-key;default=<value>]",
    "url": "$[env:server-url]"
    }

15. Setting OSGi Values via API- Calling the API will deploy the new variables and values to a Cloud environment, similar to a typical customer code deployment pipeline. Up to 20 variables can be declared. The author and publish services will be restarted and reference the new values, typically taking a few minutes. Format:
    PATCH /program/{programId}/environment/{environmentId}/variables
    Via command line -
    $ aio cloudmanager:set-environment-variables ENVIRONMENT_ID --variable MY_VAR1 "plaintext value" --secret MY_VAR2 "some secret value"
    Refer this link for more details - Cloud Manager API

Key Concepts

1. AEM as a Cloud Service SDK- It is recommended to refresh local SDK in stance at least after a monthly maintenance release. The SDK is comprised of the following artifacts:
   - Quickstart Jar - The AEM runtime used for local development
   - Java API Jar - Formerly called Uberjar. The Java Jar/Maven Dependency that exposes all allowed Java APIs used to develop against AEM as as Cloud Service.
   - Javadoc Jar - The javadocs for the Java API Jar
   - Dispatcher Tools - The set of tools used to develop against Dispatcher locally. Separate artifacts for unix and windows.
2. Immutable Areas: Can not be changed at runtime- /apps, /libs. Any attempt to change an immutable area at runtime will fail. 
3. Mutable Areas: Can be changed at runtime - /content , /conf , /var , /etc , /oak:index , /system , /tmp , etc.
4. /oak:index deployed part of ui.apps- oak:index configurations are part of the Code Package even though they are mutable because they need to be deployed before any other mutable content.
5. Separation of content and code- Which means a single content package cannot deploy to both /apps and runtime-writable areas (e.g. /content , /conf , /home , or anything not /apps ) of the repository. Instead, the application must separate code and content into discrete packages for deployment into AEM - ui.apps and ui.content.
6. Repo Init (Repoinit)- Repo Init provides instructions, or scripts, that define JCR structures, ranging from common node structures like folder trees, to users, service user, groups and ACL definition. They are deployed part of ui.apps. Repo Init scripts are stored as scripts entries of RepositoryInitializer OSGi factory configurations.
7. Package Types- Packages are to be marked with their declared package type.
    - Container packages must not have a packageType
    - Code (immutable) packages must set packageType to application
    - Content (mutable) packages must set packageType to content
8. Repository Structure Package- Code Packages e.g. ui.apps require configuring the FileVault Maven plug-in's configuration to reference a <repositoryStructurePackage> that enforces correctness of structural dependencies (to ensure one code package doesn't install over another). This is only required for Code packages i.e. Package marked with <packageType>application</packageType>.
9. Embed Packages- All Container package embeds the following packages, to create a singular deployment artifact
   -ui.apps embedded in /apps/my-app-packages/application/install deploys code to both AEM author and AEM publish
   -ui.apps.author embedded in /apps/my-app-packages/application/install.author deploys code to only AEM author
   -ui.content embedded in /apps/my-app-packages/content/install deploys content and configuration to both AEM author and AEM publish
   -ui.content.publish embedded in /apps/my-app-packages/content/install.publish deploys content and configuration to only AEM publish
10. Embedding 3rd-party Packages- All packages must be available via the Adobe's public Maven artifact repository or an accessible public, referenceable 3rd party Maven artifact repository.
    -If the 3rd party packages are in Adobe's public Maven artifact repository , no further configuration is needed for Adobe Cloud Manager to resolve the artifacts.
    -If the 3rd party packages are in a public 3rd party Maven artifact repository , this repository must be registered in the project's pom.xml and embedded thereafter.
11. Package organization:

Constraints

1. i18n dictionary translation - Does not work at runtime as 
2. Developer Mode in AEM Sites Page Editor
3. Code is never deployed directly to a running AEM instance - It means no code package deployment via crx package manager, no direct changes via OSGi Console etc. All content and code persisted in the immutable repository must be checked into git and deployed through Cloud Manager. 
4. Package Manager can not install content or code into the immutable repository, so these content packages should only consist of mutable content (mainly /content or /conf ). 
5. Use AEM Project Maven Archetype 21 or later
6. Packages are now included using the Maven FileVault Package Maven plugin's embeddeds configuration , rather than the <subPackages> configuration.
7. Any content-packages installed via Cloud Manager (both mutable and immutable) will appear in frozen state in crx Package Manager. These packages cannot be reinstalled, rebuilt or even downloaded, and will be listed with a "cp2fm" suffix, indicating their installation was managed by Cloud Manager.
8. It is not supported to configure custom domain names for the AEM author tier.
9. Securing the Author Tier- By default the author tier is accessible from the Internet by default. To secure it- the procedure is based on authorizing the IP ranges that should be granted network access to your author environment. Raise a Support ticket from the Adobe Admin Console with the requested information: program ID, environment ID and, IP address ranges to authorize

Deprecated/ Removed Features

1. The DAM Asset Update workflow has been deprecated as it is no longer needed and replaced by robust asset processing service called Asset Microservices.
2. Use of certain softwares e.g. ImageMagick and FFmpeg has been made obsolete. These should be handled via processing profiles.
3. Except to some admin tools, the Classic UI in general has been removed in the AEM product UI.
4. Dynamic Media Classic (Scene7) and Dynamic Media Hybrid mode are not available in AEM as a Cloud Service. Just use Dynamic Media.
5. Portal Director, Portlet Component and Design Importer features has been removed.