Introduzione all’architettura di Adobe Experience Manager as a Cloud Service

Adobe Experience Manager (AEM) as a Cloud Service ha apportato delle modifiche all’architettura.

Ridimensionamento

AEM as a Cloud Service adesso include:

• Architettura dinamica con un numero variabile di immagini AEM

Tale architettura:

• viene ridimensionata in base al traffico e all’attività effettiva;

• presenta istanze singole che vengono eseguite solo quando necessario;

• utilizza applicazioni modulari;

• per impostazione predefinita dispone di un cluster di authoring, per garantire la disponibilità continua anche durante le attività di manutenzione.

Questo approccio consente la scalabilità automatica in base alle esigenze di diversi schemi di utilizzo:

A tal fine, tutte le istanze di AEM as a Cloud Service vengono create uguali, ciascuna con le medesime caratteristiche predefinite in termini di numero di nodi, di memoria e di capacità di elaborazione allocate.

AEM as a Cloud Service si basa sull’utilizzo di un motore di orchestrazione che:

• controlla costantemente lo stato del servizio;

• ridimensiona in modo dinamico ciascuna istanza del servizio in base alle esigenze effettive, potenziandola o riducendola a seconda delle necessità.

Tale comportamento:

• è applicabile al numero di nodi, alla quantità di memoria e alla capacità della CPU allocata su ciascun nodo;

• consente ad AEM as a Cloud Service di adattarsi agli schemi di traffico mano a mano che cambiano.

La scalabilità delle istanze per tenant del servizio si applica ai due assi:

• Orizzontale: il numero di nodi per un determinato servizio viene aumentato o diminuito automaticamente, consentendo comunque configurazioni predefinite individuali.

• Verticale: la memoria e la capacità della CPU allocate possono essere potenziate o ridotte tramite la configurazione di un numero fisso di nodi per soddisfare i singoli requisiti in base alle esigenze.

Ambienti

AEM as a Cloud Service è disponibile come istanza singola, dove ogni istanza rappresenta un ambiente AEM completo.

Con AEM as a Cloud Service sono disponibili tre tipi di ambienti:

• Ambiente di produzione: ospita le applicazioni utilizzate dagli utenti business.

• Ambiente stage: è sempre associato a un unico ambiente di produzione con una relazione 1:1. L’ambiente stage viene utilizzato per vari test di prestazioni e qualità, prima che eventuali modifiche all’applicazione vengano inviate all’ambiente di produzione.

• Ambiente di sviluppo: consente agli sviluppatori di implementare le applicazioni AEM nelle medesime condizioni di esecuzione degli ambienti di stage e produzione.

  Fai riferimento a Gestione degli ambienti per ulteriori dettagli.

• Ambiente di sviluppo rapido: consente di eseguire rapidamente le iterazioni di sviluppo per il debug di un codice nuovo o già esistente.

Programmi

Qualsiasi nuovo progetto AEM è sempre associato a una singola base di codice specifica, in cui puoi memorizzare sia la configurazione che il codice personalizzato per il progetto. Queste informazioni sono memorizzate in un archivio di codice, accessibile tramite i consueti client Git, messi a disposizione al momento della creazione di nuovi programmi.

Un programma AEM è il contenitore che include:

Per AEM as a Cloud Service, inizialmente sono disponibili due tipi di programmi:

• AEM Cloud Sites Service

• AEM Cloud Assets Service

Entrambi consentono l’accesso a una serie di funzioni e funzionalità. Il livello di authoring contiene tutte le funzionalità di Sites e Risorse per tutti i programmi, ma i programmi delle risorse non avranno per impostazione predefinita un livello di pubblicazione né di anteprima.

Architettura runtime

Questa nuova architettura presenta diversi componenti principali:

• Per AEM Sites as a Cloud Service:

  • Per ogni ambiente ad alto livello permane il concetto di livello di authoring e livello di pubblicazione.

  • Il livello di authoring è composto da due o più nodi all’interno di un singolo cluster di authoring e viene ridimensionato automaticamente in base all’attività di authoring.

    • Gli autori o i creatori dei contenuti accedono al livello di authoring di AEM per creare, modificare e gestire i contenuti.

    • L’accesso al livello di authoring è gestito da Adobe Identity Management Services (IMS).

    • L’integrazione e l’elaborazione di Assets utilizza un servizio dedicato di elaborazione Assets.

  • Il livello di anteprima è composto da un singolo nodo di anteprima. Utilizzato per il controllo qualità dei contenuti prima della pubblicazione sul livello di pubblicazione.

  • Il livello di pubblicazione è composto da due o più nodi all’interno di una singola farm di pubblicazione, che possono operare indipendentemente l’uno dall’altro. Ogni nodo è costituito da un editore AEM e da un server web dotato del modulo AEM Dispatcher. Il nodo viene ridimensionato automaticamente in base alle esigenze di traffico del sito.

    • Gli utenti finali o i visitatori del sito visitano il sito web tramite AEM Publish Service.

• Per AEM Assets as a Cloud Service:

  • L’architettura include solo un ambiente di authoring.

• Sia il livello di authoring, livello di anteprima, che quello di pubblicazione leggono e rendono persistente i contenuti da/a un servizio di archiviazione dei contenuti.

  • Il livello di pubblicazione e il livello di anteprima leggono i contenuti solo dal livello di persistenza.

  • Il livello di authoring legge e scrive i contenuti da e verso il livello di persistenza.

  • L’archiviazione BLOB è condivisa tra il livello di pubblicazione, anteprima e authoring. I file non vengono moved.

  • Quando il contenuto viene approvato dal livello di authoring, ciò indica che può essere attivato e quindi inviato al livello di persistenza del livello di pubblicazione (oppure al livello di anteprima). Ciò avviene tramite il servizio di replica, una pipeline middleware. Questa pipeline riceve il nuovo contenuto: i singoli nodi del servizio di pubblicazione (o servizio di anteprima) si abbonano al contenuto inviato alla pipeline.

    NOTA

    Per ulteriori dettagli, consulta Replica.

  • Sviluppatori e amministratori gestiscono l’applicazione AEM as a Cloud Service mediante Continuous Integration/Continuous Delivery (CI/CD), tramite Cloud Manager. Il servizio include distribuzioni di codice e configurazione tramite la pipeline CI/CD di Cloud Manager. I clienti di Cloud Manager visualizzano tutto ciò che riguarda il monitoraggio, la manutenzione e la risoluzione dei problemi, ad esempio, i file di registro.

  • L’accesso ai livelli di authoring e pubblicazione avviene sempre tramite un load balancer, che è sempre aggiornato con i nodi attivi in ciascuno dei livelli.

  • Per il livello di pubblicazione e di anteprima, come primo punto di ingresso è disponibile anche un servizio CDN (Continuous Delivery Network).

• Per le istanze dimostrative di AEM as a Cloud Service, l’architettura viene semplificata a un singolo nodo di authoring. Pertanto non presenta tutte le caratteristiche dell’ambiente di sviluppo, stage o produzione standard. In altre parole, possono anche verificarsi tempi di inattività e non è incluso il supporto di operazioni di backup e ripristino.

Architettura di distribuzione

Cloud Manager gestisce tutti gli aggiornamenti alle istanze di AEM as a Cloud Service. È una scelta obbligatoria, essendo l’unica soluzione per creare, testare e distribuire l’applicazione del cliente, sia per il livello di authoring che per quello di pubblicazione. Questi aggiornamenti possono essere attivati da Adobe quando è pronta una nuova versione di AEM Cloud Service oppure dal cliente stesso, quando è pronta una nuova versione della sua applicazione.

Tecnicamente, l’implementazione avviene grazie al concetto di pipeline di distribuzione, associata a ogni ambiente presente all’interno di un programma. Quando una pipeline di Cloud Manager è in esecuzione, crea una nuova versione dell’applicazione del cliente per il livello di authoring, anteprima e pubblicazione. Tale risultato si ottiene combinando gli ultimi pacchetti cliente con la più recente immagine linea di base di Adobe. Quando le nuove immagini vengono create e testate correttamente, Cloud Manager automatizza completamente il cutover alla versione più recente dell’immagine tramite l’aggiornamento di tutti i nodi del servizio, secondo uno schema di aggiornamento in sequenza. Ciò non comporta tempi di inattività né per il servizio di authoring né per quello di pubblicazione.

Distribuzione dei contenuti

Con Adobe Experience Manager as a Cloud Service cambia il funzionamento della pubblicazione dei contenuti. Con AEM as a Cloud Service, il framework di replica delle versioni precedenti di AEM non viene più utilizzato per pubblicare le pagine (le modifiche vengono spostate dall’istanza di authoring a quelle di pubblicazione).

AEM as a Cloud Service adesso utilizza la funzionalità di distribuzione dei contenuti Sling per spostare il contenuto appropriato. Tale funzionalità si basa su un servizio pipeline eseguito su Adobe I/O, che si trova al di fuori del runtime AEM.

La configurazione è automatizzata, con autoconfigurazione automatica quando i nodi di pubblicazione vengono aggiunti, rimossi o riciclati durante il runtime.

Una singola richiesta di pubblicazione o di annullamento della pubblicazione può includere più risorse, ma restituirà un unico stato applicato a tutte, e avrà esito positivo o negativo per tutte le risorse di AEM Publish Service. In questo modo le risorse di AEM Publish Service non presenteranno mai uno stato incoerente.

Diagramma dell’architettura di distribuzione dei contenuti di alto livello

Evoluzioni fondamentali

La nuova architettura di AEM as a Cloud Service introduce alcune modifiche e innovazioni fondamentali rispetto alle generazioni precedenti:

• Tutti i file (BLOB) vengono caricati e serviti direttamente da un archivio dati cloud. Il flusso di bit associato non passa mai attraverso la JVM dei servizi AEM Author e Publish. Di conseguenza, i nodi dei servizi di authoring e pubblicazione di AEM possono avere dimensioni più ridotte e risultare maggiormente compatibili con l’aspettativa di una rapida scalabilità automatica. Per i professionisti del settore, questo consente un’esperienza più rapida durante il caricamento e il download di immagini, video ecc.

• Tutte le operazioni che consistono nella pubblicazione di contenuto adesso includono una pipeline che segue uno schema di sottoscrizione. Il contenuto pubblicato viene inviato a varie code della pipeline, alle quali sono abbonati tutti i nodi del servizio di pubblicazione. Di conseguenza, il livello di authoring non deve essere a conoscenza del numero di nodi presenti nel servizio di pubblicazione, il che consente un rapido ridimensionamento automatico del livello di pubblicazione.

• Il concetto di Golden Master è stato introdotto per automatizzare il ciclo di vita dei nodi di pubblicazione. Il Golden Master è un nodo di pubblicazione specializzato, a cui nessun utente finale accede e da cui vengono creati tutti i nodi del servizio di pubblicazione. Le operazioni di manutenzione, come la compattazione, vengono eseguite nell’archivio dei contenuti collegato al Golden Master. I nodi di pubblicazione vengono riciclati ogni giorno e non richiedono alcun tipo di manutenzione ordinaria. In passato, tale manutenzione comportava tempi di inattività, in particolare per l’istanza di authoring.

• L’architettura separa completamente il contenuto dell’applicazione dal codice e dalla configurazione dell’applicazione. Tutto il codice e la configurazione diventano praticamente immutabili e vengono inseriti nell’immagine linea di base utilizzata per creare i vari nodi dei servizi di authoring e pubblicazione. Di conseguenza, esiste una garanzia assoluta che ogni nodo sia identico e che le modifiche al codice e alla configurazione possano essere apportate solo a livello globale, eseguendo una pipeline di Cloud Manager.

Risorse Business.Adobe.com