Linux minacciato dal cloud? Un dibattito senza risposte certe

Y

CVE-2021-3177 https://nvd.nist.gov/vuln/detail/CVE-2021-3177

Informati meglio prima di parlare, il tuo link usa CVSS 2, che è uno scoring obsoleto, ora si tende a usare il CVSS 3 che è considerato più sicuro. Sei l ennesima riprova del perché sia meglio che la gestione dell'OS sia levata dalle mani dello sviluppatore / sistemista medio quando possibile.

A me di recente è capitato un problema simile su un portale opendata, bombardato di richieste (lecite) dopo che è stato premiato in non so quale concorso.
In questo caso a essere sovraccarico era l'application server, ma poco cambia.

Nonostante ci fossero chiare evidenze di problemi applicativi, riscontrate persino su diverse issue sulla pagina Github del progetto che hanno portato a una patch ufficiale, il cliente ha voluto scalare (anche in quel caso verticalmente) per non "rischiare" con l'installazione di un aggiornamento (procedura documentata, già testata, sicura, rollback tranquillo etc etc etc...)

Problema risolto? No.
Problema tamponato, ma ci sono già i primi segnali di degrado prestazionale e li aspettiamo al varco perchè sappiamo tutti benissimo che quando il problema è applicativo, scalare (orizzontalmente o verticalmente) non risolve nulla in casi come questo, e in fin dei conti sono in assoluto i più frequenti.

Aspetta, il disaster recovery è tutto un altro film.
Se mi parli di CDN posso essere d'accordo (e quello è un esempio eclatante di SaaS su cui i provider cloud possono dare un contributo decisivo, anche solo per il fatto che fare qualcosa di simile in proprio è, non dico impossibile, ma decisamente sfidante), ma poi ci fermiamo li; lasciami dire però che in quel caso parliamo di qualcosa che esiste dalla notte dei tempi, ben prima che containers, orchestrators, supercazzole serverless e simili fossero anche solo concepite nelle menti malate dei venditori di fumo, credo siano passati più di 10 anni dalla prima volta in cui su un progetto abbiamo usato Akamai come CDN, quindi non è certo una novità.

L'idea di far passare il traffico applicativo tra servizi che stanno in regioni diverse è assurdo, già solo i problemi di I/O basterebbero per evitare come la peste una soluzione del genere.
Io ho lavorato su un paio di progetti dove qualcuno ha provato a farlo (per altri motivi, ma la sostanza non cambia) ed è stato pianto e stridore di denti.
Mi ricordo ancora le jvm in thread starvation e la garbage collection impazzita...

Il caso di OVH è un'altra storia, il problema in quel caso è che i backup (per chi li aveva e se n'era preoccupato) stavano nella stessa location dei servizi.
Pensare di clusterizzare un servizio mettendo un nodo a Bankok, uno a Berlino, uno a Parigi e uno a Canicattì non ha senso e provoca più problemi dei vantaggi che potresti avere in termini di ridondanza imho.

come sempre dipende, non puoi dire che un sistema è sempre più caro di un altro senza considerare i casi d'uso e i vari profili di utilizzo (soprattutto con le politiche di pricing variabili che usano i vari provider cloud)

ad esempio io ho un paio di sistemi che girano con lambda e non ci penserei mai di metterli su macchine virtuali, hanno relativamente poche richieste, sono hostate su account dei clienti e non abbiamo la minima intenzione di dover gestire altri server, con il costo di una giornata di lavoro di un sistemista ne paghi di richieste lambda

Concordo sul multiregione, non è sempre, anzi spesso non é necessario, ma molti Cloud provider seri hanno più datacenter fisicamente isolati nella stessa regione (e non a 20m di distanza), in quel caso avere un servizio attivo su due datacenter dietro un load balancer e magari il db quantomeno in replica in entrambi i DC non sarebbe male. Se salta uno il traffico viene preso interamente dall'altro.

Uno potrebbe anche non scalare orizzontalmente e fare un fallback se la prima regione è impattata, ma in genere queste operazioni prevedono downtime e intervento manuale (poi ovviamente dipende) quindi se il servizio scala orizzontalmente di suo questo non accade. Se invece hai un load balancer fatto bene puoi distribuire il carico in automatico tra i servizi Poi ogni architettura é un caso a parte ma questa é in generale l idea.

Ti invito a riportarmi dove abbia scritto che si tratti di una mistica previsione sul futuro del kernel. No, non diventa magicamente nulla quell'articolo, diventa solo uno spunto di riflessione e discussione, motivo per cui ho invitato a esprimere la propria opinione in chiusura del pezzo.
Il motivo per cui non ho incluso tutto ciò che ha scritto lo sviluppatore in questione è proprio perché ritenevo che altre cose non fossero corrette.

Forse mi sono espresso male io e quello che ho scritto era facilmente fraintendibile, ma la mia critica non era rivolta a voi (o a te se nello specifico ti sei occupato dell'articolo) ma a questo Mariano Rentería e a quanti pensano le stesse cose.

L'articolo in se ci sta e imho è un buono spunto di riflessione, c'è tanta gente che si illude che magicamente con il cloud i problemi infrastrutturali non esisteranno più e chiunque sarà in grado di progettare e configurare architetture complesse buttando quattro istruzioni in un banale file yaml, o che queste automagicamente si possano manutenere da sole...

Ti ringrazio per il chiarimento. Concordo con il tuo pensiero: il cloud ha molti punti di forza, ma non è meno complesso dei sistemi tradizionali (anzi, per moti versi lo è di più!). Mi ci sono scontrato a inizio anno, seguendo un piccolo progetto: anche solo capire da dove cominciare è abbastanza un'impresa, tra mille immagini senza spiegazioni e opzioni oscure di cui non è chiaro il funzionamento se si è inesperti. Insomma, ce n'è ancora di strada da fare per rendere "democratico" l'IT...