Infrastruttura cloud o locale: come scegliere dove eseguire un sistema

Scegliete la collocazione di uno specifico sistema aziendale, anziché prendere un’unica decisione per l’intera azienda. Posta elettronica, database di un’applicazione in produzione e archiviazione dei file possono avere requisiti diversi. Iniziate il confronto identificando chi usa il sistema, quali dati gli servono e che cosa accade se diventa indisponibile.

I servizi cloud non eliminano la necessità di gestione, e l’hardware in ufficio non garantiscono la sicurezza. Confrontare due opzioni in base alle stesse attività e requisiti. Utilizzare la matrice sottostante per registrare le condizioni confermate e assegnare i responsabili per le informazioni mancanti.

Descrivere il sistema e i confini del confronto

Raccogliere i requisiti del carico di lavoro

Un carico di lavoro include l’applicazione, i dati e i componenti correlati che, insieme, svolgono un compito aziendale. Ad esempio, valutare un singolo server è insufficiente se l’applicazione dipende da un database locale, una stampante e un servizio di autorizzazione. Registrare queste dipendenze prima di confrontare i costi.

• Scopo del sistema, responsabile e utenti, comprese le sedi remote.
• Versioni, licenze e opzioni di implementazione supportate dal fornitore.
• Volume dei dati, carico normale, picchi e cambiamenti previsti.
• Connessioni ad altre applicazioni, apparecchiature e servizi esterni.
• Requisiti di tempo di risposta, disponibilità e ripristino.
• Restrizioni sui dati e sulla posizione, confermate dalla persona responsabile dei requisiti aziendali.

La direzione conferma l’attività aziendale, il reparto IT verifica le condizioni tecniche e il proprietario dell’applicazione fornisce supporto. Segnalare informazioni sconosciute. Se il fornitore non consente l’implementazione o il supporto della configurazione richiesta, risolvere tale limitazione prima di considerare l’opzione come disponibile.

Distinguere la collocazione dal livello di servizio

Con l’implementazione locale, il sistema funziona su apparecchiature presso la vostra sede. Il vostro team o un appaltatore possono mantenerlo. Nel cloud, un fornitore fornisce risorse o un’applicazione come servizio. Tuttavia, una macchina virtuale e un’applicazione pronte all’uso trasferiscono diverse quantità di lavoro al fornitore.

Confrontare le opzioni che svolgono la stessa attività aziendale. Un abbonamento a un’applicazione pronta all’uso non è equivalente al noleggio di una macchina virtuale vuota. Quest’ultima richiede comunque l’installazione, le licenze, gli aggiornamenti e il supporto dell’applicazione. Un hosting o una virtualizzazione di base non descrivono automaticamente tutte le caratteristiche di un servizio cloud.

Definire chi gestisce il sistema

Suddividere le responsabilità per livello

Per ogni opzione, elenca i proprietari per l’hardware fisico, il sistema operativo, l’applicazione, gli account, le autorizzazioni, il monitoraggio e i dati. Registra chi esegue ogni azione e chi verifica il risultato. Definire un fornitore senza definire i confini del servizio crea un’ambiguità.

Il modello di responsabilità condivisa di Microsoft dimostra che il cliente gestisce le macchine virtuali, i sistemi operativi e le applicazioni in IaaS. In PaaS e SaaS, il fornitore gestisce alcune di queste attività. I dati, gli account e le impostazioni di accesso rimangono comunque parte delle responsabilità del cliente. Conferma i confini esatti per il servizio scelto.

Per un sistema locale, verifica non solo se esiste un amministratore. È necessario avere accesso all’attrezzatura, accordi di supporto, documentazione utilizzabile e un processo per ottenere pezzi di ricambio. Se un appaltatore mantiene il sistema, specifica i confini del lavoro e un contatto. La posizione del server non esegue queste attività.

Verificare requisiti di sicurezza e dei dati

I dati sensibili richiedono condizioni chiare di archiviazione e accesso in qualsiasi modello. Conferma le posizioni consentite, i diritti di amministratore, la registrazione e la gestione delle chiavi. Basare le condizioni necessarie su regole aziendali e obblighi applicabili, piuttosto che su un’opinione generale sulla sicurezza del cloud o dell’ufficio.

La certificazione del fornitore nel cloud non dimostra che la tua configurazione sia corretta. Anche la tua sala server non dimostra la protezione contro errori di accesso, interruzioni di corrente o furti. Consulta uno specialista competente per eventuali richieste specifiche. Non concludere che un settore regolamentato vieta sempre i servizi cloud o richiede sempre un server locale.

Confrontare il costo totale sullo stesso periodo

Includere avvio, gestione e uscita

Scegli lo stesso periodo di confronto e lo stesso insieme di funzionalità. Utilizza preventivi reali, contratti attuali e dati sull’utilizzo. Separa il lavoro iniziale, i pagamenti ricorrenti e i costi che variano in base all’utilizzo. Non inserire zero per un prezzo sconosciuto.

Microsoft raccomanda di includere i costi iniziali, continui e operativi, nonché i servizi correlati, nel modello di costo. Pertanto, il prezzo di un singolo server o licenza non riflette il costo dell’intero sistema operativo. Valutare diversi livelli di carico e verificare come cambiano i costi totali.

Verificare le condizioni per aumentare e ridurre le risorse

I costi del cloud possono dipendere dall’utilizzo, dal numero di utenti, dagli impegni a lungo termine e da altre condizioni. L’arresto di una macchina virtuale non interrompe necessariamente i costi per i dischi, gli indirizzi o i servizi correlati. Verificare i componenti della fattura e i termini di cancellazione delle risorse, piuttosto che solo i prezzi di calcolo.

In un ambiente locale, la capacità acquistata potrebbe rimanere inutilizzata, ma è possibile utilizzarla per compiti appropriati. La crescita potrebbe richiedere un ulteriore acquisto. Confrontare i tempi di consegna delle risorse e i costi totali, piuttosto che solo il tipo di pagamento. Il reparto finanziario può confermare la classificazione dei costi per la contabilità.

Per ogni calcolo, registrare la fonte del prezzo, la data di riferimento, le assunzioni sul carico di lavoro e il proprietario. Verificare i costi di trasferimento dei dati in entrambe le direzioni, in termini di volume e di servizi. Conservare anche uno scenario di dismissione: come recuperare i dati e quanto lavoro richiederà un altro ambiente.

Includere gli impegni rimanenti sotto i contratti attuali e il periodo di supporto per l’hardware già acquistato. Un server a pagamento richiede comunque l’operatività, e una nuova sottoscrizione al cloud potrebbe sovrapporsi a un vecchio contratto. Non contare la stessa licenza o lavoro due volte. Indicare separatamente il periodo in cui entrambi gli ambienti sono necessari per la transizione.

Verificare connettività e risposta dell’applicazione

Considerare l’intero percorso dell’utente

Un sistema cloud necessita di connessioni alle risorse che utilizza. Per un utente, questo potrebbe significare Internet. Per un’applicazione, potrebbe anche significare una connessione a un database in un’altra sede. Verificare la latenza, la stabilità e il comportamento sotto carico, nonché la velocità di connessione pubblicizzata.

Un sistema locale potrebbe non funzionare senza Internet. L’autorizzazione, la licenza, i directory esterni, gli scambi con i partner e l’accesso remoto potrebbero dipendere da servizi esterni. Creare una breve catena di dipendenze e verificare cosa continua a funzionare quando una connessione fallisce.

Provare le operazioni richieste

Scegliere le azioni che i dipendenti eseguono al lavoro: aprire un documento, registrare una transazione di database, recuperare un report, trasferire un file o utilizzare un dispositivo locale. Misurare il risultato in condizioni normali e con un carico rappresentativo. Concordare una risposta accettabile con il responsabile del processo.

Non promettere qualità basandosi su un singolo test di velocità. Il tempo di risposta dipende anche dall’applicazione, dal database, dal percorso e dal carico del server. Se un’applicazione è strettamente legata all’attrezzatura presente in loco, verificare innanzitutto se il fornitore supporta tale configurazione. Spostare solo un componente può peggiorare le prestazioni dell’intera catena.

Valutare le variazioni del carico e il supporto dell’applicazione

I servizi cloud aiutano ad aggiungere e ridurre le risorse, ma ogni servizio ha dei limiti. Verificare le quote, le configurazioni disponibili, le licenze e come l’applicazione si adatta. L’aggiunta di una singola macchina virtuale non trasforma automaticamente un’applicazione esistente in una distribuita e pronta per la crescita.

Per un carico costante, valutare l’utilizzo delle risorse esistenti e il loro periodo di supporto rimanente. Per i picchi variabili, verificare i costi di espansione e i tempi in entrambe le opzioni. Non presumere un beneficio finanziario semplicemente perché l’espansione nel cloud è tecnicamente possibile.

Se si sceglie una soluzione SaaS, verificare le integrazioni, i metodi di esportazione, i limiti dell’API e il supporto dei dispositivi richiesto, nonché le funzionalità. Se si sceglie un’installazione propria, confermare la compatibilità tra il sistema operativo, il database, le licenze e il metodo di ridondanza. Documentare chi è responsabile degli aggiornamenti e come verrà testata una nuova versione.

Definire le condizioni di guasto e ripristino

Identificare quali operazioni vengono interrotte durante un guasto, i dati persi che l’azienda accetta e il tempo disponibile per il ripristino. Queste condizioni supportano il confronto tra le opzioni. Sviluppare un piano di backup dettagliato e una procedura di test separatamente, ma includere i costi e il responsabile nella decisione.

Garantire l’alta disponibilità, una copia dei dati e un ripristino verificato affrontano compiti diversi. Non considerare i servizi cloud come un backup predefinito o promettere il ripristino automatico di ogni applicazione. Chiarire cosa include il servizio scelto, cosa configura il cliente e come viene verificato il ripristino.

Per un sito locale, verificare l’alimentazione, l’hardware e l’accesso a risorse aggiuntive. Per i servizi cloud, verificare l’architettura scelta, la disponibilità delle dipendenze e i termini contrattuali. Nessuna delle due opzioni diventa resiliente solo per il nome. Un articolo su backup di server e cloud copre le posizioni di archiviazione.

Compilare una matrice per ciascun sistema

Registrare due opzioni specifiche invece di utilizzare termini astratti come “cloud” e “server”. Ad esempio, specificare un livello di servizio e una configurazione, oppure una piattaforma locale con un responsabile della manutenzione. Conservare prove e domande aperte per ogni riga. I punteggi non supportati non sostituiscono i controlli dei vincoli.

Provare un’applicazione che utilizza apparecchiature locali

Se un’applicazione riceve dati da un dispositivo in loco, verificare le interfacce supportate, la latenza e il comportamento in caso di interruzione della connessione. Testare prima l’intera catena, inclusi il database e l’autorizzazione. Una soluzione locale può essere adatta a una forte dipendenza da quell’apparecchiatura, ma non risolve automaticamente la ridondanza o il supporto.

Non escludere un’opzione basata esclusivamente sul nome del settore. Chiedere al fornitore di confermare un’architettura adatta ed eseguire i test richiesti. Senza conferma, registrare la limitazione specifica. Questo è più utile di una affermazione generale secondo cui tutti i dati sensibili devono rimanere in ufficio.

Verificare la collaborazione di un team remoto

Se le persone condividono documenti da diverse posizioni, valutare l’accesso a una versione, i permessi, gli scambi con altri sistemi e il funzionamento in caso di interruzione della connessione. Per SaaS, chiarire quali azioni funzionano offline e cosa accade quando la connessione viene ripristinata. Una copia locale da sola non conferma una corretta collaborazione.

Per un servizio di file locale, testare il metodo di accesso remoto scelto con dimensioni di file realistiche. Per entrambe le opzioni, concordare sulla conservazione e sulla possibilità di recuperare i dati in un formato utilizzabile. Un’interfaccia comoda non elimina questi controlli né dimostra che esiste un backup separato.

Verificare picchi brevi e ambienti temporanei

Se le risorse sono necessarie solo per un periodo limitato, confrontare il tempo di preparazione e il costo del ciclo completo. Nel cloud, verificare la disponibilità della configurazione, i limiti e come terminare le risorse indesiderate. Sul hardware locale, valutare la capacità disponibile, gli effetti sui sistemi principali e i costi di espansione.

Un ambiente di test può utilizzare un set di dati limitato e avere una durata diversa dal sistema principale. Concordare queste condizioni prima di crearlo. Dopo il completamento, verificare che i risultati richiesti rimangano e che i costi inutili siano interrotti. Non applicare i vantaggi di uno scenario temporaneo a un carico di lavoro permanente senza un calcolo separato.

Confrontare le evidenze in un’unica matrice

Se un’opzione viola una condizione obbligatoria, assegnare un controllo o escluderla con una motivazione. Se le informazioni sono mancanti, lasciare la domanda aperta con un responsabile e una scadenza. Non scegliere un’opzione basandosi esclusivamente sul numero di celle completate o sul prezzo più basso visualizzato.

Non è necessario spostare tutti i sistemi nello stesso modo. Alcuni possono rimanere in loco, mentre altri utilizzano servizi cloud. È comunque necessario verificare lo scambio di dati, l’accesso e la responsabilità. La composizione di un ambiente ibrido e l’utilizzo di più fornitori di servizi cloud richiedono un confronto architettonico separato.

Preparare la decisione per la verifica e i cambiamenti

Conservare l’opzione selezionata, le motivazioni, i vincoli e le condizioni di revisione. Prima di apportare una modifica, verificare l’accesso, l’ambito dei dati, le licenze, la prontezza del supporto e la possibilità di tornare a uno stato concordato. Iniziare con un test limitato delle azioni aziendali necessarie, invece di spostare tutto solo per cambiare la sua posizione.

Un piano di migrazione deve definire la sequenza, la finestra di tempo per le modifiche e i responsabili. Questo lavoro segue la decisione sulla posizione. Dopo il lancio, confrontare la risposta effettiva, i costi e lo sforzo di supporto con le assunzioni originali. Aggiornare la decisione se il carico, la versione dell’applicazione o il compito aziendale cambiano.

Il responsabile del sistema conferma che l’opzione esegue il compito aziendale. L’IT conserva i risultati dei test tecnici, mentre la finanza conferma la base di calcolo. Assegnare un responsabile e il prossimo passo per i vincoli rimanenti. La decisione è pronta per l’implementazione quando il team comprende sia la posizione che le sue condizioni operative.

È necessario valutare dove dovrebbero essere eseguiti i sistemi aziendali? Contattare DKs Enterprises per assistenza con infrastrutture cloud e ibride. Preparare un elenco di applicazioni, dipendenze, requisiti di connettività e spese correnti per discutere le opzioni.

Fonti

• Responsabilità condivisa nel cloud
• Creare un modello di costo del carico di lavoro