Showing posts with label AEM as Cloud Service. Show all posts
Showing posts with label AEM as Cloud Service. Show all posts

Friday, 31 July 2020

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

Friday, 10 July 2020

All you need to know about AEM Assets as a Cloud Service

The new 'AEM Assets as a cloud service' which is part of AEM as a cloud (platform as a service solution) provides Digital Asset Management capabilities(storage, managing metadata online, versioning, upload and download) with below extended features.
  • Based on asset microservices(asset ingestion and processing).
  • Smart capabilities, such as AI/ML
  • Highly scalable
  • Always current
  • Always available
  • Auto scaled, deployed and monitored

In older AEM all the asset operations happened at AEM Author instance - which consumes considerable CPU, memory, and I/O resource.Asset processing and storage requirements demand resources which in turn create performance issues impact authoring and browsing experience of end users.

A High-level Architecture of Assets as a Cloud Service can be seen below



The generic steps followed in sequence are,
  • Clients send an upload request - then start uploading binary directly to cloud
  • Once the direct upload is completed, the client notifies AEM
  • Now the AEM sends a processing request to Assets Microservice
  • The asset microservice now start processing the asset (based on the rendition request from AEM) - asset microservice runs relevant microservices for this. They access the binary from cloud and processed assets are also placed in binary cloud.
  • Now assets microservice notifies AEM that renditions are available.

Assets as a Cloud Service Vs AEM Asset upload on premise

Assets as a Cloud Service uses direct binary access principle for upload and download - Previously Assets were uploaded directly to AEM author instance for processing.

Assets as a Cloud Service uses 'asset microservices' for asset processing, which is external to AEM -  But in older AEM versions, all process happened within AEM.

In Assets as a Cloud Service DAM Asset Update Not available [ asset microservices provide a scalable, readily available service that covers most of the default asset processing (renditions, metadata extraction, text extraction for indexing)]. But in older AEM we had DAM Asset Update workflow as default.

Assets as a Cloud Service comes with post-processing workflows which can be used or customizations(where additional processing of assets is required that cannot be achieved using the processing profiles) -In older AEM we had default + customized workflow steps (Even though it looks as an advantage it had used AEM for all processing).

In Assets as a Cloud Service the standard Asset upload interface is the Touch-enabled UI -  In older version Classic UI was available.

In Assets as a Cloud Service only the new upload APIs are supported -The older AEM Assets HTTP API(AEM 6.5), AssetManager Java API, is deprecated now

Advantages of new cloud
  • The uploaded binaries do not go through AEM, which is now simply coordinating the upload process with the binary cloud storage configured for the deployment. finally clients get direct access to them to carry out their work. This minimizes the load on networks and duplication of binaries stored.
  • Binary cloud storage is fronted by a Content Delivery Network (CDN, Edge Network), which brings the upload endpoint closer to the client, helping to improve upload performance and user experience, especially for distributed teams uploading assets
  • More scalable and performant handling of asset uploads.

Ways of uploading Assets to Assets as a Cloud Service
Upload using web interface, Adobe Asset Link, AEM desktop app or custom applications which uses the new HTTP API.

Post-processing workflows
There are cases where we need additional processing to be done, which are not done by asset microservices(For eg. Generating a rendition which requires an integration with other application), additional post-processing workflows can be added to the configuration.

Post-processing workflows, once configured, are automatically executed by AEM after the microservices processing finishes. There is no need to add workflow launchers manually to trigger them.

Some examples for Post Processing workflow use cases are:
  • Custom workflow steps to process assets.
  • Additional processing done by external services.
  • Integrations to add metadata or properties to assets from external systems

How to create Post - Processing Workflows: Steps involved
  1. Create one or more workflow models. - they are of regular AEM workflow models
  2. Add specific workflow steps to these models.
  3. Add 'DAM Update Asset Workflow Completed' Process step at the end(To inform AEM once the processing is done)
  4. Create a configuration for the Custom Workflow Runner Service(configuration of an OSGi service) - This ensures the execution of a post-processing workflow model either by a path (folder location) or by a regular expression.
Supported File Formats

Adobe formats - AI, COLLAGE, DN, IDEAS, INDD, INDT, PDF, PROTO, PSB, PSD, XD
Imaging file formats - BMP, EPS, GIF, JPEG, PNG, SVG, TIFF
Image formats in Dynamic Media - PNG, GIF, TIFF, JPEG, BMP, PSD , EPS, PICT
3D formats - DN, gLB, gLTF, OBJ, STL, USDz
Camera Raw file formats - 3FR, ARW, CR2, CR3, CRW, DCR, DNG, ERF, FFF, GPR, IIQ, KDC, MEF, MFW, MOS, MRW, NEF, NRW, ORF, PEF, RAF, RAW, RW2, RWL, SRF, SRW, X3F
Document formats - PDF,DOCX,DOC,PPTX,PPT, XLSX,XLS,ODF,OFG,ODM,ODP,ODS,ODT,EPUB,HTML,PS,RTF,TXT,XML
Document formats in Dynamic Media - AI, PDF, INDD
Video formats - 3G2,3GP,AVI,DIVX,F4V,FLV,M2T,M2TS,M2V,M4V,MKV,MOV,MP4,MPEG,MPG,MTS,OGV,QT,R3D,SWF,WEBM,WMV
Video formats in Dynamic Media for transcoding - MP4,MOV, QT,FLV, F4V,WMV,MPG, VOB, M2V, MP2,M4V,AVI,WebM,OGV, OGG,MXF,MTS,MKV,R3D, RM,RAM, RM,FLAC,MJ2,
Audio formats  - AIF, ASF, M4A, MP3, WAV, and WMA