Qualche mese fa mi sono ritrovato in una riunione che conosco bene: un merchant fashion europeo, intorno ai 15M di GMV, con un progetto di replatforming del commerce già avviato e la domanda che prima o poi arriva sempre. “Il content management lo teniamo dov’è o lo spostiamo?”. Sul tavolo c’erano le due opzioni che oggi vedo con più frequenza quando si parla di Adobe Experience Manager: AEM as a Cloud Service e AEM 6.5. Sembra una scelta da architetti, e in parte lo è. Ma le conseguenze le paga chi vende online, ogni giorno, in termini di costi, velocità di rilascio e manutenzione.
Provo a mettere in fila quello che ho imparato sul campo, senza girarci troppo intorno.
Due modelli operativi, non due versioni
La prima cosa che dico sempre è di smettere di pensare a “6.5 contro Cloud Service” come a un salto di versione, tipo passare da un rilascio al successivo. Sono due modelli operativi diversi.
AEM 6.5 è la linea che installi tu: on-premise sui tuoi server, oppure gestita da Adobe con Adobe Managed Services (AMS). In entrambi i casi hai un’istanza tua, con una sua versione precisa, i suoi service pack, le sue finestre di aggiornamento. Sei tu (o il tuo partner) a decidere quando applicare una patch e a portartene la responsabilità.
AEM as a Cloud Service è l’altra filosofia: un modello SaaS-like in cui l’ambiente è sempre aggiornato da Adobe, si scala in automatico e non ha più il concetto di “versione installata” che ti porti dietro per anni. Non gestisci l’infrastruttura, gestisci il codice che ci gira sopra tramite Cloud Manager e la sua pipeline di CI/CD.
Detta così sembra che uno sia semplicemente il successore dell’altro. Nella pratica di chi ha un e-commerce sotto, la differenza si sente altrove.
Aggiornamenti: continui o pianificati
Qui sta secondo me il vero spartiacque.
Con AEM as a Cloud Service gli aggiornamenti sono continui. L’ambiente cambia sotto di te, con una cadenza regolare, e non decidi tu quando. In cambio non ti trovi mai su una versione vecchia di tre anni con un upgrade monstre da affrontare. Il rovescio della medaglia è che devi tenere il codice sempre allineato: c’è un set di regole e di best practice (Adobe le chiama Cloud Manager quality gates) che il tuo custom code deve rispettare, altrimenti la pipeline ti blocca il deploy. È una disciplina, non un optional.
Con AEM 6.5 gli aggiornamenti sono pianificati. Applichi i service pack quando vuoi, testi con calma, resti sulla tua versione finché ti serve. Per certe realtà è esattamente ciò che vogliono, per altre è la porta d’ingresso al debito tecnico: conosco progetti fermi da anni su una versione che nessuno vuole più toccare, perché “funziona” e l’upgrade fa paura.
La mia opinione netta: se il tuo team ha una cultura di continuous integration già solida, il modello continuo del Cloud Service ti toglie un peso enorme. Se invece rilasci due volte l’anno con un freeze prima del Black Friday e nessuna pipeline degna di questo nome, il Cloud Service non è un problema, ma va accompagnato da un cambio di abitudini. Non è un dettaglio: è il punto in cui vedo fallire più adozioni.
Costi: CapEx contro OpEx
Sul fronte costi la differenza è meno banale di come viene raccontata.
AEM 6.5 on-premise ha una componente di CapEx: server, storage, licenze, e soprattutto le persone che tengono in piedi l’infrastruttura. Con AMS parte di questo peso si sposta su Adobe, ma paghi comunque per un ambiente dedicato dimensionato sui tuoi picchi.
AEM as a Cloud Service è puro OpEx: un canone, l’auto-scaling che segue il traffico, nessun ferro da gestire. Per un e-commerce con stagionalità marcata — pensa ai saldi, alle campagne, ai lanci — l’auto-scaling non è marketing: è la differenza tra dimensionare tutto l’anno sul picco di dicembre e pagare la capacità solo quando serve davvero.
Attenzione però a non leggerlo come “il Cloud Service costa meno”. Non è detto. Sposti i costi da un capitolo all’altro e ne riduci di nascosti (le ore di sistemistica, i downtime, gli upgrade rimandati), ma il canone è quello che è. Il ragionamento giusto non è sul prezzo di listino, è sul total cost of ownership su tre-quattro anni, incluso il costo del non-aggiornare.
Sviluppo e time-to-market
Sul modo di sviluppare, il Cloud Service impone dei vincoli che a prima vista sembrano fastidi e col tempo diventano garanzie. Niente più modifiche a caldo sull’istanza, tutto passa da Git e dalla pipeline. Non tutto ciò che gira su 6.5 gira identico sul Cloud Service: alcune abitudini vanno riviste, e la migrazione richiede un lavoro di adeguamento del codice che non è mai zero.
In cambio il time-to-market tende a migliorare, perché i rilasci diventano ripetibili e meno drammatici. Su un progetto 6.5 mal gestito ho visto deploy che duravano una notte intera con mezza squadra sveglia; su un Cloud Service ben impostato il deploy è un evento noioso, ed è esattamente ciò che vuoi.
E il commerce, in mezzo a tutto questo?
Nei progetti che integrano AEM con Adobe Commerce il tema si fa concreto. AEM porta la parte editoriale ed esperienziale — le pagine di brand, i contenuti, lo storytelling di prodotto — mentre Commerce porta catalogo, carrello e checkout. La qualità dell’integrazione conta più della sigla sotto.
Il mio consiglio: se stai costruendo o rifacendo adesso il layer di commerce, e vuoi un’esperienza che tenga insieme content e catalogo con approcci moderni, il Cloud Service è la base su cui costruirei, perché ti mette nella direzione giusta e non ti lascia indietro su una versione destinata a invecchiare. Se invece hai un 6.5 in produzione che funziona, con integrazioni Commerce già rodate e nessuna urgenza, non lo tocco solo per moda: pianifico la migrazione come progetto a sé, quando c’è una vera ragione di business.
Come scelgo, in pratica
Quando mi chiedono di decidere, guardo tre cose, in quest’ordine: la maturità del team su CI/CD, la stagionalità del traffico, e l’orizzonte temporale del progetto. Team maturo, picchi forti, orizzonte lungo: Cloud Service, senza troppi dubbi. Team abituato ai rilasci manuali, traffico piatto, sistema che deve solo durare ancora un paio d’anni: 6.5 con AMS resta una scelta legittima, non un ripiego.
La cosa che non farei è scegliere per inerzia. Entrambe le strade hanno un costo di manutenzione: una lo mette in bolletta ogni mese, l’altra te lo presenta tutto insieme il giorno dell’upgrade.
Mini-FAQ
AEM as a Cloud Service è semplicemente la versione più recente di AEM 6.5?
No. Sono due modelli operativi diversi: 6.5 è un’istanza a versione fissa che aggiorni tu (on-premise o con Adobe Managed Services), mentre il Cloud Service è SaaS-like, con aggiornamenti continui e auto-scaling gestiti da Adobe.
Il Cloud Service costa meno di AEM 6.5?
Non necessariamente. Sposta i costi da CapEx a OpEx e riduce quelli nascosti come sistemistica e upgrade rimandati, ma va valutato sul total cost of ownership a tre-quattro anni, non sul prezzo di listino.
Posso restare su AEM 6.5 se ho già un’integrazione con Adobe Commerce che funziona?
Sì. Se il sistema è in produzione, rodato e senza urgenze, la migrazione va pianificata come progetto a sé quando c’è una ragione di business, non affrontata per moda.
Qual è il vero prerequisito per adottare il Cloud Service?
Una cultura di continuous integration solida: il codice deve rispettare i quality gate di Cloud Manager, altrimenti la pipeline blocca il deploy.
Sull’autore — Sono Fabio Canovi, mi occupo di e-commerce enterprise da oltre dieci anni, con focus su Magento / Adobe Commerce e Adobe Experience Manager. Sono stato tra i primi in Italia a ottenere la certificazione Adobe Commerce. Su questo blog racconto quello che vedo sul campo lavorando con merchant mid-market, senza filtri di marketing.