In che modo un reparto IT dovrebbe scegliere una distribuzione Linux standard?

Soluzione 1:

Condividerò le mie esperienze di lavoro come tecnologo in diversi campi...

(Attenzione:questa è una storia su Red Hat e su come sono cresciuto professionalmente con essa)

Ho iniziato a lavorare professionalmente con Linux nel 2000-2002. Ciò è avvenuto durante l'ampia adozione di Red Hat e delle edizioni Red Hat Professional (6.x, 7.x, 8.0). Questi erano disponibili per il download gratuito così come i set confezionati in scatola. Potrebbero essere facilmente trovati nei negozi al dettaglio di computer.

Per me, questo ha avuto il vantaggio di coinvolgere hobbisti e utenti domestici con lo stesso prodotto che cominciava ad emergere nell'impresa. Il mio lavoro in quel momento consisteva nel trasferire i sistemi server dei clienti da Unix commerciali (HP-UX, AIX e SCO) alla piattaforma Red Hat.

Il risparmio sui costi è stato notevole! La sostituzione di server PA-RISC HP9000 da oltre 100.000 dollari con server Compaq ProLiant Intel da 40.000 dollari è stata una vittoria assoluta in termini di costi e prestazioni.

Allora, perché Red Hat?

Red Hat è stata la prima a entrare in questo mercato, ottenendo un supporto critico per le aziende, i fornitori e l'hardware. Vedere i fornitori di applicazioni di grandi dimensioni utilizzare Red Hat come piattaforma di destinazione ha sigillato l'affare. Gli utenti hobbisti come me sono stati in grado di trasferire facilmente le abilità affinate a casa nei nostri ambienti di lavoro. La comunità stava crescendo. Gli stack Slashdot, Freshmeat e LAMP hanno dominato! Era un buon momento per Linux.

A questo punto, ero responsabile dello sviluppo e della valutazione delle distribuzioni Linux come piattaforma per una soluzione software ERP proprietaria. Sono rimasto con Red Hat. Ogni tanto, provavo un'altra distribuzione (Mandrake, SuSE, Debian, Gentoo), ma trovavo problemi con il packaging, il supporto hardware (server o periferiche), la (dimensione del) community o qualche altro rompicapo.

Un esempio:stavo usando hardware Compaq/HP ProLiant dotato di schede PCI-X di espansione Digi Serial e software fax di produzione Esker VSIfax. Gli ultimi due avevano solo il supporto dei driver per i sistemi operativi Red Hat. In alcuni casi, il software veniva fornito solo in formato binario o RPM, precludendo un facile utilizzo su altre varianti di Linux.

Lo slancio è importante nel mondo dell'Information Technology
Nessuno vuole essere uno che consiglia di perdere soluzione o progetto che alla fine diventa orfano, quindi ti attieni a scelte sicure. Stavo gestendo uno stack tecnologico che doveva funzionare in modo affidabile e avere diversi livelli di supporto. Scegliere una distribuzione diversa a quel punto sarebbe stato giusto. stato. irresponsabile.

La luna di miele di Red Hat si è conclusa per me nel 2003 con l'interruzione delle edizioni professionali del software. Red Hat Enterprise Linux è stato il sostituto e ha portato con sé un po' di bagaglio... Costo (costoso modello basato su abbonamento), accessibilità (riducendo la base di utenti e la comunità) e confusione generale sul futuro...

Ho iniziato a cercare alternative, rivalutando Gentoo, Debian e SuSE. Non sono riuscito a ottenere il giusto supporto su tutti i componenti del nostro stack tecnologico. Sono stato costretto a rimanere fedele all'ecosistema Red Hat... A causa del selvaggio spostamento dei costi associato a Red Hat Enterprise Linux, ho finito per eseguire un Red Hat 8.0 altamente modificato per anni oltre il suo fine vita. È stato solo quando i cloni RHEL sono maturati (Whitebox Linux e, successivamente, CentOS) che ho preparato un vero allontanamento dal mio standard.

Il principale vantaggio dei derivati ​​di Red Hat era ed è compatibilità binaria con le versioni RHEL a pagamento. È persino possibile eseguire conversioni sul posto tra RHEL e CentOS e viceversa. Ho continuato a lavorare con sistemi simili a RHEL fino a quando non ho fatto la prossima mossa di carriera...

Successivamente mi sono ritrovato nel settore del trading finanziario ad alta frequenza, dove ero responsabile della ricerca e sviluppo e dell'ingegneria Linux per i sistemi di trading automatizzati critici. L'enfasi in questo mondo era la velocità , mediante accurati test e messa a punto. Ancora una volta, il supporto hardware è stato fondamentale. Avrei schede di rete specifiche, hardware specializzato, hardware del server o librerie di applicazioni certificate solo per sistemi RHEL o simili a RHEL. Anche nei casi in cui le cose potevano essere compilate per altre varianti di Linux, è sorto il fattore community. Quando ero al punto in cui avevo bisogno di ricercare un problema, spesso si trattava di un problema che poteva essere ricondotto a note o commenti nei report di Red Hat Bugzilla, o talvolta, inviavo semplicemente una patch o una richiesta per la prossima versione .

Quando ho iniziato ad approfondire il networking a bassa latenza e l'ottimizzazione del kernel, ho iniziato a sezionare i kernel RHEL di serie e i kernel RHEL MRG Realtime. Ho notato quanto lavoro quando nei rilasci ... 200+ patch a un kernel vanilla kernel.org. Leggi i commenti e le note di impegno. Potresti avere piccole cose come sysctl parametri esposti o impostazioni predefinite più sensate applicate. Red Hat paga persone per correggere, testare e risolvere questi problemi. Non ho visto lo stesso impegno da altre distribuzioni Linux... Aggiungi il fatto che la piattaforma aziendale è garantita per avere sicurezza reale, correzione di bug e supporto backport per anni .

Così alla fine mi sono trasferito in un'altra società finanziaria che era quasi tutta Gentoo sul server e desktop... È stato un disastro per me. Venendo dal mondo Red Hat e CentOS, ho riscontrato numerosi problemi di stabilità e gestione con l'installazione di Gentoo. Il controllo della versione era il problema più grande, ma anche la diminuzione del supporto della comunità e la mancanza di test reali erano preoccupazioni. Ho iniziato a introdurre RHEL nell'ambiente perché alcuni dei nostri software di terze parti lo richiedevano...

Ma c'era un problema... I miei sviluppatori erano abituati a Gentoo e avevano percorsi di aggiornamento relativamente semplici per le librerie principali e le versioni delle applicazioni. Non potevano adattarsi ad avere le versioni principali fisse su cui standardizza Red Hat Enterprise Linux. Il processo di sviluppo e rilascio è stato afflitto da domande sul perché GLIBC 2.7 non potesse essere innestato su RHEL 5.x o sul perché una certa versione del compilatore o della libreria non fosse disponibile. Quando gli è stato detto che gli aggiornamenti tra le versioni principali di RHEL/CentOS richiedevano essenzialmente ricostruzioni complete, hanno perso molta fiducia nella soluzione.

A questo punto, mi sono reso conto che Red Hat si stava muovendo troppo lentamente per gli sviluppatori che volevano essere all'avanguardia. RHEL 6.x era un aggiornamento tanto necessario e gradito, ma questo tema è diventato più evidente una volta che ho iniziato a intervistare startup e aziende che hanno aderito ai principi DevOps.

Oggi...
Un numero crescente di sviluppatori e utenti Linux proviene da ambienti Linux non Red Hat, non SuSE e non aziendali.

• Stanno usando Ubuntu o Debian...
• Non avevano a che fare con l'hardware della vecchia scuola o con l'assistenza di grandi fornitori.
• Stanno scrivendo le proprie applicazioni da zero (auto-supportate).
• La virtualizzazione e il cloud computing astraggono il livello hardware, quindi le preoccupazioni per i driver del controller RAID stravaganti, le periferiche PCI-X o gli agenti di gestione distribuiti binari non sono nemmeno sul radar.
• Questi utenti vogliono gli strumenti e l'area utente a cui sono abituati.

Quindi c'è un conflitto... Questi utenti non capiscono perché dovrebbero essere limitati sulle versioni dell'applicazione o della libreria. Gli amministratori della vecchia scuola si stanno ancora adattando al nuovo paradigma. Argomenti che sembrano essere radicati nella religione sono in realtà solo funzioni di come le persone hanno sviluppato le rispettive competenze.

Oggi ho visto un annuncio di lavoro per una posizione di ingegnere DevOps Linux molto anziano che diceva:

Deve essere da esperto a esperto nelle distribuzioni Linux basate su Debian (Ubuntu e varianti ok. Red Hat passabile , ma non preferito)

Quindi immagino che funzioni in entrambi i modi ... Ho abbandonato le opportunità di lavoro perché gli 800 server CentOS che avrei gestito dovevano essere convertiti in Ubuntu. Certo, Linux è Linux... ma non pensavo che sarei stato efficace come avrei potuto essere... Ho armeggiato con le installazioni di Debian e desideravo che fosse in uso una distribuzione basata su RPM. Ho avuto accese discussioni sui meriti di varie piattaforme (di solito metto Gentoo in fondo alla lista).

Quindi cosa è giusto per il TUO ambiente? Dipende. Sono stato in aziende in cui gli ingegneri di sistema guidano le decisioni, così come in organizzazioni in cui gli sviluppatori sono i re. Penso che l'accordo migliore sia quando gli sviluppatori e le persone che supportano i sistemi concordano sulla piattaforma. Ma al di fuori di questo, pensa al supporto a lungo termine, all'usabilità, alla community e a cosa si adatta al tuo stack di applicazioni nel modo più appropriato.

Uno sviluppatore di talento dovrebbe essere in grado di lavorare in un ambiente simile a RHEL o Debian. E bene, le piattaforme di sviluppo dovrebbero rispecchiare l'ambiente di produzione. Vai da lì...

Soluzione 2:

Attualmente lavoro in un ambiente che utilizza Linux da più di un decennio. Tutti in ufficio utilizzano distribuzioni diverse sui propri desktop e sui server. Pertanto, le scelte di distribuzione tendono a ruotare attorno a una serie di cose senza un ordine particolare:

1. Cronologia - Ovviamente sistemi come RedHat e Debian esistono da molto tempo. In quanto tale, l'adagio "se non è rotto, non aggiustarlo" può essere usato per questi. L'aggiornamento diventa più semplice se il software è ben supportato su una distribuzione.
2. Familiarità - Simile alla storia, tuttavia tutti abbiamo i nostri preferiti. Mi sono fatto le ossa su Debian e sono migrato su Ubuntu (una decisione difficile all'epoca perché tendo a impegnarmi in una comunità). Al contrario, è una seccatura dover ricordare come fare le cose su una dozzina di distribuzioni diverse (per non parlare di quelle create da zero).
3. Assistenza - Sono migrato a Ubuntu principalmente perché apprezzavo quello che stavano facendo per quanto riguarda l'offerta di supporto a pagamento. Questo era un punto di forza se mai un cliente avesse avuto dubbi sull'esecuzione di un sistema a lungo termine. Simile all'approccio di RedHat (ma all'epoca era in corso l'inferno degli RPM). Abbiamo un certo numero di server RedHat anche per questo motivo.
4. Dipendenze - Alcuni software sono più facili da usare su alcune distribuzioni semplicemente perché i pacchetti dipendenti sono più facilmente ottenibili o compilabili. Come esempio di questo sarebbe oVirt su RedHat. Non ci sono pacchetti per alcuni software su alcune distribuzioni. E potresti compilarlo, ma perché dovresti se il pacchetto fosse proprio lì su un'altra distribuzione?
5. Granularità - Le distribuzioni come Gentoo offrono un controllo più preciso sul controllo delle versioni e sulla granularità del cambio di software. Altre distribuzioni hanno "pinning" in varie forme, ma non è ancora così controllabile o affidabile.
6. Rilegatura - Sebbene sia possibile compilare dal sorgente sulla maggior parte delle distro, alcune distro sono migliori di altre. Ciò può avere un effetto, ad esempio, se il tuo progetto corregge le librerie esistenti per funzionalità estese.
7. Bellezza - Alcune distribuzioni sono semplicemente più belle. Tutti i geek sanno che è solo una sciocchezza (e probabilmente potresti farla franca facendola come un'app web di questi tempi) ma alcuni clienti sono entusiasti di queste cose, e lo sappiamo tutti.
8. Stabilità - Alcune distribuzioni trasmettono in streaming versioni "stabili" del software anziché "testing", "sperimentale", ecc. Questo può significare molto se sai che la versione su cui stai costruendo alla fine raggiungerà un consenso sulla stabilità. Puoi sviluppare su "sperimentale" sapendo che quando il tuo progetto sarà finito avrà raggiunto "stabile" e sarà un bene su cui fare affidamento.
9. Gestione dei pacchetti - Se stai sviluppando qualcosa su base giornaliera e verrà distribuito a migliaia di macchine in un colpo solo, allora probabilmente vorrai qualcosa che semplifichi la creazione, la manutenzione e il monitoraggio dei pacchetti su questi sistemi.
10. Coerenza - Questo è più un argomento a favore dello uguale distribuzione. Vengono commessi meno errori (e meno errori nella sicurezza) quando le persone possono concentrarsi su una distribuzione anziché su diverse.
11. Programma di rilascio prevedibile - Se vuoi essere sicuro che il tuo software rimanga supportato, gli aggiornamenti pianificati offrono un certo tipo di stabilità.
12. Sicurezza - Alcune distribuzioni hanno team di sicurezza attivi il cui compito è rispondere immediatamente a veri rischi per la sicurezza in qualsiasi pacchetto approvato.

Queste sono solo alcune delle cose che mi vengono in mente riguardo ai motivi per cui è stato scelto ciascun sistema. Non vedo alcuna luce guida o preferenza di una distribuzione rispetto a un'altra in questa decisione. La diversità e la scelta possono essere fantastiche e offrirti alcune ottime opzioni per avviare rapidamente un progetto, ma è anche il cappio che può impiccarti. Assicurati di pensare in anticipo a ciò di cui avrai bisogno. Pianifica quali sono le esigenze del sistema e quando il sistema verrà aggiornato o ritirato. Non dare per scontato che sarai sempre tu a mantenerlo.