CISCO.COM CASE STUDY
Extending Adobe AEM for High Availability, High Performance and High Scalability
PRESENTED BY

ABOUT US
2
• Akhil Aggrawal
• Distinguish Engineer & Chief
Architect Cisco.com
• linkedin.com/in/akhilaggrawal
• @akhil183
• Anshul Chhabra
• Principal Architect, McAfee
• Previously Architect, Cisco.com
• linkedin.com/in/anshulchhabra
• @Anshul2

Cisco’s Digital Presence
355M
visits to Cisco.com
11.5M
social reach
112M
organic search
referrals
3.9M
paid search click-throughs
3M
social media
mentions
40% 34%
71%
4%
10.7M
mobile web
visits
1.4M
social referrers
to Cisco.com
5.7M
customer
app
downloads
Q1FY14 – Q4FY14
2.5M
video views on
Cisco.com
Web Social Media Mobile
7.5M
video views on
Cisco YouTube
47%
Video
[Date Range: Q1FY14 – Q4FY14]

CISCO.COM WEB EXPERIENCE MANAGEMENT -
(FEB24TH & 25TH)
• Ave 1200 hits/sec @ Edge
• 1.75m visitors
• 41% to Cisco Datacenter
• 28m hits @ Adobe AEM
• 82m hits @ non-AEM (migration
in fy15)
• Contains ~800K files (.html, .jpg, .gif, .pdf, .mobi and more) [35% of overall cisco.com content]
• ~1.5 TB
Source: Enterprise Operation Intelligence (Splunk) & Akamai Control Panel & Enterprise Web Analytics

EXPECTATIONS FROM AEM ARCHITECTURE
• Always on / Highly Available
• Amazing Global Performance
• Scalable to support cisco.com traffic/volume
CISCO SPECIFIC REQUIREMENTS
• Cisco Visibility Needs (Entitlement)
• Personalization/Targetting
• Localization 40 languages, 85 countries
• Auto Generation of product pages as part of New Product Introduction Process
• Content Rendition via CTS : Frame à html|pdf, wordà html|pdf

6
WEB ARCHITECTURE

WEM PHYSICAL ARCHITECTURE (PUBLISH)
Cisco DC1 Cisco DC2
Active- Active Multiple Datacenter (Cisco MVDC) Architecture

WEM PHYSICAL ARCHITECTURE (AUTHOR)
§ Single data center
presence
§ No Clustering
§ ISSUE - Can not be
distributed
geographically/DC
Cisco RCDN Datacenter

9
HA AND FAULT TOLERANT

HA PROBING MODEL
§ Web level probes stay
at Web level
§ Web won’t go down
due to app failure
§ Site Selection at Web
and App Level
DC1 Webserver Cisco
ACE LB
DC2 Webserver Cisco
ACE LB
DC1 AppServer
Cisco ACE LB
DC2 AppServer
Cisco ACE LB

COMPLETE AEM APP
FAILURE SCENARIO
§ All App Servers Down
§ Web still up
§ Serves cached content
§ Independent Alerting
via Enterprise Monitoring
DC1 Webserver Cisco
ACE LB
DC2 Webserver Cisco
ACE LB
DC1 AppServer
Cisco ACE LB
DC2 AppServer
Cisco ACE LB

12
CACHE IS KING!!
Dispatcher as Billboard – Proactive Caching
Akamai
Entitlement Caching
Impact Analysis

CACHING IN WEM
Web
• Page load : 2-5 s
• Max request time
within DC: 500ms
Akamai Client
Web
CQ Publish Server ACE
Leverage Apache to
Stream content (via
Adobe dispatcher)
App level caching
of High compute
objects (ehCache)
Assets + all content
caching – guest, customer,
etc (flexible cache ID)
Dispatcher

WEM Caching
Caching Layers
BROWSER: USER CLIENT CACHING. ASSETS ARE CACHED WITH MAX-AGE=
8H. PAGES/DOCUMENTS ARE CACHED WITH ETAG AND MAX-AGE=0.
AKAMAI: CDN. EDGE CACHING. GEO DISTRIBUTED. PROVIDES FLEXIBLE
CACHE ID BY WHICH MULTIPLE VERSIONS OF AN URL/PAGE CACHEABLE.
APACHE: SERVES THE FILES CACHED BY DISPATCHER WITH ETAG.
REWRITES INCOMING REQUESTS SUCH THAT THE URL ENCODES
VERSION OF THE PAGE AND DISPATCHER SEES DIFFERENT URL FOR
DIFFERENT VERSIONS OF A PAGE.
DISPATCHER: AN APACHE MODULE THAT STORES CQ RESPONSES IN A
FILE UNDER APACHE DOCUMENTROOT. THE FILE IS A REPRESENTATION
OF THE URL.
CQ: RUNTIME PAGE ASSEMBLY. DATA OF HIGH COMPUTATIONS ARE
CACHED IN IN-MEMORY CACHE FOR FAST ACCESS. URL IS RESOLVED
INTO CQ NODE WHICH HAS PROPERTIES, TAGS INCLUDING CONCEPTS,
DOCTYPE
Browser
Akamai
Apache/Dispatcher
CQ
ehCache
Sling

END 2 END REQUEST FLOW & CACHING
15
With Caching comes complexity!!!

INCREMENTAL REFRESH DESIGN
With Proactive Caching comes
added complexity!!!
For each Page in
Set P {i}
Process
User Activate
Author
CQ
Publish
CQ
Publish
Dispatc
her
Page(s)
Replic
ation
Node
replication events
ActivationListener
Start
Impact
Analysis
CQ /var
[P-cd]
d=d.getParent()
Is d Series
Doctype or
above?
P-cd
continue
For each Node P-cd
in List L-cd
L-cd=getList of
Nodes tagged to
d+c no
yes
Stop
Note:
P-cd is pages tagged to concept c and
doctype d that are impacted. This is
minimal impacted pages.
The URLs are stored in CQ under /var/
ia_impacted_pages
Refresh Job {P-cd}
interval=15min
For each publish
Node N{x=1..8}
GET N:4503/Pi?
refresh
http://Nx:4503/Pi?refresh
On Complete
On replication
Complete
replication
complete:
All publish nodes
received the
activation
For each Page in
Set P{i}
For each publish
Web server VIP
V{y=1,2}
GET invalidate Pi http://Vy:80/dipatcher
/invalidate.cache?CQ:Handle=Pi
Query-Action Legend
debug - debug info
cachemode=refresh - remove app
cache for page and rebuild page and
populate the cache
cachemode=nocache: build page
without using app cache
Impact
Analysis
c[],d
Remove cached file
Pi.*.html & Pi.html
WEM Cache Refresh Scheme
for Dispatcher and App
WEM
Pi
Architecture
Team
Call /invalidateHandler
Script
GET V:80/Pi.html
Store file Pi.hmtl
Bill Board for
anonymous
users*
is Tag(s)
changed
?
no
Stop
c[],d
For activated Page P-cd, find Tags:
Concepts c[]
Doctype d
Old Concepts oc[]
Old Doctype od
[previous active version]
IA
IA
yes
oc!=null?c=change(oc)
od!=null?d=od
note: change(oc) is concepts
that changed
IA
current page
8 x i
for each concept
in c[]
c[],d
/var c,d
/ia_impacted_pages
p1
p2
p1
p3
CQ /var
[P-cd]
read max 1000
URLs in Set {P}
**
Pi
Logic for U:
set property status=complete
set time=currentTime
move the node under /var/ia_history
**Logic for computing Set {P}:
url=nextNode()
if ({P} has url) {
set property status=dup
set time=currentTime
move the node under /var/ia_history
} else
put url in {P}

17
• CONTENT TRANSFORMATION
• MULTI TENANCY

SUPPORTED DOCUMENT TRANSFORMATIONS
Source Format Target Format
book (all file extensions that are
members of book will be processed) flb pdf, epub, Mobi
fm (including chapters)
html, pdf , (epub, Mobi – only for
non-chapters)
doc, docx html, pdf
eps, epsi, ps, svg, tiff jpg

CONTENT RENDITION INTEGRATION

RENDITION PROCESS FLOW

21
MULTITENANCY

1. No Shared Architecture 2. 100% Sharing of Architecture
SEPARATE Adobe clusters
Virtualized infrastructure
SHARED Adobe Clusters
Virtualized infrastructure
Implementation
Approach
More Licenses (higher license cost)
Better operational insulation
More Scalable
More autonomy/agility among
tenants
Less Licenses (lower license cost)
Less operational insulation
Less Scalable
Less autonomy/agility among
tenants
IT Implication
Stakeholder
Impact
Transparent
Different
approaches
may be used
depending on
stakeholder
needs and
impact to
existing platform
Transparent

AEM
Platform
MULTI TENANCY MODEL
CQ
Instance
VM
Component/Theme Code Component/Theme Code
CQ
Java Code Java Code
Instance
VM
CQ
Instance
VM
CQ
Instance
VM
Tenant2
CQ
Instance
Tenant3
CQ
Instance
platform Framework (monitoring/instrumentation etc)
VM VM
• Why separate CQ
Instance?
• Independent User
Store
• Fault Isolation
• platform Contract
• Logical/Physical
Architecture
• CQ Upgrade
• Product Roadmap
• Platform framework
• Tenant Contract
• Manage Component
deployment
• Manage Java Code
Deployment
Tenant1

24
QUESTIONS?