Amazon Web Service & Adobe Experience Manager:- A Journey together (Part-8)
In the previous parts (1,2,3,4,5,6 &7) we discussed how one day digital market leader meet with the a friend AWS in the Cloud and become very popular pair. It bring a lot of gifts for the digital marketing persons. Then we started a journey into digital market leader house basement and structure, mainly repository CRX and the way its MK organized. Ways how both can live and what smaller modules they used to give architectural benefits.Also visited how they are structured together to give more and AEM eCommerce.In the last part we have visited with Adobe Creative cloud part .
In this part as well will see more focus on movement or migration of AEM on-premise to cloud to best fit into this combination.
I hope now you ready to go with this journey to move AEM form On premise to the cloud with its best buddy AWS to enrich a lot of blessing to the digital marketing persons.
So let set go.....................
However this look like very tough and complex task but careful preparation and planning, can drive a smooth migration.
Prerequisite for the migration or pre-preparation:-
b)Allocate sufficient time.
c)Preset the infrastructure.
Planning Before the migration:-
High level view of Migration Process
In case there is no CDN in front of load balancing and the switch needs to be directly on domains. Ensure that both environments are running in parallel and switch as few sites as possible one by one.
Choose a less traffic site with minimal impact and perform switch etc operation on it then start testing. If require then fix manually and then fix in the process.
Before migrating the AEM to AWS , we must know about ways. There are 2 way of the migrations:
1. Without Adobe involvement:-Directly go to AWS (Amazon Web services) and Start AEM instances from there.
2. With Adobe involvement:-But better recommended way is first go to AMS (Adobe Managed Services), and then Adobe host your AEM instances either on AWS as per your request. Here Adobe involve into complete process and manage this entire show.
1st way of migration required following decisions :-
1. Select VM’s as size, type etc.
3. Create the AutoScaling group(ASG).
4. Create S3 bucket for assets.
5. Create the load balancer (LB).
6. Setup Jenkins and repository.
7. Decide the CDN from cloud front or third party.
Deployment with partner or self-owned
Responsibility owned by organization for the deployment and maintenance , it required skill set of AEM, AWS and devOps as well. Or with AWS APN(AWS partner network) it can be done.
Now we will throughway in AMS(AEM Managed Service) area.
It is managed by AEM in this migration journey . Quicker, easier and more accurate in very short time span. It come with best practices and support of Adobe. Cloud Manager is main part of AEM manage service , it gives administrative features to the organization, for self-manage AEM in the cloud. It includes a continuous integration and continuous delivery (CI/CD) pipeline with performance and security.
AWS EC2 family is best suited for Author and Publish instance , as it require CPU, I/O and memory.
EC2 M5 family have some advance compute power and also provide the network and broad storage of workloads and they have good local storage too.
AEM Dispatcher is provides the additional security , caching, load balancing which require I/O, compute power and memory. Here EBS I/O optimized volume of AWS is best fit.
Adobe recommend minimum 4 core CPU with 16GB RAM
The CDN switch: Only when all issues are fixed, switch on the CDN side for the less traffic site, testing and rectify issue. Each CDN switch might take from 10-30 minutes to be applied, It is alwayse better to switch in phases at least 3-5 phases.
Load Balancer:- As we know why we are using the load balancer i.e to distribute the traffic.
Classic Load Balancer versus ALB
Switching from a Classic Load Balancer to an Application Load Balancer (ALB) is highly advised as it enables a lot of possibilities.
For example, one ALB can hold multiple certificates, so you can support multiple domains. An ALB can also have different target groups based on the hostname, which allows you to use the same load balancer to handle multiple interactions. For example, 80/443 ports are open for web access and some other ports are open for deployments of target groups based on the hostname.
The Application Load Balancer has deletion protection and, in the case of debugging, you can do a request tracking.
Scaling:- In order to overcome CPU/EC2 is failing then we can configure the auto scaling so whenever when there is health issues on the EC2 it will create the new EC2/CPU and redirect the traffic over there.
Content delivery:- This is used for caching layer in AWS we use cloudFront but you can use 3rd party (CDN).
Dynamic Content:- To incorporate dynamic elements in a static page, the recommended approach is to use client-side JavaScript, Edge Side Includes (ESIs), or web server level Server Side Includes (SSIs). Within an AWS environment, ESIs can be configured using a solution such as Varnish, replacing the dispatcher.
S3 :- It is used to store the binary data and back up management related stuff.
Tools to simplify the migration process and management
Apply server: Using the apply server, you can enable your setup to be much more automated. In some cases, you might not have the luxury of using a fully-fledged configuration management system like Puppet or Chef, and there may be a need for something more flexible with regards to releases and deployments. With the apply server, you don't need that flexibility. It is a tiny tool that can be put into place and whose specific actions you can control. This makes use of HTTP/S and no longer requires SSH access.
Shell2http: Shell2http is a tool that allows you to configure specific commands on a specific host. In practice, we use it to allow people to clear the cache on host machines via URL without giving them access to the machine console. This allows us to configure additional terminal commands that can be used on the machine if necessary.
Puppet (configuration management): We utilize Puppet as our main configuration management tool across our projects. Puppet has a repository in Git that is split depending on the project; based on the machine hostname it detects the environment and role.
Git (version control): Git is our main distributed version control system, which we utilize for maintaining application configuration files and application code within it. We utilize Jenkins to build application packages (that are maintained by Puppet on the machines), which also includes application configuration files.
Jenkins (ci/cd): As Puppet maintains only machine configuration files, the packages built by Jenkins have application configuration files included in them as well. The application configuration files are split by environments and roles to ensure we apply the correct configuration to the correct machine.
Nexus (software repository): Developers upload created packages for deployment to Nexus, the package repository manager. Jenkins then takes the package or packages from Nexus and uploads them to a target machine where it triggers their installation.
Terraform: It enables users to define and provision a datacenter infrastructure using a high-level configuration language known as Hashicorp Configuration Language, or optionally JSON.
Here after this migration , Cloud benefits and feature can leverage but it require a lot of effort and phase. It require handle concerns as well. But there is another player in the market which can make our life easier.
So welcome our new champ in this area AEM OpenCloud.
A very brief intro about AEM OpenCloud(we will see in detail in the coming parts)
It include AEM publish dispatcher , author dispatcher, publisher EC2 instance with auto scaling group which will scale out and in according to the traffic on the dispatcher. Also include the testing capability.
AEM openCloud helps to handle the command execution within the AEM. This include the taking backups, disabling and enabling the crx/de , SAML, deploying the multiple AEM package , AEM security checklist etc. Helps in upgrading the repository.
Security of AEM and AWS :-
Infrastructure level Security:-AWS provide the several services for the security to secure the infrastructure.
Application level Security:- AEM security checklist with the dispatcher security checklist. Mainly security aspect right from the AEM in production mode to using mod_rewrite and mod_security modules from Apache to prevent Distributed Denial of Service (DDoS) attacks and cross site scripting (XSS) attacks.
AWS provides API access to all AWS services, Many of the various commands to deploy code or content, or to create backups, etc. For CI/CD process with the use of Jenkins as a central hub, invoking AEM functionality through CURL or similar commands.
In this journey we walk through AEM & AWS migration and AEM Open Cloud. So any this combination deliver holistic, personalized experiences at scale, tailoring each moment of your digital marketing journey.
For more details on this interesting Journey you can browse back earlier parts from 1-7.
