25 Apr 2021
Stavo pensando di buttare giù un post qualsiasi tanto per ricominciare a scrivere dato che mi lamento di non avere mai tempo, e ho pensato che non vi ho mai palesato un paio di fatti: il primo è che AllaCarta da qualche tempo gira completamente su Kubernetes, il secondo è che, per dirlo con poche parole, io adoro Kubernetes in ogni sua distribuzione e forma.
Come mai? Innanzi tutto va detto che io sono mortalmente affascinato, come i miei lettori di lunga data sanno, dalle opinioni coraggiose, e “Unironically Using Kubernetes for my Personal Blog” è una delle mie preferite. Dopodiché, devo dire che due sono le cose che mi hanno fatto avvicinare a questa tecnologia che volevo apprendere da tempo: il fatto che un formidabile individuo mi abbia convinto a mandare un po’ di commit al progetto k3ai, e il fatto di aver capito che Kubernetes stesse veramente “mangiando il mondo”. Così mi sono spinto un po’ più in là, ho cominciato a studiare e per acquisire un po’ di conoscenza pratica in qualche settimana ho portato AllaCarta da un paio di macchine deployate tramite Ansible a un cluster full-fledged Kubernetes.
Devo dire che a parte lo scollinamento iniziale, è stato abbastanza semplice. Nel farlo ho scoperto persino un po’ di cose su cui da fuori è molto facile soprassedere.
Si fa presto a dire Kubernetes
Innanzi tutto Kubernetes non è “Kubernetes”, ma esattamente come Linux vuol dire tutto e niente esistono svariate distribuzioni di Kubernetes che lo rendono un bundle utilizzabile e uno strumento meno grezzo del core che siamo stati abituati a concepire nei primi anni di vita di questo adorabile orchestrator di quartiere.
Tra le distribuzioni che possiamo vedere più spesso in giro possiamo trovare K3s, MicroK8s, minikube, Rancher Kubernetes Engine. Fanno tutte un po’ la stessa cosa, semplicemente esattamente come le distribuzioni di Linux alcune sono più adatte ad alcuni use case di altre: il mio amico Carmine per esempio sta mettendo in piedi una guida abbastanza esaustiva su come deployare il proprio cluster RKE su delle VPS Hetzner, io invece sono un appassionato di K3s perché è facile come uno schiocco di dita metterci su dei begli ambienti di continuous integration per le proprie applicazioni.
Letto il titolo qui sopra? Molto bene: come tale, Kubernetes è piuttosto flessibile rispetto a quello che ci installiamo sopra, e non intendo solo i classici deployment di applicazioni, che sono la cosa più comune: è possibile estendere le funzionalità del proprio cluster Kubernetes attraverso l’uso di particolari “operator” (oltre che tramite le Custom Resource Definition), ovvero delle estensioni software che provvedono a smazzare il grosso del lavoro per noi quando si presentano tematiche un po’ più complesse e soprattutto generalizzate/generalizzabili, come il provisioning di un cluster PostgreSQL a bordo della nostra infrastruttura.
È molto bene di solito sapere che cosa avviene sotto il cofano di un operatore perché non conoscere profondamente il suo funzionamento può portarci a credere che stia avvenendo qualcosa sulla nostra infrastruttura di produzione che è assolutamente lontano da quello che in realtà sta succedendo, tuttavia penso che ci sia ancora tantissimo terreno inesplorato in tema di Kubernetes operator, che siano molto utili banalmente perché semplificano tanto lavoro, ma che siano un’astrazione da usare solo dopo aver compreso le basi.
Alcuni operatori sono una bomba allucinante, quasi talmente tanto che non è possibile concepire un cluster senza questi installati. Alcuni esempi? Datadog per il monitoraggio, Argo CD per la continuous delivery (attraverso GitOps). Questo ovviamente rischia di rendere la curva di apprendimento dell’ecosistema Kubernetes estremamente ripida, e rischia anche di creare una frammentazione allucinante nell’ecosistema dato che a questo punto non esiste un cluster che sia uguale a un altro. Ma la flessibilità e la potenza portano con loro questi lati negativi, quindi sapete che c’è? Non lamentatevi.
Non sprecate tempo né fiato nel farlo.
Se pensate che sia “troppo”, guess what: l’informatica è un lavoro più duro di quanto credevate. Potete mettervi a studiare o andare a fare i crimpatori di cavi dentro qualche data center - sempre ammesso che lo sappiate fare: crimpare un cavo per bene è un’operazione da osservare con cura.
La tematica dei costi
Infine, il momento della dolorosa come dicono in alcuni ristoranti: ma quanto costa? Heh, il problema è che è vero: Kubernetes non costa come una Lamborghini, ma di sicuro costa come una qualsiasi bella automobile che potete vedere in un concessionario. Il numero delle macchine di cui fare il provisioning lievita o comunque aumenta anche solo un po’ a seconda della strategia che utilizziamo per gestire l’hardware che sta sotto il nostro cluster. Quello che però spesso non viene contato nel foglio di calcolo del budget infrastrutturale sono le ore uomo spese a connettere le macchine tra loro, a far parlare due VPS che stanno sotto un cluster Percona (un esempio tra tanti). Kubernetes rende queste operazioni leggermente più semplici portando in fondo all’anno un risparmio in ore uomo non indifferente banalmente per via dei principi di configuration-as-code che segue. Possiamo salvare la configurazione del cluster in dei file YML e riapplicarla.
Se non avete mai usato configuration-as-code come paradigma, scoprirete quanto può essere utile quando le cose vanno storte. Rideployare un’applicazione in qualche minuto è un fattore da non sottovalutare, specie se come il sottoscritto avete un pet project che fate girare da soli.
Insomma…
Non è facile riassumere tutto quello che uno può imparare in settimane di deep dive su Kubernetes. Personalmente, non ci ho nemmeno provato: questi sono solo alcuni dei concetti che ho elaborato e che sto studiando. Da un punto di vista di piattaforma, Kubernetes è il nuovo Linux e rappresenta la koiné dialektos del mercato applicativo. Una piattaforma che può abilitarvi a fare le cose con uno schiocco di dita se solo studiate a sufficienza per averne la preparazione.
Non fatevi cogliere alla sprovvista.
Un ringraziamento particolare a Andrea Spagnolo, che mi ha fatto da mentore nell’apprendimento delle basi di Kubernetes, ed è stato anche un mio fidatissimo compagno di profanità quando ho provato a usare cert-manager.
10 Apr 2021
Qualche giorno fa Brent Simmons ha dato l’annuncio del lieto evento: uno dei progetti open source migliori di cui io abbia mai seguito gli sviluppi ha annunciato la versione 6.0, e quel software è proprio NetNewsWire.
Ma cominciamo dall’inizio: cos’è NetNewsWire? NetNewsWire è un lettore di feed RSS che sincronizza anche con Feedly, Feedbin, e un’altra buona caterva di servizi online per leggere i feed. Quest’ultima versione sincronizza anche i feed letti, nel caso in cui non usassimo nessuno di questi servizi, direttamente via iCloud; personalmente io sono un grosso fan dei feed RSS per praticamente qualsiasi cosa, e uso NetNewsWire principalmente come “interfaccia” per quanto riguarda il mio account Feedly.
Ho un’applicazione di questo tipo per ogni dispositivo che uso, il mio Macbook non fa eccezione, e devo dire di non essere mai stato così soddisfatto di un feed reader, anche perché di NetNewsWire posso vedere tutto il codice su Github, che è una cosa molto particolare se consideriamo che stiamo parlando di un’applicazione per Mac.
Brent Simmons ne parla parecchio, e si concentra spesso sullo stimolare questo tipo di sforzo per quanto riguarda l’ecosistema Apple, persino nella guida ai contributi per il suo lettore di feed:
First thing: don’t send money. This app is written for love, not money. :)
NetNewsWire is all about three things:
- The open web
- High-quality open source Mac and iOS apps
- The community that loves both of the above
Supporting all these things takes work.
In poche parole: NetNewsWire è il mio lettore di feed preferito per Mac. Questa nuova versione introduce un bel po’ di novità. È open source. Spero di avervi fatto venire voglia di usarlo.
20 Mar 2021
Questo periodo sto facendo un sacco, un sacco, un sacchissimo di cose.
Sto dando una mano con quelle poche conoscenze di Rust che ho a mantenere il mio feed reader per Linux preferito.
Sto lentamente riprendendo a contribuire a CouchDB.
Mi sto ammutinando, insieme a un gruppo di amici invasati, una volta a settimana, occupando in modo coatto il podcast di un caro amico.
Ma soprattutto, ho una casa nuova da sistemare e arredare insieme ad Agnese. Oggi ho finito di installare e attivare la connessione internet mentre arrivava un fracco di elettrodomestici nuovi.
Tutto questo per dire: avrei un sacco di cosette da scrivere, ma al momento mi trovo con troppa roba per le mani. A prestissimo!
28 Feb 2021
Prima di mettersi in bocca paroloni come “cloud native”, “microservizi” o cose simili, è necessario rafforzare i principi di base che muovono uno sviluppatore attraverso delle precise scelte di design. Come mai un determinato pezzo di software è scritto in un modo piuttosto che in un altro? C’è sempre una risposta a interrogativi di questo tipo, e The Pragmatic Programmer parla proprio di questo: delle persone che stanno dietro gli automatismi e il codice di cui tutti i giorni fruiamo e che chiunque faccia il nostro stesso mestiere ha davanti per almeno una decina di ore al giorno.
Al posto di abbandonarsi ai design pattern e ai tecnicismi (per quanto legittimi) questo libro è completamente composto di principi che rendono davvero uno sviluppatore forte di quello che conosce, piccole pillole come “cosa fare quando qualcuno ti chiede qualcosa”, “come comportarsi di fronte alle stime”, oppure il rubber-duck-debugging che oggi ormai è dato per assodato e le cui radici invece risalgono proprio a questo stupendo testo.
Testo che come avrete avuto modo di notare è vecchiotto; la prima edizione è del 1999, e per quanto nel tempo siano uscite varie riedizioni principalmente volte a svecchiare alcuni concetti e gli esempi ormai datati, il grosso dell’opera non è mai stato modificato e col tempo non solo tutto questo gli è valso il titolo di “uno tra i libri più influenti di sempre sulla programmazione”, ma per me è il libro più influente di sempre sullo sviluppo software. Personalmente - e lo dico complice il fatto che di libri tecnici ne ho letti, sia per l’università che nella banale sezione della manualistica - non sarei lo stesso sviluppatore, oggi, se non avessi letto The Pragmatic Programmer da cima a fondo, ahimé anche troppo tardi, l’anno scorso.
È stata una lettura che mi ha preso tempo ma alla fine è valsa la pena di ogni secondo speso sulle pagine, alcune veramente scorse a fatica perché è un testo denso.
I concetti che mi sono rimasti maggiormente come più cari da The Pragmatic Programmer? Eccoli qua:
- Il principio di ortogonalità dello sviluppo software: a volte è necessario che due entità all’interno di un sistema evolvano in parallelo in maniera disaccoppiata. Nel 2021 può sembrare un concetto naìf, ma provate a rileggere il vostro codice alla luce di questa affermazione;
- La teoria delle finestre rotte: più un progetto è marcio più è facile che marcisca. Quando vedete qualcosa che non va, aggiustatelo subito. Se avete un progetto pieno di cose che funzionano a singhiozzo, fate una lista delle cose da aggiustare e cominciate. Vi sorprenderete di quanto possono migliorarvi la vita anche piccoli gesti, se applicati con costanza;
- Il portfolio delle conoscenze: come state evolvendo il vostro skill set, soprattutto parlando di hard skill? Quanti linguaggi conoscete? Avete voglia di espandere la vostra toolbelt periodicamente?
- Power Editing: l’editor di testo per uno sviluppatore è come la coperta di Linus, o più semplicemente il mezzo attraverso cui quello che sappiamo si traduce prima in qualcosa di fruibile e in un secondo momento in denaro (momento venale, scusate). Conoscere il proprio editor di testo, facilitandosi il lavoro con tutto quello che il software che usiamo mette a disposizione, è essenziale per uno sviluppatore efficace;
- Tracer Bullets: saper tracciare un percorso lungo tutta la filiera (il data path, se vogliamo usare un tecnicismo) che i nostri dati percorrono, mettendo a punto una funzionalità in modo grezzo e successivamente rifattorizzarla e aggiungere le parti mancanti. Saper individuare con esattezza quali parti compongono lo scheletro della funzionalità che stiamo implementando e quali invece possono essere tralasciate per essere aggiunte senza sforzo in un secondo momento è un’abilità secondo me chiave per ogni ingegnere del software di successo.
Volete comprarlo? In ebook lo trovate in un sacco di posti, in hardcover è più difficile trovarlo. In ogni caso il libro ha a corredo un sito ufficiale su cui non solo viene venduto, ma su cui è presente la “Pragmatic Bookshelf”, ovvero altri libri di autori fidati su tematiche belle da spolpare. ;-)
19 Feb 2021
Non sono tanto il tipo da certificazioni, ma una cosa è certa: alcune volte per scollinare un argomento particolarmente ostico serve avere un qualche tipo di aiuto da parte di qualcuno che ne sa di più. Node.Js per me non ha mai rappresentato un argomento ostico, così come JavaScript in generale, ma devo ammettere di aver avuto dei tutor e dei compagni di studi eccezionali.
Per chi non avesse lo stesso tipo di fortuna, sono molto felice di sapere che la Linux Foundation insieme alla OpenJS Foundation sta lanciando un corso gratuito di JavaScript e Node.Js. Siccome io adoro JavaScript, vi lascio il linketto qui così magari ve lo appuntate.
Sicuramente sarà fatto meglio di qualsiasi corbelleria che ti propinino i bootcamp che ti trasformano, a detta loro, in un full-stack developer in sei mesi.
Introduction to Node.js
