SaaS, hosting gestito o self-hosting: scegli in base a chi si occupa del lavoro

Parti dal lavoro che l’applicazione deve supportare

Scegliere dove eseguire un’applicazione significa decidere chi si occuperà dei diversi livelli necessari a mantenerla utilizzabile. La scelta riguarda anche chi prenderà le decisioni su dati, accessi, configurazione e ripristino.

Metti per iscritto quale attività deve svolgere l’applicazione, a quali sistemi deve collegarsi, chi deve accedervi e cosa deve succedere se il servizio non è disponibile. Poi individua le attività operative che il tuo team può assumersi con continuità: un modello che sembra semplice all’attivazione può comunque lasciare al cliente compiti importanti.

Le etichette SaaS, hosting gestito e self-hosting sono punti di partenza, non definizioni contrattuali complete. L’ambito del servizio e le responsabilità effettive vanno verificati nella documentazione e negli accordi del fornitore.

• Quale processo aziendale dipende dall’applicazione e quali sarebbero le conseguenze di un’interruzione o della perdita di dati?
• Devi modificare l’applicazione, la distribuzione o la configurazione sottostante?
• Quali integrazioni, controlli degli accessi e regole per la gestione dei dati sono indispensabili?
• Chi sarà responsabile dell’amministrazione, dei rapporti con il fornitore e delle decisioni sul ripristino?

Definisci i modelli in base a chi gestisce ciascun livello

In genere, il SaaS è un’applicazione fornita come servizio da un fornitore. Le descrizioni generali del modello cloud indicano che l’applicazione è ospitata e gestita da una terza parte, spesso un fornitore SaaS ([Circadian Risk](https://www.circadianrisk.com/resources/blog/cloud-vs-self-hosting-which-should-you-choose/)). Il cliente utilizza il servizio e deve comunque chiarire come sono suddivise le responsabilità per utenti, impostazioni, dati e governance.

Con l’hosting gestito, un fornitore svolge attività di hosting o infrastruttura concordate per un’applicazione. Il termine, da solo, non specifica quali attività siano incluse né chi gestisca aggiornamenti, backup o ripristino: chiedi che il fornitore descriva il perimetro del servizio.

Con il self-hosting, l’organizzazione esegue l’applicazione su un’infrastruttura che controlla o ha predisposto. Questa modalità può darle un controllo diretto sulla distribuzione e sulla configurazione, ma richiede anche che qualcuno si occupi delle attività operative. Una descrizione comparativa del self-hosting lo associa all’esecuzione su infrastruttura controllata dall’organizzazione e al controllo su dati, distribuzione e configurazione ([Plane](https://plane.so/blog/self-hosted-vs-saas-project-management-tools-key-differences)).

Distingui l’applicazione dall’infrastruttura su cui viene eseguita. Il fatto che un fornitore gestisca un livello non dimostra che si occupi anche di tutte le attività degli altri livelli.

• SaaS: il servizio applicativo è fornito da un fornitore; verifica quali decisioni e attività restano al cliente.
• Hosting gestito: il fornitore si occupa delle attività di hosting concordate; il perimetro va specificato.
• Self-hosting: l’organizzazione controlla o predispone l’ambiente e deve assegnare le attività operative, direttamente o tramite fornitori.

Confronta le responsabilità con domande concrete

Non esiste una matrice valida per tutti i fornitori. Le fonti generali descrivono differenze di alto livello tra cloud e self-hosting, ma non stabiliscono chi debba gestire backup, accessi, aggiornamenti, ripristino o uscita dal servizio in ogni contratto. Usa le domande seguenti per ottenere risposte sul piano e sull’applicazione specifici che stai valutando.

Anche quando un fornitore dichiara una funzione di backup, occorre chiarire che cosa comprende e come si svolge un ripristino. La presenza della funzione, da sola, non spiega quali passaggi siano a carico del cliente.

• Infrastruttura — Chi predispone, amministra e mantiene l’ambiente? Per il self-hosting, l’organizzazione controlla o predispone l’infrastruttura; negli altri casi chiedi quale parte gestisce il fornitore.
• Aggiornamenti dell’applicazione — Chi decide quando applicarli, chi li esegue e chi controlla che l’applicazione funzioni dopo l’intervento?
• Backup e ripristino — Quali dati sono inclusi? Con quale frequenza e per quanto tempo sono conservati? Chi può avviare un ripristino e quali azioni spettano al cliente?
• Accessi e identità — Chi amministra gli account applicativi e quelli della piattaforma? Quali controlli di identità supporta il servizio? La scelta tra self-hosting e SaaS per un servizio di identità incide su chi gestisce l’infrastruttura di identità ([Duende Software](https://duendesoftware.com/compare/self-host-vs-saas)).
• Dati e governance — Quali impegni assume il fornitore, quali dati e configurazioni puoi esportare e quali condizioni si applicano al trattamento e alla conservazione?
• Incidenti — Chi rileva e comunica un problema, chi coordina le attività e quali interventi o informazioni sono richiesti al cliente?
• Configurazione e integrazioni — Quali modifiche e collegamenti sono supportati dal servizio? Quali richiedono accesso o interventi sull’ambiente applicativo?

Confronta controllo, impegno operativo e portabilità

Un modello può ridurre alcune attività operative senza offrire tutto il controllo desiderato. Il SaaS può limitare le scelte di distribuzione o personalizzazione; il self-hosting può dare più controllo diretto, ma solo a condizione che qualcuno possa mantenere l’ambiente. L’hosting gestito può delegare attività definite, senza trasferire automaticamente il controllo dell’applicazione o le decisioni aziendali.

Valuta anche le dipendenze e la portabilità prima di scegliere. Per passare a un altro modello potrebbero essere necessari non solo i dati, ma anche file, configurazioni, credenziali, integrazioni e accessi degli utenti. Chiedi quali elementi possono essere esportati e quali andrebbero ricreati.

• Controllo: quali decisioni su applicazione, distribuzione e configurazione devono restare nelle tue mani?
• Personalizzazione: il prodotto supporta le modifiche necessarie oppure serve accesso all’ambiente applicativo?
• Impegno operativo: chi si occuperà delle attività ricorrenti e della risoluzione dei problemi?
• Dipendenze: quali servizi di identità, archiviazione, posta elettronica o API sono necessari al flusso di lavoro?
• Portabilità: puoi ottenere copie utilizzabili dei dati e della configurazione? Che cosa andrebbe ricostruito?
• Responsabilità: per ogni attività importante è chiaro chi deve intervenire, sia dal lato cliente sia da quello del fornitore?

Individua i requisiti che possono escludere un modello

Alcuni requisiti sono condizioni indispensabili, non semplici preferenze. Se un servizio non soddisfa un requisito obbligatorio di integrazione, gestione dei dati o ripristino, un carico operativo inferiore non compensa la mancanza. Elenca prima le condizioni imprescindibili e confronta poi le opzioni rimanenti.

La governance può riguardare l’approvazione degli accessi, la gestione dei dati e chi può amministrare il servizio. Non dedurre la conformità dal solo modello di distribuzione: verifica i controlli e gli impegni pertinenti con il fornitore e, se opportuno, con gli specialisti della tua organizzazione.

Per il ripristino, definisci quali dati e funzioni devono essere recuperati, chi può autorizzare l’intervento e quali informazioni ti servono per valutare la procedura. Se le risposte non soddisfano i tuoi requisiti, rivaluta il modello o il fornitore.

• Il SaaS può non essere adatto se non offre una distribuzione o personalizzazione necessaria, oppure se le sue modalità di gestione di dati, integrazioni o accessi non soddisfano un requisito obbligatorio.
• L’hosting gestito può non essere adatto se il fornitore non assume le responsabilità di cui il team ha bisogno o se il confine tra le attività delle parti resta poco chiaro.
• Il self-hosting può non essere adatto se l’organizzazione non riesce ad assegnare le attività operative necessarie.
• Qualsiasi modello può non essere adatto se il fornitore non chiarisce esportazione dei dati, controlli degli accessi e condizioni di cessazione del servizio.

Valuta le opzioni con un carico di lavoro realistico

Immagina che un piccolo team operativo voglia un’applicazione per il monitoraggio interno dei progetti. Il personale deve accedere tramite browser, collegarsi a un sistema di identità esistente o a un flusso di notifiche e disporre di un metodo per ripristinare i record. Il team non ha uno specialista di infrastruttura interno.

Il SaaS può essere adatto se supporta il flusso di lavoro e i controlli richiesti e se le modalità di esportazione e ripristino sono accettabili. L’hosting gestito può essere adatto se il team ha bisogno di una distribuzione specifica e il fornitore si assume chiaramente le attività che il team non può gestire. Il self-hosting può essere preso in considerazione se l’organizzazione assegna un responsabile o dispone di un supporto contrattualizzato e vuole farsi carico del lavoro operativo.

Per confrontare le opzioni, prova l’integrazione concreta, chiarisci chi amministra gli account e chiedi a ciascun fornitore di descrivere aggiornamenti e ripristino. Così preferenze come «vogliamo più controllo» o «vogliamo che sia gestito» diventano requisiti verificabili.

• Elenca funzionalità e integrazioni indispensabili.
• Individua chi amministra l’applicazione e chi gestisce le modifiche agli accessi.
• Chiedi a ogni fornitore di descrivere un aggiornamento di routine e una richiesta di ripristino.
• Definisci cosa dovrebbe fare il team in caso di interruzione, uscita di un dipendente o migrazione pianificata.
• Escludi le opzioni che non soddisfano i requisiti obbligatori prima di confrontarne la praticità.

Chiedi ai fornitori chi gestisce le operazioni

Chiedi procedure concrete, non soltanto un elenco di funzioni incluse. Per ogni attività, fatti spiegare che cosa esegue il fornitore, che cosa si limita a consigliare e che cosa si aspetta dal cliente.

Airbip descrive un servizio di distribuzione gestita in cui le istanze applicative funzionano come carichi di lavoro Docker sui server cloud Airbip. Le funzionalità dichiarate comprendono instradamento automatico e certificati TLS tramite Traefik e Let’s Encrypt, controlli DNS, gestione del ciclo di vita dei servizi e backup giornalieri, settimanali e mensili configurabili. Queste informazioni non definiscono da sole ogni responsabilità: per ambito dei backup, conservazione, ripristino, accessi e dati, consulta le informazioni aggiornate sul [sito Airbip](https://airbip.com/) e chiedi chiarimenti sul servizio specifico.

• Chi installa e applica gli aggiornamenti dell’applicazione? Il cliente può scegliere quando vengono eseguiti?
• Quali attività di monitoraggio e risoluzione dei problemi sono incluse e quali richiedono un intervento del cliente?
• Che cosa include un backup, per quanto tempo viene conservato e come funziona il ripristino?
• Chi gestisce gli account applicativi, gli accessi amministrativi e l’integrazione con i sistemi di identità?
• Quali dati e configurazioni può esportare il cliente, in quale formato e con quale procedura?
• Chi comunica durante un incidente e quali informazioni o interventi sono richiesti al cliente?
• Quali integrazioni, personalizzazioni o modifiche alla distribuzione sono supportate?
• Dove sono documentati i confini del servizio e le esclusioni?

Pianifica l’esportazione dei dati e l’uscita dal servizio

Valuta la portabilità prima di adottare un servizio. Scopri come esportare record e file, se puoi trasferire configurazioni e informazioni sugli utenti e se le integrazioni dovranno essere ricreate. Verifica che il formato esportato possa essere utilizzato nella soluzione successiva: una funzione di esportazione non garantisce da sola una migrazione semplice.

Prepara un piano di uscita proporzionato all’importanza dell’applicazione. Individua chi richiederà e verificherà l’esportazione, come gestire gli accessi durante la transizione e che cosa succederà alle copie detenute dal fornitore. Controlla tempi, costi e condizioni nei termini aggiornati del servizio.

Il modello adatto è quello i cui confini operativi, livello di controllo e percorso di uscita corrispondono ai requisiti e alle capacità della tua organizzazione. La decisione non consiste nello scegliere l’etichetta che sembra più sicura, ma nell’assegnare un responsabile a ogni attività importante.

• Chiedi prima dell’adozione come funziona l’esportazione dei dati.
• Individua dati, file, configurazioni, account utente e integrazioni che potrebbero dover essere trasferiti.
• Stabilisci chi convaliderà i dati esportati e come valutare una transizione riuscita.
• Esamina le condizioni di cessazione, conservazione e cancellazione dei dati.
• Assegna un referente del cliente a ogni attività che il fornitore non accetta esplicitamente.