SlideShare a Scribd company logo
1 of 45
AEM Architecture
Adobe Meet-up : Sydney : 16th September 2015
Purpose of these slides:
To describe common AEM architecture options, outline
the various pros and cons, provide some best practise
recommendations for new and existing implementations.
Michael Henderson BAS, BSc(Hons)
Technical Director, NSW
BizTECH Enterprise Solutions
Mobile: +61 430 758 026
Email: mhenderson@btes.com.au
Website: www.btes.com.au
Agenda
Part 1: What to do when setting up Author (1 or more), Author-
Dispatcher (1 or more), Publish (1 or more), Dispatcher (1 or
more), CDN (there or not), Clustering/DB (there or not).
Part 2: Connectivity between the components; pointing out
different configurations, advantages/disadvantages, things to
consider, things to think about.
Part 3: Architectural philosophies like KISS, HA, Performance,
Scalability, etc.
Part 1 – Architecture Elements
 Basic Architecture
 What is an AEM instance?
 AEM Repositories
 Performance: Oak vs MongoDB
 Author: Configuration Options
 Publish: Configuration Options
 Dispatcher: Configuration Options
 CDN: Configuration Options
 Recommended HA Architecture
Basic Architecture (1)
 Author
 Where all the authoring goodness happens
 Publish
 Where all the public goodness gets formulated
 Dispatcher
 Where public goodness gets secured and cached
 Author-dispatcher
 Where some authoring security takes place
 CDN
 Where you gain some localised caching and/or security
Author-Dispatcher Tier
Author Tier
Publish Tier
Dispatcher Tier
Basic Architecture (2)
A
A-D
P
D
CDN TierCDN
OSGi
What is an AEM instance?
JCR
Sling
AEM
The architecture layers that make up AEM:
AEM Repositories
 AEM 5.x and older
 JCR2, but who really cares anymore. If you do? Let it go. 
 AEM 6.0
 AEM supports JCR2, JCR3, MongoDB
 MongoDB introduced as clustering repository
 AEM 6.1
 AEM supports JCR3, DB2, MongoDB, Oracle
 Clustering repository options expanded
 Experimental
 Support for MySQL, MariaDB and MS SQL Server
 Coming in next release?
MongoDB: Simple Example
AEM
1
AEM
2
MongoDB Primary
MongoDB Secondary MongoDB Secondary
Read & Write
Replication
MongoDB: More Complex Example
AEM
1
AEM
2
MongoDB Query Router
MongoDB Secondary
Mongo Sharding
MongoDB Query Router
MongoDB Primary
MongoDB Secondary
MongoDB Secondary
MongoDB Primary
MongoDB Secondary
MongoDB Secondary
MongoDB Primary
MongoDB Secondary
Performance: Oak vs MongoDB (1)
0
2
4
6
8
10
12
14
Oak
MongoMK
(Lower is better)
Performance: Oak vs MongoDB (2)
0
2
4
6
8
10
12
14
16
18
Oak
MongoDB
(Lower is better)
Performance: Oak vs MongoDB (3)
Summary:
 Oak is by far the best performer
 Use Oak unless you NEED to go DB-backed
Notes:
 Oak = TarMK = JCR3 = JackRabbit3
 I haven’t seen any performance stats for the other DB’s
 Performance Reference:
 http://www.slideshare.net/mmarth/aem-hub-oak-02-full
Author: Configuration Options (1)
1. Single Author: JCR (1x) : Not recommended
 Where you have only one Author instance
 No redundancy. If Author fails, go to backup (lose data)
2. Active/Standby: JCR (2x) : Recommended
 Where one Author instance deals with all traffic
 The standby Author instance stays synchronised
 Referred to as “Cold Standby” (although not cold)
 If Author fails, can start “standby” as master instance (no data loss)
3. Active/Active: DB (2+)
 Where any Author instance deals with traffic
 The Author instances are synchronised via a shared DB
 Cannot run on JCR; must run on DB (DB2, Mongo, Oracle)
 If one Author fails, can create new instance (or recover) and add to
the “cluster” (no author outage)
 Ensure DB is clustered, so it’s not a single point of failure
 Can run DataStore on shared disk or S3 (Amazon) for better
performance
Author: Configuration Options (2)
What configuration option should you use?
Really simple question to ask yourself:
 “Can a single Author instance sustain all the required
author traffic?”
Answers:
 Yes = Recommend: Active/Standby (JCR)
 No = Recommend: Active/Active (DB)
Author: Configuration Options (3)
What can you do to help the Author instance load?
 Ensure the project code is efficient
 Ensure the Author is running on disk with high IOPS (I.e. a
SSD or striped high IO)
 Are there tasks or processes running on the Author that
could be offloaded to another server?
 Is the Author server as big as it can be?
Publish: Configuration Options (1)
1. Single Publish: JCR (1x) : Not recommended
 Where you have only one Publish instance
 No redundancy. Failure: Go to backup or rebuild, re-publish (outage)
2. TarMK Farm: JCR (2+) : Recommended
 Active/Active configuration
 Where any Publish instance deals with traffic
 The Publish instance are synchronised via separate replication queues
on Author
 If one Publish fails, can “rebuild” from existing Publish instance or Gold
instance; or go to backup or rebuild, re-publish
3. Cluster: DB (2+)
 Active/Active configuration
 Where any Publish instance deals with traffic
 The Publish instances are synchronised via a shared DB
 If one Publish fails, can create new instance (or recover) and add to the
“cluster” (no re-publish required)
 Ensure DB is clustered, so it’s not a single point of failure
 Note: Cannot do rolling deployments
Publish: Configuration Options (2)
What configuration option should you use?
One or Two questions to ask yourself:
1. “Do you require the public to submit something and have
it displayed on the website? (I.e. Social Communities)”
Answers:
 No = Recommend: TarMK Farm (JCR)
 Yes = Ask yourself the 2nd Question
2. “Is there a business requirement for very fast display of
the submitted content with no moderation?”
Answers:
 No = Recommend: TarMK Farm (JCR)
 Yes = Recommend: Cluster (DB)
Publish: Configuration Options (3)
Why are these questions important? I.e. Why should you care?
 When your implementation requires public submitted content to appear on your
website, you need the information synchronised (somehow) across all of your
Publish instances.
 These questions seek to determine what architecture you’re going to implement
for synchronising across the Publish instances, namely:
1. Reverse replicate to Author and then replicate to all Publish instances
2. Store in shared DB and trigger invalidation across all Dispatchers
 If you need to moderate the social posts, then this is best placed to occur on the
Author. Even automated moderation should occur on the Author as it’s highly
likely that an Author will want to deal with the failures like false positives or
false negatives
 Consider all the pros and cons of your architecture: I.e:
 Don’t run a slower DB architecture unless you have good reasons
 Ask yourself whether you’re ok to give up rolling (canary) deployments
 Design a way to invalidate the pages on the dispatchers when you need to
Dispatcher: Configuration Options (1)
 Web server plugin that caches files to aid in website
performance and with some security rules
 Runs on: Apache httpd, Microsoft IIS, Oracle iPlanet
 Goal is to cache everything for as long as possible
 Operates on a publish/unpublish trigger, so cached objects
only get invalidated when they need to (as opposed to a TTL,
which expires content whether they need to or not)
 Doesn’t cache everything, so design your implementation so it
will cache everything or at least as much as possible
Dispatcher: Configuration Options (2)
How can you cache as much as possible, for as long as possible?
 Avoid use of querystrings or ignore irrelevant ones
http://domain/path/to/page.html?name=value
 Make use of selectors instead (so long as the variants are not infinite)
http://domain/path/to/page.value.html
http://domain/path/to/page.name-value.html
 Do work in Apache before sending to the dispatcher mod
 Apply rewrite rules prior
 Apply redirects prior & allowed vanity’s with new Dispatcher feature
 Apply SSI, ESI or SDI directives prior
 Spilt pages into different paths if caching policies are different
 Use SSI, ESI or SDI directives, so all fragments can be cached
independently or at least minimising the dynamic activity
 Avoid use of “Dispatcher: no-cache” directives (for obvious reasons)
 Ignore the authorisation header if you can
CDN: Configuration Options
Caches the files closer to where the users are
 Can also provide additional protection layers (DDOS, WAF, etc)
 Great for (tagged) website assets like: images, CSS, JS, etc.
 Ensure you utilise an etag, checksum or equivalent on the filename. This
ensures that if the file is updated, it generates a new filename and is
therefore distinguishable from the old version
 Not so useful for HTML pages or fragments
 Not all CDNs have a detailed API to flush selected objects or when they
do, the flushes can take a while to take effect, so you might have to rely
on TTLs instead
 If you do want to use a CDN API for invalidation, then you need to write a
custom replicator for this. If so, where will it fire? (Author or Publish?)
 Ensure you don’t introduce a race condition
 Caution: CDNs can be used as a Band-Aid to poor implementation design
and/or utilisation of the Dispatcher layer, so know why you’re going to
use it
Recommended HA Architecture
 Ensure you don’t have any single point of failure and
potential data loss if anything fails
 Avoid using a DB (especially in Publish)
 Avoid using a CDN for page (HTML) caching
Part 2 - Connectivity
 Connection: Dispatcher to Author or Publish
 Connection: Author to Publish
 Connection: Publish to Author
 Connection: Publish to Dispatcher
 Connection: AEM to CDN
Connection: Dispatcher to
Author or Publish (1)
 Dispatcher defines what server it talks to via the
/renders section in the dispatcher.any configuration file
/renders {
/0001 {
/hostname ”<publish1-name-or-ip>"
/port ”<publish1-port>"
}
# optional from here on...
/0002 {
/hostname ”<publish2-name-or-ip>"
/port ”<publish2-port>"
}
}
Connection: Dispatcher to
Author or Publish (2)
 When you specify multiple renders the page build request will
be sent equally or will send them to the best performing
renderer based on any categories defined in the /statistics
section of the dispatcher.any file
/statistics
{
/categories
{
/search { /glob "*search.html" }
/html { /glob "*.html" }
/others { /glob "*" }
}
}
 Tip: If you don’t have multiple renderers, don’t collect stats
Connection: Author to Publish (1)
 Author to Publish is for publishing or unpublishing content.
Messages are sent via a standard connection called “replicator”
 Replicators operate over a point-to-point architecture and
maintain a single queue per replicator
 On the Author, create a replicator per Publish instance when
using a single Publish or a TarMK Farm
 When using a DB, consider how you are going to replicate the
information without creating a dependency on one Publish node
or issuing duplicate replication messages (load balancer?)
 Queues may get processed at different times, which can be a
good thing. I.e. When Publish is down or busy.
 Note the potential affect on the Dispatcher when this happens!
Connection: Author to Publish (2)
Replicator
 Settings
 Transport
 Proxy
 Extra
Options
Connection: Publish to Author (1)
 Publish to Author is for content that is submitted by the
public and chosen to be stored within Author and then
possibly later to be presented out within the website on each
Publish instance.
 Messages are sent via a connection called “reverse replicator”
 Reverse replicators operate over a point-to-point architecture
and maintain a single queue per replicator
 Content is pulled from Author, so the connection is initiated
(typically) from a more secure zone to a less secure zone.
This is network best practise.
 Polling frequency is set to 30s by default
Connection: Publish to Author (2)
Two Parts:
1. Publish:
(outbox)
Reverse
Replicator
 Settings
 Transport
 Proxy
 Extra
Options
Connection: Publish to Author (3)
Two Parts:
2. Author:
(Pull)
Reverse
Replicator
 Settings
 Transport
 Proxy
 Extra
Options
Connection: Publish to Dispatcher (1)
 Publish to Dispatcher is to tell the Dispatcher what
items have changed, so it can follow its rules to
invalidate what it needs to.
 Messages are sent via a connection called “dispatcher
flush”
 Dispatcher Flushes operate over a point-to-point
architecture and maintain a single queue per replicator
 Any dispatcher that can send traffic to this Publish
instance should have a dispatcher flush connection
established
Connection: Publish to Dispatcher (2)
Dispatcher
Flush:
 Settings
 Transport
 Proxy
 Extra
Options
Load Balancer
M:N Dispatcher to Publish
 Requests go nicely through a load balancer
 Invalidations can’t go through a load balancer
 Needs point-to-point connection from each Publish to each
Dispatcher
Publish Tier
Dispatcher Tier
P2P1 P3 P4
D2D1 D3 D4
LBRequest
s
Invalidation
Paired Dispatcher to Publish
 Each Dispatcher has an assigned Publish instance
 Requests go only to the assigned Publish instance
 Invalidations go only to the assigned Dispatcher instance
 If one instance fails, they both need to be inaccessible
 Benefit for easier auto-scaling (independent module)
Publish Tier
Dispatcher Tier
P2P1 P3 P4
D2D1 D3 D4
Request
s
Invalidation
Connection: AEM to CDN
 AEM to CDN is for when you want to use a CDN API or flush
objects that have been cached there and you don’t want to
wait for a TTL
 Although the CDN may have a single entry point, the message
will need to be configured as a replicator on one (or more) of
your AEM instances (Author or Publish)
 Flush from Author and run the risk of a race condition (caused
by a Publish instance that was slow to process the message)
 Flush from Publish and you will have to choose:
1. Send from just one Publish instance, introducing a possible single
point of failure
2. Send from all your Publish instances, introducing a duplication of
flush messages for the same action
 Flush from a custom controller app, but unless you check the
processing queue of all your Publish instances, you may still
run the risk of a race condition
Part 3 – Architecture Principles
 KISS
 HA
 Performance
 Scalability
 Code Debt
KISS – Keep it simple, stupid
 Design principle coined by the US Navy in 1960
 Key philosophy of this principle being:
“Most systems work best if they are kept simple rather than made
complicated”
 Often as architects and developers we can get led astray from
“keeping it simple” by cool tech or trends in the market
 When adopting “cool tech” or “trendy tech” into an
implementation, which may seem like a great idea at the
time, if not aligned to the core product architecture and its
future roadmap, it can make the implementation unstable or
not able to be upgraded later on
 I.e. It’s generally not a good idea to put “frameworks” within
“frameworks”
HA – Highly Available
Fact: Hardware and software fails from time to time
 This principle is ensuring that the architecture is not prone to
becoming unavailable if one component fails
 This generally is aimed at the public delivery side, but is also
important internally as if systems are down, people can’t do
their job
 Ensure that every part of the core systems can continue to
operate if one host/application/tool fails
 Think about all core (and dependent) areas: Author-
Dispatcher, Author, Publish, Dispatcher, Load Balancers,
Firewalls, LDAP, Databases, Email servers, Networks,
Switches, Cables, Internet Providers, Backend applications or
systems, etc.
Performance
Fact: People don’t like slow websites
 One of the funniest architect statements I’ve ever heard is:
“You don’t need to cache anything if the servers are fast enough to handle it”
 Performance should be a core design consideration from Day 1
and beyond the implementation going live
 Websites get more popular, more websites get added to the
system, traffic has peaks and troughs, there are press releases,
product releases, social or environmental events, and seasonal
activity. Servers fail or need patching and sometimes people
hack or attack your environment
 Having your site perform as well as it can, (although important)
is not about saving hardware or license costs, it’s about making
your implementation more resilient and pleasant to end users
Scalability
 The ability to react to market demand and scale the
environment to keep meeting it
 One of the beautiful aspects of the AEM architecture is the
modularity of the components. This feature provides a
fantastic platform to support elastic architecture; one that
can automatically scale up or down
 With the introduction of virtual servers many years ago and
now with cloud infrastructure, we can tap into available
resources and scale to meet demand if/when required
 By creating pigeon-pairs of Dispatcher & Publish, you have a
modular, self-contained architecture that can be easily scaled
up or down.
Code Debt
The art of creating unnecessary or convoluted code that you or
someone else needs to look after
 Don’t create code that has already been implemented for you:
Examples: sling or acs-commons
 Sling: http://sling.apache.org/index.html
 ACS Commons: http://adobe-consulting-services.github.io/acs-aem-
commons/
 Don’t over engineer your solution
 Build what is required now, not what might be needed in the future
 Don’t over complicate something that can be implemented more
simply
 Consider that someone may need to look after your code
 Provide useful comments and appropriate debug statements
Author-Dispatcher Tier
Author Tier
Publish Tier
Dispatcher Tier
Recommended HA Architecture
A1
A-D1 A-D2
A2
P2P1 P3 P4
D2D1 D3 D4
CDN/Security TierCDN / Security
Summary
 We’ve talked about the various components that
typically make up an AEM implementation architecture
 We’ve talked about how each of these components
connect to each other and what to think about
 We’ve talked about key architecture principles to
consider
Questions?
Thank You
Michael Henderson BAS, BSc(Hons)
Technical Director, NSW
BizTECH Enterprise Solutions
Mobile: +61 430 758 026
Email: mhenderson@btes.com.au
Website: www.btes.com.au

More Related Content

What's hot

Introduction to WordPress
Introduction to WordPressIntroduction to WordPress
Introduction to WordPressEunus Hosen
 
PPT on web development & SEO
PPT on web development & SEOPPT on web development & SEO
PPT on web development & SEOPrakrati Bansal
 
How to Implement Micro Frontend Architecture using Angular Framework
How to Implement Micro Frontend Architecture using Angular FrameworkHow to Implement Micro Frontend Architecture using Angular Framework
How to Implement Micro Frontend Architecture using Angular FrameworkRapidValue
 
Aem dispatcher – tips & tricks
Aem dispatcher – tips & tricksAem dispatcher – tips & tricks
Aem dispatcher – tips & tricksAshokkumar T A
 
Adobe Experience Manager Core Components
Adobe Experience Manager Core ComponentsAdobe Experience Manager Core Components
Adobe Experience Manager Core ComponentsGabriel Walt
 
Introduction to Google Cloud Platform (GCP) | Google Cloud Tutorial for Begin...
Introduction to Google Cloud Platform (GCP) | Google Cloud Tutorial for Begin...Introduction to Google Cloud Platform (GCP) | Google Cloud Tutorial for Begin...
Introduction to Google Cloud Platform (GCP) | Google Cloud Tutorial for Begin...Edureka!
 
Dynamic CSS: Transforms, Transitions, and Animation Basics
Dynamic CSS: Transforms, Transitions, and Animation BasicsDynamic CSS: Transforms, Transitions, and Animation Basics
Dynamic CSS: Transforms, Transitions, and Animation BasicsBeth Soderberg
 
(DVO308) Docker & ECS in Production: How We Migrated Our Infrastructure from ...
(DVO308) Docker & ECS in Production: How We Migrated Our Infrastructure from ...(DVO308) Docker & ECS in Production: How We Migrated Our Infrastructure from ...
(DVO308) Docker & ECS in Production: How We Migrated Our Infrastructure from ...Amazon Web Services
 
Introduction to Google Cloud Services / Platforms
Introduction to Google Cloud Services / PlatformsIntroduction to Google Cloud Services / Platforms
Introduction to Google Cloud Services / PlatformsNilanchal
 
AWS Summit Seoul 2023 | Observability를 넘어선 클라우드 운영관리의 미래
AWS Summit Seoul 2023 | Observability를 넘어선 클라우드 운영관리의 미래AWS Summit Seoul 2023 | Observability를 넘어선 클라우드 운영관리의 미래
AWS Summit Seoul 2023 | Observability를 넘어선 클라우드 운영관리의 미래Amazon Web Services Korea
 
Building the business case for AWS
Building the business case for AWSBuilding the business case for AWS
Building the business case for AWSAmazon Web Services
 

What's hot (20)

Introduction to WordPress
Introduction to WordPressIntroduction to WordPress
Introduction to WordPress
 
Web development
Web developmentWeb development
Web development
 
PPT on web development & SEO
PPT on web development & SEOPPT on web development & SEO
PPT on web development & SEO
 
Web Development using HTML & CSS
Web Development using HTML & CSSWeb Development using HTML & CSS
Web Development using HTML & CSS
 
How to Implement Micro Frontend Architecture using Angular Framework
How to Implement Micro Frontend Architecture using Angular FrameworkHow to Implement Micro Frontend Architecture using Angular Framework
How to Implement Micro Frontend Architecture using Angular Framework
 
Aem Training Tutorials for Beginners
Aem  Training Tutorials for BeginnersAem  Training Tutorials for Beginners
Aem Training Tutorials for Beginners
 
Wordpress
WordpressWordpress
Wordpress
 
Progressive Web App
Progressive Web AppProgressive Web App
Progressive Web App
 
Aem dispatcher – tips & tricks
Aem dispatcher – tips & tricksAem dispatcher – tips & tricks
Aem dispatcher – tips & tricks
 
Adobe Experience Manager Core Components
Adobe Experience Manager Core ComponentsAdobe Experience Manager Core Components
Adobe Experience Manager Core Components
 
Cdn
CdnCdn
Cdn
 
CSS for Beginners
CSS for BeginnersCSS for Beginners
CSS for Beginners
 
Content migration to AEM
Content migration to AEMContent migration to AEM
Content migration to AEM
 
Introduction to Google Cloud Platform (GCP) | Google Cloud Tutorial for Begin...
Introduction to Google Cloud Platform (GCP) | Google Cloud Tutorial for Begin...Introduction to Google Cloud Platform (GCP) | Google Cloud Tutorial for Begin...
Introduction to Google Cloud Platform (GCP) | Google Cloud Tutorial for Begin...
 
Dynamic CSS: Transforms, Transitions, and Animation Basics
Dynamic CSS: Transforms, Transitions, and Animation BasicsDynamic CSS: Transforms, Transitions, and Animation Basics
Dynamic CSS: Transforms, Transitions, and Animation Basics
 
(DVO308) Docker & ECS in Production: How We Migrated Our Infrastructure from ...
(DVO308) Docker & ECS in Production: How We Migrated Our Infrastructure from ...(DVO308) Docker & ECS in Production: How We Migrated Our Infrastructure from ...
(DVO308) Docker & ECS in Production: How We Migrated Our Infrastructure from ...
 
Introduction to Google Cloud Services / Platforms
Introduction to Google Cloud Services / PlatformsIntroduction to Google Cloud Services / Platforms
Introduction to Google Cloud Services / Platforms
 
AWS Summit Seoul 2023 | Observability를 넘어선 클라우드 운영관리의 미래
AWS Summit Seoul 2023 | Observability를 넘어선 클라우드 운영관리의 미래AWS Summit Seoul 2023 | Observability를 넘어선 클라우드 운영관리의 미래
AWS Summit Seoul 2023 | Observability를 넘어선 클라우드 운영관리의 미래
 
Building the business case for AWS
Building the business case for AWSBuilding the business case for AWS
Building the business case for AWS
 
Vue.js
Vue.jsVue.js
Vue.js
 

Viewers also liked

Microservices Architecture for AEM
Microservices Architecture for AEMMicroservices Architecture for AEM
Microservices Architecture for AEMMaciej Majchrzak
 
New Repository in AEM 6 by Michael Marth
New Repository in AEM 6 by Michael MarthNew Repository in AEM 6 by Michael Marth
New Repository in AEM 6 by Michael MarthAEM HUB
 
Introduction to Sightly and Sling Models
Introduction to Sightly and Sling ModelsIntroduction to Sightly and Sling Models
Introduction to Sightly and Sling ModelsStefano Celentano
 
Build single page applications using AngularJS on AEM
Build single page applications using AngularJS on AEMBuild single page applications using AngularJS on AEM
Build single page applications using AngularJS on AEMconnectwebex
 
Oak, the architecture of Apache Jackrabbit 3
Oak, the architecture of Apache Jackrabbit 3Oak, the architecture of Apache Jackrabbit 3
Oak, the architecture of Apache Jackrabbit 3Jukka Zitting
 
Bombardier adobe aem msm implementation
Bombardier adobe aem msm implementationBombardier adobe aem msm implementation
Bombardier adobe aem msm implementationKen Knitter
 
Adobe AEM CQ5 - Developer Introduction
Adobe AEM CQ5 - Developer IntroductionAdobe AEM CQ5 - Developer Introduction
Adobe AEM CQ5 - Developer IntroductionYash Mody
 
Oak, the Architecture of the new Repository
Oak, the Architecture of the new RepositoryOak, the Architecture of the new Repository
Oak, the Architecture of the new RepositoryMichael Dürig
 
JCR, Sling or AEM? Which API should I use and when?
JCR, Sling or AEM? Which API should I use and when?JCR, Sling or AEM? Which API should I use and when?
JCR, Sling or AEM? Which API should I use and when?connectwebex
 
Understanding Sling Models in AEM
Understanding Sling Models in AEMUnderstanding Sling Models in AEM
Understanding Sling Models in AEMAccunity Software
 
AEM Sightly Template Language
AEM Sightly Template LanguageAEM Sightly Template Language
AEM Sightly Template LanguageGabriel Walt
 
Touching the AEM component dialog by Mateusz Chromiński
Touching the AEM component dialog by Mateusz ChromińskiTouching the AEM component dialog by Mateusz Chromiński
Touching the AEM component dialog by Mateusz ChromińskiAEM HUB
 
The new repository in AEM 6
The new repository in AEM 6The new repository in AEM 6
The new repository in AEM 6Jukka Zitting
 
Apache Jackrabbit Oak on MongoDB
Apache Jackrabbit Oak on MongoDBApache Jackrabbit Oak on MongoDB
Apache Jackrabbit Oak on MongoDBMongoDB
 
Melbourne User Group OAK and MongoDB
Melbourne User Group OAK and MongoDBMelbourne User Group OAK and MongoDB
Melbourne User Group OAK and MongoDBYuval Ararat
 
OSGi-friendly bytecode weaving – enhance your classes, not your dependency gr...
OSGi-friendly bytecode weaving – enhance your classes, not your dependency gr...OSGi-friendly bytecode weaving – enhance your classes, not your dependency gr...
OSGi-friendly bytecode weaving – enhance your classes, not your dependency gr...mfrancis
 

Viewers also liked (20)

Microservices Architecture for AEM
Microservices Architecture for AEMMicroservices Architecture for AEM
Microservices Architecture for AEM
 
New Repository in AEM 6 by Michael Marth
New Repository in AEM 6 by Michael MarthNew Repository in AEM 6 by Michael Marth
New Repository in AEM 6 by Michael Marth
 
Introduction to Sightly and Sling Models
Introduction to Sightly and Sling ModelsIntroduction to Sightly and Sling Models
Introduction to Sightly and Sling Models
 
Aem best practices
Aem best practicesAem best practices
Aem best practices
 
Build single page applications using AngularJS on AEM
Build single page applications using AngularJS on AEMBuild single page applications using AngularJS on AEM
Build single page applications using AngularJS on AEM
 
Oak, the architecture of Apache Jackrabbit 3
Oak, the architecture of Apache Jackrabbit 3Oak, the architecture of Apache Jackrabbit 3
Oak, the architecture of Apache Jackrabbit 3
 
Bombardier adobe aem msm implementation
Bombardier adobe aem msm implementationBombardier adobe aem msm implementation
Bombardier adobe aem msm implementation
 
Adobe AEM CQ5 - Developer Introduction
Adobe AEM CQ5 - Developer IntroductionAdobe AEM CQ5 - Developer Introduction
Adobe AEM CQ5 - Developer Introduction
 
Oak, the Architecture of the new Repository
Oak, the Architecture of the new RepositoryOak, the Architecture of the new Repository
Oak, the Architecture of the new Repository
 
JCR, Sling or AEM? Which API should I use and when?
JCR, Sling or AEM? Which API should I use and when?JCR, Sling or AEM? Which API should I use and when?
JCR, Sling or AEM? Which API should I use and when?
 
REST in AEM
REST in AEMREST in AEM
REST in AEM
 
Understanding Sling Models in AEM
Understanding Sling Models in AEMUnderstanding Sling Models in AEM
Understanding Sling Models in AEM
 
AEM Sightly Template Language
AEM Sightly Template LanguageAEM Sightly Template Language
AEM Sightly Template Language
 
EVOLVE'16 | Enhance | Anil Kalbag & Anshul Chhabra | Comparative Architecture...
EVOLVE'16 | Enhance | Anil Kalbag & Anshul Chhabra | Comparative Architecture...EVOLVE'16 | Enhance | Anil Kalbag & Anshul Chhabra | Comparative Architecture...
EVOLVE'16 | Enhance | Anil Kalbag & Anshul Chhabra | Comparative Architecture...
 
Touching the AEM component dialog by Mateusz Chromiński
Touching the AEM component dialog by Mateusz ChromińskiTouching the AEM component dialog by Mateusz Chromiński
Touching the AEM component dialog by Mateusz Chromiński
 
The new repository in AEM 6
The new repository in AEM 6The new repository in AEM 6
The new repository in AEM 6
 
Apache Jackrabbit Oak on MongoDB
Apache Jackrabbit Oak on MongoDBApache Jackrabbit Oak on MongoDB
Apache Jackrabbit Oak on MongoDB
 
Melbourne User Group OAK and MongoDB
Melbourne User Group OAK and MongoDBMelbourne User Group OAK and MongoDB
Melbourne User Group OAK and MongoDB
 
OSGi-friendly bytecode weaving – enhance your classes, not your dependency gr...
OSGi-friendly bytecode weaving – enhance your classes, not your dependency gr...OSGi-friendly bytecode weaving – enhance your classes, not your dependency gr...
OSGi-friendly bytecode weaving – enhance your classes, not your dependency gr...
 
Intranet Content Migration
Intranet Content MigrationIntranet Content Migration
Intranet Content Migration
 

Similar to Adobe Meetup AEM Architecture Sydney 2015

Voldemort & Hadoop @ Linkedin, Hadoop User Group Jan 2010
Voldemort & Hadoop @ Linkedin, Hadoop User Group Jan 2010Voldemort & Hadoop @ Linkedin, Hadoop User Group Jan 2010
Voldemort & Hadoop @ Linkedin, Hadoop User Group Jan 2010Bhupesh Bansal
 
Hadoop and Voldemort @ LinkedIn
Hadoop and Voldemort @ LinkedInHadoop and Voldemort @ LinkedIn
Hadoop and Voldemort @ LinkedInHadoop User Group
 
Ingesting Over Four Million Rows Per Second With QuestDB Timeseries Database ...
Ingesting Over Four Million Rows Per Second With QuestDB Timeseries Database ...Ingesting Over Four Million Rows Per Second With QuestDB Timeseries Database ...
Ingesting Over Four Million Rows Per Second With QuestDB Timeseries Database ...javier ramirez
 
Building the Perfect SharePoint 2010 Farm - TechEd Australia 2011
Building the Perfect SharePoint 2010 Farm - TechEd Australia 2011Building the Perfect SharePoint 2010 Farm - TechEd Australia 2011
Building the Perfect SharePoint 2010 Farm - TechEd Australia 2011Michael Noel
 
Unity Connect - Getting SQL Spinning with SharePoint - Best Practices for the...
Unity Connect - Getting SQL Spinning with SharePoint - Best Practices for the...Unity Connect - Getting SQL Spinning with SharePoint - Best Practices for the...
Unity Connect - Getting SQL Spinning with SharePoint - Best Practices for the...Knut Relbe-Moe [MVP, MCT]
 
Improving Drupal Performances
Improving Drupal PerformancesImproving Drupal Performances
Improving Drupal PerformancesVladimir Ilic
 
DrupalCampLA 2011 - Drupal frontend-optimizing
DrupalCampLA 2011 - Drupal frontend-optimizingDrupalCampLA 2011 - Drupal frontend-optimizing
DrupalCampLA 2011 - Drupal frontend-optimizingAshok Modi
 
Building the Perfect SharePoint 2010 Farm - SPS Brisbane 2011
Building the Perfect SharePoint 2010 Farm - SPS Brisbane 2011Building the Perfect SharePoint 2010 Farm - SPS Brisbane 2011
Building the Perfect SharePoint 2010 Farm - SPS Brisbane 2011Michael Noel
 
Drupal Performance : DrupalCamp North
Drupal Performance : DrupalCamp NorthDrupal Performance : DrupalCamp North
Drupal Performance : DrupalCamp NorthPhilip Norton
 
Austin Web Architecture
Austin Web ArchitectureAustin Web Architecture
Austin Web Architecturejoaquincasares
 
node.js 실무 - node js in practice by Jesang Yoon
node.js 실무 - node js in practice by Jesang Yoonnode.js 실무 - node js in practice by Jesang Yoon
node.js 실무 - node js in practice by Jesang YoonJesang Yoon
 
Migraine Drupal - syncing your staging and live sites
Migraine Drupal - syncing your staging and live sitesMigraine Drupal - syncing your staging and live sites
Migraine Drupal - syncing your staging and live sitesdrupalindia
 
NZSPC 2013 - Ultimate SharePoint Infrastructure Best Practices Session
NZSPC 2013 - Ultimate SharePoint Infrastructure Best Practices SessionNZSPC 2013 - Ultimate SharePoint Infrastructure Best Practices Session
NZSPC 2013 - Ultimate SharePoint Infrastructure Best Practices SessionMichael Noel
 
Oracle on AWS partner webinar series
Oracle on AWS partner webinar series Oracle on AWS partner webinar series
Oracle on AWS partner webinar series Tom Laszewski
 
DrupalCampLA 2011: Drupal backend-performance
DrupalCampLA 2011: Drupal backend-performanceDrupalCampLA 2011: Drupal backend-performance
DrupalCampLA 2011: Drupal backend-performanceAshok Modi
 
Building the Perfect SharePoint 2010 Farm - SharePoint Saturday NYC 2011
Building the Perfect SharePoint 2010 Farm - SharePoint Saturday NYC 2011Building the Perfect SharePoint 2010 Farm - SharePoint Saturday NYC 2011
Building the Perfect SharePoint 2010 Farm - SharePoint Saturday NYC 2011Michael Noel
 
From frustration to fascination: dissecting Replication
From frustration to fascination: dissecting ReplicationFrom frustration to fascination: dissecting Replication
From frustration to fascination: dissecting ReplicationBenedek Menesi
 

Similar to Adobe Meetup AEM Architecture Sydney 2015 (20)

Voldemort & Hadoop @ Linkedin, Hadoop User Group Jan 2010
Voldemort & Hadoop @ Linkedin, Hadoop User Group Jan 2010Voldemort & Hadoop @ Linkedin, Hadoop User Group Jan 2010
Voldemort & Hadoop @ Linkedin, Hadoop User Group Jan 2010
 
Hadoop and Voldemort @ LinkedIn
Hadoop and Voldemort @ LinkedInHadoop and Voldemort @ LinkedIn
Hadoop and Voldemort @ LinkedIn
 
SharePoint Performance
SharePoint PerformanceSharePoint Performance
SharePoint Performance
 
Ingesting Over Four Million Rows Per Second With QuestDB Timeseries Database ...
Ingesting Over Four Million Rows Per Second With QuestDB Timeseries Database ...Ingesting Over Four Million Rows Per Second With QuestDB Timeseries Database ...
Ingesting Over Four Million Rows Per Second With QuestDB Timeseries Database ...
 
Building the Perfect SharePoint 2010 Farm - TechEd Australia 2011
Building the Perfect SharePoint 2010 Farm - TechEd Australia 2011Building the Perfect SharePoint 2010 Farm - TechEd Australia 2011
Building the Perfect SharePoint 2010 Farm - TechEd Australia 2011
 
Unity Connect - Getting SQL Spinning with SharePoint - Best Practices for the...
Unity Connect - Getting SQL Spinning with SharePoint - Best Practices for the...Unity Connect - Getting SQL Spinning with SharePoint - Best Practices for the...
Unity Connect - Getting SQL Spinning with SharePoint - Best Practices for the...
 
Improving Drupal Performances
Improving Drupal PerformancesImproving Drupal Performances
Improving Drupal Performances
 
DrupalCampLA 2011 - Drupal frontend-optimizing
DrupalCampLA 2011 - Drupal frontend-optimizingDrupalCampLA 2011 - Drupal frontend-optimizing
DrupalCampLA 2011 - Drupal frontend-optimizing
 
Building the Perfect SharePoint 2010 Farm - SPS Brisbane 2011
Building the Perfect SharePoint 2010 Farm - SPS Brisbane 2011Building the Perfect SharePoint 2010 Farm - SPS Brisbane 2011
Building the Perfect SharePoint 2010 Farm - SPS Brisbane 2011
 
Drupal Performance : DrupalCamp North
Drupal Performance : DrupalCamp NorthDrupal Performance : DrupalCamp North
Drupal Performance : DrupalCamp North
 
Austin Web Architecture
Austin Web ArchitectureAustin Web Architecture
Austin Web Architecture
 
node.js 실무 - node js in practice by Jesang Yoon
node.js 실무 - node js in practice by Jesang Yoonnode.js 실무 - node js in practice by Jesang Yoon
node.js 실무 - node js in practice by Jesang Yoon
 
Migraine Drupal - syncing your staging and live sites
Migraine Drupal - syncing your staging and live sitesMigraine Drupal - syncing your staging and live sites
Migraine Drupal - syncing your staging and live sites
 
How To Scale v2
How To Scale v2How To Scale v2
How To Scale v2
 
NZSPC 2013 - Ultimate SharePoint Infrastructure Best Practices Session
NZSPC 2013 - Ultimate SharePoint Infrastructure Best Practices SessionNZSPC 2013 - Ultimate SharePoint Infrastructure Best Practices Session
NZSPC 2013 - Ultimate SharePoint Infrastructure Best Practices Session
 
Oracle on AWS partner webinar series
Oracle on AWS partner webinar series Oracle on AWS partner webinar series
Oracle on AWS partner webinar series
 
DrupalCampLA 2011: Drupal backend-performance
DrupalCampLA 2011: Drupal backend-performanceDrupalCampLA 2011: Drupal backend-performance
DrupalCampLA 2011: Drupal backend-performance
 
Building the Perfect SharePoint 2010 Farm - SharePoint Saturday NYC 2011
Building the Perfect SharePoint 2010 Farm - SharePoint Saturday NYC 2011Building the Perfect SharePoint 2010 Farm - SharePoint Saturday NYC 2011
Building the Perfect SharePoint 2010 Farm - SharePoint Saturday NYC 2011
 
From frustration to fascination: dissecting Replication
From frustration to fascination: dissecting ReplicationFrom frustration to fascination: dissecting Replication
From frustration to fascination: dissecting Replication
 
Aws best practices
Aws best practicesAws best practices
Aws best practices
 

Recently uploaded

The State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxThe State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxLoriGlavin3
 
Modern Roaming for Notes and Nomad – Cheaper Faster Better Stronger
Modern Roaming for Notes and Nomad – Cheaper Faster Better StrongerModern Roaming for Notes and Nomad – Cheaper Faster Better Stronger
Modern Roaming for Notes and Nomad – Cheaper Faster Better Strongerpanagenda
 
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...panagenda
 
Moving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfMoving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfLoriGlavin3
 
2024 April Patch Tuesday
2024 April Patch Tuesday2024 April Patch Tuesday
2024 April Patch TuesdayIvanti
 
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024BookNet Canada
 
Connecting the Dots for Information Discovery.pdf
Connecting the Dots for Information Discovery.pdfConnecting the Dots for Information Discovery.pdf
Connecting the Dots for Information Discovery.pdfNeo4j
 
[Webinar] SpiraTest - Setting New Standards in Quality Assurance
[Webinar] SpiraTest - Setting New Standards in Quality Assurance[Webinar] SpiraTest - Setting New Standards in Quality Assurance
[Webinar] SpiraTest - Setting New Standards in Quality AssuranceInflectra
 
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptxThe Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptxLoriGlavin3
 
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesHow to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesThousandEyes
 
TrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data PrivacyTrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data PrivacyTrustArc
 
Generative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information DevelopersGenerative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information DevelopersRaghuram Pandurangan
 
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptxMerck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptxLoriGlavin3
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxLoriGlavin3
 
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxLoriGlavin3
 
A Framework for Development in the AI Age
A Framework for Development in the AI AgeA Framework for Development in the AI Age
A Framework for Development in the AI AgeCprime
 
How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.Curtis Poe
 
TeamStation AI System Report LATAM IT Salaries 2024
TeamStation AI System Report LATAM IT Salaries 2024TeamStation AI System Report LATAM IT Salaries 2024
TeamStation AI System Report LATAM IT Salaries 2024Lonnie McRorey
 
Data governance with Unity Catalog Presentation
Data governance with Unity Catalog PresentationData governance with Unity Catalog Presentation
Data governance with Unity Catalog PresentationKnoldus Inc.
 
Take control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteTake control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteDianaGray10
 

Recently uploaded (20)

The State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxThe State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptx
 
Modern Roaming for Notes and Nomad – Cheaper Faster Better Stronger
Modern Roaming for Notes and Nomad – Cheaper Faster Better StrongerModern Roaming for Notes and Nomad – Cheaper Faster Better Stronger
Modern Roaming for Notes and Nomad – Cheaper Faster Better Stronger
 
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
 
Moving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfMoving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdf
 
2024 April Patch Tuesday
2024 April Patch Tuesday2024 April Patch Tuesday
2024 April Patch Tuesday
 
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
 
Connecting the Dots for Information Discovery.pdf
Connecting the Dots for Information Discovery.pdfConnecting the Dots for Information Discovery.pdf
Connecting the Dots for Information Discovery.pdf
 
[Webinar] SpiraTest - Setting New Standards in Quality Assurance
[Webinar] SpiraTest - Setting New Standards in Quality Assurance[Webinar] SpiraTest - Setting New Standards in Quality Assurance
[Webinar] SpiraTest - Setting New Standards in Quality Assurance
 
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptxThe Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
 
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesHow to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
 
TrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data PrivacyTrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data Privacy
 
Generative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information DevelopersGenerative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information Developers
 
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptxMerck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptx
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
 
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
 
A Framework for Development in the AI Age
A Framework for Development in the AI AgeA Framework for Development in the AI Age
A Framework for Development in the AI Age
 
How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.
 
TeamStation AI System Report LATAM IT Salaries 2024
TeamStation AI System Report LATAM IT Salaries 2024TeamStation AI System Report LATAM IT Salaries 2024
TeamStation AI System Report LATAM IT Salaries 2024
 
Data governance with Unity Catalog Presentation
Data governance with Unity Catalog PresentationData governance with Unity Catalog Presentation
Data governance with Unity Catalog Presentation
 
Take control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteTake control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test Suite
 

Adobe Meetup AEM Architecture Sydney 2015

  • 1. AEM Architecture Adobe Meet-up : Sydney : 16th September 2015 Purpose of these slides: To describe common AEM architecture options, outline the various pros and cons, provide some best practise recommendations for new and existing implementations. Michael Henderson BAS, BSc(Hons) Technical Director, NSW BizTECH Enterprise Solutions Mobile: +61 430 758 026 Email: mhenderson@btes.com.au Website: www.btes.com.au
  • 2. Agenda Part 1: What to do when setting up Author (1 or more), Author- Dispatcher (1 or more), Publish (1 or more), Dispatcher (1 or more), CDN (there or not), Clustering/DB (there or not). Part 2: Connectivity between the components; pointing out different configurations, advantages/disadvantages, things to consider, things to think about. Part 3: Architectural philosophies like KISS, HA, Performance, Scalability, etc.
  • 3. Part 1 – Architecture Elements  Basic Architecture  What is an AEM instance?  AEM Repositories  Performance: Oak vs MongoDB  Author: Configuration Options  Publish: Configuration Options  Dispatcher: Configuration Options  CDN: Configuration Options  Recommended HA Architecture
  • 4. Basic Architecture (1)  Author  Where all the authoring goodness happens  Publish  Where all the public goodness gets formulated  Dispatcher  Where public goodness gets secured and cached  Author-dispatcher  Where some authoring security takes place  CDN  Where you gain some localised caching and/or security
  • 5. Author-Dispatcher Tier Author Tier Publish Tier Dispatcher Tier Basic Architecture (2) A A-D P D CDN TierCDN
  • 6. OSGi What is an AEM instance? JCR Sling AEM The architecture layers that make up AEM:
  • 7. AEM Repositories  AEM 5.x and older  JCR2, but who really cares anymore. If you do? Let it go.   AEM 6.0  AEM supports JCR2, JCR3, MongoDB  MongoDB introduced as clustering repository  AEM 6.1  AEM supports JCR3, DB2, MongoDB, Oracle  Clustering repository options expanded  Experimental  Support for MySQL, MariaDB and MS SQL Server  Coming in next release?
  • 8. MongoDB: Simple Example AEM 1 AEM 2 MongoDB Primary MongoDB Secondary MongoDB Secondary Read & Write Replication
  • 9. MongoDB: More Complex Example AEM 1 AEM 2 MongoDB Query Router MongoDB Secondary Mongo Sharding MongoDB Query Router MongoDB Primary MongoDB Secondary MongoDB Secondary MongoDB Primary MongoDB Secondary MongoDB Secondary MongoDB Primary MongoDB Secondary
  • 10. Performance: Oak vs MongoDB (1) 0 2 4 6 8 10 12 14 Oak MongoMK (Lower is better)
  • 11. Performance: Oak vs MongoDB (2) 0 2 4 6 8 10 12 14 16 18 Oak MongoDB (Lower is better)
  • 12. Performance: Oak vs MongoDB (3) Summary:  Oak is by far the best performer  Use Oak unless you NEED to go DB-backed Notes:  Oak = TarMK = JCR3 = JackRabbit3  I haven’t seen any performance stats for the other DB’s  Performance Reference:  http://www.slideshare.net/mmarth/aem-hub-oak-02-full
  • 13. Author: Configuration Options (1) 1. Single Author: JCR (1x) : Not recommended  Where you have only one Author instance  No redundancy. If Author fails, go to backup (lose data) 2. Active/Standby: JCR (2x) : Recommended  Where one Author instance deals with all traffic  The standby Author instance stays synchronised  Referred to as “Cold Standby” (although not cold)  If Author fails, can start “standby” as master instance (no data loss) 3. Active/Active: DB (2+)  Where any Author instance deals with traffic  The Author instances are synchronised via a shared DB  Cannot run on JCR; must run on DB (DB2, Mongo, Oracle)  If one Author fails, can create new instance (or recover) and add to the “cluster” (no author outage)  Ensure DB is clustered, so it’s not a single point of failure  Can run DataStore on shared disk or S3 (Amazon) for better performance
  • 14. Author: Configuration Options (2) What configuration option should you use? Really simple question to ask yourself:  “Can a single Author instance sustain all the required author traffic?” Answers:  Yes = Recommend: Active/Standby (JCR)  No = Recommend: Active/Active (DB)
  • 15. Author: Configuration Options (3) What can you do to help the Author instance load?  Ensure the project code is efficient  Ensure the Author is running on disk with high IOPS (I.e. a SSD or striped high IO)  Are there tasks or processes running on the Author that could be offloaded to another server?  Is the Author server as big as it can be?
  • 16. Publish: Configuration Options (1) 1. Single Publish: JCR (1x) : Not recommended  Where you have only one Publish instance  No redundancy. Failure: Go to backup or rebuild, re-publish (outage) 2. TarMK Farm: JCR (2+) : Recommended  Active/Active configuration  Where any Publish instance deals with traffic  The Publish instance are synchronised via separate replication queues on Author  If one Publish fails, can “rebuild” from existing Publish instance or Gold instance; or go to backup or rebuild, re-publish 3. Cluster: DB (2+)  Active/Active configuration  Where any Publish instance deals with traffic  The Publish instances are synchronised via a shared DB  If one Publish fails, can create new instance (or recover) and add to the “cluster” (no re-publish required)  Ensure DB is clustered, so it’s not a single point of failure  Note: Cannot do rolling deployments
  • 17. Publish: Configuration Options (2) What configuration option should you use? One or Two questions to ask yourself: 1. “Do you require the public to submit something and have it displayed on the website? (I.e. Social Communities)” Answers:  No = Recommend: TarMK Farm (JCR)  Yes = Ask yourself the 2nd Question 2. “Is there a business requirement for very fast display of the submitted content with no moderation?” Answers:  No = Recommend: TarMK Farm (JCR)  Yes = Recommend: Cluster (DB)
  • 18. Publish: Configuration Options (3) Why are these questions important? I.e. Why should you care?  When your implementation requires public submitted content to appear on your website, you need the information synchronised (somehow) across all of your Publish instances.  These questions seek to determine what architecture you’re going to implement for synchronising across the Publish instances, namely: 1. Reverse replicate to Author and then replicate to all Publish instances 2. Store in shared DB and trigger invalidation across all Dispatchers  If you need to moderate the social posts, then this is best placed to occur on the Author. Even automated moderation should occur on the Author as it’s highly likely that an Author will want to deal with the failures like false positives or false negatives  Consider all the pros and cons of your architecture: I.e:  Don’t run a slower DB architecture unless you have good reasons  Ask yourself whether you’re ok to give up rolling (canary) deployments  Design a way to invalidate the pages on the dispatchers when you need to
  • 19. Dispatcher: Configuration Options (1)  Web server plugin that caches files to aid in website performance and with some security rules  Runs on: Apache httpd, Microsoft IIS, Oracle iPlanet  Goal is to cache everything for as long as possible  Operates on a publish/unpublish trigger, so cached objects only get invalidated when they need to (as opposed to a TTL, which expires content whether they need to or not)  Doesn’t cache everything, so design your implementation so it will cache everything or at least as much as possible
  • 20. Dispatcher: Configuration Options (2) How can you cache as much as possible, for as long as possible?  Avoid use of querystrings or ignore irrelevant ones http://domain/path/to/page.html?name=value  Make use of selectors instead (so long as the variants are not infinite) http://domain/path/to/page.value.html http://domain/path/to/page.name-value.html  Do work in Apache before sending to the dispatcher mod  Apply rewrite rules prior  Apply redirects prior & allowed vanity’s with new Dispatcher feature  Apply SSI, ESI or SDI directives prior  Spilt pages into different paths if caching policies are different  Use SSI, ESI or SDI directives, so all fragments can be cached independently or at least minimising the dynamic activity  Avoid use of “Dispatcher: no-cache” directives (for obvious reasons)  Ignore the authorisation header if you can
  • 21. CDN: Configuration Options Caches the files closer to where the users are  Can also provide additional protection layers (DDOS, WAF, etc)  Great for (tagged) website assets like: images, CSS, JS, etc.  Ensure you utilise an etag, checksum or equivalent on the filename. This ensures that if the file is updated, it generates a new filename and is therefore distinguishable from the old version  Not so useful for HTML pages or fragments  Not all CDNs have a detailed API to flush selected objects or when they do, the flushes can take a while to take effect, so you might have to rely on TTLs instead  If you do want to use a CDN API for invalidation, then you need to write a custom replicator for this. If so, where will it fire? (Author or Publish?)  Ensure you don’t introduce a race condition  Caution: CDNs can be used as a Band-Aid to poor implementation design and/or utilisation of the Dispatcher layer, so know why you’re going to use it
  • 22. Recommended HA Architecture  Ensure you don’t have any single point of failure and potential data loss if anything fails  Avoid using a DB (especially in Publish)  Avoid using a CDN for page (HTML) caching
  • 23. Part 2 - Connectivity  Connection: Dispatcher to Author or Publish  Connection: Author to Publish  Connection: Publish to Author  Connection: Publish to Dispatcher  Connection: AEM to CDN
  • 24. Connection: Dispatcher to Author or Publish (1)  Dispatcher defines what server it talks to via the /renders section in the dispatcher.any configuration file /renders { /0001 { /hostname ”<publish1-name-or-ip>" /port ”<publish1-port>" } # optional from here on... /0002 { /hostname ”<publish2-name-or-ip>" /port ”<publish2-port>" } }
  • 25. Connection: Dispatcher to Author or Publish (2)  When you specify multiple renders the page build request will be sent equally or will send them to the best performing renderer based on any categories defined in the /statistics section of the dispatcher.any file /statistics { /categories { /search { /glob "*search.html" } /html { /glob "*.html" } /others { /glob "*" } } }  Tip: If you don’t have multiple renderers, don’t collect stats
  • 26. Connection: Author to Publish (1)  Author to Publish is for publishing or unpublishing content. Messages are sent via a standard connection called “replicator”  Replicators operate over a point-to-point architecture and maintain a single queue per replicator  On the Author, create a replicator per Publish instance when using a single Publish or a TarMK Farm  When using a DB, consider how you are going to replicate the information without creating a dependency on one Publish node or issuing duplicate replication messages (load balancer?)  Queues may get processed at different times, which can be a good thing. I.e. When Publish is down or busy.  Note the potential affect on the Dispatcher when this happens!
  • 27. Connection: Author to Publish (2) Replicator  Settings  Transport  Proxy  Extra Options
  • 28. Connection: Publish to Author (1)  Publish to Author is for content that is submitted by the public and chosen to be stored within Author and then possibly later to be presented out within the website on each Publish instance.  Messages are sent via a connection called “reverse replicator”  Reverse replicators operate over a point-to-point architecture and maintain a single queue per replicator  Content is pulled from Author, so the connection is initiated (typically) from a more secure zone to a less secure zone. This is network best practise.  Polling frequency is set to 30s by default
  • 29. Connection: Publish to Author (2) Two Parts: 1. Publish: (outbox) Reverse Replicator  Settings  Transport  Proxy  Extra Options
  • 30. Connection: Publish to Author (3) Two Parts: 2. Author: (Pull) Reverse Replicator  Settings  Transport  Proxy  Extra Options
  • 31. Connection: Publish to Dispatcher (1)  Publish to Dispatcher is to tell the Dispatcher what items have changed, so it can follow its rules to invalidate what it needs to.  Messages are sent via a connection called “dispatcher flush”  Dispatcher Flushes operate over a point-to-point architecture and maintain a single queue per replicator  Any dispatcher that can send traffic to this Publish instance should have a dispatcher flush connection established
  • 32. Connection: Publish to Dispatcher (2) Dispatcher Flush:  Settings  Transport  Proxy  Extra Options
  • 33. Load Balancer M:N Dispatcher to Publish  Requests go nicely through a load balancer  Invalidations can’t go through a load balancer  Needs point-to-point connection from each Publish to each Dispatcher Publish Tier Dispatcher Tier P2P1 P3 P4 D2D1 D3 D4 LBRequest s Invalidation
  • 34. Paired Dispatcher to Publish  Each Dispatcher has an assigned Publish instance  Requests go only to the assigned Publish instance  Invalidations go only to the assigned Dispatcher instance  If one instance fails, they both need to be inaccessible  Benefit for easier auto-scaling (independent module) Publish Tier Dispatcher Tier P2P1 P3 P4 D2D1 D3 D4 Request s Invalidation
  • 35. Connection: AEM to CDN  AEM to CDN is for when you want to use a CDN API or flush objects that have been cached there and you don’t want to wait for a TTL  Although the CDN may have a single entry point, the message will need to be configured as a replicator on one (or more) of your AEM instances (Author or Publish)  Flush from Author and run the risk of a race condition (caused by a Publish instance that was slow to process the message)  Flush from Publish and you will have to choose: 1. Send from just one Publish instance, introducing a possible single point of failure 2. Send from all your Publish instances, introducing a duplication of flush messages for the same action  Flush from a custom controller app, but unless you check the processing queue of all your Publish instances, you may still run the risk of a race condition
  • 36. Part 3 – Architecture Principles  KISS  HA  Performance  Scalability  Code Debt
  • 37. KISS – Keep it simple, stupid  Design principle coined by the US Navy in 1960  Key philosophy of this principle being: “Most systems work best if they are kept simple rather than made complicated”  Often as architects and developers we can get led astray from “keeping it simple” by cool tech or trends in the market  When adopting “cool tech” or “trendy tech” into an implementation, which may seem like a great idea at the time, if not aligned to the core product architecture and its future roadmap, it can make the implementation unstable or not able to be upgraded later on  I.e. It’s generally not a good idea to put “frameworks” within “frameworks”
  • 38. HA – Highly Available Fact: Hardware and software fails from time to time  This principle is ensuring that the architecture is not prone to becoming unavailable if one component fails  This generally is aimed at the public delivery side, but is also important internally as if systems are down, people can’t do their job  Ensure that every part of the core systems can continue to operate if one host/application/tool fails  Think about all core (and dependent) areas: Author- Dispatcher, Author, Publish, Dispatcher, Load Balancers, Firewalls, LDAP, Databases, Email servers, Networks, Switches, Cables, Internet Providers, Backend applications or systems, etc.
  • 39. Performance Fact: People don’t like slow websites  One of the funniest architect statements I’ve ever heard is: “You don’t need to cache anything if the servers are fast enough to handle it”  Performance should be a core design consideration from Day 1 and beyond the implementation going live  Websites get more popular, more websites get added to the system, traffic has peaks and troughs, there are press releases, product releases, social or environmental events, and seasonal activity. Servers fail or need patching and sometimes people hack or attack your environment  Having your site perform as well as it can, (although important) is not about saving hardware or license costs, it’s about making your implementation more resilient and pleasant to end users
  • 40. Scalability  The ability to react to market demand and scale the environment to keep meeting it  One of the beautiful aspects of the AEM architecture is the modularity of the components. This feature provides a fantastic platform to support elastic architecture; one that can automatically scale up or down  With the introduction of virtual servers many years ago and now with cloud infrastructure, we can tap into available resources and scale to meet demand if/when required  By creating pigeon-pairs of Dispatcher & Publish, you have a modular, self-contained architecture that can be easily scaled up or down.
  • 41. Code Debt The art of creating unnecessary or convoluted code that you or someone else needs to look after  Don’t create code that has already been implemented for you: Examples: sling or acs-commons  Sling: http://sling.apache.org/index.html  ACS Commons: http://adobe-consulting-services.github.io/acs-aem- commons/  Don’t over engineer your solution  Build what is required now, not what might be needed in the future  Don’t over complicate something that can be implemented more simply  Consider that someone may need to look after your code  Provide useful comments and appropriate debug statements
  • 42. Author-Dispatcher Tier Author Tier Publish Tier Dispatcher Tier Recommended HA Architecture A1 A-D1 A-D2 A2 P2P1 P3 P4 D2D1 D3 D4 CDN/Security TierCDN / Security
  • 43. Summary  We’ve talked about the various components that typically make up an AEM implementation architecture  We’ve talked about how each of these components connect to each other and what to think about  We’ve talked about key architecture principles to consider
  • 45. Thank You Michael Henderson BAS, BSc(Hons) Technical Director, NSW BizTECH Enterprise Solutions Mobile: +61 430 758 026 Email: mhenderson@btes.com.au Website: www.btes.com.au