How to design your architecture for AEM6.1

How to design your architecture for UGC in AEM 6.1

I recently worked with a customer who were designing their application for AEM6.0 but at the last minute decided to go with AEM 6.1 just few weeks before the go live. This significantly impacted the way we designed the system infrastructure. It is very necessary to understand the new changes in AEM6.1 Social communities and how it impacts your infrastructure.

The biggest change I would say is the fact that in AEM6.1 the UGC content is no longer replicated or synced. The user generated content on a publisher stays on that publisher and will not be synced across your publish instances. Typically to keep our content in publish instances in sync we rely on the clustering capabilities of our AEM publish instance. In AEM5.6.1 and before, the clustering capability was provided by the CRX. Since AEM6.0, AEM provides clustering only with MongoMK option and uses underlying MongoDB clustering.

AEM6.1 introduces the concept of Social Resource Providers(SRP). With this the UGC content is no longer replicated across your publish instances. The UGC content is stored in a central repository or a common community content storage. All the UGC content is directly created, stored and access from this common storage. Only the content created under /content/usergenerated is persisted in this common storage. The rest of the site content is still persisted on the individual publish servers.


How

How to design your architecture for UGC in AEM 6.1

I recently worked with a customer who were designing their application for AEM6.0 but at the last minute decided to go with AEM 6.1 just few weeks before the go live. This significantly impacted the way we designed the system infrastructure. It is very necessary to understand the new changes in AEM6.1 Social communities and how it impacts your infrastructure.

The biggest change I would say is the fact that in AEM6.1 the UGC content is no longer replicated or synced. The user generated content on a publisher stays on that publisher and will not be synced across your publish instances. Typically to keep our content in publish instances in sync we rely on the clustering capabilities of our AEM publish instance. In AEM5.6.1 and before, the clustering capability was provided by the CRX. Since AEM6.0, AEM provides clustering only with MongoMK option and uses underlying MongoDB clustering.

AEM6.1 introduces the concept of Social Resource Providers(SRP). With this the UGC content is no longer replicated across your publish instances. The UGC content is stored in a central repository or a common community content storage. All the UGC content is directly created, stored and access from this common storage. Only the content created under /content/usergenerated is persisted in this common storage. The rest of the site content is still persisted on the individual publish servers.

You can visualise this with the below image:



config



The common UGC store allows you to keep your architecture simple by having all your Publish servers on TarMK. This way you can keep your publish instances in a TarMK Farm topology. TarMK is always the recommended deployment option for your publish instances in AEM6.1.

UGC Storage Options

AEM 6.1 provides 3 options to configure this UGC storage:

1) Adobe Social (ASRP) - The UGC content is persisted in Adobe Social cloud.

2) MongoDB (MSRP) - The UGC data is persisted in a shared MongoDB server.

3) JCR (JSRP) - default, The UGC data is persisted in a common JCR repository. This is currently only recommended for non-production systems.

By default, the storage option is JSRP but if you do not configure a common store, the UGC data will only be visible in the AEM publish instance where it is created.

How to configure UGC Storage?

You can configure the UGC storage option from Communities > Administration > Storage Configuration.



config



For storing your UGC data in Adobe Social cloud, you need to select the ASRP option. You need to provide the Adobe Social cloud details with the consumer key and Secret.

The MSRP option requires you to have an additional Apache Solr instance for indexing the communities data. For production system, it is recommended that you go with a clustered solr deployment.

Advantages of Common UGC Storage :

The common UGC storage options provides great advantages over replicating and syncing the content across your publish farm. Keeping your publishers in sync was a big challenge previously and any inconsistency in one of your publish is replicated to other instances. With common UGC storage in picture, it is also now much easier and faster to horizontally scale your publish layer, since the UGC data is not copied in your new instance. This also allows you to keep the rest of the content of your site in a TarMK publish server which gives much better performance.

So to keep few things in mind:

1) Always choose TarMK over MongoMK for your publish servers.

2) If your site has UGC, then choose one of the SRP options.

3) it is better to choose Adobe Social Resource Provider(ASRP), it has the following advantages over other SRP options :

          a) it keeps your architecture relatively simple and easy to maintain.
          b) it leverage the Adobe Social cloud infrastructure and offloads the storage and delivery of your social data from your servers. The social data will be directly delivered from Adobe Social cloud using CDN and will save your bandwidth. 
          c) it also provides you with unified dashboard to moderate all your social content at one place. 

4) MSRP, requires an additional Solr instance to index your social content. For production systems both MongoDB and your Apache solr should have failover.


View the discussion thread.blog comments powered byDisqus