Amazon Web Service & Adobe Experience Manager:- A Journey together (Part-2)
In the fist part we discussed how one day digital market leader meet with the a friend AWS in the Cloud and become very popular pair. Also what gift they bring for the digital marketing persons.
Now AEM asked to come to my home.
So AEM insides about its parts and structure explored.
AEM Platform :
AUTHOR:-
The content and layout of an AEM experience are created and managed in the author environment. It offers features for authoring content modifications, reviewing them, and publishing the approved versions of the content to the publish environment.
PUBLISH:-
The audience receives the experience from publishing environment. With the option to customize the experience based on demographics or targeted messaging, it renders the actual pages.
Both AUTHOR and PUBLISH instances are Java web applications that have identical installed software. They are differentiated by configuration only.
DISPATCHER:-
Dispatcher environment is the responsible for caching (storing) content and Load balancing.Helps realize a fast & dynamic web authoring environment.
Mainly dispatcher works as part of HTTP server like Apache HTTP. It store as much as possible static content according to specified rules.
So end user feel faster accessing of content and reducing load of PUBLISH. The dispatcher places the cached documents in the document root of the web server.
How AEM Store Content in Repository:-
AEM is storing data without any discrimination as it treated all the family member (data) are content only . Its following philosophy of "everything is content" and stored in the same house(Repository).
Its called CRX i.e. implementation of JCR coming from parent Content Repository API for Java and Apache Jackrabbit Oak.
The basement(base) of the building is driven by MK MicroKernels as in the picture its Tar or MongoDB. The Oak storage layer provides an abstraction layer for the actual storage of the content. MK act as driver or persistence layer here. two way of storing content , TAR MK and MongoDB MK.
TAR--> tar files-->segments
The Tar storage uses tar files. It stores the content as various types of records within larger segments. Journals are used to track the latest state of the repository.
MongoDB-->MongoDB database-->node
MongoDB storage leverages its sharding and clustering feature. The repository tree is stored in one MongoDB database where each node is a separate document.
Tar MicroKernel (TarMK)--for-->Performance
MongoDB--for-->scalability
For Publish instances, its always recommended to go with TarMK.
In more than one Publish instance each running on its own Tar MK then this combination is called TarMK Farm. This is the default deployment for publish environments.
Author instance is having freedom to go with either TAR or MongoDB. it depends on the requirement, if its performance oriented and limited number then it can go with the TarMK but if it require more scalable instances then it would go with the MongoDB. TarMK for a single author instance or MongoDB when horizontal scaling.
Now story of TarMK with Author, a cold standby TarMK instance can be configured in another availability zone to provide backup as fail-over.
TarMK is the default persistence system in AEM for both instances, but it can go with different persistent manger (MongoDB).
Gift of TarMK:-performance-optimized,for typical JCR use cases and is very fast, uses an industry-standard data format, can quickly and easily backed up, high performance and reliable data storage, minimal operational overhead and lower total cost of ownership (TCO).
Now story of MongoDB it basically come into picture when more hands required, means more user/author (more than
1,000 users/day, 100 concurrent users)and high volumes of page edits required. To accommodate these horizontal scalability required and solution is with MongoDB. It leverage MongoDB features like high availability, redundancy and automated fail-overs.
MongoDB MK can give lower performance in some scenario as its establish external connection with MongoDB.
A minimum deployment with MongoDB typically involves a
MongoDB replica consisting of
1)one primary node
2)two secondary nodes,
with each node running in its separate availability zone.
AEM--store--binary data--into ---data store.
AEM--store--content data--into ---node store.
And both stored independently.
Amazon Simple Storage Service (Amazon S3) is best high performant option for shared datastore between publish and author instances to store binary files(Assets like image etc).
Continue....
2 notes
·
View notes