Downloaded 65 times
Uploaded byEvolve The Adobe Digital Marketing Community
EVOLVE'16 | Enhance | Anil Kalbag & Anshul Chhabra | Comparative Architecture Analysis of Large Scale AEM Installations
The document presents a comparative architecture analysis of large-scale Adobe Experience Manager (AEM) installations by Anshul Chhabra and Anil Kalbag, focusing on case studies from Symantec and Cisco. It discusses their architecture decisions, multi-tenancy strategies, migration techniques, and globalization approaches, emphasizing the importance of optimizing performance and scalability. Key takeaways include recommendations for leveraging AEM capabilities while avoiding common anti-patterns and challenges in cloud integration.
More Related Content
Similar to EVOLVE'16 | Enhance | Anil Kalbag & Anshul Chhabra | Comparative Architecture Analysis of Large Scale AEM Installations
More from Evolve The Adobe Digital Marketing Community
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
EVOLVE'16 | Enhance | Anil Kalbag & Anshul Chhabra | Comparative Architecture Analysis of Large Scale AEM Installations
- 1. #evolverocks COMPARATIVE ARCHITECTURE ANALYSIS OFLARGE SCALE AEM INSTALLATIONS ANIL KALBAG DISTINGUISHED ENGINEER, IT @ CISCO ANSHUL CHHABRA DISTINGUISHED IT ARCHITECT @ SYMANTEC 8-30-2016
- 2. #evolverocks SPEAKERS INTRODUCTION Anshul Chhabra DistinguishedIT Architect Symantec Previously Principal Architect @ McAfee IT Architect @ Cisco twitter.com/anshul2 linkedin.com/in/anshulchhabra Anshul_Chhabra@Symantec.com Anil Kalbag Distinguished Engineer, IT Cisco.com linkedin.com/in/anil-kalbag anil.kalbag@cisco.com twitter.com/akalbag
- 3. #evolverocks 3 TALK OUTLINE •Introduction – 5 mins • Case Study 1 – 10 mins • Case Study 2 – 10 mins • Analysis/Comparison – 15 mins • Q&A – 5 mins
- 4. #evolverocks 4 CASE STUDYOUTLINE • Basic Usage Data • Architecture Overview (specific decisions) • Multi-Tenancy & Migration Strategy • Cloud Strategy • Globalization Strategy – approach • Other Customizations • Integrations
- 5. #evolverocks CASE STUDY NO1 ANSHUL CHHABRA DISTINGUISHED IT ARCHITECT @ SYMANTEC 8-30-2016
- 6. #evolverocks 6 SYMANTEC.COM BY THE NUMBERS Traffic Size Velocity Global •3.3 billion requests/month • 150 million Page Views/month • 40k No of Pages • 150G:Size of Repository • 200/30: No of Authors (total/concurrent) • 20 Countries • 12 Languages
- 7. #evolverocks 7 LOGICAL (DECISIONSFRAMEWORK) ARCHITECTURE DataCenter 1 AEM Author PairDispatcher WebServer InternalZone Dispatcher WebServer Cluster AEM Publish Cluster Data Center 2 Dispatcher WebServer Cluster AEM Publish Cluster CDN(Akamai) AEM Licenses Base Decisions Physical/Virtual/Cloud OS(Linux/Windows) Storage (SAN/NAS) Architecture Questions Dispatcher @ Author LB @ publish HA: DR, Multi-DC Caching Logical Preview Lifecycle TarMK, MongoMK
- 8. #evolverocks 8 Decision PointOptions Virtual/Physical All Virtuals | All Physicals | Hybrid |Cloud OS Linux| Windows Storage Attached | SAN | NAS Dispatcher@Author Yes | No LB @ Publish Yes (n:n) | No (1:1) HA: DR, Multi-DC Single DC/Multi DC, DR:Yes| No, CDN : Yes |No Caching CDN, Custom Dispatcher Cache, Custom App cache Preview Lifecycle Yes | No Author Scalability TarMK| MongoMK | Customized Solution DECISION TABLE DEEP DIVEBaseArchitecturalLogical
- 9. #evolverocks 9 MULTI TENANCYCURRENT STATE WebProperty AEMInstance DAM- Instance Pub Atln SDL Sym-Instance Pub1 Web Pub2 intrnt Cust-Instance Pub UW VYGR NS- Insta nce N-Pub NDC P-Instance N-Pub N-P WSP- Pub WS Dev- Pub Dev WS-Instance WS- Pub3 WS-1 WS- Pub2 WS-2 WS- Pub-3 WS-3 AEM Instance AEM Publish Instances Web Properties/Applications
- 10. #evolverocks 10 MULTI TENANCYCURRENT STATE WebProperty AEMInstance DAM- Instance Pub Atln SDL Sym-Instance Pub1 Web Pub2 intrnt Cust-Instance Pub UW VYGR NS- Insta nce N-Pub NDC P-Instance N-Pub N-P WSP- Pub WS Dev- Pub Dev WS-Instance WS- Pub3 WS-1 WS- Pub2 WS-2 WS- Pub-3 WS-3 Instance Instance Instance Instance Instance Instance
- 11. #evolverocks 11 TARGET STATE: INSTANCE GOVERNANCE Akamai–Caching/Acceleration Authors AEM Author Pair AEM Publish Farm – Data center 1 AEM Publish Farm – Data center 2 Visitors Request Flow Akamai–Caching/Acceleration Authors AEM Author Pair AEM Publish Farm – Data center 1 AEM Publish Farm – Data center 2 Visitors Request Flow Akamai–Caching/Acceleration Authors AEM Author Pair AEM Publish Farm – Data center 1 AEM Publish Farm – Data center 2 Visitors Request Flow • Finite number of Instances – with Governance • New instance should be created only when: – Independent branding and experience – Independent Dev teams and stakeholders – with totally different integrations – Totally different operational SLAs required – Example Symantec/Norton
- 12. #evolverocks 12 MIGRATION STRATEGY •Technologies before AEM: Teamsite, Drupal • AEM adopted three years ago • Major web presence on AEM – Long tail of migrations continue to this day • Two options for migrations – Assisted Migrations (scripted, automated) – User driven (new platform for new content + retire older content)
- 13. #evolverocks 13 GLOBALIZATION • 2Level Structure • EN is master • Language (eg French) – followed by Locale • Content Translation with SDL World Server • Custom Integration Live Copy English Master en-au en-sg en-uk en-in en-ca Portugese Master pt-pt pt-br Spanish Master es-es es-br French Master fr-fr fr-ca Chinese Master ch-cn ch-tw ch-hk 2 3 1 en-us Custom Impl
- 14. #evolverocks 14 Decision Options CountrySite Content All pages | Selective Pages Domain Single Domain | Country Specific Domains Content Structure Englishlanguagelocale) | EnglishLocale) |Custom Propagation Mechanism Multi Site Manager |Language Copy | other Integration Mechanism 3rd Party (ClayTablet)| Connector | Custom Translation Manual| Automated | Hybrid(MTPE) Source Blueprint | Existing branch or Page Rollout Configuration Manual | Auto GLOBALIZATION • Decisions Deep Dive
- 15. #evolverocks CASE STUDY NO2 ANIL KALBAG DISTINGUISHED ENGINEER, IT @ CISCO 8-30-2016
- 16. #evolverocks 16 CISCO.COM – FRONTDOOR TO CISCO’S BUSINESS 375 Million MONTHLY PAGE VIEWS 17M ANNUAL SEARCHES 1+ Million DIGITAL ASSETS 15 Million MONTHLY VISITORS 99.99% UPTIME 70 LOCALES 650K+ PAGES Marketing Sales Support Employees Every visit is an opportunity to market, sell, and support our customers and engage employees.
- 17. #evolverocks DC2 DRDC1 DMZInternalNetProtectedNet 8 coreX 32G AEM 6.0 4TB NAS for datastore/host 1TB SAN for segmentstore 8 core X 32G AEM 6.0 4TB NAS for datastore/host 1TB SAN for segmentstore 8 core X 32G AEM 6.0 4TB NAS for datastore 1TB SAN for segmentstore 8 core X 32G AEM 6.0 4TB SAN for datastore 1TB SAN for segmentstore 6 core X 32G Apache 2.2 4TB NAS for shared htdocs 6 core X 32G Apache 2.2 4TB NAS for shared htdocs 6 core X 32G Apache 2.2 4TB NAS for shared htdocs lb3lb2lb1 dc1.cisco.com dc2.cisco.com dr.cisco.com lb1 lb2 lb3 17 DEPLOYMENT ARCHITECTURE Cisco.com Deployment author.cisco.com Internal GSS/DNS RCDN lb 2 core X 16G Apache 2.2 2TB NAS for shared htdocs content replication to all DC www.cisco.com External GSS/DNS Three Availability Zones; Two Regions Active-Active with DR Load Balancers at Web & App Tiers Identical Publish Instances CDN Multiple Levels of Caching Sharding of Author Instances
- 18. #evolverocks 1818 Decision PointOptions Virtual/Physical All Virtuals | All Physicals | ✓Hybrid |Cloud OS ✓Linux | Windows Storage Attached |✓SAN|✓ NAS Dispatcher@Author ✓Yes | No LB @ Publish ✓Yes (n:n) | No (1:1) HA: DR, Multi-DC Single DC/✓Multi DC, DR:✓Yes|No, CDN : ✓Yes|No Caching ✓CDN, ✓Custom Dispatcher Cache, ✓Custom App cache Preview Lifecycle Yes | ✓No MicoKernel ✓TarMK | MongoMK | Custom Backup/Synch BaseArchitecturalLogical ARCHITECTURE DECISIONS DEEP DIVE
- 19. #evolverocks 19 MIGRATION –LEGACY TO AEM Business participation is critical Deciding what to migrate and when • SEO metric Lift-n-shift vs. Transformation Combination of automated and manual activities Optimization Preprocessing Creation Verification Activation 2.7 millions assets 281 site areas 1 framework
- 20. #evolverocks 20 MULTI-TENANCY Realms andMicrosites – Set of technologies, business process, conventions and best practices that enable and streamline multi- tenancy on a single digital platform Criteria • One or more page meant to function as separate entity within cisco.com • Targeting a specific audience • Not part of Cisco.com top level navigation • Separate permissions for authoring • Library of templates and components to choose from Digital Check-In Process Benefits Performance, CMS, Video, Security, etc. Global Ready Search Optimized Mobile 5-star Experience Cost Effective Integrated Metrics
- 21. #evolverocks 21 GLOBALIZATION • CountrySite Strategy • Created using AEM Multi Site Manager • Content Translation • Assets for global sites Live Copy INTL English Master en-au en-sg en-uk en-in en-ca en-nz ja-jp th-th vi-vn en-us Portugese Master pt-pt pt-br Spanish Master es-ar es-co es-cr French Master fr-fr fr-ca fr-ch Chinese Master ch-cn ch-tw ch-hk 1 2 3
- 22. #evolverocks 22 GLOBALIZATION DECISIONS DEEPDIVE Decision Options Country Site Content All pages | ✓ Selective Pages Domain ✓ Single Domain | Country Specific Domains Content Structure ✓ Englishlanguagelocale) | EnglishLocale) |Custom Propagation Mechanism ✓ Multi Site Manager |Language Copy | other Integration Mechanism 3rd Party | Connector | ✓ Custom Translation ✓Manual| ✓Automated | ✓Hybrid(MTPE) Source ✓Blueprint | Existing branch or Page Rollout Configuration ✓ Manual | ✓Auto
- 23. #evolverocks 23 DYNAMIC PAGES Listingpages dynamically generated Query based on Concept & Doctype Reduces workload for Authors Changes in product hierarchy immediately reflected on website Impacts Sharding of Author Instances
- 24. #evolverocks 24 AEM INTHE CLOUD Web Servers and AEM Publish instances running in private Cloud AEM on Application Centric Infrastructure (ACI) enabled private cloud • Reduce TCO • Automate IT tasks • Accelerate deployments
- 25. #evolverocks COMPARATIVE ANALYSIS ANSHUL CHHABRA& ANIL KALBAG 8-30-2016
- 26. #evolverocks 26 Decision PointOptions Virtual/Physical All Virtuals| All Physicals | ✓Hybrid|Cloud OS ✓Linux | Windows Storage Attached |SAN| NAS Dispatcher@Author ✓Yes | No LB @ Publish ✓Yes (n:n) | No (1:1) HA: DR, Multi-DC Single DC/ ✓Multi DC, DR: ✓Yes|No, CDN : ✓Yes|No Caching ✓CDN, ✓Custom Dispatcher Cache, ✓Custom App cache Preview Lifecycle Yes | ✓No MicoKernel ✓TarMK | MongoMK | Custom Backup/Synch ARCHITECTURE DECISION TABLE DEEP DIVE BaseArchitecturalLogical Scalability: Physicals with attached storage frequently preferred for Author Linux – more prevalent choice. Author: Attached/SAN Publish: SAN/NASPerformance & Author concurrency.Maximize Resiliency Vs Increase cache clearing complexity Most companies use all three Dynamic Pages, cacheability.External preview capabilityAuthor Scalability.
- 27. #evolverocks 27 WHY MULTI TENANCY Leverage Architecture •Caching •HighAvailability •Best Practices for maintenance/monitoring •Product Upgrades/Patches Leverage Expertise •Cross utilization of AEM expertise across projects •Reduce intra-company competition for resources in marketplace •Retain good resources by giving them varied challenges Leverage Adobe •Coordinated engagement •Influence Product Roadmap •Maximise ROI •Get our patches prioritized Adobe is a leader in Web Content Mgmt Space
- 28. #evolverocks 28 MULTI TENANCYCOMPARISON Akamai–Caching/Acceleration Authors AEM Author Pair AEM Publish Farm – Data center 1 AEM Publish Farm – Data center 2 Visitors Request Flow Akamai–Caching/Acceleration Authors AEM Author Pair AEM Publish Farm – Data center 1 AEM Publish Farm – Data center 2 Visitors Request Flow Akamai–Caching/Acceleration Authors AEM Author Pair AEM Publish Farm – Data center 1 AEM Publish Farm – Data center 2 Visitors Request Flow Akamai–Caching/Acceleration Authors AEM Author Pair AEM Publish Farm – Data center 1 AEM Publish Farm – Data center 2 Visitors Request Flow Separate instance For every team One Uber instance Shared by all Maximize Re-use Maximize Tactical Agility & Isolation
- 29. AEM as aService •Templates and Components reused •All integrations are taken care of SaaS •AEM Container upgrades/maintenance/patches are provided •Framework/Architecture elements reused PaaS •Only Infrastructure (not AEM specific) IaaS Copyright © 2014 Symantec Corporation 29 Recommended
- 30. #evolverocks 30 AEM ARCHITECTUREANTI PATTERNS • Over Customization • Everything is a nail – when AEM is the hammer • AEM as a Façade • AEM as THE Application Engine • Taking every “sold” feature on its face value • AEM – Target integration • Continuing to use AEM classic UI over touch • Not planning for continued investment in AEM (and other Adobe) Products & resources • Includes investment in a tight well organized team • Investment of time in building a good relationship in Adobe & community
- 31. #evolverocks 31 AEM INTHE CLOUD • Most installations so far are on prem – or not completely cloud native. • Future – looks different – more and more push to Cloud. • Multiple options going forward • AEM Managed Services (AWS MarketPlace) • Azure Virtual Machine (BYOL) – on windows • Rackspace – complete with full suggested deployment architectures • Need Adobe Product to evolve more also: • More Cloud Native offerings • Support for MicroServices & Continuous Integration& Delivery • Better Support for Multi Tenancy in same instance
- 32. #evolverocks 32 WISHLIST FROMADOBE • Improved Integrations – eg: Target, Segments (Audience Mgr), eCommerce • Better Support and penetration in Cloud • More Cloud Native offerings • Support for MicroServices & Continuous Integration& Delivery • Better Support for Multi Tenancy in same instance • More robust and scalable repository • Improved support for Active Passive Mode, Backups, Maintenance activities • Improved content transfer capability from Prod to Non-Prod
- 33.
Editor's Notes
- #8 AEM Licenses Author – content size and no of authors- might prompt multiple authors in active active configuration (or sharded) Complex requirements HA needs Enterprise commit
- #27 Virtual/Physicals : Many installations with virtuals exist – and are successful. But in large scale installations – due to scalability issues – and lack of the Mongo option in prior years – people frequently go to physical author. Many examples exist of this paradigm (Cisco – and other companies of cisco’s size) Linux/Windows : On the surface there does not seem to be any data to support superiority of Linux over Windows – however – anecdotally – there seem to be more examples of Linux based installations. Storage – For Author NAS is probably not a great idea. SAN can usually do the trick on author – but there might be a case to consider attached storage for best performance. For Publish – SAN would be a safer bet, but NAS can also do the job . Dispatcher@Author – Our recommendation is to have it – even if it only alleviates some of the asset caching. There are some caching settings to keep in mind – to ensure the content is fresh. Usually only very small scale installations tend to skip dispatcher at the author. LB @ Publish : Provides maximized fault tolerance. Cisco has this model. However it increases the complexity of the architecture. Especially the clearing of dispatcher cache on activation in publish HA: DR, Multi-DC: For most large scale installations – multi DC is a must, Author can be a bit challenging here – in case of TarMK – DR is also recommended. But there might be some innovative approaches that could be used to optimize the cost of DR. Either by having a small footprint – that can be quickly increased (scaled up if required), or just focusing on author – and having some extended caching settings at DR (servecacheonstale equivalent). Also – it is a good idea to have backups of author, a single publish and the dispatcher – foeasy restore in case all else fails. Caching : Multiple levels of caching – CDN, web server & application server. Tradeoff between performance and simplicity. Application cache is required only if there is a lot of application logic – and dynamic component or other logic. Web server is required if there is a huge amount of traffic that still makes it through to the publish server and there is not enough offload.. HAL DR , Multi DC: Generally all large scale companies need both a DR and multi DC strategy (in addition to a solid back up strategy) CDNs can provide some level of protection
- #30 - Think clearly about how to present this – ITaaS angle may need to be cleared up..
- #31 Over Customization complicates everything - Maintainability – system bloat - Upgrade path -
- #32 Check with Sameer – whether I can share Azure… Make it real -