15 anni di Adobe Experience Manager - Una storia

Ad oggi, sono passati 15 anni da quando Adobe ha finalizzato l'acquisto di Day Software, acquisendo così il prodotto che tutti voi conoscete ora come "AEM".

Per tutti coloro che (come me) lavorano con questa piattaforma da anni, speriamo che questo post sia un divertente (o doloroso) viaggio nella memoria per voi mentre rivisitiamo il motivo per cui Adobe avrebbe acquistato Day e cosa è cambiato (e non è cambiato!) nei 15 anni da qui a qui.

Comunicato del giorno - prima dell'acquisizione di Adobe

Day Software era un'azienda con sede a Basilea, in Svizzera, che ha creato il suo rivoluzionario CMS Communique su una piattaforma personalizzata basata su filesystem, ma che in seguito si è trasformata nel sistema supportato da Java Content Repository che conosciamo oggi.

La prima versione di CQ era una raccolta di script CGI per Netscape Enterprise Server (alzi la mano chi l'ha mai usato!) all'inizio del 2000, ed è stata riscritta come applicazione Java per CQ2 e poi il server HTTP si è separato da essa per CQ3 (la genesi di CQSE).

Fino a CQ4, il contenuto era ancora memorizzato in file sul file system locale, ma nel 2005, con il rilascio di CQ 4.0, è stato passato dal vecchio archivio del file system "Content Bus" al repository "Content Repository eXtreme" (o CRX) versione 1.0, un'evoluzione del quale alimenta ancora AEM oggi, 20 anni interi dopo.

CQ5 è stato un aggiornamento massiccio e la base dell'AEM di oggi

CQ5 ha rappresentato una riscrittura quasi completa del prodotto.

Ci sono una serie di caratteristiche e approcci che potrebbero sembrare comuni oggi che erano parti enormi e rivoluzionarie della piattaforma CQ5. Un affascinante articolo di CMSwire del 2008 osservava: "Mentre alcuni fornitori di CMS evitano il Web 2.0, pensando che l'implosione del Web 2.0 sia imminente; Day si concentra su di esso alla grande". Quante persone di quei tempi potevano definire il web 2.0? Ma le enormi nuove funzionalità rilasciate con CQ5 l'hanno essenzialmente resa una piattaforma completamente nuova e la maggior parte di noi non potrebbe nemmeno immaginare un CQ/AEM senza di essa, come ad esempio:

• L'interfaccia utente Sidekick & Author: l'authoring GUI e WYSIWG di CQ erano un enorme punto di forza all'epoca, e il fatto che si potesse lavorare con i componenti in un ambiente ricco di grafica era un enorme passo avanti rispetto ad altre offerte CMS dell'epoca.

  

• Flussi di lavoro: il motore del flusso di lavoro è stato aggiunto con questa versione che stava anche lasciando a bocca aperta le persone, in quanto era possibile visualizzare un flusso di lavoro DIRETTAMENTE NEL CMS e sviluppare la logica di business direttamente nel sistema di gestione dei contenuti. Posso immaginare che questa funzione da sola abbia convinto molti clienti aziendali a passare al sistema

  

• CQ Tags: Riesci a immaginare di lavorare in CQ senza tag? L'aggiunta del supporto per i tag ha finalmente portato la tassonomia completa su CQ.

• Il DAM: CQ5 ha ottenuto un gestore di asset digitali con questa versione, situato nel percorso /content/dam che tutti conosciamo così tanto ora. Anche in questa prima era, ha portato il ritaglio e la rotazione delle immagini basate su browser (non Flash!).

  

• Clustering: questo è qualcosa che è durato solo fino alla versione CQ5 e non è arrivato ad AEM6, nel bene e nel male. CQ5 aveva un clustering abbastanza avanzato che consentiva una configurazione di clustering attivo-attivo o attivo-passivo sia per l'autore che per gli editori. Ho visto proprio un cliente utilizzare il clustering di Publisher, è stata un'idea terribile e non ho idea del perché l'abbiano fatto. Il clustering degli autori ERA, tuttavia, una buona "idea" che permetteva di creare teoricamente su un master del cluster e di far propagare tali modifiche su un slave del cluster (terminologia che è stata ritirata). Il clustering, tuttavia, è sempre stato un enorme problema di affidabilità.

• Ambiente di sviluppo CRX: all'epoca, Day ha rilasciato un ambiente di sviluppo basato su Eclipse in cui lavorare per avere una visione spessa sul lato client nel Java Content Repository. Hanno anche rilasciato un'interfaccia leggera basata su browser che potrebbe essere utilizzata al posto di Eclipse chiamata "CRX Development Environment Lite" o crxde, che sopravvive ancora oggi in quasi la stessa identica forma.

Non è una novità per questa versione, ma vale la pena menzionare - i livelli di authoring e pubblicazione separati di CQ hanno fatto in modo che i vincoli di prestazioni o l'instabilità sul lato dell'authoring non bloccassero il tuo sito pubblico, e viceversa. Avere CQ alla base di OSGI e Sling significava un motore di contenuti estremamente flessibile, in grado sia di ricche risposte dinamiche che di rendering delle pagine, nonché la capacità di collegare il lavoro pesante in Java per tutti i tipi di applicazioni che in precedenza avrebbero dovuto essere eseguite nel proprio stack di server delle applicazioni.

Una cronologia dei rilasci e delle modifiche di CQ

Fino all'acquisizione di Adobe, la cronologia delle versioni di CQ era la seguente:

• Giorno CQ 3.5 (2002)

• Giorno CQ 4.0 (2005)

• Giorno CQ 4.1 (2006)

• Giorno CQ 4.2 (2008)

• Day CQ 5.0 (2008) - rilasciato solo ai clienti interni come anteprima

• Day CQ 5.1 (2008) - prima versione di disponibilità generale di CQ5. Prima aggiunta di Flussi di lavoro, DAM, Tag, CRXDE, Clustering e Sidekick

• Giorno CQ 5.2 (2009):

  • Gestione delle risorse digitali (DAM) migliorata con una migliore gestione dei metadati
  • Miglioramenti del motore del flusso di lavoro per l'elaborazione dei contenuti
  • Migliore integrazione con Adobe Analytics
  • È qui che Multi-Site Manager (MSM) è stato rilasciato per la prima volta nel mondo.

• Giorno CQ 5.3 (2010)

  • Introduzione delle funzioni di Communities per la collaborazione social (e come nota solo AEM 6.5 LTS ha finalmente deprecato e rimosso questa funzionalità!)
  • "Site Optimizer" per test A/B e multivariati (sentiremo presto di nuovo QUEL nome)
  • Flussi di lavoro di traduzione migliorati e supporto all'internazionalizzazione

L'acquisizione da parte di Adobe di Day Software & CQ

Adobe ha annunciato nel luglio 2010 che avrebbe acquistato Day Software e con esso il prodotto CQ. A questo punto Adobe stava già gestendo il proprio sito Web su CQ e, data la loro nuova attenzione alla creazione di una linea di business tecnologica di marketing, aveva senso. Adobe aveva appena acquisito Omniture nel settembre 2009 per 1,8 miliardi di dollari e Scene7 nel 2007, quindi era chiaro che Adobe stava iniziando a fare sul serio con qualcosa di più del semplice business del software creativo.

L'acquisizione da parte di Adobe è stata completata nel settembre 2010 per 240 milioni di dollari in un accordo interamente in contanti, 7 volte più economico di quello che hanno pagato per Omniture, il che è stato un vero affare se si guarda con il senno di poi.

Non sono sicuro di te, ma io ricordo esattamente dove mi trovavo quando è stato annunciato l'accordo. All'epoca stavo eseguendo CQ 5.2 per AARP (erano stati su CQ da CQ 4.2). CQ all'epoca per me, era in parti uguali "enorme mal di testa" e "è qui che sta andando CMS?" dato che stavamo ancora cercando di capire quali servizi dovessero rimanere su JBoss e quali potessero essere facilmente eseguiti all'interno di CQ5 ora che CQ aveva un framework di server applicativi Java così robusto.

Ma ACQUISTATO DA ADOBE ORA?? Questo ha cambiato tutti i miei calcoli sull'opportunità o meno di continuare a investire tempo nell'apprendimento di CQ5, perché ovviamente con Adobe alle spalle, era probabile che avesse le gambe. E così è stato!

Il marchio "Day Software" all'interno dell'app è stato brevemente cambiato in "Adobe CQ", anche se tutto il resto è rimasto lo stesso, per la maggior parte.

• Adobe CQ 5.4 (2011)

  • Repository CRX2 per migliorare le prestazioni e la scalabilità (questo è stato il mio primo grande progetto CQ, una migrazione del repository che aggiorna da CQ 5.3 a 5.4)
  • Funzionalità social e gestione della community migliorate
  • Migliori funzionalità di authoring per dispositivi mobili

• Adobe CQ 5.5 (2012)

  • Connettori per Adobe Creative Suite, Scene7 e Search&Promote
  • Creazione diretta di app per dispositivi mobili
  • Partnership con Hybris per l'integrazione dell'eCommerce
  • Funzionalità Annulla/Ripeti nell'editor
  • I frammenti di contenuto hanno fatto la loro prima apparizione qui, così come uno sviluppo personalizzato per un cliente con cui stavo lavorando, e successivamente rilasciati come pacchetto di funzionalità.

Rebranding in "Adobe Experience Manager"

Adobe sapeva che questo non sarebbe stato chiamato "CQ" per sempre, quindi ha provato alcuni tentativi di re-branding abortiti, prima chiamandolo "Adobe WCM" e poi "Web Experience Manager" per un po' prima di decidere di chiamarlo "Adobe Experience Manager". È stato durante la versione 5.6 che la schermata di accesso è cambiata e ora vedevi "Adobe Experience Manager" quando accedevi a CQ.

• AEM 5.6 (2013)

  • TouchUI è stato introdotto per l'ambiente di authoring (quante applicazioni conosci che utilizzano ANCORA ClassicUI?)
  • Supporto per siti e app per dispositivi mobili
  • Personalizzazione e targeting migliorati
  • DAM migliorato con profili video

• AEM 6.0 (2014)
  AEM 6 è stata una riscrittura SIGNIFICATIVA di molte delle basi di AEM. Per ognuno di noi nel settore CQ5 -> le migrazioni AEM6 hanno occupato la stragrande maggioranza del nostro tempo in quanto erano MOLTO laboriose.

  • AEM 6 ha sostituito l'archivio sottostante da Apache Jackrabbit ad Apache Oak, richiedendo una migrazione su larga scala.
  • Il clustering attivo-attivo di CQ non era più disponibile, anche se Adobe ha introdotto il back-end di archiviazione MongoMK per AEM che potrebbe teoricamente (a questo punto MOLTO TEORICAMENTE) fornire autori AEM in scala orizzontale. Tuttavia, era estremamente difettoso e la nostra unica implementazione che abbiamo fatto su questo si è conclusa con un disastro e un passaggio a un singolo autore TarMK
  • Ingombro maggiore di TouchUI per la maggior parte delle pagine
  • Tag avanzati per le risorse

• AEM 6.1 (2015)

  • Molte correzioni di bug, ma la 6.1 non era ancora una versione particolarmente stabile.
  • Il supporto per i vanity URL è apparso nella versione 6.1
  • ContextHub per la personalizzazione
  • SDK per app mobili
  • Viene introdotto AEM Communities e, insieme ad esso, una serie di opzioni di infrastruttura e archiviazione per i contenuti generati dagli utenti. Nel corso del tempo sarebbero stati apportati miglioramenti a questo aspetto, ma purtroppo non è sopravvissuto al passaggio al servizio cloud.
  • L'app desktop AEM è stata rilasciata per la versione 6.1, sono riuscito a 100% DDOS un ambiente di authoring con questa app :(

• AEM 6.2 (2016)

  • Molte altre correzioni di bug e miglioramenti della stabilità - ancora non una versione particolarmente stabile, ma ENORMEMENTE migliore della 6.1 o della 6.0.
  • Introduzione di frammenti di contenuto diffusi (prima poteva essere fatto tramite il pacchetto di funzionalità, ma ora fa parte del prodotto)
  • Supporto SSL all'interno di AEM
  • L'interfaccia utente cambia il modo in cui siamo abituati ora, con il nav spostato in alto dalla barra laterale

• AEM 6.3 (2017)

  • Core Components viene presentato come "pronto per la produzione".
  • I grandi miglioramenti dell'archiviazione sottostante nella versione 6.3 rendono finalmente questa la prima versione AEM 6 molto stabile. Si tratta dell'introduzione della datastore e della segmentstore separate e di un meccanismo affidabile per la gestione delle versioni online (compattazione del tar).
  • Vengono introdotti i frammenti di esperienza
  • L'editor a pagina singola è stato introdotto per le app a pagina singola.
  • "Adobe Sensei" inizia a permeare AEM Assets come marchio AI di Adobe, con quelle che erano (all'epoca) funzionalità AI piuttosto rivoluzionarie. Smart-cropping, smart-tagging, ecc. si sono fatti strada in Assets.

• AEM 6.4 (2018)

  • La versione 6.4 è stata la prima fase di "ristrutturazione del repository" progettata per semplificare gli aggiornamenti e, infine, aprire la strada al passaggio al servizio cloud.
  • Flussi di lavoro spostati in TouchUI
  • Una serie di miglioramenti ai servizi di traduzione
  • Ritaglio avanzato video nelle risorse

• AEM 6.5 (2019)

  • Molta ristrutturazione dei repository
  • Le risorse connesse hanno fornito una potenziale opzione per collegare ambienti di risorse remote a un ambiente AEM Sites separato. Funziona solo per le immagini però.
  • Enormi miglioramenti all'editor SPA
  • GraphQL per il commercio
  • E, dal momento che la 6.5 è attiva da 6 anni (la più lunga di qualsiasi versione AEM/CQ fino ad oggi!) ci sono un sacco di nuove funzionalità che sono state rilasciate tramite il service pack. A questo punto siamo al Service Pack 23 e un riepilogo di tutte le nuove funzionalità uscite dal 2019 merita un post sul blog a parte.

• AEM come servizio cloud (2020)
  Anticipato per la prima volta ad adaptTo() 2019 (la maggior parte di noi non sapeva cosa stavamo veramente guardando, in questo momento!) AEM as a Cloud Service è stato rilasciato al mondo nel gennaio 2020 e sarebbe stato al centro dell'Adobe Summit 2020... se ci fosse stato un Adobe Summit di persona nel 2020. È un peccato. AEM as a Cloud Service è stato creato per risolvere una serie di carenze di lunga data di AEM e CQ e ha avuto un successo variabile nel farlo, dando vita al panorama delle offerte AEM che abbiamo oggi. Ciò che offre è:

  • Un ambiente AEM completo basato su servizi nel cloud
  • Ridimensionamento automatico a livello di autore ed editore
  • CDN integrato
  • Flusso di lavoro e funzionalità di acquisizione dei dati notevolmente aggiornate con il motore di acquisizione delle risorse basato su microservizi
  • Nuove funzionalità di ricerca, con la ricerca potenziata dall'intelligenza artificiale (basata su RAG) che è stata appena rilasciata e di cui si è parlato su adaptTo()

• AEM 6.5 LTS
  Denominabile in modo variabile come "AEM 6.6" o "AEM 6.5 LTS" a seconda che tu stia parlando con tecnici o addetti al marketing, 6.5 LTS è l'opzione a lungo termine per le persone che intendono continuare a ospitare autonomamente o AMS i propri carichi di lavoro AEM 6.5 dopo il 2025. Java 11 sta per terminare il ciclo di vita, quindi l'unica opzione è l'esecuzione di AEM su Java 17 o Java 21.
  
  Questo è, di sicuro, l'ultimo VERO SUCCESSORE rimasto al prodotto completo uscito nel 2009, poiché molte parti di esso (ad es. /crx/packmgr e /crx/de e /etc/replication.html e così via) sono quasi ESATTAMENTE gli stessi di quando erano nella versione originale di CQ5.

• Servizi di consegna edge e DA
  Qual è il futuro di AEM? Probabilmente, il successore funzionale e "spirituale" di AEM per il futuro sarà Edge Delivery Services per il livello di distribuzione e Document Authoringper la gestione dei contenuti e l'abilitazione all'authoring. Questo è assolutamente oggetto di dibattito, ma DA è un caso molto forte per la direzione che AEM prenderà nei prossimi anni.

Informazioni sull'autore

Ti piace quello che hai sentito? Hai domande su cosa è giusto per te? Ci piacerebbe parlare! Contattaci

Altri articoli AEM che potrebbero piacerti