Linux minacciato dal cloud? Un dibattito senza risposte certe

[Redazione di Hardware Upg]

Link alla notizia: https://edge9.hwupgrade.it/news/inno...rte_97391.html

Uno sviluppatore, Mariano Rentería, si domanda se Linux e i posti di lavoro a esso collegati siano minacciati dalla crescita del cloud, riaprendo un dibattito che non vede risposte chiare e nette

Click sul link per visualizzare la notizia.

[jepessen]

E' perche' dovrebbe uccidere Linux? Semmai il contrario. Avere l'astrazione del sistema operativo e' un vantaggio indiscusso che permette alle aziende ed agli sviluppatori di disaccoppiare il sistema di sviluppo, da quello di test, a quello di produzione. Se al momento ci sono macchine windows per il testing, nulla vieta a questo punto di utilizzare macchine linux. Fra l'altro le applicazioni anche se containerizzate devono comunque girare sui PC, e sui PC ci sono i sistemi operativi, quindi non vedo perche' dovrebbe frenarne lo sviluppo...

[matsnake86]

Non ho capito dove vuole arrivare.....

Ormai anche MS usa linux per azure.
Su windows stesso si può installare un subsystem linux che è una figata...

Forse quello che intende lui è che andando sempre più verso il cloud la figura del sistemista potrebbe diventare superflua in molte aziende...

MA ad ogni modo i server di tutto il mondo o girano su kernel linux o su NT....

Non ho capito cosa c'entri il discorso su docker e vari...
Chi usa queste cose solitamente sa che cosa c'è sotto il cofano.....

[io78bis]

Originariamente inviato da jepessen

E' perche' dovrebbe uccidere Linux? Semmai il contrario. Avere l'astrazione del sistema operativo e' un vantaggio indiscusso che permette alle aziende ed agli sviluppatori di disaccoppiare il sistema di sviluppo, da quello di test, a quello di produzione. Se al momento ci sono macchine windows per il testing, nulla vieta a questo punto di utilizzare macchine linux. Fra l'altro le applicazioni anche se containerizzate devono comunque girare sui PC, e sui PC ci sono i sistemi operativi, quindi non vedo perche' dovrebbe frenarne lo sviluppo...

A me dall'articolo sembra che sia più preoccupato dalla scomparsa della figura del sistemista IT interno all'azienda piuttosto che Linux.

Sicuramente il cloud non ucciderà Linux, la necessità di sistemisti/amministratori Linux subirà una flessione ma non credo sparirà.

[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?

Peraltro l'articolo linkato contiene una serie di castronerie, tipo l'idea terrificante che Amazon possa farsi il suo sistema operativo.
Embè? L'ha già fatto 10 anni fa, si chiama Amazon Linux ed è uno delle tante distribuzioni derivate da RedHat Linux
Altro kernel? E a che scopo? Far pagare una licenza per non dover ricadere nei vincoli di licenza del kernel di Linux e finire per essere abbandonata da tutti? Mi sembra alquanto autolesionista, senza contare che nessuno sano di mente si metterebbe a progettare e sviluppare un kernel nuovo da zero, sarebbe una follia.
Ad Amazon interessa incentivare l'uso dei suoi servizi, non far fuggire gli utenti verso altri lidi.

Ma il guru di cui sopra non si è accorto che i servizi più utilizzati sul cloud sono proprio istanze, di fatto macchine virtuali?
E qual'è il software che gira prima di tutto su queste macchine? Esatto, il sistema operativo.
E qual'è il kernel più utilizzato su queste macchine? Esatto Linux...
E chi le deve installare, configurare, manutenere, amministrare? Esatto, proprio i sysadmin che l'onniscente Mariano da per spacciati...


Forse il guru di cui sopra, non a caso uno sviluppatore, pensa che tutto il software di questo mondo sia stateless, che tutto sia riconducibile a qualche mitico microservizio senza alcun repository, e quindi sia tutto trasformabile in magici container che possono scalare all'infinito, mentre chiunque abbia un minimo di esperienza sa benissimo che solo certe applicazioni possono concedersi questo lusso, e nel caso uno voglia usare qualche servizio di object storage o database as service deve pagarlo a peso d'oro.

Poi secondo il suddetto i servizi su cui girano le applicazioni si manutengono automagicamente, e più passa il tempo più migliorano, come un buon vino d'annata... mentre invece sappiamo tutti che inacidiscono e scoppiano sommersi da eccezioni che proprio gli sviluppatori come il suddetto non fanno niente per gestire e finiscono per azzoppare qualsiasi servizio (sia che giri dentro un container o no).

Ma naturalmente tutto questo non gli è passato per l'anticamera, così come le implicazioni del "cloud" sui costi, che magicamente lievitano rispetto ad architetture tradizionali o altre forme di provisioning, senza contare il fatto che su cloud è praticamente impossibile fare una previsione esatta dei costi.

Ma tutto questo non lo preoccupa nemmeno per sbaglio, e questo è normale, lui è uno sviluppatore, quando qualcosa gira sul suo ide e il deploy in produzione è fatto tutto va bene, tutto è perfetto, il lavoro è finito e si può passare ad altro...

Classico caso di approccio miope da parte di chi vede solo il suo "pezzettino" e ignora l'universo che ci sta dietro, ma poi del resto è la filosofia che sta dietro anche ai container, nati da sviluppatori per sviluppatori, e poi adottati in produzione da gente che non ha la minima idea delle criticità a cui si espone.

[ZioMatt]

Originariamente inviato da Tasslehoff

Classico caso di approccio miope da parte di chi vede solo il suo "pezzettino" e ignora l'universo che ci sta dietro, ma poi del resto è la filosofia che sta dietro anche ai container, nati da sviluppatori per sviluppatori, e poi adottati in produzione da gente che non ha la minima idea delle criticità a cui si espone.

Ti quoto l'ultima frase ma appoggio in pieno tutto il post che hai scritto.
Da sistemista, vedo sempre più una "mitizzazione" del Cloud, qualcosa di aleatorio mistico e immateriale che risolve tutti i problemi dell'universo compresa la fame del mondo, che non richiede manutenzione né personale per la sua gestione.

BALLE!

Chi pensa così (ed il brutto è purtroppo che a farlo è soprattutto il manglement...) si scontrerà molto presto contro un muro, e molto dolorosamente anche.

Il cloud ha innegabili vantaggi, tra cui la scalabilità e l'assenza di infrastrutture locali da mantenere, ma l'unico sistemista di cui puoi fare a meno è quello di primo livello che fa "rack&stack" delle apparecchiature. Tutto il resto ti serve ancora, e anzi più di prima perché devono nascere delle figure dedite all'ottimizzazione dei servizi perché tutto ciò che è acceso inutilmente a fine giornata ti costa bei soldi e non puoi permetterti come faresti on prem di lasciare attive ma idle un tot di VM perché "metti caso che"...
Anzi, la figura che a rigor di logica sparisce non è tanto quella del sistemista ma il contorno: impiantisti, elettricisti, frigoristi, gestori di UPS e genset, condizionamento, ...

Non serve fare patch? Ah no? Perché i container (mezzo aborto, IMHO, perché confondono sistema/ambiente con applicazione) non vanno ricreati ed aggiornati all'uscita della versione X+1 di $libreria o $appserver? Non farlo è esattamente come lasciare applicativi non aggiornati in esecuzione su macchine "tradizionali", non è che perché sono in container salvi da vulnerabilità ed errori applicativi, è solo un modo più comodo di impacchettare il tutto.

[Tasslehoff]

Originariamente inviato da ZioMatt

Ti quoto l'ultima frase ma appoggio in pieno tutto il post che hai scritto.
Da sistemista, vedo sempre più una "mitizzazione" del Cloud, qualcosa di aleatorio mistico e immateriale che risolve tutti i problemi dell'universo compresa la fame del mondo, che non richiede manutenzione né personale per la sua gestione.

BALLE!

Chi pensa così (ed il brutto è purtroppo che a farlo è soprattutto il manglement...) si scontrerà molto presto contro un muro, e molto dolorosamente anche.

Il cloud ha innegabili vantaggi, tra cui la scalabilità e l'assenza di infrastrutture locali da mantenere, ma l'unico sistemista di cui puoi fare a meno è quello di primo livello che fa "rack&stack" delle apparecchiature. Tutto il resto ti serve ancora, e anzi più di prima perché devono nascere delle figure dedite all'ottimizzazione dei servizi perché tutto ciò che è acceso inutilmente a fine giornata ti costa bei soldi e non puoi permetterti come faresti on prem di lasciare attive ma idle un tot di VM perché "metti caso che"...
Anzi, la figura che a rigor di logica sparisce non è tanto quella del sistemista ma il contorno: impiantisti, elettricisti, frigoristi, gestori di UPS e genset, condizionamento, ...

Non serve fare patch? Ah no? Perché i container (mezzo aborto, IMHO, perché confondono sistema/ambiente con applicazione) non vanno ricreati ed aggiornati all'uscita della versione X+1 di $libreria o $appserver? Non farlo è esattamente come lasciare applicativi non aggiornati in esecuzione su macchine "tradizionali", non è che perché sono in container salvi da vulnerabilità ed errori applicativi, è solo un modo più comodo di impacchettare il tutto.

Esattamente, da un certo punto li capisco anche i manager che si lasciano infinocchiare e buttano quantità di risorse improponibili per migrazioni più o meno improbabili su container.
Per loro stessa natura i manager non sanno confrontarsi con la complessità tecnica, per loro è tutto "quantitativo", ad ogni problema c'è sempre una soluzione quantitativa.
Quante giornate uomo? Quante licenze? Quante risorse?

Ergo per loro la scalabilità è la perfetta soluzione ad ogni problema tecnico, è la soluzione quantitativa definitiva, e i container promettono appunto questo (poi è un dettaglio se l'applicazione è stateful e la scalabilità è un miraggio... ).
Riproducibilità, versionamento, isolamento dei processi all'interno del container, tutto questo non li tange minimamente, la scalabilità è la risposta a tutto...
Poi però si scopre che in realtà, a meno che tu non sia Netflix o Facebook o Amazon o [aggiungere big a caso che offre servizi livello globale], della scalabilità essenzialmente non sai che fartene, perchè 9 volte su 10 i problemi prestazionali sono il risultato di problemi applicativi, eccezioni non gestite, servizi di terze parti che non rispondono correttamente o che rappresentano colli di bottiglia, etc etc... (***)
Di conseguenza l'unico effetto della scalabilità orizzontale è: più eccezioni/sec

*** = e qui vorrei fare due chiacchere con l'amico Mariano citato nell'articolo...

[Tasslehoff]

Originariamente inviato da matsnake86

Non ho capito cosa c'entri il discorso su docker e vari...
Chi usa queste cose solitamente sa che cosa c'è sotto il cofano.....

Ahimè su questo la mia esperienza è esattamente l'opposto, spesso è proprio chi spinge per i container ad aver poco chiaro cosa c'è sotto il cofano, e spesso costoro sono proprio coloro che sviluppano i servizi, non coloro che li devono manutenere e amministrare.

Come dicevo per lo sviluppatore il problema è semplice: se gira sul container sul mio ambiente di sviluppo allora gira in produzione, problema risolto.

Poi quando un sistemista ci mette il naso dentro (solitamente dopo che i problemi sono esplosi e nessun altro riesce a capirci nulla) si scoperchia il vaso di pandora ed escono le peggio porcate.
Servizi che girano dentro il container esposti a web anche se non dovrebbero, porcate tipo comunicazione tra container che passano da web perchè nessuno si è preoccupato di creare una rete dedicata tra loro, ma giusto per citarne un paio di tanti, forse i più frequenti che mi è capitato di incontrare...

A questo aggiungi un aumento di complessità non indifferente, anche solo gestire qualcosa che solitamente è semplice come il logging (semplice nel senso di un append di stdout e stderr su file) diventa di una complessità mostruosa, tirando in causa servizi prima non necessari come syslog (quindi maggiore complessità --> più cose che si romperanno) o veri e propri polpettoni applicativi (es stack ELK), spesso per assurdo più complessi ed elefantiaci delle applicazione da cui devono ricevere i log...
In alternativa puoi sempre fare come tanti sviluppatori e lasciare i log sul container (senza volumi persistenti, vogliamo scalare giusto? Ok go stateless... ), poi al prossimo aggiornamento del container perdi tutto...

[acerbo]

l'os piu' installato nelle istanze azure é linux, credo che questo dato dia la misura dell'inutilità di questo articolo.
Che poi l'os diventerà sempre meno importante é un dato di fatto, ma da qui a dire che uno vale l'altro é un'ipotesi ben lontana dalla realtà.
Lavoro da qualche mese su un progetto docker ed il cliente ci chiede di deployare immagini distroless per questioni di sicurezza e, a parte qualche prodotto di nicchia, la maggior parte dei sw hanno ancora bisogno di un sacco di librerie di sistema, quindi che sia un OS completo o "minimal" linux serve sempre, anche nei containers.

[acerbo]

Originariamente inviato da Tasslehoff

Ahimè su questo la mia esperienza è esattamente l'opposto, spesso è proprio chi spinge per i container ad aver poco chiaro cosa c'è sotto il cofano, e spesso costoro sono proprio coloro che sviluppano i servizi, non coloro che li devono manutenere e amministrare.

Come dicevo per lo sviluppatore il problema è semplice: se gira sul container sul mio ambiente di sviluppo allora gira in produzione, problema risolto.

Poi quando un sistemista ci mette il naso dentro (solitamente dopo che i problemi sono esplosi e nessun altro riesce a capirci nulla) si scoperchia il vaso di pandora ed escono le peggio porcate.
Servizi che girano dentro il container esposti a web anche se non dovrebbero, porcate tipo comunicazione tra container che passano da web perchè nessuno si è preoccupato di creare una rete dedicata tra loro, ma giusto per citarne un paio di tanti, forse i più frequenti che mi è capitato di incontrare...

A questo aggiungi un aumento di complessità non indifferente, anche solo gestire qualcosa che solitamente è semplice come il logging (semplice nel senso di un append di stdout e stderr su file) diventa di una complessità mostruosa, tirando in causa servizi prima non necessari come syslog (quindi maggiore complessità --> più cose che si romperanno) o veri e propri polpettoni applicativi (es stack ELK), spesso per assurdo più complessi ed elefantiaci delle applicazione da cui devono ricevere i log...
In alternativa puoi sempre fare come tanti sviluppatori e lasciare i log sul container (senza volumi persistenti, vogliamo scalare giusto? Ok go stateless... ), poi al prossimo aggiornamento del container perdi tutto...

questi purtroppo sono gli effetti della nuova moda chiamata devops, ma dipende sempre dalla bontà degli sviluppatori, fortunatamente ce ne sono sempre di piu' che si interessano al sistema e comprendono le necessità di un servizio che deve girare in produzione e non solo su un POC

[lollo9]

Originariamente inviato da acerbo

questi purtroppo sono gli effetti della nuova moda chiamata devops, ma dipende sempre dalla bontà degli sviluppatori, fortunatamente ce ne sono sempre di piu' che si interessano al sistema e comprendono le necessità di un servizio che deve girare in produzione e non solo su un POC

“nuova moda” ormai nemmeno, siamo ben oltre il devops.
se poi sistemisti reinventatisi devops e programmatori fanno porcate senza conoscere un H di architetture cloud giusto perché hanno imparato a scrivere una pipeline YML è un discorso differente.
di wannabes è sempre stato pieno il mondo IT, tanto di programmatori quanto di sistemisti.

Se tutto si sta muovendo verso modelli Qualcosa-as-service, non è solo perché i manager son tutti scemi e buttano milioni per ferri che potrebbero avere onprem, c’è anche un’offerta d’infrastruttura che garantisce margini migliori per chi i prodotti invece li crea/vende.
Noi da baraccone onprem da minimo 50K l’anno adesso riusciamo ad aggredire anche il mercato della piccola e media impresa grazie proprio alla flessibilità ed allo scaling del cloud, ed il costo di entrata lo riusciamo a vendere da 10€/seat.
Chiaro che poi sta a noi non fare porcate con gli orchestrators/gateway/vaults/etc. e tenere tutto stateless, ma queste erano buone pratiche anche 25 anni fa agli albori dei microservizi.

[xarz3]

Originariamente inviato da acerbo

questi purtroppo sono gli effetti della nuova moda chiamata devops, ma dipende sempre dalla bontà degli sviluppatori, fortunatamente ce ne sono sempre di piu' che si interessano al sistema e comprendono le necessità di un servizio che deve girare in produzione e non solo su un POC

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.

[xarz3]

Originariamente inviato da Tasslehoff

Esattamente, da un certo punto li capisco anche i manager che si lasciano infinocchiare e buttano quantità di risorse improponibili per migrazioni più o meno improbabili su container.
Per loro stessa natura i manager non sanno confrontarsi con la complessità tecnica, per loro è tutto "quantitativo", ad ogni problema c'è sempre una soluzione quantitativa.
Quante giornate uomo? Quante licenze? Quante risorse?

Ergo per loro la scalabilità è la perfetta soluzione ad ogni problema tecnico, è la soluzione quantitativa definitiva, e i container promettono appunto questo (poi è un dettaglio se l'applicazione è stateful e la scalabilità è un miraggio... ).
Riproducibilità, versionamento, isolamento dei processi all'interno del container, tutto questo non li tange minimamente, la scalabilità è la risposta a tutto...
Poi però si scopre che in realtà, a meno che tu non sia Netflix o Facebook o Amazon o [aggiungere big a caso che offre servizi livello globale], della scalabilità essenzialmente non sai che fartene, perchè 9 volte su 10 i problemi prestazionali sono il risultato di problemi applicativi, eccezioni non gestite, servizi di terze parti che non rispondono correttamente o che rappresentano colli di bottiglia, etc etc... (***)
Di conseguenza l'unico effetto della scalabilità orizzontale è: più eccezioni/sec

*** = e qui vorrei fare due chiacchere con l'amico Mariano citato nell'articolo...

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.

[ZioMatt]

Originariamente inviato da xarz3

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

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

Originariamente inviato da xarz3

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.

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.

Originariamente inviato da xarz3

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.

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.

[Tasslehoff]

Originariamente inviato da ZioMatt

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

[Tasslehoff]

Originariamente inviato da xarz3

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.

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

[xarz3]

Originariamente inviato da ZioMatt

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.

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

[xarz3]

Originariamente inviato da Tasslehoff

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

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?

[ZioMatt]

Originariamente inviato da xarz3

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

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.

Originariamente inviato da xarz3

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ì?

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.

Originariamente inviato da xarz3

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.

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

https://www.cvedetails.com/vulnerabi...21/Python.html

Originariamente inviato da xarz3

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.

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.

Originariamente inviato da xarz3

Chi sottovaluta queste problematiche é perché semplicemente non se ne é mai preoccupato seriamente,

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?

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

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

[acerbo]

Originariamente inviato da ZioMatt

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.

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.