Cambio oggetto e espando la discussione... perché trovo spunti degni di approfondimento: chissa' che con questo thread non facciamo --almeno qui, in lista, con diversi "*NON* addetti ai lavori"-- un po' di chiarezza... Il 02/05/24 6:33 PM, Giuseppe Attardi ha scritto:
[...] Kamal, da una breve scorsa alla documentazione, è qualcosa tipo Ansible [...] Hanson spiega che Kubernetes è complesso e richiede competenze (appunto come sospettavo), perché è “dichiarativo”.
Kubernetes è complesso... perché chi l'ha pensato aveva in mente di gestire il workload di Google, su scala worldwide. A quella scala, la complessità di kubernetes... è insignificante rispetto all'infrastruttura che dovra' gestire. Il discorso cambia a scale piu' piccole (Ateneo, ASL, Regione...). A queste scale, la complessita' di K8S si sente, forte. E' la stessa scala di Hey/Heinemeier e per questo Heinemeier ha premuto "reset": a lui, semplicemente, non serviva. Meglio: era sufficiente qualcosa di *MOLTO* piu' semplice. E' un folle? E' un ignorante? Oppure è semplicemente un "realista"? A me piace inquadrarlo come qualcuno che si alza e dice: "Il Re è nudo"... e poi va alla macchina da cucire, e prepara uno straccio di vestito (che comunque "copre"). Non è di seta. Na ha lapislazzuli incastonati a griglia. Non ha i bordi valorizzati con merletti ricamati al tombolo. Ma copre. Ed è quello che gli serve.
Appunto, dichiarativo vs procedurale. La differenza sta lì, da una parte fai tutto tu a mano, devi tenere traccia di tutyo e ogni modifica costa quanto ricominciare daccapo. Dall’altra hai un sistema dichiarativo, in cui specifichi i requisiti e gli obiettivi, e il software che gestisce la piattaforma, determina i passi per attuare la soluzione.
Non ho alcuna difficolta' ad ammettere che fino a ~quattro anni fa la distinzione fra questi due paradigmi (dichiarativo vs. procedurale) mi era chiara... solo in teoria. Poi, pero', ho avuto il piacere (e la fortuna) di poter mettere le mani su una infrastruttura cloud, "giocandoci" a piacere. Ed e' finita che oggi, una parte consistente della "mia" infrastruttura è definita (e gestita) con "terraform" [1], soluzione di riferimento in ambito dichiarativo: server virtuali, dischi, segmenti di rete, regole di firewalling e di routing sono tutte definite "dichiarativamente". Ed abbiamo anche sperimentato l'ebrezza di conservare lo "stato" in un'area condivisa (GitLab) affinché piu' persone potessero lavorare sulla stessa infrastruttura... senza pericolo di creare collisioni. Addirittura abbiamo pure testato la possibilita' che fosse GitLab stesso, con le sue pipeline, a "riconciliare" i cambiamenti nei file di definizione (aka: un PUSH con modifiche/aggiunte alle direttive di terraform) sull'infrastruttura di produzione (terraform apply) - [2] Anche ad una scala ridottissima come la mia, i vantaggi di un tale approccio mi sono talmente chiari che oggi la creazione di macchine virtuali (e relativo storage e networking) la faccio esclusivamente con terraform. E tale approccio è possibile anche a scala ridottissima, ed anche in contesti 100% F/OSS (es.: utilizzo di un host proxmox [3], pilotato da terraform o il suo fork, OpenTofu [4]], attraverso il provider specifico [5]. Ho la sensazione forte, pero', che il mio approccio non sia esattamente mainstream... e mi domando come mai [senza trovare una risposta semplice]. Dall'altro lato, mi è chiarissimo il paradigma "imperativo" (hai citato "ansible"), anche lui ampiamente testato in questi anni. *NON* concordo sulla tua affermazione: "/...ogni modifica costa quanto ricominciare daccapo.../". Non conosco gli altri strumenti, ma sono sicuro che ansible porta con se l'idempotenza: applicare un playbook (la lista delle cose da fare, nella sequenza indicata) su un set di sistemi sui quali, in precedenza, la stessa ricetta è stata gia' applicata... *NON* produce conseguenze. Questo mette al riparo lo sviluppatore [...che comunque è meglio che sappia cio' che sta facendo...] dal porsi il problema: "L'avro' gia' fatto?". Semplicemente lui applica le modifiche alla ricetta e la rispara su tutti i target: quelli che erano gia' a posto, resteranno invariati. Quelli che erano disallineati... si allineeranno (ai dettami della ricetta). Fra "dichiarativo" vs. "procedurale", personalmente ho trovato un equilibrio lasciato che l'infrastruttura (IAAS) sia gestita 100% in modo dichiarativo (terraform), mentre tutta la parte applicativa soprastante (setup dell'infrastruttura di containerizzazione e deploy dei container e delle relative dipendenze [storage persistente e networking]) preferisco farla con approccio "procedurale" (ansible). I due approcci, inoltre, possono anche operare in simbiosi: modifica ai file dichiarativi di terraform e, al loro interno, includere il minimo indispensabile per avviare, a fine attivita', un playbook ansible che si occupa del resto. Tutto automaticamente. Insomma: non c'e' una ricetta magica per tutto. E continuano ad esserci contesti che mal si applicano ad entrambi gli approcci. L'ottimale credo sia quello di conoscere (possibilmente in modo almeno sufficiente) entrambi gli approcci, con i principali strumenti che li rendono possibili e poi decidere sulla base delle proprie esigenze.
[...kubernetes...] Se cambiano i requisiti, basta cambiare le specifiche e il sistema si riadatta ad esse in modo totalmente automatico. Su questo elemento *DISSENTO* fortemente. In *TEORIA* funziona cosi'. Nella pratica, dipende assolutamente dall'applicazione che deve girarci.
Se a dover essere gestita è una applicazione "classica" (un Wordpress che richiede un MySQL; un GitLab che richiede millemila prerequisiti; un applicativo "old-school" che utilizza il file-system come repository di dati; etc.)... portarlo su kubernets è un bagno di sangue: la complessita' aumenta di almeno un ordine di grandezza e la probabilita' che si rompa tutto aumenta allo stesso modo. Usare K8S per far girare OpenSearch, Kafka, una applicazione Node/Python che *NON* utilizza storage persistente.... è un conto. Usare K8S per far girare il 99% del carico di lavoro che trovo negli Atenei, nelle ASL e, scommetto, nelle aziende... è un altro. Chiaramente, se ti chiami AWS, Google Microsoft, alla tua scala ti organizzi solo con applicativi che ricadono nella prima categoria. Pero', poi, vorrai che anche gli utenti che hanno applicativi della seconda categoria... possano venire da te. E tu vuoi fatturarli. Quindi fai un po' di "fumo da cloud" e dici a tutti: "venite da noi, sempre e comunque". E tutti corrono. E tu fatturi. Heinemeier se ne è accorto, ed ha agito di conseguenza.
I server su cui gira Kamal vanno invece installati a mano (you boot a Ubuntu server) e magari se li fa installare da un contractor che gli installa i server nel datacenter (lo spiega nel video). Insomma, you get what you pay for. Tutt’altra cosa di una infrastruttura cloud scalabile, resiliente e automatizzata.
Ho la sensazione che tu guardi la questione dal lato infrastrutturale (tiro su del ferro, ci metto OpenStack e K8S e metto a disposizione di terzi una meravigliosa piattaforma "scalabile, resiliente e automatizzata"), mentre Heinemeier guarda la questione dal lato applicativo: ho una applicativo relativamente moderno, di cui ho il controllo completo. Posso farlo girare come dico io, dove dico io, al livello di affidabiita' che decido io... ad una frazione del costo che mi costa farla girare su AWS. Tu e AWS volete "vendere" la vostra piattaforma. Heinemeier preferisce gestirla per i fatti suoi (perché pensa di sapere quello che fa). A me piace piu' il suo approccio... sia perché la "vostra" piattaforma offre il suo lato migliore, solo in condizioni particolarissime, sia, soprattutto, perché soltanto cosi' Heinemeier resta competitivo a lungo termine.
Negli ultimi anni, ho visto (molte) persone sostenere che "andavano su cloud" perché spostavano il loro wordpress su una VM su AWS... (o su Azure). Vedo N Atenei sostenere la tesi che vanno "sul cloud Azure" (quello venduto a marchio CRUI...) quando semplicemente spostano le VM che prima erano interne, su VPS Azure.
Vedo Atenei sostenere che vanno su cloud... perché "spostano" le VM interne sull'infrastruttura VMware che Cineca mette a disposizione su catalogo ACN/exAGID.
Quello è semplicemente utilizzo di infrastrutture cloud, altrimenti detto IaaS, non è cloud computing nativo, che richiede riprogettare le soluzioni in ottica cloud.
Mi è moltissimo chiaro. Ma mi è altrettanto chiaro che quella "riprogettazione" --che tu poni come "prerequisito" del cd. cloud-computing nativo-- *NON* la fa... nessuno. Tutti, pero', dicono: "Siamo sul cloud". Se non hanno fatto quella riprogettazione... come fanno a starci?
Poi mi giro... è mi vedo a deploiare --con tool di automazione-- applicativi nativamente-cloud (kafka, opensearch, microservizi nodejs stateless), sull'infrastruttura GARR-Cloud, facendolo (io) senza utilizzare kubernetes (che tu citi), ma operando comunque con container (docker), stateless (con persistenze su motori nativi-cloud) e con anche livelli non banali di affidabilita'/resilienza (docker-swarm, nomad). Sono, io, "cloud"?
Stai gestendo a mano, con l’ausilio di tool, una infrastruttura fornita da altri. Il cloud GARR è basato su OpenStack e Kubernetes, entrambi orchestrati in modo dichiarativo da Canonical Juju. La scelta di una soluzione dichiarativa era quella che consentiva di gestire una piattaforma così sofisticata con solo 5 persone, anziché 50.
Per consentire ad un team di 5 persone di operare una infrastruttura la cui complessita', 10 anni fa, richiedeva 50 persone.... *NON* serve l'adozione tout-court di paradigmi dichiarativi. Serve *L'AUTOMAZIONE*. Che poi tale automazione possa avvalersi di soluzioni dichiarative (a-la-terraform) o imperative (a-la-ansible), è un dettaglio. Posso cambiare una singola riga su un file ".tf" di terraform per poi far si che un "terraform apply" produca la distruzione (reale!) di 100 macchine virtuali esistenti [quelle in produzione] e la creazione di 100 *nuove* macchine virtuali. ...e posso cambiare una singola riga in un playbook ansible... per distruggere (o aggiustare, o anche creare) 100 macchine virtuali. La chiave è l'automazione. Non la modalita' con la quale viene implementata. Al limite, l'elemento a corredo (dell'automazione) è tutto lo stack che serve a garantire il pieno controllo su quello che si sta facendo. In una parola: il tracciamento maniacale di quello che si fa, su Git (GitLab, ForgeJo, etc.). Mi fermo. Mi sa che ho esagerato :-( Perdonatemi... Bye, DV [1] https://www.terraform.io/ [2] https://docs.gitlab.com/ee/user/infrastructure/iac/ [3] https://www.proxmox.com/en/proxmox-virtual-environment/overview [4] https://opentofu.org/ [5] https://registry.terraform.io/providers/bpg/proxmox/latest/docs -- Damiano Verzulli e-mail:damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html