Re: [nexa] "...and... We've left the cloud!" - David Heinemeier Hansson / 37signals
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
Buongiorno, vi chiedo perdono per l'estrema lunghezza di questo messaggio, se non vi interessa approfondire i concetti alla base di kubernetes et al fareste meglio a ignorarmi :-) Damiano Verzulli <damiano@verzulli.it> writes:
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...
Giusto cercare di fare un po' di chiarezza almeno in questa lista, purtroppo però le cose sono sufficientemente complesse da risultare a volte poco chiare anche agli addetti ai lavori, me per primo sicuramente.
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”.
Iniziamo con un paio di concetti: 1. kubernetes è un sistema di gestione dei cluster, piuttosto complesso https://en.wikipedia.org/wiki/Kubernetes; di sistemi di gestione cluster è piena la storia dell'IT [1], kubernetes non sarà l'ultimo... e nemmeno il penultimo. La caratteristica di kubernetes, che lo rende così /complicato/, è che *ingloba* un sacco di altri servizi che in altri sistemi di gestione dei cluster sono lasciati ad altri software che i sistemisti devono scegliere, installare e configurare indipendentemente. 2. ansible è un sistema di gestione della configurazione (Infrastructure as Code) https://en.wikipedia.org/wiki/Ansible_(software); di sistemi di configuration management è piena la storia dell'IT, ansible non sarà l'ultimo e nemmeno il penultimo :-)
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.
I sistemi di "cluster management for world sized cloud infrastructure" sono figli dell'/ideologia/ "pets vs cattle" [2] --8<---------------cut here---------------start------------->8--- Pets Servers or server pairs that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed, and “hand fed”. Examples include mainframes, solitary servers, HA loadbalancers/firewalls (active/active or active/passive), database systems designed as master/slave (active/passive), and so on. Cattle Arrays of more than two servers, that are built using automated tools, and are designed for failure, where no one, two, or even three servers are irreplaceable. Typically, during failure events no human intervention is required as the array exhibits attributes of “routing around failures” by restarting failed servers or replicating data through strategies like triple replication or erasure coding. Examples include web server arrays, multi-master datastores such as Cassandra clusters, multiple racks of gear put together in clusters, and just about anything that is load-balanced and multi-master. --8<---------------cut here---------------end--------------->8--- (http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/) Come se i due insiemi descritti sopra fossero davvero _disgiunti_: sarà mica una cosa seria? (e infatti kubernetes usa il termine "Pet Sets" che l'autore dell'articolo sopra contesta... non proprio "rocket science" diciamo :-D ) L'ideologia "pets vs cattle" è stata osannata come il "nuovo (cattle) che avanza sul vecchio (pets)", nonostante sia _evidente_ sia è frutto di mistificazione su come funzionavano i sistemi "high availability clusters" già mooolto tempo prima che il _meme_ fosse inventato. Il tutto è anche frutto della confusione assordante tra "scale-out" vs "scale-up", che tra l'altro sono problemi che si incontrano _regolarmente_ nel ciclo di vita di una infrastruttura IT, che essendo "fatta di bit" è da decenni che è "nomade". Tutto ciò ha portato alla /reificazione/ del concetto che i container sono _ephemeral_ by nature... tranne che i dati (https://en.wikipedia.org/wiki/Kubernetes#Storage) e le configurazioni (https://en.wikipedia.org/wiki/Kubernetes#etcd) che servono non lo sono affatto: Comunque: --8<---------------cut here---------------start------------->8--- You don't need Kubernetes when the following four conditions are true: 1 You are deploying a very small number of containers to a very small number of machines (hosts). 2 The number of containers and machines is static and does not scale up or down. 3 Your containers and machines do not fail often. 4 You do not need additional features like persistent storage, LoadBalancing, configuration management, service discovery, autohealing, autoscaling, etc. Or you do need those features but you have very limited requirements and don't mind vendor lock-in. --8<---------------cut here---------------end--------------->8--- (via https://home.robusta.dev/blog/kubernetes-is-complex-because-you-want-complex...) Il punto 4 sopra mi fa rotolare dal ridere, come se "persintent storage" (che è lo standard storage dal 1960), "distributed storage", "load balancing" ecc. non fossero già implementati e usati in produzione da anni prima che fosse "inventato" kubernetes (con autoscaling e _soprattutto_ autohealing che meriterebbero un capitolo a parte). Il punto 3 (Your containers and machines do not fail often) è pura poesia: se i tuoi container falliscono spesso, caro sistemista, hai uun problema e invece di mettere in pista kubernetes per sparare a raffica container che falliscono, sarebbe opportuno fare debugging. Il combinato disposto dei punti 1 e 2 sopra fa sì che sistemi complessi come kubernetes vanno bene solo se l'infrastruttura deve vendere macchine (containers) usa e getta (per te) perché hai tonnellate di ferro che non stai usando e devi in qualche modo riciclare facendolo pagare almeno 10 volte tanto a chi fa fatica a gestirsi la propria infrastruttura IT in autonomia (anche avvalendosi di terzi neh, ma il concetto fondamentale è /autonomia/).
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"?
É un sistemista che ha ben presente lo "use case" di kubernetes e ha chiaramente capito che a lui proprio non serve. Dopotutto deve /solo/ erogare 4/5 applicazioni web con backend per i dati, mica fare AWS. ...poi essendo un bravissimo sviluppatore si diverte anche a reinventare la ruota (Kamal) perché gli piace fare "il sarto", ma vabbè, ognuno ha il suo ego :-) [...]
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.
Questa "una parte" sarebbe Ansible? Ma Ansible è dichiarativo! ...ormai "tutto è dichiarativo" :-)... "Infrastrutcture as Code".
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.
Come il venerabile CFEngine... in teoria (Promise Theory) :-O ...e Puppet, Salt, Chef; ma in pratica... Il problema irrisolvibile per tutti i sistemi di configuration management per sistemi operativi la cui gestione dei pacchetti _e_ della configurazione è _stateful_ [3] è che è praticamente impossibile ottenere l'idempotenza [4]. Nel caso specifico dei container Docker definiti coi Dockerfiles, l'idempotenza è _doppiamente impossibile_. Nel caso di Ansible: --8<---------------cut here---------------start------------->8--- Reliable. When carefully written, an Ansible playbook can be idempotent, to prevent unexpected side effects on the managed systems. It is possible to write playbooks that are not idempotent. --8<---------------cut here---------------end--------------->8--- (https://en.wikipedia.org/wiki/Ansible_(software)#Design_goals) Divertente "it is possible... not idempotent": chiunque ha un po' di esperienza con simili sistemi sa che la promessa di poter ottenere "playbook" (o "manifests") idempotenti è una... _forzatura_ Per fare un esempio semplice su cosa significa idempotenza in una dichiarazione di un "manifest" Puppet (su cui ho esperienza) et al, per installare un pacchetto, nel manifest del sistema devi dichiarare: --8<---------------cut here---------------start------------->8--- package { 'openssh': ensure => installed, name => openssh, [...] } --8<---------------cut here---------------end--------------->8--- (https://www.puppet.com/docs/puppet/7/types/package.html) e poi applicare il manifest al sistema per ottenere il nuovo stato. Se il pacchetto NON lo vuoi, invece, non basta _non inserire_ quella dichiarazione dal manifest di sistema ma devi dichiarare: --8<---------------cut here---------------start------------->8--- package { 'openssh': ensure => absent, name => openssh, [...] } --8<---------------cut here---------------end--------------->8--- e poi *applicare* il manifest al sistema... tranne che magari "openssh" è una dipendenza di altri packages e il manifest non "concilia". [...]
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".
Sì ma anche Damiano è incappato in quello che prima o poi succede a tutti coloro che hanno usato simili sistemi dichiarativi /supposti/ idempotenti: la dichiarazione NON coincide con lo stato :-( https://www.garrlab.it/p3_terraform_state/ --8<---------------cut here---------------start------------->8--- Today I discovered a mismatch between the state and the real infrastructure. If not addressed and solved, such a mismatch could cause serious problem to the infrastructure itself (dropping and re-creating three OpenStack instances… and related services!) [...] So, now it’s clear that the image used to build the three VMs were gone, and replaced with a different one, with same name. [...] The bad image ref id (00ece84f-c723-4ea0-a4fb-5555bea06c8d) is tightly associate to the VM at the OpenStack level. The same problem apply to the other two VMs: --8<---------------cut here---------------end--------------->8--- La cosa è (ovviamente) risolvibile, come ha dimostrato Damiano, ma c'è stato bisongo di un processo di _riconciliazione_ tra la dichiarazione e lo stato, cosa che in un sistema idempotente sarebbe... impensabile [...]
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.../".
No infatti, secondo me è fuorviante; con Ansible (et al) raramente è necessario "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.
Tranne che può succedere che ci siano incongruenze tra la dichiarazione e lo status, come è successo quella vota a Damiano... e allora bisogna riconciliare. [...]
Insomma: non c'e' una ricetta magica per tutto.
Sì invece: «Purely Functional System Configuration Management» by Eelco Dolstra and Armijn Hemel, 2007-05-07 --8<---------------cut here---------------start------------->8--- System configuration management is difficult because systems evolve in an undisciplined way: packages are upgraded, configuration files are edited, and so on. The management of existing operating systems is strongly imperative in nature, since software packages and configuration data (e.g., /bin and /etc in Unix) can be seen as imperative data structures: they are updated in-place by system administration actions. In this paper we present an alternative approach to system configuration management: a purely functional method, analogous to languages like Haskell. In this approach, the static parts of a configuration — software packages, configuration files, control scripts — are built from pure functions, i.e., the results depend solely on the specified inputs of the function and are immutable. As a result, realising a system configuration becomes deterministic and reproducible. Upgrading to a new configuration is mostly atomic and doesn’t overwrite anything of the old configuration, thus enabling rollbacks. We have implemented the purely functional model in a small but realistic Linuxbased operating system distribution called NixOS. --8<---------------cut here---------------end--------------->8--- (https://edolstra.github.io/pubs/hotos-final.pdf) Oggi quei concetti sono implementati in NixOS e Guix System; per i manifest di packages e servizi il primo usa un _mix_ di Nix - un DSL funzionale sviluppato ad-hoc - e bash, il secondo usa Guile, un dialetto di Scheme. [...]
[...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.
Confermo: la statefulness dei sistemi purtroppo a volte è _embedded_ nelle applicazioni che sono progettate proprio male [3]
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
anche GitLab (o analogo) che richiede millemila prerequisiti? Ho in mente decine di applicazioni _webbiche_ che richiedono millemila prerequisiti. [...]
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...
appunto, e magari prendono una _virtual machine_ "sul cloud" con attaccato un persistent storage proprietario, un'istanza RDMBS e robe simili e poi ci installano su Ubuntu per farci girare Wordpress o una applicazione PHP custom sviluppata su framework Laravel [...]
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...
Non è solo una questione di gusti, è che a parità di competenze l'approccio on-premises costa almeno un ordine di grandezza meno. La questione quindi si "riduce" a: per farselo "da soli" occorre avere adeguate competenze, se lo facciamo "in cloud" non abbiamo bisogno di quelle competenze e quindi _risparmiamo_... ...tranne poi rendersi conto che dopo 5 anni, non 10, non 20, stai spendendo una fucilata indecente che faresti meglio a spendere per avere le competenze "in casa", anche fornite da terzi, ma con un "technical debt" gestibile, non con uno col quale rischi di fallire da un momento all'altro nel caso il tuo vendor decida di dismettere un servizio essenziale per la tua infrastruttura
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.
esatto: on-premises is (already!) the new normal :-D [...]
Quello è semplicemente utilizzo di infrastrutture cloud, altrimenti detto IaaS, non è cloud computing nativo, che richiede riprogettare le soluzioni in ottica cloud.
ammesso e _non_ concesso che l'"ottica cloud" sia quella dei microservices, allora anche quel concetto è ormai obsoleto (anche se difficile da superare) detto in altre parole: le applicazioni ben progettate che girano su sistemi on-premises ben progettati sono di almeno 1 ordine di grandezza più efficienti di quelle "cloud native"; per rimanare solo sul piano di progettazione delle applicazioni: --8<---------------cut here---------------start------------->8--- Replacing method calls and module separations with network invocations and service partitioning within a single, coherent team and application is madness in almost all cases. --8<---------------cut here---------------end--------------->8--- (https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-micr...)
Mi è moltissimo chiaro. Ma mi è altrettanto chiaro che quella "riprogettazione" --che tu poni come "prerequisito" del cd. cloud-computing nativo-- *NON* la fa... nessuno.
No infatti: continuano (quasi) tutti a usare applicazioni client-server webbiche "tradizionali", come si facevano anche prima dell'hype ...anche perché le applicazioni per essere "cloud native" devono praticamente essere riscritte da sviluppatori competenti, a meno di far su un paciugone di codice SOAP/REST che ci mette 100 volte il tempo che ci metteva prima
Tutti, pero', dicono: "Siamo sul cloud". Se non hanno fatto quella riprogettazione... come fanno a starci?
Prendono una/dieci/cento VM su AWS, ci attaccano storage, database ecc e ci installano Ubuntu con su la loro bella webapp. [...]
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é
Il fine ultimo di tutti questi bei ragionamenti è questo e soltanto questo: decimare le persone necessarie a far funzionare una infrastruttura come quelle di GARR o altre organizzazioni pubbliche o private? Tra l'altro i 5 rimasti devono limitarsi a fare 4 click su un "admin panel". Figuriamoci se io ho qualcosa contro l'automazione, il mio alter ego ci lavora per l'automazione, ma non può sempre e _solo_ limitarsi tutto a _risparmiare_ sugli stipendi. Infine, sarà anche che alla fine rimangono in 5 su 50 a gestire una intrastruttura basata su kubernetes... ma prima o poi le cose cominciano a non funzionare più con 4 click e allora... parte il _cinema_. [...]
La chiave è l'automazione. Non la modalita' con la quale viene implementata.
Non vorrei dire ma per _sviluppare_ le librerie necessarie a rendere _accessibile_ l'automazione nel "Infrastructure as Code" è necessario tanto lavoro competente... ma a quello non ci pensa nessuno? Le "librerie" di Terraform, Ansible, Puppet, NixOS, Guix crescono sugli alberi? [...]
Mi fermo. Mi sa che ho esagerato :-( Perdonatemi...
Ops, mi sa anche io :-/
[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
Grazie mille per questo bel thread! Saluti, 380° [1] kubernetes è basato sulla Promise Theory di Mark Burgess, autore di CFEngine rilasciato la prima volta nel 1993 https://en.wikipedia.org/wiki/CFEngine [2] http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ [3] a volte la statefulness _purtroppo_ è legata a come è progettata (male!) l'applicazione stessa, come nel caso di Nextcloud ad esempio [4] https://en.wikipedia.org/wiki/Idempotence -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
On 5/3/24 15:24, 380° wrote: > [...] >> 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”. > Iniziamo con un paio di concetti: > > 1. kubernetes è un sistema di gestione dei cluster, piuttosto complesso > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FKubernetes&e=566de099&h=2b97a3f5&f=y&p=n ; di sistemi di gestione > cluster è piena la storia dell'IT [1], kubernetes non sarà > l'ultimo... e nemmeno il penultimo. La storia dell'IT è piena di tante cose. Alcune di queste hanno preso piede, altre no. Tutte noi della lista Nexa tendenzialmente siamo per l'Open Source. Qualcuno addirittura per il Software Libero. Per usare le tue parole, esistono tanti kernel, Linux non sarà l'ultimo e nemmeno il penultimo. Eppure non so vedere all'orizzonte il prossimo. Il mondo è andato verso questa direzione, con buona pace di sistemi probabilmente migliori come FreeBSD e al netto di tutte le distro-war che possiamo fare (e che fanno sempre piacere ;-) ). Idem con patate per Kubernetes. Essere utilizzati di più, come sai, significa avere maggiore supporto dalla comunità, poter risolvere più facilmente i problemi, avere più documentazione, maggior affidabilità e stabilità, maggiore interoperabilità e integrazione... > La caratteristica di kubernetes, > che lo rende così /complicato/, è che *ingloba* un sacco di altri > servizi che in altri sistemi di gestione dei cluster sono lasciati ad > altri software che i sistemisti devono scegliere, installare e > configurare indipendentemente. Sono moderatamente d'accordo. Anche se più banalmente, secondo me, la difficoltà sta nella configurazione dettagliata di una molteplicità di risorse IT. Il vantaggio è l'uniformità di queste configurazioni, l'opportunità di versionamento delle stesse e la centralizzazione della loro gestione. [...] >> 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. > I sistemi di "cluster management for world sized cloud infrastructure" > sono figli dell'/ideologia/ "pets vs cattle" [2] Non so se si tratti di un'ideologia. Direi più un portato industriale. Si potrebbe forse dire che l'industria è un'ideologia. Rimanendo, però, con i piedi per terra, servono sia i pets che i cattle. Così come serve sia l'artigianato che l'industria. A me piacerebbe avere una casa piena di oggetti di artigianato, purtroppo non posso permettermelo. Mi limito ad alcune cose, sul resto cedo. Penso che valga in generale. > Come se i due insiemi descritti sopra fossero davvero _disgiunti_: sarà > mica una cosa seria? (e infatti kubernetes usa il termine "Pet Sets" > che l'autore dell'articolo sopra contesta... non proprio "rocket > science" diciamo :-D ) Non ho mai sentito dire da nessuno che Kubernetes è rocket science. Al massimo si sente dire che è una "ficata" oppure una "rottura di scatole". :-) > L'ideologia "pets vs cattle" è stata osannata come il "nuovo (cattle) > che avanza sul vecchio (pets)", nonostante sia _evidente_ sia è frutto > di mistificazione su come funzionavano i sistemi "high availability > clusters" già mooolto tempo prima che il _meme_ fosse inventato. > > Il tutto è anche frutto della confusione assordante tra "scale-out" vs > "scale-up", che tra l'altro sono problemi che si incontrano > _regolarmente_ nel ciclo di vita di una infrastruttura IT, che essendo > "fatta di bit" è da decenni che è "nomade". > > Tutto ciò ha portato alla /reificazione/ del concetto che i container > sono _ephemeral_ by nature... tranne che i dati > (https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FKubernetes%23Storage&e=566de099&h=c59b9bc2&f=y&p=n ) e le configurazioni > (https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FKubernetes%23etcd&e=566de099&h=6b0726e4&f=y&p=n ) che servono non lo sono > affatto: Non lo so se sia questo che abbia portato alla reificazione dei container. I namespace sono nel kernel di Linux dal 2002 e i cgroups dal 2006. Kubernetes è nato nel 2014. La storia dei container inizia negli anni '80 con chroot e per 3 decenni sono state proposte numerose variazioni sul tema, fino a quella che ha preso piede. Che non è necessariamente la migliore, così come Linux non è il miglior kernel in circolazione. Il fatto che siano effimeri è fondamentale. Tenere separata la computazione dai dati e dalle configurazioni è una buona prassi. Tutto è più pulito e portabile. Gestire questa separazione è sempre stato un problema. Mi pare che Kubernetes ultimamente abbia fatto passi da gigante verso una gestione convincente: snapshot e volume cloning, secrets encryption tramite API e poi i Container Storage Interface che hanno standardizzato il modo in cui i container interagiscono con i sistemi di storage esterni. Stiamo parlando di un sistema con migliaia di contributori, centinaia di migliaia di commit e una vitalità che dopo 10 anni non accenna a diminuire (all'ultimo KubeCon a Parigi eravamo 10.000 persone!). [...] >> 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"? > É un sistemista che ha ben presente lo "use case" di kubernetes e ha > chiaramente capito che a lui proprio non serve. Dopotutto deve /solo/ > erogare 4/5 applicazioni web con backend per i dati, mica fare AWS. Ma infatti, benissimo così. Basta che funzioni. Non è necessario passare a Kubernetes e tanto meno al cloud, se non serve. Allo stesso tempo se a qualcuno serve, il prodotto è lì a disposizione, con una licenza Open Source (Apache License 2.0) compatibile con la GPLv3. > ...poi essendo un bravissimo sviluppatore si diverte anche a reinventare > la ruota (Kamal) perché gli piace fare "il sarto", ma vabbè, ognuno ha > il suo ego :-) Ottimo. Adoro i sarti! :-) > [...] > >>> 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. > Questa "una parte" sarebbe Ansible? Ma Ansible è dichiarativo! > > ...ormai "tutto è dichiarativo" :-)... "Infrastrutcture as Code". Ansible è dichiarativo, ma stateless, ossia non mantiene lo stato (come invece fa OpenTofu, ad esempio). Lo stato è ricostruibile implicitamente, ma al prezzo di usare sinapsi umane. Come hai ben descritto nel seguito, l'idempotenza è limitata ai moduli, non al loro assemblamento in una logica di processo, che potrebbe facilmente far incappare in un deadlock. Ci sono le buone prassi per evitarlo e poi c'è l'esperienza che ti aiuta a debuggare le situazioni più ostiche. [...] > --8<---------------cut here---------------start------------->8--- > > Reliable. When carefully written, an Ansible playbook can be idempotent, > to prevent unexpected side effects on the managed systems. It is > possible to write playbooks that are not idempotent. > > --8<---------------cut here---------------end--------------->8--- Esatto. [...] > --8<---------------cut here---------------end--------------->8--- > > La cosa è (ovviamente) risolvibile, come ha dimostrato Damiano, ma c'è > stato bisongo di un processo di _riconciliazione_ tra la dichiarazione e > lo stato, cosa che in un sistema idempotente sarebbe... impensabile > > [...] E' così. Del resto è stata una scelta quella di tenerlo il più possibile leggero, con una curva di apprendimento piatta, e un'apertura a qualsiasi situazione. E di conseguenza a qualsiasi casino... [...] > > [...] > >> Insomma: non c'e' una ricetta magica per tutto. > Sì invece: > > «Purely Functional System Configuration Management» > by Eelco Dolstra and Armijn Hemel, 2007-05-07 > > --8<---------------cut here---------------start------------->8--- > > System configuration management is difficult because systems evolve in > an undisciplined way: packages are upgraded, configuration files are > edited, and so on. The management of existing operating systems is > strongly imperative in nature, since software packages and configuration > data (e.g., /bin and /etc in Unix) can be seen as imperative data > structures: they are updated in-place by system administration > actions. In this paper we present an alternative approach to system > configuration management: a purely functional method, analogous to > languages like Haskell. In this approach, the static parts of a > configuration — software packages, configuration files, control scripts > — are built from pure functions, i.e., the results depend solely on the > specified inputs of the function and are immutable. As a result, > realising a system configuration becomes deterministic and > reproducible. Upgrading to a new configuration is mostly atomic and > doesn’t overwrite anything of the old configuration, thus enabling > rollbacks. We have implemented the purely functional model in a small > but realistic Linuxbased operating system distribution called NixOS. > > --8<---------------cut here---------------end--------------->8--- > (https://urlsand.esvalabs.com/?u=https%3A%2F%2Fedolstra.github.io%2Fpubs%2Fhotos-final.pdf&e=566de099&h=c7fe91cd&f=y&p=n ) > > Oggi quei concetti sono implementati in NixOS e Guix System; per i > manifest di packages e servizi il primo usa un _mix_ di Nix - un DSL > funzionale sviluppato ad-hoc - e bash, il secondo usa Guile, un dialetto > di Scheme. > > [...] Ecco su questo vorrei espandere un po'. Sono soluzioni di nicchia, sicuramente interessanti ed eleganti, ma pochissimo utilizzate e quindi l'ecosistema a supporto è limitato. >>> [...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. > Confermo: la statefulness dei sistemi purtroppo a volte è _embedded_ > nelle applicazioni che sono progettate proprio male [3] Certo. Su questo non si può fare molto di più che odiare i programmatori. :-P [...] >> 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... > Non è solo una questione di gusti, è che a parità di competenze > l'approccio on-premises costa almeno un ordine di grandezza meno. Ma dipende, in realtà, non generalizzerei. Bisogna farsi bene i conti. Dovrebbe essere questo il mestiere del Product Owner. In ogni caso, la questione dei costi mi interessa fino ad un certo punto. Quanto meno valuterei anche i benefici, che sono soggettivi, come il caso di Heinemeier dimostra. > La questione quindi si "riduce" a: per farselo "da soli" occorre avere > adeguate competenze, se lo facciamo "in cloud" non abbiamo bisogno di > quelle competenze e quindi _risparmiamo_... Non è detto che sia così. L'idea portante dell'IT automation è quella della standardizzazione. Che ci sta, secondo me. Con tutte le riserve di qualsiasi approccio industriale alla tecnologia, ma anche con tutto l'incoraggiamento all'inclusività. Intendo dire che grazie alla standardizzazione in meccanica, anche un pasticcione come me può fare bricolage in casa. Poi per le cose serie (e per i casini inenarrabili che combino) ci sono i professionisti. [...] >>>> 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. > Il fine ultimo di tutti questi bei ragionamenti è questo e soltanto > questo: decimare le persone necessarie a far funzionare una > infrastruttura come quelle di GARR o altre organizzazioni pubbliche o > private? > > Tra l'altro i 5 rimasti devono limitarsi a fare 4 click su un "admin > panel". Beh no. Direi che il fine ultimo sarebbe lavorare tutte, lavorare meno. > Figuriamoci se io ho qualcosa contro l'automazione, il mio alter ego ci > lavora per l'automazione, ma non può sempre e _solo_ limitarsi tutto a > _risparmiare_ sugli stipendi. > > Infine, sarà anche che alla fine rimangono in 5 su 50 a gestire una > intrastruttura basata su kubernetes... ma prima o poi le cose cominciano > a non funzionare più con 4 click e allora... parte il _cinema_. > > [...] Giustissimo. Non c'è nulla di magico. E occorre conoscere approfonditamente le soluzioni per evitare casini mondiali. E' anche vero che con la standardizzazione, magari un po' di "bricolage" riusciamo ad ottenerlo anche dai meno tecnici. Il che ci potrebbe consentire di creare comunità più inclusive e orizzontali, non comunità dove pochi smanettoni fanno cose incomprensibili alle più. >> La chiave è l'automazione. Non la modalita' con la quale viene >> implementata. > Non vorrei dire ma per _sviluppare_ le librerie necessarie a rendere > _accessibile_ l'automazione nel "Infrastructure as Code" è necessario > tanto lavoro competente... ma a quello non ci pensa nessuno? > > Le "librerie" di Terraform, Ansible, Puppet, NixOS, Guix crescono sugli > alberi? > > [...] Al momento a finaziarle sono aziende multinazionali turbo-capitaliste (tranne NixOS e Guix, ovviamente). Del resto anche per il Kernel Linux è così. Qui c'è un recente articolo da leggiucchiare sulla scarsa resilienza di progetti trainati dal capitale (e sulle contromisure da prendere): https://www.jeffgeerling.com/blog/2024/corporate-open-source-dead D. (null)
Ciao Davide, grazie per i commenti e scusa se rispondo solo ora. Non voglio entrare nei dettagli tecnici più di quanto io abbia già fatto (in realtà ho cercato di stare sui principi tecnici, ma a volte le due cose si confondono). "D. Davide Lamanna" <davide.lamanna@binarioetico.it> writes:
On 5/3/24 15:24, 380° wrote:
[...]
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”. Iniziamo con un paio di concetti:
1. kubernetes è un sistema di gestione dei cluster, piuttosto complesso
[...]
Essere utilizzati di più, come sai, significa avere maggiore supporto dalla comunità, poter risolvere più facilmente i problemi, avere più documentazione, maggior affidabilità e stabilità, maggiore interoperabilità e integrazione...
con i miei commenti nei confronti di kubernetes non era mia intenzione denigrarlo, forse mi sono spiegato male [...]
Sono moderatamente d'accordo. Anche se più banalmente, secondo me, la difficoltà sta nella configurazione dettagliata di una molteplicità di risorse IT.
Esattamente, e siccome è il totale che fa la somma, sono i dettagli che rendono il tutto complicato... ma non vado oltre qui, ho già detto abbastanza
Il vantaggio è l'uniformità di queste configurazioni, l'opportunità di versionamento delle stesse e la centralizzazione della loro gestione.
Sì, è l'approccio Infrastructure As Code: quando funziona bene i vantaggi sono /stratosferici/, ma la differenza tra un sistema è l'altro è come poter intervenire (e a che livello) quando le cose non funzionano [...]
I sistemi di "cluster management for world sized cloud infrastructure" sono figli dell'/ideologia/ "pets vs cattle" [2]
Non so se si tratti di un'ideologia. Direi più un portato industriale.
Un portato di ideologia marketing, che non c'entra nulla con la sistemistica (informatica) e di conseguanza con l'Infrastructure As Code (che è un concetto di industrializzazione informatica) [...]
Rimanendo, però, con i piedi per terra, servono sia i pets che i cattle. Così come serve sia l'artigianato che l'industria.
Se vuoi far passare la cosa in questi termini fai pure ma stai andando fuori tema Tutto questo (sub)thread si è sviluppato sulle scelte _industriali_ di 37Signals in merito ai suoi prodotti: se li vuoi chiamare artigiani fai pure. :-) [...]
Come se i due insiemi descritti sopra fossero davvero _disgiunti_: sarà mica una cosa seria? (e infatti kubernetes usa il termine "Pet Sets" che l'autore dell'articolo sopra contesta... non proprio "rocket science" diciamo :-D )
Non ho mai sentito dire da nessuno che Kubernetes è rocket science.
Io non mi riferivo a kubernetes, ma alla definizione originale di "pets vs cattle": quella non è "rocket science", ognuno interpreta e adatta la definizione in merito alle proprie esigenze narrative. [...]
Tutto ciò ha portato alla /reificazione/ del concetto che i container sono _ephemeral_ by nature... tranne che i dati (https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FKube... ) e le configurazioni (https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FKube... ) che servono non lo sono affatto:
Non lo so se sia questo che abbia portato alla reificazione dei container. I namespace sono nel kernel di Linux dal 2002 e i cgroups dal 2006. Kubernetes è nato nel 2014. La storia dei container inizia negli anni '80 con chroot e per 3 decenni sono state proposte numerose variazioni sul tema, fino a quella che ha preso piede. Che non è necessariamente la migliore,
Sì è esattamente quello che prima Heinemeier e poi Damiano Verzulli hanno spiegato anche meglio di me: non esiste "la migliore", esiste la più adatta alle esigenze sistemistiche dei progetti (industriali) [...]
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. Questa "una parte" sarebbe Ansible? Ma Ansible è dichiarativo!
...ormai "tutto è dichiarativo" :-)... "Infrastrutcture as Code".
Ansible è dichiarativo,
ecco appunto, solo che molte persone, anche del settore, sono convinte che sia "procedurale" [...]
Ecco su questo vorrei espandere un po'. Sono soluzioni di nicchia, sicuramente interessanti ed eleganti, ma pochissimo utilizzate e quindi l'ecosistema a supporto è limitato.
mi avvalgo della facoltà di non rispondere :-) ...però se mi permetti un consiglio non richiesto: metti le mani in pasta, in /quella/ pasta. [...]
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. Confermo: la statefulness dei sistemi purtroppo a volte è _embedded_ nelle applicazioni che sono progettate proprio male [3]
Certo. Su questo non si può fare molto di più che odiare i programmatori.
Tranne che poi ai sistemisti tocca farli funzionare i sistemi [...]
Non è solo una questione di gusti, è che a parità di competenze l'approccio on-premises costa almeno un ordine di grandezza meno.
Ma dipende, in realtà, non generalizzerei. Bisogna farsi bene i conti. Dovrebbe essere questo il mestiere del Product Owner.
Ecco vedi che convergiamo :-) 37Signal è un product owner che ha saputo farsi bene i conti e ha documentato (bene, anche se sparso in enne articoli) il suo processo di analisi
In ogni caso, la questione dei costi mi interessa fino ad un certo punto. Quanto meno valuterei anche i benefici, che sono soggettivi, come il caso di Heinemeier dimostra.
Diciamo che io ho il motivato sospetto che il "caso di Heinemeier" farà scuola :-) [...]
Tra l'altro i 5 rimasti devono limitarsi a fare 4 click su un "admin panel".
Beh no. Direi che il fine ultimo sarebbe lavorare tutte, lavorare meno.
mi avvalgo della facoltà di non rispondere :-P [...]
Giustissimo. Non c'è nulla di magico. E occorre conoscere approfonditamente le soluzioni per evitare casini mondiali.
E' anche vero che con la standardizzazione, magari un po' di "bricolage" riusciamo ad ottenerlo anche dai meno tecnici.
No: serve più competenza per evitare "casini mondiali", molta più competenza
Il che ci potrebbe consentire di creare comunità più inclusive e orizzontali, non comunità dove pochi smanettoni fanno cose incomprensibili alle più.
Non so cosa vuol dire "comunità più inclusive"... e non lo voglio sapere :-) [...] Ciao e grazie! 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
participants (4)
-
380° -
D. Davide Lamanna -
Damiano Verzulli -
Giuseppe Attardi