SaaS e architettura non sono sinonimi
Microsoft distingue il SaaS come modello di servizio dalla multitenancy come scelta architetturale. Una software house può gestire ambienti separati per cliente e seguire comunque una logica SaaS, se onboarding, versioni e operazioni sono governati come un servizio ripetibile. AWS descrive anche il modello con infrastruttura dedicata per cliente e sottolinea che la gestione unificata è la differenza rispetto a installazioni curate una per una.
Questo non rende automaticamente conveniente un ambiente dedicato per ogni cliente. La scelta deve tenere insieme isolamento, costi, rilascio delle versioni e capacità operativa del team. La domanda utile è quale modello puoi gestire in modo prevedibile quando i clienti aumentano.
Fonti: Microsoft Learn — SaaS e architettura multitenant · AWS SaaS Lens — full-stack isolation
Tre gradini da non confondere
Con l'accesso web i clienti usano il software esistente attraverso il browser, oppure nuove funzioni web collegate al core. Il prodotto può rimanere ospitato presso di loro o in un ambiente dedicato. La responsabilità operativa va concordata, non si deduce dall'interfaccia.
Con l'hosting gestito la software house ospita il prodotto e ne segue disponibilità, backup e aggiornamenti, magari con un ambiente distinto per ciascun cliente. È un passo importante, ma se ogni installazione ha una versione e una procedura diverse il lavoro può restare fortemente artigianale.
In un servizio SaaS ripetibile onboarding, distribuzione delle versioni, osservabilità e supporto seguono processi condivisi. Le differenze tra clienti sono configurazioni governate, non modifiche manuali che rendono ogni rilascio un progetto separato. Non c'è obbligo di percorrere tutti e tre i gradini in un unico progetto. La scelta utile mantiene sostenibili qualità del servizio, margine e capacità del team.
Chi risponde di che cosa?
Quando il prodotto è installato presso il cliente, il cliente o il suo fornitore IT può occuparsi dei server. Gli aggiornamenti sono spesso concordati caso per caso. Backup, accessi e ripristino dipendono dall'accordo in essere. Se la software house eroga il servizio, deve organizzare hosting, capacità, manutenzione, distribuzione e verifica dei rilasci.
Identità, accessi, osservabilità e incidenti diventano parte del lavoro quotidiano. Il costo delle operazioni entra nell'economia del prodotto. Questa ripartizione è una traccia per la discussione, non sostituisce i contratti attuali: prima di cambiare modello occorre verificare cosa sia incluso nell'assistenza che già fornisci.
La guida Microsoft ai workload SaaS include tra le aree di progetto identità, isolamento dei clienti, costi, distribuzione e gestione degli incidenti. Sono decisioni di prodotto e di servizio, non soltanto di infrastruttura.
- Infrastruttura: chi prepara i server oggi e chi li manterrà domani?
- Aggiornamenti: chi pianifica, distribuisce e verifica ogni versione?
- Backup e ripristino: chi esegue le prove e chi interviene in caso di errore?
- Identità: come vengono creati clienti, utenti e ruoli?
- Supporto: chi riceve gli incidenti, li diagnostica e comunica l'esito?
- Costi: quali oneri passano dal cliente alla software house?
Fonti: Microsoft Learn — Azure Well-Architected SaaS workloads
Dati: scegliere l'isolamento che puoi gestire
La domanda non è soltanto «un database per tutti o uno per cliente?». Bisogna decidere come un utente viene associato al proprio cliente, quali dati può leggere, come si eseguono backup e ripristini, cosa succede se un cliente genera molto carico e come si trasferiscono dati da un'installazione esistente. Un database condiviso può ridurre alcune attività, ma richiede controlli rigorosi dell'isolamento logico. Ambienti separati semplificano alcuni confini e ne complicano altri, per esempio distribuzione e controllo delle versioni.
Nel primo pilota può essere ragionevole conservare un ambiente per cliente, purché la sua creazione e gestione non dipendano da istruzioni ricordate da una sola persona. Se servono molte eccezioni manuali, il rischio è spostare il lavoro di installazione dal cliente alla software house senza renderlo scalabile. Il criterio di scelta è operativo: quanto tempo serve ad attivare un cliente, aggiornarlo, diagnosticare un problema e recuperare un dato?
Versioni e supporto diventano parte del prodotto
Un aggiornamento distribuito presso cento clienti richiede coordinamento. In un servizio gestito, la software house può controllare il rilascio, ma assume anche il compito di verificarlo. Servono ambienti rappresentativi, test sui flussi critici, una sequenza di attivazione e una procedura di ritorno. Le personalizzazioni devono essere conosciute: una funzione su misura può impedire di mantenere tutti sulla stessa versione se non viene ripensata come configurazione o estensione governata.
Anche l'assistenza cambia. Sapere che «il servizio non risponde» non basta; occorre distinguere errore applicativo, prestazioni, integrazione esterna o problema di un solo cliente. Log, metriche e tracciamento delle operazioni aiutano a capire che cosa è successo. Bisogna definire chi riceve la segnalazione, chi può intervenire e come viene comunicato l'esito. La qualità percepita del prodotto dipende da queste attività quanto dalla nuova interfaccia.
Un esempio illustrativo: partire da un gruppo omogeneo
Immaginiamo una software house che vende un prodotto per laboratori. Alcuni clienti hanno installazioni standard; altri usano periferiche e procedure locali molto personalizzate. La software house può iniziare rendendo disponibile online il prodotto standard a un piccolo gruppo, mantenendo per ora le installazioni complesse. Durante il pilota misura tempi di attivazione, uso effettivo, incidenti, costo di gestione per cliente e necessità di supporto. Poi decide se estendere il servizio, creare varianti governate o conservare due modalità di erogazione.
È un esempio inventato, non un progetto cliente MadeInCode. Mostra perché il pilota deve verificare anche il modello operativo, non solo se il software si apre nel browser. Se il prodotto resta installato dai clienti per una fase, un Web Bridge può già offrire accessi e integrazioni utili. La scelta SaaS può maturare con evidenze migliori.
Le domande per il primo passo
Un Legacy Assessment può chiarire che cosa portare online subito e quali vincoli risolvere prima di assumere la gestione del servizio. Con Modernization Partner, MadeInCode affianca il team nella scelta del percorso tecnico e operativo.
- Chi ospiterà il prodotto e chi interverrà quando non è disponibile?
- Come si creano clienti, utenti e permessi senza operazioni manuali fragili?
- Dove risiedono i dati e come si verificano backup e ripristino?
- Quante versioni e personalizzazioni vanno mantenute?
- Come vengono rilasciate le nuove funzioni e gestiti gli incidenti?
- Qual è il costo ricorrente per ogni cliente, oltre al lavoro iniziale?