Linux minacciato dal cloud? Un dibattito senza risposte certe

non e' una moda, e' una necessita.

Gli sviluppatori sviluppano il codice, qualcuno deve farlo girare quel codice e possono essere gli sviluppatori stessi (cosa che preferisco) o i devops.

Qui non si sta parland di container etc, i container contengono gia' nel 99% dei casi una immagine di un SO (eg alpine linux) e deve essere mantenuta a tutti gli effetti e patchata se necessario.

Qui ci si lamenta che ci sono servizi tipo le Lambda che astraggono via il sistema operativo del tutto. E grazie al cielo che esistono.
Quante piccole medie aziende stanno veramente dietro alle patch di sicurezza del kernel linux e fanno deployment per tappare le falle?

Con le lambda tutto il patching e' gestito da AWS, invece con container, macchine virtuali etc in bocca al lupo, l overhead operativo del patching e' molto alto (anche solo stare dietro agli aggiornamenti del kernel, quante aziende lo fanno?) e spesso, quasi sempre, si va a finire che non viene fatto quindi ben venga l astrazione del sistema operativo.

Questo e' un punto di vista sbagliato. Se non disegni l applicativo per scalare orizzontalmente praticamente ti autocondanni alla riscrittura quando il business cresce. Questo e' un errore madornale per applicazioni create da zero, perche pensare una architettura scalabile e' incredibilmente meno faticoso che riadattare l esistente.

Sviluppare da zero nel 2021 senza prevedere la possibilita' di scalare in orizzontale, per lo meno entro ragionevoli limiti, e' una ricetta per il disastro. Nessuno chiede di sviluppare servizi multi regionali deployati in tutto il mondo con caching vicino i clienti etc etc, ma che tu riesca per lo meno a soddisfare piu richieste solo aggiungendo server e' il minimo, e poco piu del minimo ci sta fare uno studio e capire se l uso di un SQL e' veramente la scelta giusta visto gli enormi limiti di scalabilita' che hanno.

Pensa che io triturerei la tastiera di un buon numero di sviluppatroti con cui ho avuto a che fare...



Ok, e le lambda dove girano? Esatto, su un sistema linux. Quindi? Si sta solo spostando il problema ed erigendo pareti oltre le quali non si vuole vedere cosa c'è oltre. Il cloud è sempre e solo il computer di qualcun altro, da qui non si scappa.



Dissento sull'ultima frase, perché astrazione significa anche non avere il controllo.
Confondi kernel con SO, l'uno è una componente del secondo, ma non il contrario. Il patching va gestito comunque, a tutti i livelli, perché anche le librerie applicative le devi aggiornare, dato che di bachi ne escono parecchi anche lì. E per una distro linux "standard" non è che serva un gran ché, basta dare un giro di update/upgrade con i repo mantenuti dalle distro. Il problema nasce per il software installato fuori repo, lì sì che sono $falli. Per i container è ancora se possibile peggio, perché demandi ai devops la ricostruzione periodica di tutto l'ambaradan, e se qualcuno ha piantato nel dockerfile una versione del container di partenza le patch non le hai comunque (no, includere lo step di update come passo di costruzione del container non è una bella idea...), senza contare che questo può essere visto come operazione di "aggiornamento applicativo", e molte (troppe) aziende concentrano la forza di sviluppo sulla "next big thing" e non alla manutenzione dell'installato, salvo non ci siano problemi da correggere.

Quoto, anzi sono soprattutto le librerie applicative ad avere bisogno di aggiornamenti, dato che in fin dei conti quello è ciò che esponi in prima istanza (per ovvi motivi, senza l'applicazione mancherebbe la necessità di avere un sistema o un servizio su cui l'applicazione gira).
Patchare il sistema è tutto sommato semplice con un sistema tradizionale, può essere fatto in modo schedulato e non è un azzardo come molti credono (io lo faccio da quando esistono apt e yum e ho avuto pochissimi problemi, a prescindere da questi il rapporto costi/benefici è infinitamente superiore rispetto a gestire manualmente gli updates imho).

Pensare a una architettura e a una applicazione scalabile non significa necessariamente scalare o che la scalabilità (mi riferisco a quella orizzontale ovviamente) sia necessaria, perchè come dicevo 9 volte su 10 non lo è assolutamente, almeno dalla mia esperienza (e non parlo del sito della ditta pizza&fichi srl)

Quasi sempre la sofferenza in termini di performance viene interpretata come scarsità di risorse e necessità di scalare, quando invece i problemi nella maggior parte dei casi hanno natura applicativa, dalle classiche query scritte a "membro di segugio", indici mancanti, eccezioni non gestite, utilizzo di risorse di terze parti scorretto o che rappresentano colli di bottiglia, oppure analisi mal fatta.

Pensiamo ai classici casi da clickday, ok l'idea di base è assurda ma ahimè capitano.
Già solo pensare di affrontarli pensando prima di tutto alla scalabilità significa perdersi dei pezzi fondamentali e creare delle solide fondamenta ad un disastro annunciato.

Al mio gruppo di lavoro è capitato di affrontare casi del genere, con benefici fiscali (leggasi soldi regalati) ad una platea fino a un paio di milioni di potenziali utenti e la logica di base (assurda) era "chi prima arriva meglio alloggia, gli altri si attacchino al tram e urlino in curva".
In quel caso già solo disaccoppiare la fase di prenotazione della domanda per definire l'ordine di arrivo (es stacco il biglietto col numerino dal salumiere) dalla presentazione della stessa (complessa finchè vuoi ma "spalmata" su un lasso temporale più gestibile) ci ha permesso di affrontarla in totale scioltezza.
Scalabilità? Giusto due application server per garantire quel minimo sindacale di ridondanza, ma il carico era ampiamente gestibile con uno solo.

E parliamo di un caso limite, quanti gruppi di lavoro si trovano ad affrontare scenari da clickday? Pochissimi (e spero sempre meno in futuro, ma solo perchè spero che chi ha potere decisionale risavisca un po' visti i flop clamorosi osservati).

Poi ragazzi, onestamente negli ultimi 15 anni non ho più visto un progetto da Roma a Milano dove le risorse siano oggettivamente scarse (tolto forse lo storage, ma quello più per ragioni quantitative che prestazionali).
Posso capire finchè si parla del boom del web dei primi anni 2000, quando si un server scaccione, assemblato alla buona con pezzi di fortuna si doveva far girare tutto e il contrario di tutto, ma oggi oggettivamente i problemi per scarsità di risorse bisogna proprio andarseli a cercare (appunto con le rogne applicative di cui sopra).

"Basta dare un giro di update/upgrade". Si vede che non hai mai avuto a che fare con questi problemi, o comunque non ad una scala rilevante. Quando fai update/upgrade? Quando te ne ricordi? Oppure monitori costantemente i database di vulnerabilità note come fa AWS per te e interviene proattivamente, non aspettando di leggere la CVE in un sito di news tecnologiche generalista. E se sei tra queste mosche bianche ti rendi conto che il resto del mondo non é così?

Sai che un mese fa circa é uscita una CVE per il runtime python, tutte le versioni fino alla 3.8 affette, severità 9.8. Praticamente una catastrofe epocale. E praticamente tutti i SO Linux integrano il runtime python, quindi dubito fortemente che lo sviluppatore medio che deploya direttamente su VM si ricorda di monitorare quotidianamente le patch di sicurezza del runtime python e di patchare tempestivamente. Con le lambda AWS ha patchato il runtime in automatico a tutti i clienti in tempo zero. Con macchine virtuali? Beh ci sta da farsi il segno della croce.

Poi ovvio astrarre il SO non risolve tutti i problemi ma lascia agli sviluppatori solo le vulnerabilità strettamente in capo a loro.

Chi sottovaluta queste problematiche é perché semplicemente non se ne é mai preoccupato seriamente, e questo é proprio il motivo per cui é meglio che costoro non se ne occupino più. Per cui ripeto ben venga astrarre via il SO dove possibile.

E invece io questi problemi li ho visti. Ho lavorato in una startup passata da 30 a 400 dipendenti in 12 mesi, fatturato, volume di richieste e traffico letteralmente esploso. Database postgres in fiamme, query lente e caricamenti massivi di dati che impiegano ore, disperata ricerca di db admin esperti per capire come ottimizzare il tutto. Db scalato verticalmente fino al top possibile e poi solo molta pazienza da parte dei clienti.

Per non parlare della ridondanza. Con OVH che ha preso fuoco siamo ancora convinti che vogliamo avere codice e dati in un solo datacenter?

Bah, visto che assumi dall'altra parte ci sia sola bieca ignoranza, questa è la mia ultima risposta.
Hint: non fare assunzioni, che non sai mai chi ti sta scrivendo dall'altra parte.



La mosca bianca mi sa che sei tu, perché tutte le aziende di medio-grandi dimensioni hanno procedure codificate e standard di lavoro, quindi il patch è un'attività periodica, non "se mi ricordo".
E fidati che è molto più facile che siano allineati i sistemi operativi che le millemila librerie prese da sa il $divinita dove dagli sviluppatroti.



Talmente catastrofe che non esiste. O vogliamo anche confutare i CVE ora?

https://www.cvedetails.com/vulnerab...021/Python.html



Con le lambda paghi carissime operazioni che con le VM ti costerebbero una frazione.
Rileggi i miei messaggi, prima di commentare in modo sconclusionato... non ho mai negato che il cloud possa avere dei suoi vantaggi, ma non è di certo la soluzione ad ogni problema. E non tutte le applicazioni possono essere progettate od adattate a lavorare solo con chiamate serverless.



E 'vanti con lo spalare fango in faccia ad altri... ti rendi conto, vero, che tu sei uno e sulla Terra ci sono forse milioni di sistemisti? Mica generalizzi un po' troppo?



Appunto. Tipica mentalità da startup che non guarda oltre il proprio naso, perché pianificare è old-style.

Per esperienza personale tutto dipende dalla governance all'interno delle aziende, quindi della mera organizzazione.
Il problema del devops nelle piccole aziende o in quelle con poco budget é che si lascia implementare l'infrastruttura agli sviluppatori, nelle aziende piu' grandi e con una organizzazione che coniuga l'agile all'itil gli sviluppatori usano gli strumenti che gli mettono a disposizione gli admin.
Noi ad esempio siamo i garanti dei cluster kubernets e delle immagini docker, se lasciassimo agli sviluppatori mano libera quelli andrebbero a scaricare un sacco di merda da dockerhub e girarebbe tutto con configurazioni di default.
Ovviamente in piccole realtà non puoi permetterti di mettere su repo interni con tanto di cicd di controllo, scan delle immagini per le falle di sicurezza, immagini del SO personalizzate, etc, etc ed in questo amazon e gli altri principali provider fortunatamente ti danno una mano enorme, il problema é quando si lavora su piattaforme cloud private e si lascia ai devops (piu' dev che ops) sia il build che il run dei servizi.

Hint: ho lavorato per startup, ho lavorato per aziende di medie dimensioni e ora lavoro per forse la più grande azienda al mondo di sviluppo software, diciamo una FAANG, chiaramente all'estero. Non farò nomi perché ho firmato 11 pagine di NDA quando sono stato assunto. So di cosa parlo, forse sei tu quello che fa assunzioni senza cognizione di causa.