There’s been an unbroken wave of interest from all sides since the latest version of the Adobe Experience Manager (AEM) Content Repository was announced (AEM 6.0 has been available for a few days now). So to address some of the main questions — what are the most significant improvements to the platform?
One of the primary goals was to address Web-scale, a scale-out architecture, so that your customer experiences (across all digital devices) can be optimized and maximized. New options for scalability and performance are now available and these can be implemented according to your business requirements, allowing you to plan the long-term success of your digital marketing engagements.
But let’s start from the beginning…
As in previous versions of AEM, the content repository CRX (Content Repository eXtreme) includes (and builds on) the open-source implementation of Apache jackrabbit. Adobe engineering teams are fully involved in the development of this open-source project, under the leadership of David Nuescheler (VP, Enterprise Technology at Adobe Systems) and Dr. Michael Marth (Senior Engineering Manager at Adobe Systems).
So, AEM 6.0 is still fully JCR-compliant (Java Content Repository). Since 2006, the JCR-specification has been the industry-leading standard for content-centric applications.The advantages of this standard in a heterogeneous landscape are many and varied — often being the deciding factor in real-life scenarios. The JCR API guarantees long-term security when planning at the application level (layer); for example, code compatibility when upgrading AEM.
The following 4 goals were pursued with the further development of the AEM content repository:
- Scalability: to cater for large repositories, with many distributed, clustered nodes.
- Write-performance: to allow parallel writes and high write-throughput.
- Content-scalability: to provide support for many child nodes and high ACL complexity.
- Search-performance: to realize focus-oriented content indexing.
Results show that these goals have been achieved; different JCR actions are all performing faster compared to the previous repository version, measured with Jackrabbit 2.
These improvements have been made possible by the introduction of the MicroKernel implementation. In the repository architecture this is responsible for the persistence of content, taking over (and significantly enhancing) the previous concept of the TAR-PersistenceManager. The MicroKernel optimizes the performance via memory-mapped content handling. Current variations of the MicroKernel include TarMK and MongoMK, with others in the pipeline. While the TarMK manages the content persistence of tar files (fast, local), the MongoMK for the MongoDB can be integrated. This concept enables several scaling options, all of which are dependent on your individual use-cases. Let’s look at a couple of the possibilities:
- CPU-Power for processing AEM content: this can be increased as required through the addition of extra AEM instances.
- Read-Throughput: can be increased by the addition of MongoDB Replicas.
- Write-Throughput: repository growth and distributed authoring can be increased by the use of extra MongoDB shards.
According to engineering measurements and tests, the major goal of horizontal linear scalability across different disciplines can be achieved by adding MongoDB shards.
AEM 6.0 has truly earned its title as an engine of innovation and offers significantly better performance. With the (optional) use of MongoDB, further, powerful scaling possibilities is possible. These simplify your planning and protect your investments for the future. So, AEM 6.0 is Webscale-ready…offering the best potential for web experiences that really make the difference for your customers.