Il pendolo DevOps: agilità vs. Controllo
Di: Cindy Blake il 2 agosto 2023
Gestire le modifiche alle risorse cloud è oggi un problema universale sentito da molti leader tecnici, nonostante tutti i progressi negli strumenti e nelle pratiche come GitOps. Questo perché, in realtà, è semplicemente impossibile tenere tutto sempre completamente bloccato: non viviamo in un'utopia con zero incidenti. Se la tua organizzazione tecnica impedisce che vengano apportate modifiche tramite la console cloud o alla tua infrastruttura come codice (IaC) senza rispettare le rigide pratiche GitOps o i processi di gestione delle modifiche tramite CI/CD, è probabile che tu abbia degli sviluppatori molto frustrati che non possono risolvere problemi o eseguire il debug in tempo reale e che hanno poco controllo in un incidente del mondo reale.
L'ingegneria, come ogni altra cosa nella vita, è tutta una questione di equilibrio.
La pandemia ha creato una mentalità e una pratica completamente nuove per la gestione dell’ingegneria e delle operazioni distribuite e ad alta velocità. Da un giorno all'altro, le aziende che non erano state create per modalità di lavoro a distanza hanno dovuto continuare le loro operazioni in un modo globale, distribuito e asincrono con cui non avevano completamente familiarità. Ciò ha richiesto un nuovo modo di pensare alla distribuzione del software e ha accelerato le pratiche DevOps che supportano tale distribuzione. L'infrastruttura self-service ha rimosso gli ostacoli per gli sviluppatori per garantire prestazioni e velocità continue.
Allo stesso tempo, il tuo cloud non può essere il selvaggio west in cui tutti creano infrastrutture su misura. Diventa impossibile da gestire e le configurazioni errate possono essere rischiose. I guardrail e l’automazione delle politiche sono diventati un tema caldo. Oggi, con i mercati tecnologici depressi e i costi del cloud in aumento, sembra esserci una tendenza crescente a bloccare nuovamente le cose, anche a rischio di frustrare gli sviluppatori.
Ciò fa sorgere la domanda: come puoi ottenere un'infrastruttura libera per i tuoi sviluppatori seguendo allo stesso tempo le policy e le migliori pratiche per conformità, rischio e costi? C'è un modo per trovare l'equilibrio.
Come per molti altri aspetti della sicurezza, abbiamo imparato che quando i vincoli e le barriere sono troppo elevati, gli utenti alla fine trovano il modo di aggirarli. Questo vale anche per le operazioni. Anche se a volte potrebbe sembrare più semplice bloccare tutto piuttosto che progettare un modo migliore e più equilibrato per consentire agli sviluppatori di muoversi velocemente, alla fine questo approccio fallisce. Si tratta della stessa identica evoluzione che sta attraversando attualmente il settore delle applicazioni e della sicurezza nativa del cloud. Tutti i guardrail e i controlli applicati hanno creato troppi attriti nei processi di sviluppo e gli sviluppatori alla fine li aggirano.
CloudOps può imparare molto dallo sconvolgimento che sta attraversando oggi il settore della sicurezza. Allo stesso modo in cui la sicurezza puntuale è stata resa completamente inutile, gli avvisi non in tempo reale o eventuali avvisi sulla deriva dell'infrastruttura non saranno sufficienti quando si gestisce un cloud effimero. Ciò che è veramente necessario è lo stesso tipo di scansione continua e in tempo reale delle risorse cloud e dell’IaC, simile a quella che applichiamo ai nostri sistemi attraverso il monitoraggio e l’osservabilità. Queste soluzioni sono diventate una spina dorsale essenziale della nostra attività per garantire operazioni continue e disponibilità dei servizi cloud.
Abbracciando IaC e i vantaggi che offre, Everything-as-code sblocca maggiore agilità e visibilità, consentendoti di correggere automaticamente senza bloccare tutto. Come dice DevOps, “fail forward e fail fast”. Invece di concentrarti sul non commettere mai errori, concentrati su come risolverlo immediatamente.
Fornendo un confronto continuo delle risorse cloud effettive con il loro stato desiderato tramite IaC e GitOps, è possibile evidenziare immediatamente deviazioni della configurazione e violazioni delle policy, proprio come qualsiasi altro tipo di violazione o grave errore di sistema. I fallimenti e gli incidenti sono inevitabili. Non è realistico, e perfino pericoloso, costruire sistemi con una progettazione sottostante intrinseca che ti impedisca di modificare qualcosa sulla console cloud alle 2:00 del mattino durante un'interruzione.