Linux minacciato dal cloud? Un dibattito senza risposte certe

[xarz3]

Originariamente inviato da ZioMatt

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/vulnerabi...21/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.

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.

[xarz3]

Y

Originariamente inviato da ZioMatt

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/vulnerabi...21/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.

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.

[Tasslehoff]

Originariamente inviato da xarz3

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.

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.

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

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.

[!fazz]

Originariamente inviato da ZioMatt

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/vulnerabi...21/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.

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

[xarz3]

Originariamente inviato da Tasslehoff

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.

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.

[Slater91]

Originariamente inviato da Tasslehoff

Cioè fatemi capire, pigliate un post scritto da un blogger sviluppatore e magicamente questo diventa una mistica previsione sul futuro del kernel su cui praticamente gira il mondo intero dell'informatica e della figura professionale che lo sostiene?

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.

[Tasslehoff]

Originariamente inviato da Slater91

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...

[Slater91]

Originariamente inviato da Tasslehoff

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...