On 2 May 2024, at 17:36, nexa-request@server-nexa.polito.it wrote:

From: Damiano Verzulli <damiano@verzulli.it>
To: nexa@server-nexa.polito.it
Subject: Re: [nexa] "...and... We've left the cloud!" - David
   Heinemeier Hansson / 37signals
Message-ID: <0b0bef9a-2901-40e5-84b0-2e8953522228@verzulli.it>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Il 02/05/24 9:30 AM, Giuseppe Attardi ha scritto:
Interessante, però…
Non sembra utilizzi un modello cloud con virtualizzazione, scalabilità
e resilienza.

Uhm....

Sicuramente non scende nei dettagli infrastrutturali di base (e quindi,
ad esempio, non fornisce indicazioni su quale hypervisor stia
utilizzando e quali tecnologie ci siano, subito sopra). Dubito
fortissimamente, pero', che sull'hardware che hanno documentato (
https://world.hey.com/dhh/the-hardware-we-need-for-our-cloud-exit-has-arrived-99d66966) non ci giri sopra un hypervisor e qualche tool di orchestrazione di
container: non compri 600.000 dollari di hardware da DELL... per farlo
funzionare "bare-metal" (senza virtualizzazione).

Di converso, in diversi punti cita sia l'esperienza negativa (costo) con
Suse / Rancher [1], sia il fatto che alla fine ha optato per scriversi
il suo orchestratore (Kamal [2][3]) che poggia su docker (e quindi
container... microservizi... etc) e che è sensibilmente piu' "semplice"
di tutto kubernetes (come biasimarlo?).

Kamal, da una breve scorsa alla documentazione, è qualcosa tipo Ansible, ti consente di eseguire comandi su vari server, in particolare lanciare app basate su container:
  1. Ensure Traefik is running and accepting traffic on port 80.
  2. Ensure your app responds with 200 OK to GET /up (you must have curl installed inside your app image!).
  3. Start a new container with the version of the app that matches the current git version hash.

Hanson spiega che Kubernetes è complesso e richiede competenze (appunto come sospettavo), perché è “dichiarativo”. 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. Se cambiano i requisiti, basta cambiare le specifiche e il sistema si riadatta ad esse in modo totalmente automatico.
È un sistema più complesso, ma una volta superato l’impatto dell’investimento iniziale, cominci a sfruttare i benefici con un fattore moltiplicativo rilevante, in funzione del numero di utenti, di server e di dinamicità.

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.

Da qui, mi sorge un dubbio: quando si puo' dire di "utilizzare un
modello cloud"? Piu' in generale: che significato diamo al termine "cloud"?

La domanda non e' cattiva...

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.

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 esempio, quando ci fu un temporale che fece mise fuori uso il datacenter INFN di Catania, fu possibile rilocare tutta la regione in un altro datacenter in pochissimo tempo.


Insomma: posso anche capire che l'esperienza di Heinemeier non sia
"accademicamente interessante" (...d'altronde a lui interessa il
business nudo e crudo), pero' sostenere il fatto che non sia "cloud"...
mi pare un pizzico eccessivo.


Da qui, ripeto, la domanda: secondo coloro che frequentano questo
gruppo... quand'e' che ci si puo' fregiare del titolo "siamo su cloud",
legittimamente?

La definizione ufficiale di cloud computing ha 5 requisiti:
On-demand self-service
Broad network access
Resource pooling
Rapid elasticity
Measured service



Io una mezza idea ce l'ho ma... se la applico, il numero di medagliette
che rilascio è *MOLTO* vicino a zero (perché per definirti "cloud", nel
mio mondo, devi partire dalle applicazioni... e non certo da quello che
hai. Risultato: nessuno lo fa...)

Bye,
DV


BTW: Scopro solo ora che Heinemeier è il creatore di Ruby on Rails... [4]

[1]
https://world.hey.com/dhh/the-only-thing-worse-than-cloud-pricing-is-the-enterprisey-alternatives-854e98f3

[2] https://world.hey.com/dhh/introducing-kamal-9330a267
[3] https://kamal-deploy.org/

[4] https://dhh.dk/


--

Damiano Verzulli
e-mail: damiano@verzulli.it