10 Mag Kubernetes e il Grafico della Conoscenza Aziendale

Nelle aziende di oggi, dedichiamo gran parte del nostro tempo a occuparci di informazioni, che si tratti di dati, conoscenza o analisi. Proprio come i lavoratori della catena di montaggio del secolo scorso, i “knowledge worker” di oggi si occupano di una logistica simile che consiste nel prendere le materie prime come input e produrre un prodotto finito come output. Solo in questo caso, la materia prima è tutta l’informazione non organizzata e talvolta casuale a nostra disposizione, e il prodotto finito è un’informazione strutturata. Questa è una bellissima definizione di “lavoratore delle conoscenza”.
Eppure stiamo ancora parlando di una proverbiale linea di produzione operaia.

Pensa alla quantità di tempo che trascorri leggendo e-mail, controllando Slack o seduto alle riunioni remote. Tutto questo riguarda la ricezione di informazioni per adempiere meglio alle tue mansioni lavorative e la condivisione di informazioni per aiutare gli altri a fare lo stesso. La conoscenza all’interno dell’impresa di oggi è spesso una proprietà altamente distribuita: gli individui possiedono una parte della conoscenza collettiva dell’azienda.

In questo articolo, esploreremo la connessione tra conoscenza aziendale e Kubernetes.
Leggendo tra le righe si capiranno i vantaggi economici che che l’adozione di uno strumento di orchestrazione può innescare dentro una “software company”.

Il grafico della conoscenza aziendale

Esploriamo le conoscenze aziendali in termini di “grafico della conoscenza”. Il grafico è costituito da molti nodi collegati in un sistema, con diversi gradi di separazione a seconda del nostro ruolo nell’organizzazione. A un’estremità del grafico, un nodo (persona) comprende molto meno ciò che accade all’estremità del grafico. Le connessioni tra nodi (persone) vengono create in quanto tali nodi richiedono una maggiore collaborazione tra loro. E infine, abbiamo il sistema di base in cui le informazioni scorrono all’interno di un’organizzazione.

Supponiamo che tu sia uno sviluppatore responsabile di un’API. Sai molto sul design dell’API. Tuttavia, devi interagire con un database, quindi lavori con un team DBA. È inoltre necessario sapere come verrà eseguita questa API in produzione, quindi dovrai consultare un team DevOps. Infine, ciò richiederà servizi di rete, quindi dovrai chiedere a un altro team come dirottare il traffico verso l’API. In questo esempio, quattro “nodi” stanno interagendo e scambiando conoscenza. E perché hai bisogno di così tante informazioni? Bene, spesso è perché dobbiamo prendere decisioni nel software che ci richiedono di considerare le interazioni della modifica con molti componenti del sistema.

Come sviluppatore di API, probabilmente riceverai le informazioni di cui hai bisogno attraverso Slack, meeting e wiki. E se potessi costruire la tua API in modo da dover fornire solo le informazioni di cui sei responsabile? Altri team gestiranno le preoccupazioni degli altri sistemi che supportano la tua API in modo indipendente e senza coordinamento umano. Questa è la visione dietro Kubernetes.

Kubernetes e l’Organizzazione della conoscenza

Kubernetes è stato progettato da ingegneri che si occupavano di grafici delle conoscenze organizzative su vasta scala. Considera che Google ha quasi 100.000 dipendenti, che devono coordinarsi tra loro. L’efficienza è migliorata attraverso un sistema che interseca il grafico della conoscenza in modo tale che ciascun “nodo” possa operare nell’ambito delle proprie competenze senza dover comprendere i dettagli del sistema maggiore. Consentire agli ingegneri di concentrarsi sulla propria competenza principale e non spendere la propria energia per apprendere l’esperienza di qualcun altro rafforza il loro contributo unico all’organizzazione. Sei sei curioso, leggi il documento Gestione dei cluster su larga scala presso Google con Borg.

Amazon.com e scambio di conoscenze

Dobbiamo riconoscere che questo modello esisteva anche su Amazon.com dall’inizio. Nel 2002, Jeff Bezos ha pubblicato un memo interno che alcuni chiamano “The API Mandate” (leggetelo alcuni passaggi sono divertenti). Alcuni dei suoi punti chiave sono:

1. D’ora in poi tutti i team esporranno i loro dati e funzionalità attraverso le interfacce di servizio (API).
2. I team devono comunicare tra loro attraverso queste interfacce.
3. Non ci sarà altra forma di comunicazione tra processi consentita: nessun collegamento diretto, nessuna lettura diretta dell’archivio dati di un altro team, nessun modello di memoria condivisa, nessuna backdoor. L’unica comunicazione consentita è tramite le chiamate dell’interfaccia di servizio sulla rete.

Con la crescita veloce di Amazon.com, l’azienda si stava proteggendo dal crollare sotto il peso del grafico della conoscenza. In Amazon.com mettono in atto modelli e interfacce che chiariscono dove e come le persone possono scambiare informazioni. Kubernetes porta questo modello ad un livello successivo indirizzando i sistemi oltre il livello API.

PodDisruptionBudget object (PDB) in Kubernetes

Diamo un’occhiata al PodDisruptionBudget , un costrutto in Kubernetes che consente ai team che gestiscono l’infrastruttura o il data center di calcolare l’impatto delle attività di manutenzione sulle applicazioni che supportano. Tradizionalmente, la rimozione di server da un cluster richiede un attento coordinamento con i team delle applicazioni per capire come vengono distribuite le applicazioni, come gestiscono i guasti, il livello di ridondanza che hanno, ecc. Questo processo potrebbe richiedere facilmente una settimana o due di riunioni, e-mail e discussioni prima di eseguire tale compito. Con un PodDisruptionBudget (PDB), i team delle applicazioni possono articolare le tolleranze della loro applicazione nel codice e i team dell’infrastruttura possono utilizzare l’API Kubernetes per rimuovere un nodo assicurando che ciò non violi le tolleranze delle applicazioni in esecuzione su quel nodo . Tutto ciò richiede zero coordinamento umano.
Si deve notare che Kubernetes diveniene quindi il filo continuo che interseca le diverse parti del grafico della conoscenza. Kubernetes diventa un condotto asincrono del flusso di informazioni.

Ampia il potenziale di Kubernetes

Ogni impresa oggi ha la scelta di abbracciare questo modo di pensare. Gliporterà vantaggi immediati. Ma cambiare il mindset non è subito semplice;è del tutto possibile usare Kubernetes in un modo in cui richiede un sacco di coordinamento umano e non ci si rende conto dei suoi benefici. Non confondete le funzionalità di Kubernetes con un biglietto gratuito per ripensare il processo di ingegneria del software.
La realtà è che molte aziende potrebbero non realizzare mai il potenziale di Kubernetes semplicemente per il modo in cui lo usano. L’uso ottimale di Kubernetes avvantaggia l’organizzazione riducendo l’attrito e l’interdipendenza di tutte le parti. Man mano che un’azienda si ridimensiona e aggiunge più team, può comunque mantenere l’efficienza poiché i team possono coordinarsi attraverso il framework strutturato della piattaforma.

Fortunatamente, ci sono molte risorse disponibili per le aziende che vogliono adottare un approccio diverso all’ingegneria del software e utilizzare pienamente i principi di progettazione cloud-native. In questo OneClickApp vi può guidare nel percorso.

Migliora il tuo grafico della conoscenza con Kubernetes

Quindi, cosa puoi fare per rendere il tuo grafico delle conoscenze più efficiente? Inizia osservando i flussi di lavoro con traffico elevato nella tua organizzazione di ingegnerizzazione del software. Ad esempio, se uno sviluppatore desidera creare una nuova API, quali attività devono svolgere? Come allocano elaborazione, archiviazione e networking per svilupparlo? Come lo faranno una volta che entrerà in una ambiente di produzione? Chi sono tutte le persone e i team con cui uno sviluppatore dovrebbe interagire per svolgere tali compiti? Una di queste attività può essere gestita in modo self-service o asincrono? Possono creare un’API interna per gestire una di queste attività?

Da dove iniziare

Inizia con una sessione su una semplice lavagna, assolda i membri chiave del team e discuti del modo in cui lavorano l’uno con l’altro. Abbinalo a una comprensione olistica delle funzionalità e delle API di Kubernetes in modo da trovare modi creativi per applicare Kubernetes a questiproblema. La documentazione di Kubernentes è un ottimo punto di partenza.
Discuti  le tue idee per l’implementazione di Kuberenetes con i tuoi collegi dei teams esterni è sempre utile. Trascorrere del tempo con gli altri utenti utenti e ingegneri che come te stanno scoprendo modi nuovi e più utili per applicare la progettazione cloud-native ai loro ambienti.

E, soprattutto, ricorda che è un viaggio. Fai un passo alla volta e divertiti a risolvere i problemi lungo la strada.

Abbiamo due libri da segnalarti per comprendere che i metodi cloud-native vengono prima dell’adozione dei tools: