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:

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

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:

1. AEM Cloud Sites Service
2. 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 authors and publish tiers always accessed via a load balancer. But publish tier, a Continuous Delivery Network (CDN) is always available.

The method of the 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 the 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 the author

5) Do we have all types of runmodes as in the 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 the 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, sub-asset 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 the 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
- onboard -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 the Admin console of the 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 contain 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 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 do 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