Il nuovo modo di gestire i database open source

Non molto tempo fa, l'industria dei database era composta da una manciata di fornitori. I database erano principalmente relazionali e funzionavano su singole macchine. L'elevata disponibilità è stata implementata tramite "cluster" di standby attivo. Con un modello "scale-up" verticale, si trattava principalmente di archiviazione condivisa (SAN o DRBD) o replica asincrona dei log per sincronizzare lo stato con un nodo di standby. Nel 2001, quando ho iniziato a lavorare con NDB Cluster (quello che sarebbe poi diventato MySQL Cluster), il concetto di tenere un intero database nella memoria principale era strano:"e se spegnessi il server?". La distribuzione di un database su più server era preoccupante:"hai pezzi di dati qua e là". E l'idea di un database open source per carichi di lavoro mission-critical era ridicola.

Avanti veloce di 15 anni e ora abbiamo dozzine di fornitori di database sul mercato - per lo più open source, diversi modelli (valore chiave, documento, grafico, ...) e distribuiti per impostazione predefinita. I dati residenti in memoria sono praticamente la norma per ottenere prestazioni elevate e bassa latenza. Tre dei primi 5 database più popolari (secondo la classifica di db-engines) sono open source (MySQL, PostgreSQL e MongoDB). Al giorno d'oggi, è più probabile che tu gestisca una flotta di server di database distribuiti su diversi data center. Potresti anche avere alcuni dei tuoi database gestiti da un fornitore di servizi cloud di terze parti.

Allora, com'è gestire i database nel 2018?

AUTOMAZIONE

Con così tante attività da gestire e solo così tante ore in un giorno, uno sarebbe pazzo a fare le cose manualmente.

L'automazione è un ottimo modo per fare le cose. Quando avevamo pochi database da gestire, il funzionamento del database sarebbe stato molto pratico, con alcune attività scritte in script in qualcosa come bash o perl, ad esempio uno script per il backup del database, un altro per spostare i file di backup in una posizione. Il failover sarebbe manuale e staremmo persino discutendo se debba essere automatizzato o meno.

Al giorno d'oggi, l'automazione è un gioco da ragazzi. Esistono numerosi sistemi di automazione IT o di gestione della configurazione che possono essere sfruttati:Puppet, Chef, Ansible e Salt offrono tutti framework generici che possono essere utilizzati per creare l'automazione per diverse topologie di database. Il software di gestione del cluster scritto specificamente per gestire le impostazioni del database include MongoDB Ops Manager e ClusterControl. Consentono ai team operativi di gestire i loro cluster con qualcosa che è prontamente disponibile. Costruire un sistema di gestione del cluster da zero utilizzando un sistema di gestione della configurazione non è un'impresa da poco. Richiede una notevole esperienza nello strumento di automazione, nonché la comprensione delle operazioni di gestione come la pianificazione e la verifica del backup, il failover automatico con successiva riconfigurazione dei sistemi, l'implementazione di modifiche alla configurazione, l'applicazione di patch, l'aggiornamento o il downgrade della versione, ecc.

E, naturalmente, c'è l'ascesa delle piattaforme di servizi DBaaS, in cui distribuzione, integrità, failover, backup e così via sono tutti controllati dal software. I fornitori di cloud sono davvero molto bravi nell'automazione. Amazon RDS è un ottimo esempio di automazione del database su larga scala:automatizza la distribuzione, gli aggiornamenti delle patch, i backup, il ripristino point-in-time, il ridimensionamento delle repliche e l'elevata disponibilità/failover.

ANIMALI vs BOVINI

Negli anni '90 e fino al boom e al crollo delle dotcom, Sun Microsystems e Oracle hanno fatto fortuna vendendo database scalabili su hardware SMTP di grandi dimensioni. Aggiungi un po' di storage SAN e software di failover Veritas e ti avresti ottenuto un cluster di failover active-standby all'avanguardia per un'elevata disponibilità. I server di database erano relativamente pochi in numero, ma potenti poiché crescevano verticalmente. Sono stati dati loro dei nomi (proprio come chiami i tuoi animali domestici!) e sono stati seguiti dai DBA.

Al giorno d'oggi, i database sono economici e funzionano bene su hardware di base. Ce ne sono molti e diamo loro dei numeri, proprio come i bovini. Se uno si rompe, possiamo semplicemente prenderne uno nuovo.

È anche una nuova razza di bovini:bovini open source! Tre dei primi cinque database, secondo db-engines, sono tutti open source:stanno lentamente ma inesorabilmente mangiando la quota di mercato dei due fornitori proprietari. L'open source è il nuovo standard per i datacenter, non solo per il sistema operativo ma anche per i database.

Quindi cosa significa questo per te? Ebbene, in futuro è più probabile che tu gestisca un database open source, o anche più database per applicazioni che utilizzano raccolte di dati eterogenee. In un mondo di persistenza poliglotta e microservizi, il datastore sottostante è ora dettato dalla natura dei dati. Dal punto di vista dell'architettura, i database a istanza singola con HA basato su disco stanno lasciando il posto a cluster potenzialmente distribuiti su più data center.

Abbiamo bisogno di un DBA?

Il ruolo di DBA è specializzato:ci vogliono anni di esperienza per diventarlo. In passato, quando c'erano solo un paio di fornitori di database proprietari tra cui scegliere, avresti DBA specializzati con un insieme specifico di abilità ed esperienza. Era anche necessario:i database come Oracle o SQL Server hanno enormi set di funzionalità, costruiti nel corso di decenni. Non sono facili da gestire. In genere venivano distribuiti come unico database per un'applicazione e dovevano essere monitorati, eseguito il backup dei dati e tutti i problemi che si presentavano dovevano essere affrontati. Queste attività erano esattamente ciò su cui i DBA si sarebbero concentrati.

Nell'ultimo decennio, tuttavia, è emersa un'industria di database completamente nuova, con dozzine e dozzine di database open source e servizi di database cloud. Come abbiamo visto in precedenza, non è raro che un'applicazione utilizzi un paio di diversi datastore. Ma le aziende raramente hanno un DBA per questi datastore che usano. Dove trovi un DBA MongoDB o Cassandra o con oltre 5 anni di esperienza nella produzione? Si può obiettare che la nuova generazione di database NoSQL è molto più semplice dei loro predecessori closed source e quindi non incorrerebbe nella stessa curva di apprendimento.

La loro gestione sarebbe solo un'altra attività aggiunta all'elenco delle cose da fare del team SysAdmin o DevOps o Site Reliability Engineering (SRE). E vediamo oggi che molte aziende non hanno DBA a tempo pieno. La responsabilità è invece distribuita tra i team, con strumenti di automazione sempre più utilizzati per occuparsi delle attività quotidiane di routine. Per i database che sono passati al cloud, gli aspetti operativi di come vengono archiviati i dati sono interamente esternalizzati al provider cloud. Quindi, invece di lavorare su come archiviare i dati, il team operativo può ora concentrarsi sull'uso dei dati.

Ciclo di vita del database

Il ciclo di vita medio di un database era molto più lungo di quello che è oggi. Una volta che hai scelto una piattaforma di database, il gioco è fatto. La decisione verrebbe presa tra due o tre database relazionali, di solito dal DBA o da qualcuno più in alto nell'organizzazione. La società troverebbe i soldi per acquistare licenze perpetue. Una volta presa la decisione, ora dovevi conviverci per i prossimi 10+ anni. I database erano monolitici e le applicazioni in genere utilizzavano un unico database condiviso.

Oggi, in un mondo di container, cloud, microservizi e pipeline CI/CD, non è raro che gli sviluppatori facciano le scelte tecnologiche, soprattutto se si tratta di un database open source che può essere facilmente scaricato o offerto come servizio, senza dover parlare con un rappresentante di vendita o dover cercare budget dalla direzione. Le organizzazioni sono sfidate a creare valore più velocemente, quindi il tasso di cambiamento dell'infrastruttura/delle applicazioni è aumentato notevolmente. I database monolitici sono ora suddivisi in più database di piccole dimensioni, con ogni database che gestisce i dati di dominio per un singolo microservizio. Con la varietà di prodotti di database oggi disponibili nell'ecosistema open source, i team hanno la scelta e la libertà di passare a un datastore migliore. Man mano che i servizi vengono commissionati e dismessi, seguono anche i database, sebbene i dati stessi possano essere archiviati o spostati in un data lake. In un panorama infrastrutturale oggi molto più dinamico, scopriamo che i nostri database vivono una vita più breve.

RUOLO DBA

Il DBA, tradizionalmente sia tutore che custode del database, soddisferebbe le esigenze del database di diversi team di applicazioni/infrastruttura nell'organizzazione. Eventuali modifiche che richiedessero l'accesso o modifiche al database richiederebbero i servizi del DBA. Tuttavia, priorità contrastanti e mancanza di disponibilità del DBA potrebbero significare che il progetto sarebbe bloccato/ritardato e seguirebbero inevitabili attriti.

L'alto costo della collaborazione e l'innovazione rapida/il breve time-to-market non vanno d'accordo. Come abbiamo visto in precedenza, i microservizi sono un esempio di come l'infrastruttura e i servizi applicativi sono ora progettati in modo da disaccoppiare il più possibile. I database vengono sempre più automatizzati e il controllo del database si sta spostando sugli sviluppatori o sui team di progetto. Anche cose come le modifiche allo schema non sono così pesanti come una volta. Erano molto più difficili nel contesto di un database centrale per un'applicazione monolitica. Con i dati condivisi tra diversi componenti, le modifiche allo schema dovrebbero essere coordinate e pianificate con attenzione, in genere con mesi di anticipo. I DBA hanno avuto un ruolo chiave nella comprensione e nell'esecuzione dei cambiamenti. Le dinamiche sono diverse oggi, dove il tasso di cambiamento è molto più veloce. Non è raro che i team di sviluppo spingano le modifiche al codice in produzione su base settimanale o giornaliera, o anche più volte al giorno! I database necessitano di aggiornamenti costanti per stare al passo con le modifiche alle applicazioni e questi vengono eseguiti dagli sviluppatori. Alcuni dei database più recenti come MongoDB lo rendono anche molto semplice avendo un modello senza schema. Ciò che effettivamente significa è che lo schema del database si sta spostando nel codice dell'applicazione.

Quindi, se tutte le attività principali comuni vengono automatizzate, cosa accadrà al ruolo DBA in futuro? Invece di concentrarsi sulle attività amministrative, il DBA fungerà più da mentore per gli altri team dell'organizzazione. Le organizzazioni devono capire quali dati hanno e come utilizzarli. Dopotutto, i dati sono più preziosi se condivisi e combinati con altre risorse, non solo archiviati. Schemaless suona alla grande, ma dobbiamo comunque tenere traccia dei nostri dati, nel database o nel codice. La sicurezza è una sfida e le violazioni dei dati continuano a peggiorare. Quindi, se vogliamo rendere nuovamente eccezionali i dati, il DBA deve passare a un ruolo di consulente/abilitatore orizzontale che si estende a tutti i team. Dal punto di vista delle competenze, il moderno DBA deve comprendere come progettare sistemi distribuiti ad alta disponibilità e mettere in atto sistemi di automazione efficienti per svolgere le attività ordinarie. Man mano che le aziende implementano l'infrastruttura in ambienti cloud o persino container, capire come creare database altamente disponibili e scalabili su queste piattaforme garantirà la sopravvivenza del DBA.

Riepilogo

Siamo seduti a un affascinante incrocio nella storia dell'industria dei database, che ha subito una massiccia trasformazione negli ultimi 2 decenni. La tabella seguente cerca di riassumerlo.

Sarei interessato a conoscere i tuoi pensieri sulla gestione dei database open source e se hai visto le stesse tendenze? Come sono state le tue lotte o i tuoi successi con gli OSDB negli ultimi anni? E cosa prevedi che accadrà il prossimo anno?

Noi di Multiplenines continueremo ovviamente a lavorare per facilitare la gestione e l'automazione dei tuoi database open source fino al prossimo anno e oltre. Quindi resta sintonizzato per gli aggiornamenti a partire dal prossimo gennaio.

Ma nel frattempo fatemi sapere cosa ne pensate e ci vediamo nel 2019!

Foto di SoRad (Shutterstock) e I Simpson; le altre foto sono dei rispettivi proprietari.