There are three options when it comes to installing and maintaining an AEM instance
If you choose to implement your own system on-premises, here are a few things to keep in mind to ensure you have a secure, performant system. In addition to the “care and feeding” items, this paper will also point out several items AEM Developers ought to keep in mind to assist in keeping the system running well.
Backups - ensure you have complete and/or partial backups on a frequent schedule:
Many customers do snapshot backups, which only take a few minutes assuming the underlying operating system supports such backups. Make sure these backups are stored properly (off the AEM system). Ensure the backups are functional and can be used to recreate a working system periodically - there’s nothing worse than having the system crash and your backups are corrupt for some reason!
There are several items you need to monitor to ensure trouble-free operation:
Indexes allow queries to run as quickly as they can, freeing up resources for other operations. Ensure your indexes are in tip-top shape! AEM cancels queries that travere instead of using an index to keep one bad query from affecting overall AEM performance.
Each update to the repository creates a new content revision. As a result, with each update the size of the repository grows. To avoid uncontrolled repository growth, old revisions need to be cleaned up to free disk resources.
Purge lucene binaries and reduce the running data store size requirement.
When an asset in AEM is deleted, the reference to the underlying data store record may be removed from the node hierarchy, but the data store record itself remains. This unreferenced data store record becomes “garbage” that need not be retained. In instances where a number of unreferenced assets exist, it is beneficial to get rid of them to, preserve space, optimize backup, and filesystem maintenance performance.
Minimizing the number of workflow instances increases the performance of the workflow engine, so you can regularly purge completed or running workflow instances from the repository.
AEM events that qualify for audit logging generate a lot of archived data. This data can quickly grow over time due to replications, asset uploads and other system activities.
Ensure the Security Checklist best practices are followed closely to ensure the most secure instance of AEM.
Monitor diskspace to ensure you have enough for the JCR Repository, plus about half again as much space - the tar compaction uses extra space when it runs. Running out of diskspace is the number one reason for JCR corruption!
Try not to use custom components - use core components. Your goal should be to use core components 80-90% of the time and custom components only sparingly. This often requires a new way of looking at the components on a page - you must realize the components can be restyled easily by a front-end developer using CSS. Also keep in mind that those core components can be embedded in each other to achieve quite complex results. Get creative!
Style systems allow the core components, and even custom components, to have their look and feel change at the Authors discretion to create completely new looking components. These stylistic changes generally only involve a front-end designer and a knowledgeable author (often referred to a ‘Super Author’)
Launches allow for work to be completed for a new Promotion, Sale, or website rollout without impacting the currently deployed pages. In addition, they can be scheduled to go live automatically, without attendance or supervision, allowing Authors to do next week’s (or next quarter’s) work today and not rush into page development the day before it should go live - it’s truly the gift of TIME!)
Content fragments are customizable “chunks” of information that can be easily reused all over the site. If you need a change you just change the original chunk and the update is seen everywhere it’s used - immediately!
While sounding almost identical to Content Fragments, Experience Fragments are small, visible, pieces of a page. These can also be reused widely across your site and maintained in a central location within AEM to ease the task of making potentially global changes across your site in seconds, not days or weeks.
Think ahead and see what might be reused. A footer? A disclaimer? A Header? Certain types of content? All these can be shared across an entire site while keeping maintenance at a minimum. Need to update a date in a disclaimer, but it’s on 1,000 pages on your site? It’s a 5 second operation if you used an Experience Fragment!
Stay abreast of changes AEM through continued learning - don’t get stuck in the past. Use Experience League and Adobe Digital Learning Services (ADLS) to hone your skills.
AEM can be a large system, and it takes many types of people to make it “sing”. From Admins to Developers (both front-end and hardcore Java developers) to Authors - there’s something for everyone! And if you don’t feel like handling the day to day Administration, there’s always AMS and AEM as a Cloud Service.