Linux minacciato dal cloud? Un dibattito senza risposte certe

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

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

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

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.

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

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

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.

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.