AEM as a Cloud Service (AEMaaCS) – Quick Introduction

By

AEM as a Cloud Service (AEMaaCS) – Introduction

If you are working in content management space, you must have heard of Adobe Experience Manager (AEM, previously known as CQ5). It is one of the core products offered by Adobe as part of their Adobe Experience Cloud. AEM has evolved over the time from all perspectives (features, maturity, stability, integration with other products and deployment model).

 

As of today, organizations have 3 options to deploy AEM:

  1. AEM on premisses
  2. AMS – Adobe Managed Service (mainly hosted on AWS)
  3. AEM as a Cloud Service (AEMaaCS) 

Focus of this article will be on AEM as a Cloud Service (AEMaaCS). Adobe Experience Manager as a Cloud Service is a new generation software-as-a-service for AEM by Adobe.

 

AEMaaCS is based on the leading solution Adobe Experience Manager (AEM) and offers outstanding content management (CMS) capabilities and digital asset management (DAM) for marketing and communication teams.

 

The solution has been entirely designed for the cloud and is scalable, secure, always available, and up to date.

 

What is AEM as a Cloud Service?

In very simple terms consider that old classic AEM was a big monolithic application and had limitations (e.g., scalability, extensibility) like any other legacy applications that are not cloud native. AEM as a Cloud Service is a result of refactoring of monolithic AEM application into a set of modular components/services that are cloud native. Because of this refactoring, AEM as a Cloud Service inherits benefits of cloud like scalability, agility, extensibility etc. Many core concepts like replication, asset computing/processing, repository services etc. have been changed as part of AEMaaCS offering. We'll look at each one of these concepts in details in upcoming articles.


Adobe Experience Manager (AEM) as a Cloud Service is the latest offering of the AEM product line, helping you continue to provide your customers with personalized, content-led experiences. It provides cloud-native agility to accelerate time to value and is extensible to meet your unique business requirements. You can build on past investments and innovations by preserving and extending all your use cases and functionalities.

AEM as a Cloud Service lets you capitalize on the AEM applications in a cloud-native way, so that you can:

  • Scale your DevOps efforts with Cloud Manager: CI/CD framework, autoscaling, API connectivity, flexible deployment modes, code quality gates, service delivery transparency, and guided updates.
  • Enable developers to add automation to application development practices.
  • Deliver content quickly and efficiently on a global scale, using a built-in Content Delivery Network (CDN) and other network-layer best practices.
  • Leverage a dynamic architecture that auto-scales, thus removing infrastructure considerations.
  • Stay on top of threats and security-risk mitigation, using automated tests to scan for common vulnerabilities.
  • Ensure maximum resilience and efficiency backed by optimized performance topologies.
  • Take advantage of AEM as a Cloud Service’s deep integration with the Adobe Experience Cloud to provide better customer experiences with online marketing and web analytics products.
  • Utilize tools that help accelerate the migration tasks, such as code refactoring, transfer of content, and more.

Typical AEM as a Cloud Service environment

 A new project that is getting onboarded on AEMaaCS will be provisioned under a Program. There are three types of environments available with a Program of AEM as a Cloud Service:

  • Production environment: hosts the applications for the business practitioners.
  • Stage environment: is always coupled to a single production environment in a 1:1 relationship. The stage environment is used for various performance and quality tests before changes to the application are pushed to the production environment.
  • Development environment: allows developers to implement AEM applications under the same runtime conditions as the stage and production environments.


Figure 1: AEM as a Cloud Service (simplified component view)

 

An AEM program is the container that includes following apart from environments that we saw above:






Any new AEM project is always bound to exactly one specific codebase, where you can store both configuration and custom code for your project. This information is stored in a code repository, accessible via the usual Git clients, made available to you at the time new programs are created.

  • AEM Cloud Sites Service
  • AEM Cloud Assets Service

Both of these allow access to a number of features and functionalities. The author tier will contain all Sites and Assets functionality for all programs, but the Assets programs will not have a publish tier, nor a preview tier, by default.

 

Core benefits of AEM as a Cloud Service:

  • It is always on with zero downtime
  • It is always at scale
  • It is always current with latest features/upgrades
  • It is always evolving (Adobe is adding new set of standards and best practices constantly, those are by default included automatically)
  • Low cost of ownership
  • Usage based license model
  • More secure as it is always on the latest security level

Why AEM as a Cloud Service?

Before we answer why AEM as a Cloud Service, we need to look at the expectation of consumers and businesses in today’s era. Also, we need to look at the limitations/challenges with either AEM classic/on-premisses or AMS.

 

At high-high customers want:

  • Better experience (personalization, just in time experience)
  • Relevant content/information
  • Fast and seamless experience

On the other hand, businesses expectation is:

  • Customer satisfaction
  • Lower cost of delivery
  • Self-resilient applications/IT infrastructure
  • Modernized and scalable applications

From business perspective, let’s also look at quick comparison of 2 modes in which AEM was offered (before AEMaaCS):


Also, there were challenges that exists in both offerings (above):

  • Scalability limitation because of the way Oka/JCR repository works in classic AEM
  • Computational limitations (e.g., asset processing and rendition generation)
  • Content replication related issues (performance, reliability etc.) 

Some of these limitations (highlight) directly translates into a need of cloud native solution so that AEM can be scaled, inherit the security benefits of cloud along with lower cost of ownership and therefore Adobe came up with AEMaaCS offering.

 

A lot has been changed (for good reasons) in AEMaaCS! I’ll cover all of that in more details in my other articles (coming up soon!). For now, consider that old classic AEM has been refactored into following:

  • A containerized architecture for scalability and to make AEM cloud-native
  • Set of smaller and scalable services (repository service, asset computer service etc.) for extensibility and performance improvements 

In my upcoming articles, I’ll discuss in detail about:

  • Architecture and core components of AEM as a Cloud Services
  • AEM as a Cloud Service and DevOps
  • AEM as a Cloud Service and Dispatcher
  • AEM SDKK for AEM as a Cloud Service
  • How developers need to adapt to work with AEM as a Cloud Service
  • Migration from existing (AEM on-premisses or AMS) to AEM as a Cloud Service

 

Comments

Post a Comment

Popular posts from this blog

AEM as a Cloud Service (AEMaaCS) – Architecture Overview

By
Image
AEM as a Cloud Service (AEMaaCS) – Architecture Adobe Experience Manager (AEM) is one of the leading CMS from Adobe and is part of Adobe Experience Cloud (AEC). The Adobe Experience Manager (AEM) web content management offers a set of capabilities for creating, managing, delivering, and personalizing content across various digital marketing channels, including web, mobile, and email.  Before we dive into architecture of AEM as a Cloud Service (AEMaaCS) we need to understand why AEMaaCS is needed and how it is different as compared to classic AEM. To understand this, we’ll first look at: Evolution/history of AEM Challenges with traditional/classic AEM (the AEM that majority of us have used from last 10-12 years) Evolution/History of AEM The software was originally launched in early 2000 as Communiqué (CQ) by Day Software of Basel, Switzerland. After CQ 5.3 had been released, Day Software was acquired by Adobe Systems in 2010 then CQ became Adobe Experience Manager. From
Read more

Custom synchronisation or rollout action for blueprint ?

By
Image
Blueprint is an important feature for all those sites which needs to deals with multiple locale and region specific sites. Consider that we have 20 different regional sites and each regional site have 2 locales (English and regional language). Now let’s say you need to do a small update on a English locale page and that changes is required on all sites, there will be 20 pages that you’ll need to visit and make changes one by one (if you have not used blueprint and live copy). With blueprint  we can create a master copy (which is called as blueprint) and create many live copies (which are actual sites) and the benefit you get is that as soon as you do any change in blueprint that same change will be propagated to all live copies pages when changes are rolled out by authors…this is cool. With blueprint you’ll need to apply changes only to English locale page on blueprint and all English locale pages (live copies) will receive that change implicitly. So, how this whole thing works? W
Read more

AEM, FORM Submission & Handling POST requests

By
In this article I’ll be specifically talking about how to handle POST request in AEM and what options we have. Please note that Adobe has added more security around handling POST request from AEM 6.x onwards to prevent CSRF attack. If you don’t configure AEM correctly, POST requests will not work even after using any of methods explained in this article.   You can read more about security configurations and restriction at: https://docs.adobe.com/docs/en/aem/6-1/develop/security/csrf-protection.html It is very common use cases to have external application POST some data to an AEM page (e.g. /content/en/home.html) or even submit a form (POST) to same URL. But, as you know that in AEM POST works differently and any POST call to AEM is intercepted by Sling’s POST servlet (org.apache.sling.servlets.post.impl.SlingPostServlet). In some cases org.apache.sling.servlets.post.impl. SlingPostServlet is very useful when you actually want to perform CURD (create, update, read and d
Read more