Advancing AEM Elasticity: Earlier Signals, Faster Readiness, Better Resilience
Elasticity is about more than adding capacity. Its effectiveness depends on two separate but closely connected dimensions: how early a system recognizes the need to respond to changing demand, and how quickly newly added instances are ready to handle load efficiently.
This talk explores both sides of AEM elasticity through the lens of AEM as a Cloud Service and takes a closer look at the mechanisms that make elastic behavior possible in practice. First, it examines how elasticity decisions can become earlier and more proactive by improving the underlying signals, moving from visible pressure to earlier indicators and more predictive thinking. This includes a deeper look at the types of signals and platform behaviors that influence when additional capacity should be introduced.
Second, the session focuses on readiness: how startup and warm-up behavior influence the point at which new instances can contribute meaningful request capacity. It will dive into the practical mechanics behind scale-out in AEM as a Cloud Service, including the gap between instance startup and effective traffic handling, and why this gap matters for short-lived alerts, responsiveness under changing demand, and overall resilience.
Based on operational learnings, this session shares how elasticity can be improved over time to become more responsive, more efficient, and more resilient. It also provides practical guidance for customers and partners on how to design and optimize applications for faster readiness, smoother scale-out behavior, and fewer short-lived alert situations during periods of change.
Attendees will leave with a practical framework for thinking about elasticity not just as the ability to add capacity, but as the combination of earlier response, deeper understanding of scaling behavior in AEM as a Cloud Service, and faster availability of that capacity when it matters most.
wolf
How do you stop underprovisioning/overprovisioning flip-flops with erratic traffic? Any level of reserved capacity?
Dominik Suess
During active hours capacity is constantly opening up and along with overprovisioning demand can be satisfied in seconds. Only during very quiet times when a cluster is mostly idling the packing might be as stable that the overprovisioning is not sufficient to handle bursts without provisioning new cluster nodes which can add a bit of delay.
Simon
How can we found out if any of these issues affects us?
Dominik Suess
I hope my answer clarified a bit, start with breaking down your startup times
Michal
Have you encountered issues related to load balancers or private networking saturation?
Dominik Suess
I‘m not sure what you have in mind. Initially (years ago) we had trouble of loadbalancers being delayed in taking new instances in, now it‘s only seconds after ready that traffic hits- that was the point about being prepared to deal with full load right after ready
Tad Reeves
What is the best way to track application startup time in production? The SDK is one place to check, but production is where the rubber (and our awful anti-patterns) typically meet the road.
Dominik Suess
The answer hopefully soon is otel - right now it’s log parsing
angela
How can customers assess if their setup belongs to the troubled category? AEM should be able to tell them and maybe even suggest fixes? No??
Michael
Any plans for MCP server to support OTel? I'd rather my agent watch over it instead of having a fancy Grafana dashboard nobody looks at.
wolf
There are a few third-party MCP implementations for oTel. It’s an open standard.
Michael
I can always implement it myself, it would be nice not having to do that though.
bhabegger
How do you ensure that client's external metrics system doesn't itself, as an external service, become cause of slowing startup ?
Dominik Suess
The pipeline is attached through a collector, the agent is not directly feeding into the otel target
Robert
Regaring synchronous BE calls and instead using import to repository: how can this work on a (golden) publish instance? Can there be Jobs only running on it an writting to its repository?
Dominik Suess
No - that’s why I refered to import on author and replicate. Anyhow publishers could check what they already have and just catch up so anything processed by golden publish would be skipped and only the catchup is necessary. This is also how the relication it self is implemented