In this post, we will explore some of my key learnings from migrating to AEM as a Cloud Service. In a previous post, ‘Key Considerations for Migrating to AEM as a Cloud Service,’ we discussed the essential factors to consider when moving to this platform
Content/Asset Migration:
Content and asset migration to AEM as a Cloud is a complex task, especially depending on the size and nature of your existing repository. While the Content Transfer tool from Cloud Acceleration Manager can assist, the first hurdle is ensuring adequate infrastructure, such as sufficient disk space, CPU, and disk I/O, to handle the migration process.
If you are migrating from AMS, one strategy is to set up a new dedicated AMS environment specifically for migration. This approach prevents disruption to ongoing work on the current platform but does incur additional costs. Alternatively, repurposing one of the existing environments might be more cost-effective, though it may still require upgrades — Disk Space, Environment Size, and disk I/O capabilities, to meet migration demands.
The recommended steps are to clone your current production environment to this dedicated migration environment, ensure the environment is upgraded to meet your capacity needs mainly disk space and DISK IO (Higher DISK I/O is critical to extract and ingest high volume content seamlessly) then use it to extract and ingest content/assets to the AEM Cloud environments. This ensures a smoother transition and helps manage the load effectively during the migration.
Configuring Environment-Specific ETC MAPs in AEM Cloud:
Custom run modes are not supported in AEM as a Cloud; only ‘dev’, ‘stage’, and ‘prod’ run modes are available. This makes enabling environment-specific variables challenging, especially when multiple development environments are used for different purposes. However, this issue can be addressed by using Cloud Manager to support custom run modes. For more details, see my article: Support Custom Run Modes in AEM as a Cloud.
Another challenge is enabling environment-specific ETC MAPs for resource resolving, particularly when defining site-specific test domains in different environments. Although AEM does not support run mode-specific ETC MAPs directly, this can be managed by configuring the Resource Resolver Factory to point to environment-specific ETC MAP folders. In the cloud, where all development environments are typically set to ‘dev’ run mode, this can be managed using Cloud Manager environment variables. For more information, refer to my article: How to Configure Environment-Specific ETC MAPs for AEM as a Cloud Service?.
Migration of existing users and groups:
User migration is a critical component in AEM as a Cloud, where user management is facilitated through IMS. First, create the necessary groups in IMS and associate the existing users to the corresponding groups. For efficiency, you may consider using a bulk CSV upload to map current users to the appropriate IMS groups. User permissions can be managed through local AEM groups by linking them with IMS groups. If needed, local group ACLs can be defined through repo init scripts. For more information on this process, refer to ‘AEM as a Cloud: IMS based SSO Authentication for Authors’ by Albin Issac on Tech Learnings.
If CUG (Closed User Group) based users and groups are enabled in your current AEM publishers, use the ACL Packager to migrate the users to the cloud publisher. Upload the package to the Author environment and then replicate it. Make sure that the CUG users are not installed into the Author environment to avoid any permission overlaps, especially if some users are common between Authors and CUG. Live user synchronization between publish pods is not enabled by default. Create a support ticket to enable user sync across publisher pods.
Environment-specific SAML configurations within AEM for supporting Author login through the customer’s IAM system are no longer necessary. This configuration has now been centralized and is managed globally through IMS.
DAM Asset Update Workflow:
The default DAM Asset Update workflow in previous versions of Experience Manager is no longer available. Instead, asset microservices provide a scalable, readily available service that covers most of the default asset processing (renditions, metadata extraction, and text extraction for indexing). Refer to the configuration and use of asset microservices for more details. To include customized workflow steps in the processing, post-processing workflows can be used.
Synthetic URL Monitoring:
Synthetic URL monitoring is a crucial tool in web performance monitoring, used to assess the availability, functionality, and responsiveness of web applications, services, and APIs. If you currently utilize custom monitoring tools such as New Relic or Datadog, these can be effectively used to monitor URLs and APIs. However, it’s important to note that while New Relic is integrated into AEM as a Cloud, it does not support specific URL monitoring for AMS platforms.
In AEM as a Cloud, URL monitoring is only available through the Advanced Cloud Support package, which incurs additional costs. If you opt out of Advanced Cloud Support and do not have an existing custom monitoring setup, your only alternative is to find a custom solution that meets your URL monitoring needs.
Supporting Parallel Development and Content Authoring:
Supporting the ongoing development of projects on the platform and content authoring is critical. Ensure you plan this in advance while selecting System Integrators and during the planning phase. Supporting parallel development and content authoring can alter your project’s timeline and required effort, so it’s crucial to develop a strategy for parallel development and content authoring. This includes merging ongoing development code to the cloud, ensuring cloud compatibility, conducting tests, and migrating delta content.
Static Templates and ETC Designs:
Although static templates and ETC/Designs are supported in the cloud, they are not recommended. You should migrate ETC/Designs folders from the current platform to the cloud. However, a challenge arises as there are no miscadmin pages available to manage and publish ETC/Designs. While designs can be modified through design mode, there is no direct method to activate these changes. To activate design changes, you could use one of the following approaches: package the changes and install them on the publisher, or utilize a tree activation workflow.
Splunk Log forwarding:
The AEM logs, including CDN logs, can be forwarded to a customer-owned Splunk instance. To enable this forwarding, please create a support ticket with the necessary details: the Splunk HEC endpoint address, Splunk port, and Splunk HEC token. Three different indexes — dev, stage, and prod — are created; logs from all dev-type instances are sent to the dev index.
SSL and DNS Configurations:
The SSL and DNS configurations can be managed through Cloud Manager as a Self-Service. To support site-specific test domains across various environments, create a test domain strategy. It’s advisable to use a common domain pattern to simplify management, such as site1-dev.test.com, site1-uat.test.com, and site1-stage.test.com.
Enable a separate wildcard SSL, for example, *.test.com, to support various test domains across different environments (site1-dev.test.com, site1-uat.test.com, site1-stage.test.com). Additionally, consider enabling individual or SAN SSL to support live domains in production.
Domains can be directed to either the Preview or Publish environments. The Preview environment allows you to preview changes before they are published. After publishing changes to the Preview server and conducting tests, you can then move the changes to the Publish environment. By default, the Preview service is blocked for all traffic, but you can manage IP allowlisting through Cloud Manager
CDN Configurations:
The caching headers for the CDN can be enabled through dispatcher configurations. For more details, please refer to the ‘Caching in AEM as a Cloud Service’ section on the Adobe Experience Manager website. It’s important to assess the current CDN cache behavior configurations as well. When migrating from AMS and CloudFront to AEM as a Cloud, I recommend not merely transferring individual configurations from the current CDN directly. Instead, identify your specific caching needs and implement the necessary configurations. This might include common configuration files used in every virtual host to control caching behaviors.
Additionally, you can define other CDN configurations such as rate limiting, filtering rules, and WAF rules, if licensed, through the cdn.yml file in a separate config folder, refer to Traffic Filter Rules including WAF Rules | Adobe Experience Manager for more details. Deploy these configurations separately through the Config Cloud Manager Pipeline. The CDN configuration also supports enabling a Reverse Proxy (Origin Selector) for non-AEM servers, as well as request and response transformers, refer to Configuring Traffic at the CDN | Adobe Experience Manager for more details.
Purge-Key. You should request the environment-specific purge key from the Adobe team by creating a support ticket.
There are two types of purges available: soft and hard. A soft purge marks the affected object as stale rather than making it completely inaccessible, whereas a hard purge immediately makes the object inaccessible to new requests. To execute a hard purge, simply remove Fastly-Soft-Purge:1 from the request.
curl -X PURGE -H "Fastly-Soft-Purge:1" <URL_TO_BE_ PURGED> -H "x-aem-purge-key: <X_AEM_PRUGE_KEY>" DevOps Process:
Adjusting and updating your current DevOps process to adapt to cloud best practices is critical. The cloud platform enables additional deployment pipelines, such as the Dispatcher pipeline for deploying Dispatcher configurations and the Config pipeline for deploying CDN configurations. If you are not currently using Cloud Manager to manage deployments, you should define an end-to-end DevOps process that includes both your code repository and the Cloud Manager repository, along with the deployment pipelines.
Testing:
Testing is critical for the success of the project. Ensure that a comprehensive test strategy is defined to cover all required tests: Functional, Content, Integration, Regression, Performance, and Security. If any integrations require IP whitelisting, you will need to enable dedicated IP configuration in AEM Cloud and whitelist the IP. For more details, refer to ‘Demystifying Dedicated Egress IPs in AEM Cloud Services’ by Albin Issac on Tech Learnings | Medium.
Another challenge involves functionalities that cannot be tested in non-production environments. You may need to enable test services to assess these functionalities. If it’s not feasible to test ahead of the go-live, consider testing these functionalities by adding host entries on your local machine to point the sites to the AEM Cloud platform.
Adobe Support:
Adobe Support is critical. If you opt for Ultimate Support, you will gain access to focused ticket support. Additionally, Launch Advisory services provide extra guidance from an Adobe Architect and their team during the project, including any necessary reviews and monitoring during the migration. If you decide against Ultimate Support, you will need to plan how to navigate support tickets in case of any blockers. Furthermore, if you currently use AMS, you may need to arrange for the required support from a Customer Success Engineer (CSE) for tasks such as cloning the environment, supporting content migration, or obtaining details from the current platform, such as CDN configurations.
Restrict release orchestration for Production:
You can raise a support ticket to prevent the production environment from automatically upgrading during your go-live window, thereby avoiding any unexpected issues. The request should be submitted at least one week in advance, specifying the period during which the release orchestration for production should be disabled (i.e., preventing the production environment from receiving updates).
Maintenance Tasks:
In the cloud, Adobe handles some maintenance tasks, but customers are responsible for others. You will need to schedule these tasks according to your specific needs. For more information, refer to the Maintenance Tasks in AEM as a Cloud Service on the Adobe Experience Manager website.
Content Back Sync:
If you have enabled scheduled content back-sync from production to non-production environments in AMS or your own AEM platform, be aware that this functionality is not supported in AEM as a Cloud. Instead, AEM as a Cloud allows you to create content sets and migrate content between Author instances as needed, but this is not scheduled nor does it extend to the Publisher. You should consider implementing a package-based batch content sync, such as using the Multi-Channel Publishing (MCP) tool, from Author to Publisher.
Operational Changes:
Some of the operations previously performed by CSE on the AMS platform can now be managed directly by customers. These include managing deployments, installing mutable content packages through the Package Manager, provisioning new environments, and configuring IP whitelisting, SSL, and DNS, among others. Additionally, the repositories on stage and production can be accessed through the repository browser available in the Developer Console.
Configure Notification Services:
Configure Incident Notification and Proactive Notification, refer to Notification Profiles | Adobe Experience Manager for more details.
Post Go Live Reviews:
Review the CDN cache hit ratio through the Cloud Manager, which also provides recommendations for improving this metric.
Issues:
Responsive Authoring Issue in AEM as a Cloud | by Albin Issac | Tech Learnings | Mar, 2024 | Medium
No comments:
Post a Comment