FAQ on AEM as a cloud service

1) Which are all the environments available as part of AEM as a cloud service?

Four types of environments available with AEM as a Cloud Service:

• Production environment - for the business practitioners
• Stage environment : performance and quality tests before changes to the application are pushed to the production
• Development environment -  developers to implement AEM applications
• Demonstration environment : Training , demos, pocs etc - is simplified to a single author node, all others having min 2 author nodes

2) Which are all the types of programs available as part of AEM as a cloud service?

Two types of programs are initially available for AEM as a Cloud Service:

• AEM Cloud Sites Service
• AEM Cloud Assets Service

3) What we get as part of AEM as a cloud license?

When we get the license we will have

• Code repository (Git)  1
• Baseline image (Sites or Assets)  1
• Stage and production environment set (1:1) 0 or 1
• Non-production environments (development or demonstration) 0 to N
• Pipeline for each environment 0 or 1

**Note:* The author tier will contain all Sites and Assets functionality for all programs, but the Assets programs will not have a publish tier by default

4) What are all the changes in Author, Publish & Replication in AEM as a Cloud Service

Author and publish features:

Both author and publish tiers always accessed via a load balancer. But publish tier, a Continuous Delivery Network (CDN) is always available.

The method of author to publish replication has upgraded now. AEM as a Cloud Service Sling Content Distribution which  allows one to distribute Sling resources between different Sling instances.{The API works at path level and the distribution agents basically enable distribution of specific paths between instances.}This uses a pipeline service run on Adobe I/O, which is external to AEM.

Replication changes - The replication agents used in previous versions of AEM are no longer used or provided, which might impact the following areas of existing AEM projects:

• Custom workflows that push content to replication agents of preview servers for example.
• Customization to replication agents to transform content
• Using Reverse Replication to bring content from publish back to author

5) Do we have all types of runmodes as in previous version of AEM?

The answer is NO.

Run modes that are defined typically include the service (author and publish) and the environment (dev, stage, prod).

Pattern
<service>.<environment_type>

Fr eg: author.dev or publish.prod

The supported runmode configurations in AEM as a cloud service are:

• config ( The default, applies to all AEM Services )
• config.author ( Applies to all AEM Author service )
• config.author.dev ( Applies to AEM Dev Author service )
• config.author.stage ( Applies to AEM Staging Author service )
• config.author.prod ( Applies to AEM Production Author service )
• config.publish ( Applies to AEM Publish service )
• config.publish.dev ( Applies to AEM Dev Publish service )
• config.publish.stage ( Applies to AEM Staging Publish service )
• config.publish.prod ( Applies to AEM Production Publish service )
• config.dev (*Applies to AEM Dev services)
• config.stage (*Applies to AEM Staging services)
• config.prod (*Applies to AEM Production services)

** OSGI configuration that has the most matching runmodes is used.

6) How do we do local development when AEM is in cloud?

For local development:
The following artifacts are made available to the developers:

• The AEM as a Cloud Service QuickStart: a .jar based, standalone installer of the latest AEM code base, with the same functional and API surface.
• The AEM as a Cloud Service Dispatcher SDK: an image-based process for testing and validating Dispatcher configurations locally

[* The quickstart is a simple author environment where the majority of the extensions can be developed and tested - does not allow for all AEM Sites and AEM Assets functionalities]

7. What are all some of the important terminologies which we should be aware of?

New important terminologies w.r.t. cloud

• AEM as a Cloud Service - The cloud-native way of leveraging the AEM applications
• AEM Image - A deployable artifact that contains the AEM product code together with the customer code.
• Golden Master - The AEM publish tier.
• Orchestration Engine - AEM as a Cloud Service uses an orchestration engine to ensure that all author and publish services are scaling as and when needed.
• Asset microservices - Cloud-based digital asset processing services that cater to various asset processing use cases, such as rendition generation, PDF processions, subasset handling, text extraction etc.

8) What are all the types of users and roles available in AEM as a cloud?

Users & Roles

Cloud Manager currently defines four roles for users which govern the availability of specific features:

• Business Owner - defining KPIs, approving production deployments
• Program Manager -  team setup, review status
• Deployment Manager - execute stage/production deployments
• Developer - Develops and tests custom application code , do git operations

* There is a role 'Content Author' who does not interact with Cloud Manager. May use Cloud Manager Program Switcher (having navigated from Experience Cloud) to access AEM

9) How do we upgrade from existing AEM version to Cloud Service

> Planning
Access cloud service readiness - determine areas that will require refactoring to be compatible with AEM as a Cloud Service.(Source code Vs deprecated features, New path structure w.r.t AEM as cloud). Then estimate the plan.
Review resource planning - identify resources, create a team, and map out roles and responsibilities
Establish KPIs - Define KPIs to help your team focus on what matters the most.

> Execution
- onboad -familiarize & deploy the code to cloud service
- Integrate - the Git and deploy the code, content transfer, code refactor( Use tools where ever possible For eg: Asset Workflow Migration Tool, Dispatcher Converter, Modernization Tools. )
- Configure - user roles and other things on Admin console of cloud manager

> Post Go-Love
clean-up of temporary files,
review best practices for continuous development
manage logs

10) What are all the options available to troubleshoot anything in AEM as a cloud service?

The following tools are available to troubleshoot AEM as a Cloud Service environments:

• Developer Console
• CRX/DE Lite
• Managing Logs

11)  What does the SDK For Local Development contains in AEM as a Cloud Service?

SDK is comprised of the following artifacts

• Quickstart Jar - The AEM runtime
• Java API Jar - all allowed Java APIs that can be used to develop against AEM as as Cloud Service(Previously known as Uber Jar)
• Javadoc Jar - The javadocs for the above JAR
• Dispatcher Tools - set of tools used to develop against Dispatcher locally

12) How does the Maintenance tasks became more users friendly now?

With AEM as a Cloud Service, the need for customers to configure the operational properties of maintenance tasks is minimal. Customers can focus their resources on application-level concerns, leaving the infrastructure operations to Adobe.

Below given customer owned the configuration

• Ad-hoc Task Purge
• Workflow Purge
• Project Purge

13) Can you explain mutable vs immutable in AEM as a Cloud Service?

Mutable Vs immutable

• /apps and /libs are considered immutable areas of AEM as they cannot be changed (create, update, delete) after AEM starts (i.e. at runtime). Any attempt to change an immutable area at runtime will fail.
• Everything else in the repository, /content , /conf , /var , /home , /etc , /oak:index , /system , /tmp , etc. are all mutable areas, meaning they can be changed at runtime.
• Oak indexes are mutable at run time
• *  /oak:index configurations are part of the Code Package and not part of the Content Package