Linux minacciato dal cloud? Un dibattito senza risposte certe

Linux minacciato dal cloud? Un dibattito senza risposte certe

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

di pubblicata il , alle 15:01 nel canale Innovazione
Linux
 

Con l'avvento del cloud e la su presenza sempre maggiore all'interno delle aziende, ci si interroga su quale possa essere il futuro per le piattaforme "tradizionali" come Linux e Windows. Uno sviluppatore, Mariano Rentería, dà voce ad alcuni timori che emergono nella comunità e si interroga sull'impatto che il cloud avrà sullo sviluppo di Linux come piattaforma commerciale usata dalle aziende.

Il cloud porterà alla morte di Linux? Non proprio

Il dubbio che Rentería esprime nel suo articolo, Is AWS killing Linux? ("AWS sta uccidendo Linux?"), è che i servizi cloud come AWS, Azure e Google Cloud stiano portando le aziende sempre più verso modelli astratti in cui anche il sistema operativo non è più rilevante. Le direzione che i servizi cloud hanno intrapreso è quella di diventare strumenti che non hanno bisogno di conoscenze sul sistema utilizzato, né hanno bisogno di personale all'interno dell'azienda che si occupi della manutenzione, delle patch, della sicurezza e di tutti gli altri aspetti per cui è normalmente necessario avere a disposizione sistemisti Linux.

"Mi domando se l'amministrazione [di sistemi] Linux sarà ancora una realtà nel prossimo futuro, o una carriera che qualcuno vorrà intraprendere uscendo dall'università, e addirittura se sia qualcosa da raccomandare ai neolaureati, dal momento che noi professionisti dell'IT preferiamo consigliare sulla base delle esigenze future e non di quelle attuali", scrive Rentería.

La questione non è banale, dato che l'uso degli strumenti nativi del cloud richiede spesso competenze differenti rispetto all'uso delle macchine classiche, e non richiede la stessa competenza nella loro amministrazione. Una larga parte della manutenzione è infatti affidata ai provider stessi, che richiedono molto meno personale rispetto al numero di clienti che servono.

Dall'altro lato, però, la conoscenza necessaria per utilizzare strumenti come Docker, Kubernetes e così via resta fortemente legata al mondo Linux, per quanto sia differente rispetto a quella più "classica". È probabile dunque che ci sarà un cambiamento nel mondo dell'amministrazione di sistema, ma le competenze di base resteranno necessarie e dovranno essere integrate con altre più specifiche riguardo i singoli fornitori di servizi cloud e le loro funzionalità particolari.

Il dibattito resta comunque aperto e passibile di interpretazioni personali, che vi invitiamo a condividere nei commenti.

27 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
jepessen05 Maggio 2021, 15:27 #1
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...
matsnake8605 Maggio 2021, 15:39 #2
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.....
io78bis05 Maggio 2021, 15:45 #3
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à.
Tasslehoff05 Maggio 2021, 15:53 #4
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.
ZioMatt05 Maggio 2021, 16:18 #5
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.
Tasslehoff05 Maggio 2021, 16:48 #6
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...
Tasslehoff05 Maggio 2021, 17:02 #7
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...
acerbo05 Maggio 2021, 18:09 #8
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.
acerbo05 Maggio 2021, 18:18 #9
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
lollo905 Maggio 2021, 21:51 #10
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.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^