AEM as a Cloud Service: Empowering Continuous Deployment for Large-Scale Web Platforms

Would you like to see a real-life example of a large AEM as a Cloud Service based platform where there are up to 10 production deployments per day?

During this talk we will take you through all the key aspects of a successful Continuous Deployment with AEM as a Cloud Service, starting from the architecture - a mixture of AEMaaCS and AWS Serverless, going through robust CI/CD pipelines, regression testing methodologies and tooling, all the way up to monitoring & observability.

The talk will cover both process and tooling aspects of the platform. We will also talk about the mentality needed within the team to be able to deploy to production multiple times a day.

10 deployments a day means one planned deployment and 9 hotfixes for it? 😉

Tomasz Sobczyk

Nope :) we keep our bug levels rather low. Of course sometimes we get an important piece of feedback right after releasing it. Thanks to this process we can implement it often the same /next day in prod.

agasteovski

With static site generation, how do you handle dynamic data? Is the dynamic logic fully in the AWS serverless APIs?

Tomasz Sobczyk

We have most of it on The Frontend (our logins are client side jwt/oidc based). If we need server side integration (eg search indexing) we will do that on lambdas or edge functions. If we need to secure api we will use either jet tokens or api keys (depending on The use case)

How do you handle Frontend app code base and its infrastructure?

Tomasz Sobczyk

We utilize ootb Frontend pipelines and themes for deployments and managing these. The files are then pulled into s3 (during page publishing we will search through markup for static asset links).

Cool setup and solution: But how does the bill from AWS and Adobe look like? Is it still reasonably affordable?

Tomasz Sobczyk

Answered during the talk. Bill from AWS is Tiny compared to Adobe one. Most of the cost comes from cloudwatch (logs, tracing, real user monitoring) and aws waf (which we need to have because we are the front facing cdn)

Dennis Fisch

IMHO this kind of implements EDS on top of AEMaaCS, doesn't it?

Tomek Niedzwiedz

Not quite, because it's full static generation. EDS still relies on front-end manipulation. There are many similarities though.

Tomasz Sobczyk

Eds pulls the files from the source and does certain things in run time. Also eds doesnt allow you to implement edge logic (eg hide content behind login). In this infra adding these kind of features is a breeze. I can also replace my search engine for example in few days. Lots of flexibility

Michal Cukierman

Using AEM as a content source and serverless/CDN as a runtime sounds like a perfect decision. How long did it take to build the solution?

Tomasz Sobczyk

Discussed during the call. We had a first working, but bit native version after around a month. We then started adding scalability, and observsbility to it. We have actively developed it during the first year of the project. Now we are Re-writing the whole infra as a code to typescript (because of some legacy reasons we have built original one in python - that was a bad decision :))

Davorin

How do you handle multiple publish events triggered from each publish AEM instance?

Tomasz Sobczyk

There is an event in sling distribution that is fired when content is delivered to publish instances but it fires only once. We also use timestamps to make sure we dont get stałe content (timestamp from publish has to be newer than the beginning of publication event)

Yegor Kozlov

Do you need AEM Publish at all? Would it be simpler to replicate from AEM Author to AWS directly and start the page processing workflow?

Michal Cukierman

You need publishers if you want to know what's the state of the published site, not a single page. While rendering a page from an Author, you could for example build invalid navigations/listings.

Tomasz Sobczyk

Spot on Michal. We still want aem features like author / publish /preview split. Its an important feature on such a big platform. Also acvessing publish instance is easier ( we have some simple key based access controls to it). We blocked publish cdn url so that people dont use them.

hluetolf

Are form submissions being sent to AEM backend?

Tomasz Sobczyk

No. Aem is only a source of content for us. Contact us form submissioms go to dedicated crm system. We dont store any data on AEm.we have other types of data we deal with but it all goes either to dedictaed system (external) or to aws infra

puradawid

How do you handle content that is reused across the content, i.e. experience fragments, configs, templates, related pages and content fragments? Does the page processor recognize the dependencies?

Tomasz Sobczyk

We will regenerste the whole site (market /lang in our case) when someone publishes content fragment or ca config that belongs to a particular market /lang.

Michal Cukierman

Do you always use full Static Site Generation (SSG), or can you re-generate part of the content (like in the Incremental Site Regarneration (ISR). How do you handle the relations (required scripts, required images). How long does it take to re-generate the site?

Tomasz Sobczyk

Currently it takes 20 minutes for all experiences. For now its ok for us. Once it starts becoming to slow we will start looking to implement isr. To be clear when you publish one page - we generate only that page For code changes we wipe the whole thing out. We cache images to death and we ask authors to upload images under new paths when they want to replace them which forced of course content reauthoring as well

Which frontendframework are you using

Tomasz Sobczyk

Vanilla java script for most of the website. For dynamic apps we use Vue. Its better for us than react because of lower entry barier. Its also more opinionated than react which makes it harder to make fatal arch mistakes in it (in react its very easy to make things very messy)

Anian Weber - TechDivision

How long does the generation of the pages take? I imagine that you need to regenerate all pages after/with a deployment.

Tomasz Sobczyk

Yes we regenerste all tenants for fullstack (aem) it takes around 20 minutes. For Frontend - depends on how much content tenant has, varies from couple of minutes up to ~15. We could speed it up dramatically but we dont want to overload aem (we dont want to cause Dominik S. Any trouble :)) we have intentionally drastically throttled our lambda functions for pulling content to avoid that

puradawid

You never decommission unused features?

Tomasz Sobczyk

We always decomission them. We delete old code. We also run groovy scripts automatically to refactor live content to new features when needed

Just to get a feeling about the rough scale: how many teams and persons (developers, architects, devops,pm..) are involved in that setup?

Tomasz Sobczyk

We dont have any devops people. The whole infra was written by developers ( fullstacks who can work on aws, aem or Frontend /spa) Core infra and main tenant (Frontend) is two teams of jointly around 20 engineers (fullstack + ui + qa) + 2 pms plus one architect. We also do other things like supporting users, etc. Other tenants are mainainted by small teams of couple people max (ui and qa only).

Ashok Kumar

Is search also come from AWS service or search requests still comes back to AEM ?

Tomasz Sobczyk

We use aws cloud search. Index is populated based on s3 event. Integration eith search endpoint is done through an api gateway proxy

Do you have an approval from business before you deploy to PROD? This is usually the bottleneck in the development process

Tomasz Sobczyk

No :) Agreed ticket with acceptance criteria is our contract with the business. We meet the contract - we go to prod. We run bi-Weekly demos to give all stakeholders an update about progress and gather feedback

Matija Kovacek

With this approach do you actually save costs (content requests to AEM), or aws is additional as you said minimal cost on top of Adobe costs? Do you still need to report to Adobe about number of Customer content requests?