Dopo la crescita di una startup, conviene riportare l'infrastruttura dal cloud a sistemi gestiti direttamente? Nel confronto con InMarvinWeTrust, Marvin risponde senza una regola universale: dipende da come è costruito il servizio e da ciò che comporterebbe cambiarlo.
La discussione collega convenienza, dipendenze tecniche e continuità operativa. Il confronto corretto non è soltanto tra una fattura mensile e il prezzo di un server.
Quanto il progetto dipende dal fornitore
Marvin richiama API, automazioni e servizi specifici del cloud. Possono offrire vantaggi durante la crescita, ma rendere più impegnativo un passaggio ad altri ambienti.
È una forma di dipendenza da considerare nel progetto: non basta spostare i dati se l'applicazione usa funzioni che vanno sostituite o ripensate. La difficoltà della migrazione dipende dall'architettura, non soltanto dalla dimensione dell'azienda.
Il periodo di transizione ha un costo
Per riportare alcuni servizi su un'infrastruttura propria occorre predisporre risorse prima di completare il trasferimento. Per un periodo possono quindi coesistere costi del cloud e costi del nuovo ambiente.
Nella conversazione Marvin cita il repatriation, cioè il ritorno di carichi dal cloud a un'infrastruttura gestita più direttamente. Può riguardare sia aziende che avevano già sistemi interni sia realtà nate utilizzando servizi cloud.
Che questi percorsi esistano non dimostra che siano convenienti per chiunque. Servono una valutazione del lavoro necessario e un confronto sul periodo rilevante per il progetto.
Dalla convenienza alla continuità del servizio
Una domanda del pubblico introduce cluster, ridondanza e macchine virtuali. Marvin racconta la propria esperienza con strumenti come Heartbeat, Corosync e Keepalived, sottolineando la maturità di tecnologie usate per la disponibilità dei servizi.
Questi nomi non identificano però componenti tutti intercambiabili. Una configurazione deve essere progettata e verificata rispetto al guasto che si vuole gestire. Il giudizio positivo dell'ospite non equivale alla garanzia che qualsiasi combinazione funzioni senza interruzioni.
Proxmox come esempio di integrazione
Marvin cita il lungo utilizzo personale di Proxmox e il modo in cui una piattaforma può rendere gestibili più tecnologie attraverso un'interfaccia comune.
Proxmox VE integra virtualizzazione basata su KVM, container LXC e strumenti di gestione dell'infrastruttura. È quindi impreciso presentarlo come concorrente di KVM, che ne costituisce una tecnologia di base. Caratteristiche ufficiali di Proxmox VE.
La possibilità di predisporre alta disponibilità è una funzione da progettare, non un risultato automatico dell'installazione. Rimangono importanti anche conservazione dei dati e prove di ripristino.
Il ruolo del sistemista attraversa più ambienti
La conversazione si allarga a desktop, server, sistemi embedded e dispositivi con compiti specifici. Un'infrastruttura può combinare ambienti differenti, ciascuno con requisiti propri.
Marvin considera sempre meno sufficiente definirsi esclusivamente legati a una piattaforma, almeno nel tipo di lavoro che racconta. Servono capacità di adattamento e comprensione delle relazioni tra i sistemi.
Per rispondere alla domanda iniziale bisogna quindi descrivere carichi, dipendenze, responsabilità e transizione. Solo dopo quel lavoro il confronto economico tra cloud e infrastruttura interna diventa significativo.
