Nel corso degli anni, progettando e gestendo installazioni Magento prima e Adobe Commerce poi, la domanda che mi arriva più spesso all’inizio di un progetto non riguarda un modulo o un tema. Riguarda l’hosting: meglio andare su Adobe Commerce on cloud infrastructure o tenersi un’installazione self-hosted, su server propri o su un cloud generico gestito da noi? È una scelta che sembra tecnica ma è soprattutto organizzativa, e la vedo prendere male più spesso di quanto vorrei.
Voglio mettere sul tavolo pro e contro reali dei due approcci, come li ho visti sul campo nel mid-market, e gli errori ricorrenti che portano a decisioni di cui poi ci si pente.
Cosa compri davvero con Adobe Commerce on cloud infrastructure
Partiamo dai nomi, perché generano confusione. “Adobe Commerce Cloud” nel linguaggio comune indica Adobe Commerce on cloud infrastructure: la stessa Adobe Commerce che gireresti on-premise, ma su una piattaforma PaaS gestita da Adobe sopra AWS. Non è un prodotto diverso a livello di codice. È lo stesso applicativo dentro un ambiente confezionato.
Cosa c’è dentro quel pacchetto, in concreto:
- Ambienti pronti: production, staging e integration già impostati, con la deploy pipeline basata su Git. Fai push, parte il build, poi il deploy. La logica di build e deploy phase è standardizzata e questo, quando il team la rispetta, riduce parecchio gli errori a rilascio.
- Fastly come CDN e WAF, con il full-page cache in edge e la protezione a monte. È uno dei pezzi che apprezzo di più, perché configurato bene toglie carico all’origin e ti dà un layer di sicurezza che altrimenti dovresti costruire.
- Stack gestito: MySQL/MariaDB, Redis, RabbitMQ, Elasticsearch forniti e mantenuti nella loro versione supportata, senza doverli installare e patchare a mano.
- Monitoring incluso, con New Relic sugli ambienti, e supporto Adobe sull’infrastruttura.
La promessa è chiara: tu ti concentri sul codice e sul business, l’infrastruttura è responsabilità loro. Nella mia esperienza questa promessa è mantenuta, a patto di accettarne i vincoli.
Il prezzo della comodità: i vincoli del PaaS
Il rovescio della medaglia esiste ed è onesto elencarlo. Su Adobe Commerce on cloud infrastructure non hai root sui server. Non decidi tu le versioni dei servizi: usi quelle supportate dalla piattaforma, e quando devi aggiornarne una segui le loro finestre e i loro vincoli di compatibilità. Alcune installazioni di sistema che daresti per scontate su una macchina tua qui passano da un file di configurazione dichiarativo o, nei casi limite, da un ticket al supporto.
Ho visto team di sviluppo abituati all’on-premise sbattere contro questo muro nei primi mesi: “perché non posso installare questa estensione di sistema?”, “perché il cron gira così?”. Non è che il cloud sia peggio. È che ragiona per convenzioni, e chi arriva dal server nudo deve disimpararne alcune.
Poi c’è il costo. La licenza di Adobe Commerce è già commisurata al fatturato del merchant; la versione on cloud infrastructure la include ma pesa sul totale, e i piani sono dimensionati su soglie di GMV e di risorse. Per un merchant piccolo il costo per unità di traffico può risultare alto rispetto a un self-hosted tirato al risparmio. Su questo bisogna essere lucidi.
Self-hosted: libertà totale, responsabilità totale
All’estremo opposto c’è la stessa Adobe Commerce installata su infrastruttura tua, o su un cloud IaaS generico che gestisci in autonomia. Qui il quadro si ribalta.
I vantaggi sono reali e li riconosco senza fatica:
- Controllo pieno: root, versioni dei servizi decise da te, tuning del kernel e del web server come vuoi, estensioni di sistema senza chiedere permesso.
- Architettura su misura: puoi mettere il database su hardware dedicato, scegliere il provider di CDN che preferisci, disegnare la rete come serve al tuo caso.
- Costo potenzialmente più basso sulla pura infrastruttura, soprattutto se hai già competenze sistemistiche interne o un partner di hosting solido.
Il problema è che ogni voce di quella lista è anche una responsabilità. Nel self-hosted la deploy pipeline, il full-page cache in edge, il WAF, il monitoring, il patching di sicurezza e il disaster recovery non te li regala nessuno: li costruisci e li mantieni tu. Fastly o un’altra CDN vanno integrate e configurate a mano. Il security patching di Adobe Commerce, quando esce un bollettino, tocca a te applicarlo in tempi ragionevoli. La replica del database, i backup testati, i piani di ripristino: tuoi.
Un caso che mi è rimasto impresso: un merchant fashion, giro attorno ai 12M di GMV, era su self-hosted per risparmiare. Sulla carta l’hosting costava meno. Nella realtà avevano accumulato mesi di patch di sicurezza non applicate perché “non c’era mai il momento”, un full-page cache configurato male e un solo sistemista che teneva insieme tutto. Il costo vero non era in bolletta: era il rischio operativo silenzioso che si era accumulato. Non è un problema del self-hosting in sé — è un problema di non aver dimensionato le competenze che il self-hosting richiede.
Come scelgo, nel mid-market
La mia posizione, dopo diversi progetti, è netta: nel mid-market la domanda giusta non è “quale costa meno” ma “chi si prende la responsabilità operativa, e ha davvero le competenze per farlo”.
Ragiono così, in ordine:
- Competenze DevOps interne. Se il merchant o il partner non ha un team che sa gestire deploy, cache edge, patching e incident 24/7, il PaaS gestito non è un lusso, è una rete di protezione. Adobe Commerce on cloud infrastructure diventa la scelta di buon senso.
- Prevedibilità contro flessibilità. Se il valore è avere ambienti standard, pipeline ripetibile e meno variabili da gestire, il cloud vince. Se hai esigenze architetturali particolari che il PaaS non concede — e devono essere esigenze vere, non preferenze — il self-hosted ha senso.
- Profilo di rischio. Un merchant che fa numeri importanti nei picchi stagionali e non può permettersi downtime, secondo me sta molto più tranquillo con Fastly e l’infrastruttura gestita davanti, piuttosto che con un setup fatto in casa da manutenere.
- Costo totale, non solo l’infrastruttura. Al canone del self-hosted va sommato il costo reale delle persone e degli strumenti per fare bene tutto ciò che il cloud include. Fatta questa somma onesta, il divario si assottiglia più di quanto si creda.
Gli errori che vedo nella scelta
Chiudo con i tre sbagli più frequenti, perché evitarli vale più di qualsiasi tabella comparativa.
Scegliere il self-hosted solo per il prezzo di listino dell’hosting. È l’errore numero uno. Si guarda il canone mensile del server e si ignora il costo delle competenze che quel canone non compra. Il conto vero arriva dopo, sotto forma di rischio.
Andare sul cloud pensando di non doversi più occupare di niente. Adobe Commerce on cloud infrastructure gestisce l’infrastruttura, non il tuo codice. Un modulo scritto male, un full-page cache non sfruttato, una deploy pipeline usata a metà: quei problemi restano tuoi. Il PaaS toglie il peso sistemistico, non l’igiene dello sviluppo.
Decidere l’hosting prima di aver mappato chi opera. La scelta hosting è a valle del modello operativo, non a monte. Prima definisco chi tiene in piedi la piattaforma nel tempo, poi scelgo l’infrastruttura che si adatta a quel team. Farlo al contrario è la ricetta per ritrovarsi con lo strumento sbagliato in mano.
Mini-FAQ
“Adobe Commerce Cloud” e Adobe Commerce sono prodotti diversi?
No. È lo stesso applicativo. “Adobe Commerce Cloud” indica Adobe Commerce on cloud infrastructure, cioè l’edizione ospitata sulla piattaforma PaaS gestita da Adobe, con Fastly, deploy pipeline e stack preconfigurato.
Il self-hosted costa davvero meno?
Sull’infrastruttura pura spesso sì. Sul costo totale, che include competenze, patching, monitoring e disaster recovery, il divario si riduce e a volte si annulla.
Quando conviene il self-hosted?
Quando hai competenze DevOps solide e interne, esigenze architetturali reali che il PaaS non concede, e sei disposto a prenderti la responsabilità operativa completa.
Quando conviene Adobe Commerce on cloud infrastructure?
Quando vuoi prevedibilità, ambienti e pipeline standard, Fastly e sicurezza a monte già pronti, e non hai un team dedicato a gestire l’infrastruttura giorno e notte.
Fabio Canovi è tra i primi in Italia ad aver ottenuto la certificazione Adobe Commerce. Lavora su Magento e Adobe Commerce dal 2011, progettando e gestendo installazioni per merchant del mid-market.