Quando si introduce un nuovo strumento, linguaggio di programmazione o dipendenza nel proprio ambiente, quali passaggi si eseguono per valutarlo? In questo articolo, illustrerò un quadro di sei domande che utilizzo per prendere queste determinazioni.
Quale problema sto cercando di risolvere?
Siamo tutti coinvolti nelle minuzie del problema immediato a portata di mano. Una valutazione onesta e critica aiuta a divulgare cause profonde più ampie e previene micro-ottimizzazioni.
[ Potrebbe interessarti anche: Sei passaggi di implementazione per i servizi Linux e i relativi strumenti ]
Supponiamo che tu abbia problemi con il tuo sistema di gestione della configurazione. Le attività operative quotidiane richiedono più tempo del dovuto e lavorare con la lingua è difficile. Un nuovo sistema di gestione della configurazione potrebbe alleviare questi problemi, ma assicurati di dare uno sguardo più ampio al contesto di questo sistema. Forse il passaggio da macchine virtuali a contenitori immutabili allevia questi problemi e altro nell'ambiente pur comportando una quantità equivalente di lavoro. A questo punto, dovresti esplorare anche la fattibilità di soluzioni più complete. Potresti decidere che questo non è un progetto fattibile per l'organizzazione in questo momento a causa della mancanza di conoscenze organizzative sui container, ma accettare coscienziosamente questo compromesso ti consente di inserire i container in una tabella di marcia per il prossimo trimestre.
Questo esercizio intellettuale ti aiuta ad approfondire le cause profonde e a risolvere i problemi fondamentali, non i sintomi di problemi più grandi. Questo non sarà sempre possibile, ma sii intenzionale nel prendere questa decisione.
Questo strumento risolve questo problema?
Ora che abbiamo identificato il problema, è tempo di una valutazione critica di noi stessi e dello strumento selezionato.
Una particolare tecnologia potrebbe sembrare interessante perché è nuova perché leggi un interessante post sul blog o vuoi essere tu a tenere un discorso in conferenza. Campanelli e fischietti possono essere utili, ma lo strumento deve risolvere i problemi principali che hai identificato nella prima domanda.
A cosa sto rinunciando?
Lo strumento, infatti, risolverà il problema e sappiamo che stiamo risolvendo il giusto problema, ma quali sono i compromessi?
Queste considerazioni possono essere puramente tecniche. La mancanza di strumenti di osservabilità impedirà un debug efficiente in produzione? La natura closed-source di questo strumento rende più difficile rintracciare bug sottili? La gestione di un'altra dipendenza vale i vantaggi operativi dell'utilizzo di questo strumento?
Inoltre, includi i più ampi contesti organizzativi, aziendali e legali in cui operi.
Stai rinunciando al controllo di un flusso di lavoro aziendale critico a un fornitore di terze parti? Se quel fornitore raddoppia il costo dell'API, è qualcosa che la tua organizzazione può permettersi ed è disposta ad accettare? Ti senti a tuo agio con gli strumenti closed-source che gestiscono una parte sensibile di informazioni proprietarie? La licenza del software rende difficile l'utilizzo commerciale?
Sebbene non siano semplici domande a cui rispondere, dedicare del tempo a valutare questo in anticipo ti farà risparmiare molto dolore in seguito.
Il progetto o il fornitore sono sani?
Questa domanda viene fornita con l'addendum "per l'equilibrio delle tue esigenze". Se hai solo bisogno di uno strumento per portare la tua squadra a superare un salto di quattro -sei mesi fino al Progetto X è completo, questa domanda diventa meno importante. Se si tratta di un impegno pluriennale e lo strumento guida un flusso di lavoro aziendale critico, questa è una preoccupazione.
Durante questo passaggio, utilizzare tutte le risorse disponibili. Se la soluzione è open source, esamina la cronologia dei commit, le mailing list e le discussioni del forum su quel software. La comunità sembra comunicare in modo efficace e lavorare bene insieme, o ci sono ovvie fratture tra i membri della comunità? Se parte di ciò che stai acquistando è un contratto di supporto, utilizza tale supporto durante la fase di prova del concetto. È all'altezza delle tue aspettative? La qualità dell'assistenza vale il costo?
Assicurati di fare un passo oltre le stelle e i fork di GitHub quando valuti anche gli strumenti open source. Qualcosa potrebbe colpire la prima pagina di un aggregatore di notizie e ricevere attenzione per alcuni giorni, ma uno sguardo più approfondito potrebbe rivelare che solo un paio di sviluppatori principali stanno effettivamente lavorando a un progetto e hanno avuto difficoltà a trovare contributi esterni. Forse uno strumento è open source, ma un team finanziato dall'azienda guida lo sviluppo principale e il supporto probabilmente cesserà se l'organizzazione abbandona il progetto. Forse l'API è cambiata ogni sei mesi, causando molto dolore alle persone che hanno adottato versioni precedenti.
Quali sono i rischi?
Come tecnologo, capisci che niente va mai come previsto. Le reti si interrompono, le unità si guastano, i server si riavviano, le righe nel data center perdono energia, intere regioni AWS diventano inaccessibili o i dirottamenti BGP reindirizzano centinaia di terabyte di traffico Internet.
Chiediti come questo strumento potrebbe fallire e quale sarebbe l'impatto. Se stai aggiungendo un prodotto del fornitore di sicurezza alla pipeline CI/CD, cosa succede se il fornitore non funziona?
Ciò solleva considerazioni sia tecniche che commerciali. Le pipeline CI/CD sono semplicemente scadute perché non riescono a raggiungere il fornitore o si verifica un "errore di apertura" e si consente alla pipeline di completare con un avviso? Questo è un problema tecnico, ma in definitiva una decisione aziendale. Sei disposto a passare alla produzione con una modifica che ha ignorato la scansione di sicurezza in questo scenario?
Ovviamente, questo compito diventa più difficile man mano che aumentiamo la complessità del sistema. Per fortuna, siti come k8s.af consolidano scenari di interruzione di esempio. Queste autopsie pubbliche sono molto utili per capire come un software può fallire e come pianificare quello scenario.
Quali sono i costi?
Le considerazioni principali qui sono il tempo dei dipendenti e, se applicabile, il costo del fornitore. Quell'app SaaS è più economica di un numero maggiore di dipendenti? Se risparmi a ogni sviluppatore del team due ore al giorno con quel nuovo strumento CI/CD, si ripagherà da solo nel prossimo anno fiscale?
Certo, non tutto deve essere una proposta di risparmio sui costi. Forse non sarà neutrale in termini di costi se risparmierai al team di sviluppo un paio d'ore al giorno, ma stai rimuovendo un enorme blocco nel loro flusso di lavoro quotidiano e ne sarebbero molto più felici. Quella felicità probabilmente vale il costo finanziario. L'inserimento di nuovi sviluppatori è costoso, quindi non sottovalutare il valore di una maggiore fidelizzazione quando fai questi calcoli.
[ Una guida gratuita di Red Hat:5 passaggi per automatizzare il tuo business. ]
Concludi
Spero che tu abbia trovato questo quadro perspicace e ti incoraggio a incorporarlo nei tuoi processi decisionali. Non esiste una struttura valida per tutti che funzioni per ogni decisione. Non dimenticare che, a volte, potresti aver bisogno di andare con il tuo istinto e dare un giudizio. Tuttavia, avere un processo standardizzato come questo aiuterà a distinguere tra quei momenti in cui puoi analizzare criticamente una decisione e quando devi fare quel salto.