Architettura dei dati e Teorema CAP Dove si scontrano?

Architettura dati e Teorema CAP scontro?

Nota dell’editore: Joep Kokkeler è un relatore per ODSC West questo autunno. Assicurati di dare un’occhiata al suo intervento, “Catturare CAP in un’architettura dei dati Kappa”, lì!

Prima di approfondire i diversi tipi di architettura dei dati, concentriamoci prima sul teorema CAP. Il teorema CAP afferma che in qualsiasi sistema (escludendo le transazioni acid per ora) è possibile avere due delle seguenti tre caratteristiche, ma mai tutte e tre: coerenza, disponibilità e tolleranza. Per gestire ciò, è possibile fare la scelta giusta quando si sceglie un tipo di architettura.

Quando si parla di architettura, le persone assumono sempre di sapere cosa si intende per ciascun tipo di architettura. Ma cosa succede se non lo sai? Diciamo che conosci l’implementazione tecnica dell’architettura lambda ma non sai cosa significa rispetto ad altre implementazioni.

Permettimi di spiegare usando un’analogia semplice.

Tutti sono stati almeno una volta in un giardino zoologico. Ci sono molti animali diversi e sono necessarie molte competenze diverse per prendersi cura di questi animali da parte dei custodi. Quindi devi avere la conoscenza giusta per gestire un giardino zoologico o assumi persone che sappiano come prendersi cura in modo che tu possa goderti il tuo giardino zoologico. Con la scelta dell’architettura, è quasi la stessa cosa, poiché non è necessario conoscere tutto su ogni implementazione, ma è necessario sapere con cosa si ha a che fare.

Monolite

Cominciamo con l’architettura monolite, come suggerisce il nome, è grande, è vecchia, occupa molto spazio ed è probabilmente un elefante. In particolare, un elefante africano della savana, il più grande elefante in giro. E c’è un vecchio nel tuo gruppo che sa come prendersi cura di esso, sa quali pulsanti può premere e da quali stare lontano. Uno degli stagisti ha provato a lavorare con la grande bestia ma dopo aver spento molti incendi alle sue spalle, è meglio che l’uomo nato nello stesso periodo in cui è stato coniato il termine architettura si prenda cura del monolite.

Microservizio

Il successivo sarebbe il microservizio. In un’architettura a microservizi, è importante creare servizi che abbiano ognuno le proprie responsabilità. A volte queste responsabilità si sovrappongono e prima che tu te ne accorga, stai gestendo un mini monolite. E cercare di guidare un giovane elefante grigio verso dove vuoi che vada richiede un set di competenze completamente diverso rispetto all’esecuzione di microservizi. Il mio miglior paragone per i microservizi è un branco di lupi. Quando sono nella natura, un branco si muove in linea retta (per risparmiare energia) con tutti nella giusta posizione all’interno del branco. E ogni posizione nel branco ha determinate responsabilità.

C’è un’immagine che circola su internet in cui si vede un branco nella natura nella neve e la didascalia dice che i lupi davanti sono malati o vecchi, quindi bisogna fare attenzione affinché non rimangano indietro o vengano usati come “ammortizzatore” in caso di attacco. Tenendo presente che muoversi sulla neve costa molta energia, non ha senso avere un lupo già indebolito davanti. Stessa cosa con i tuoi microservizi: il primo servizio potrebbe essere un po’ sovraccarico ma fa il grosso del lavoro per gli altri. L’architettura lambda è nota per la sua dimensione di componente ridotta e perché ne vuoi sempre di più.

Quindi è più paragonabile a un gruppo di suricati. Un gruppo di suricati si chiama “mob”, che mi piace molto di più. Invece di dire che gestisci più gruppi di lambda, hai un certo numero di “mob” sotto la tua ala. La cosa con i suricati e con le lambda è che devi rendere la responsabilità il più piccola possibile, altrimenti il suricato la lascerebbe com’è. In passato, al suricato ci volevano alcuni minuti per fare effettivamente ciò che volevi che facesse, ma abbiamo risolto il problema nutrendolo con cose da fare in modo che non si fermi mai. Questo rende facile per il suricato fare il suo lavoro e assicurarsi di passare i risultati del lavoro al prossimo suricato, e avrai molti “mob” sotto il tuo controllo che fanno ciò che vuoi che facciano.

Kappa

Ultimo ma non meno importante, l’architettura kappa. Immagina un pinguino grasso, uno di quei ragazzi di “Madagascar”. I pinguini hanno sempre bisogno di muoversi in gruppo, quindi all’interno della tua architettura kappa, ci sono molti gruppi di pinguini che sorridono e salutano. Ma in realtà vogliamo che la nostra architettura sia molto veloce e intelligente. Quindi immagina lo stesso pinguino ma ora con un razzo attaccato alla schiena. Questa è la base della nostra architettura kappa. Molti pinguini con molti razzi attaccati a loro. Si prega di notare che non è necessario essere un esperto di razzi per lavorare su un’architettura kappa.

Conclusion

Ora abbiamo una visione di che tipo di creature stiamo osservando, come possiamo implementare una di queste architetture per avere tutti e tre i componenti del Teorema CAP? Per sapere quale è la migliore creatura (o un pinguino con un razzo) per il teorema CAP, venite a trovarmi a ODSC West a San Francisco per una spiegazione più dettagliata di questo problema e per vedere una demo dal vivo sulle diverse implementazioni.

Riguardo all’autore:

Joep Kokkeler ha più di 12 anni di esperienza nello sviluppo, nell’ingegneria, nell’architettura e nella visualizzazione di prodotti dati in vari settori, dalla produzione di energia alla produzione di abbigliamento. Si concentra sull’abilitazione dei team nel gestire meglio i dati e nel fornire loro gli strumenti e le conoscenze necessarie per andare in produzione e rimanere in produzione.

È stato membro del comitato del programma Teqnation, ha fatto una presentazione sull’utilizzo di Kafka e Hue durante il calcio, lo sviluppo e il rilascio su Hololens, Total Devops usando Gitlab, l’evoluzione di un prodotto di data science, l’utilizzo dello stack elastico dal PoC alla produzione, Xbox Kinect su una bicicletta a Devoxx London.