Comment un département informatique doit-il choisir une distribution Linux standard ?

Je vais vous faire part de mes expériences en tant que technologue dans différents domaines...

(Attention : ceci est une histoire sur Red Hat et comment j'ai grandi professionnellement avec elle)

J'ai commencé à travailler professionnellement avec Linux en 2000-2002. C'était au moment de la large adoption de Red Hat et de la Red Hat Professional Editions (6.x, 7.x, 8.0) . Ils étaient disponibles en téléchargement gratuit ainsi qu'en coffrets. On pouvait facilement les trouver dans les magasins d'informatique.

Pour moi, cela a eu l'avantage d'inciter les amateurs et les utilisateurs à domicile à s'intéresser à l'histoire de l'entreprise. même qui commençait à émerger dans l'entreprise. Mon travail à cette époque consistait à faire passer les systèmes de serveurs des clients des Unices commerciaux (HP-UX, AIX et SCO) à la plate-forme Red Hat.

Les économies réalisées ont été substantielles ! Le remplacement des serveurs HP9000 PA-RISC de plus de 100 000 $ par des serveurs Compaq ProLiant Intel de 40 000 $ a été une victoire absolue en termes de coût et de performances.

Alors, pourquoi Red Hat ?

Red Hat a été le premier à se lancer sur ce marché, obtenant un soutien critique de la part des entreprises, des fournisseurs et du matériel. Le fait de voir de grands fournisseurs d'applications utiliser Red Hat comme plate-forme cible a scellé l'affaire. Les utilisateurs amateurs comme moi ont pu transférer facilement les compétences acquises à la maison vers nos environnements de travail. La communauté s'est développée. Slashdot , Viande fraîche y Piles LAMP gouverné ! C'était un bon moment pour Linux.

À ce stade, j'étais responsable du développement et de l'évaluation de distributions Linux en tant que plateforme pour une solution logicielle ERP propriétaire. Je suis resté avec Red Hat. De temps en temps, j'essayais une autre distribution ( Mandrake , SuSE , Debian , Gentoo ), mais trouverait des problèmes au niveau de l'emballage, de la prise en charge du matériel (serveurs ou périphériques), de la (taille de la) ou un autre problème.

Un exemple : J'utilisais du matériel Compaq/HP ProLiant équipé de Cartes d'extension PCI-X Digi Serial y Logiciel de production de fax Esker VSIfax . Ces deux derniers n'avaient que le support des pilotes pour les systèmes d'exploitation Red Hat. Dans certains cas, les logiciels n'étaient livrés que sous forme binaire ou RPM, ce qui empêchait une utilisation facile sur d'autres variantes de Linux.

L'élan est important dans le monde des technologies de l'information
Personne ne veut être celui qui recommande le en perdant une solution ou un projet qui finit par devenir orphelin, alors vous vous en tenez à des choix sûrs. Je gérais une pile technologique qui devait fonctionner de manière fiable et disposer de plusieurs couches de support. Choisir une autre distribution à ce moment-là aurait été tout simplement irresponsable.

La lune de miel de Red Hat s'est terminée pour moi en 2003 avec les arrêt des éditions professionnelles du logiciel. Red Hat Enterprise Linux était le remplaçant et venait avec pas mal de bagages... Coût (modèle d'abonnement coûteux), accessibilité (réduction de la base d'utilisateurs et de la communauté) et confusion générale quant à l'avenir...

J'ai commencé à chercher des alternatives, en réévaluant Gentoo, Debian et SuSE. Je n'arrivais pas à obtenir le bon support sur tous les composants de notre pile technologique. J'ai été contraint de m'en tenir à l'écosystème Red Hat... En raison des coûts élevés associés à Red Hat Enterprise Linux, j'ai fini par utiliser une version hautement modifiée de Red Hat 8.0 pour les applications suivantes années après sa fin de vie. Ce n'est que lorsque les clones de RHEL sont arrivés à maturité ( Whitebox Linux et plus tard, CentOS ) que j'ai préparé un véritable éloignement de ma norme.

Le principal avantage des dérivés de Red Hat était et est Compatibilité binaire avec les versions payantes de RHEL. Il est même possible d'effectuer des conversions sur place entre RHEL et CentOS, et vice-versa. J'ai continué à travailler avec des systèmes de type RHEL jusqu'à ce que je fasse le prochain changement de carrière...

Je me suis retrouvé plus tard dans le les transactions financières à haute fréquence où j'étais responsable de la R&D et de l'ingénierie Linux pour des systèmes critiques de trading automatisé. L'accent dans ce monde était vitesse par le biais d'essais et de réglages minutieux. Là encore, le support matériel a été déterminant. J'aurais des cartes réseau , matériel spécialisé Les bibliothèques de serveurs ou d'applications qui n'ont été certifiées que pour RHEL ou les systèmes similaires à RHEL. Même dans les cas où les choses pouvaient être compilées pour d'autres variantes de Linux, le facteur communauté se posait. Lorsque j'en étais au point de devoir rechercher un problème, il s'agissait souvent d'un problème qui pouvait être retracé dans les notes ou les commentaires des rapports Red Hat Bugzilla, ou parfois, je soumettais simplement un correctif ou une demande pour la prochaine version.

Lorsque j'ai commencé à m'intéresser aux réseaux à faible latence et à l'optimisation des noyaux, j'ai commencé à disséquer les noyaux RHEL de base et à les modifier. RHEL MRG Temps réel noyaux. J'ai remarqué combien de travail quand dans les versions... 200+ patches pour un noyau vanille de kernel.org. Lisez les commentaires et les notes commit. Vous pouvez avoir de petites choses comme sysctl paramètres exposés ou des valeurs par défaut plus saines appliquées. Red Hat paie des gens pour corriger, tester et réparer ces problèmes. Je n'ai pas vu le même engagement de la part des autres distributions Linux... Ajoutez à cela le fait que la plateforme d'entreprise est garantie d'avoir une vraie sécurité, des corrections de bugs et un support backport pour années .

J'ai donc fini par aller dans une autre société financière qui était presque entièrement sous Gentoo sur le serveur. und le bureau... C'était un désastre pour moi. Venant du monde de Red Hat et CentOS, j'ai rencontré de nombreux problèmes de stabilité et de gestion avec la configuration Gentoo. Le contrôle de version était le plus gros problème, mais la diminution du support de la communauté et le manque de tests réels étaient également des préoccupations. J'ai commencé à introduire RHEL dans l'environnement parce que certains de nos logiciels tiers l'exigeaient...

Mais il y avait un problème... Mes développeurs étaient habitués à Gentoo et à des chemins de mise à jour relativement faciles pour les bibliothèques de base et les versions des applications. Ils ne pouvaient pas s'habituer à avoir les versions majeures fixes sur lesquelles Red Hat Enterprise Linux est standardisé. Le processus de développement et de mise à jour a été assailli de questions concernant pourquoi GLIBC 2.7 n'a pas pu être greffé sur RHEL 5.x ou pourquoi une certaine version de compilateur ou de bibliothèque n'était pas disponible. Lorsqu'on leur dit que les mises à niveau entre les versions majeures de RHEL/CentOS ont essentiellement nécessité des reconstructions complètes ils ont perdu beaucoup de confiance dans la solution.

À ce moment-là, j'ai réalisé que Red Hat était beaucoup trop lent pour les développeurs qui voulaient être à la pointe du progrès. RHEL 6.x était une mise à niveau nécessaire et bienvenue, mais ce thème est devenu plus évident lorsque j'ai commencé à passer des entretiens avec des start-ups et des entreprises qui s'abonnaient à Principes DevOps .

Aujourd'hui...
Un nombre croissant de développeurs et d'utilisateurs de Linux proviennent d'environnements Linux autres que Red Hat, autres que SuSE et autres que ceux des entreprises.

• Ils utilisent Ubuntu ou Debian...
• Ils n'ont pas eu à s'occuper de matériel de la vieille école ou de l'assistance d'un gros fournisseur.
• Ils écrivent leurs propres applications à partir de la base (auto-support).
• La virtualisation et l'informatique en nuage font abstraction de la couche matérielle, de sorte que les préoccupations concernant les pilotes de contrôleurs RAID, les périphériques PCI-X ou les agents de gestion distribués de manière binaire ne sont même pas sur le radar.
• Ces utilisateurs veulent les outils et l'espace utilisateur auxquels ils sont habitués.

Il y a donc un conflit... Ces utilisateurs ne comprennent pas pourquoi ils seraient limités aux versions de l'application ou de la bibliothèque. Les administrateurs de la vieille école sont encore en train de s'adapter à l'évolution de la technologie. nouveau paradigme . Les arguments qui semblent d'être enracinés dans la religion ne sont en fait que des fonctions de la façon dont les gens ont développé leurs compétences respectives.

J'ai vu une offre d'emploi aujourd'hui pour un poste d'ingénieur DevOps Linux très senior qui disait :

Doit être compétent à expert dans les distributions Linux basées sur Debian. (Ubuntu et ses variantes sont acceptables. Red Hat passable mais pas préféré)

Donc je suppose que ça marche dans les deux sens... J'ai refusé des offres d'emploi parce que les 800 serveurs CentOS que je devais gérer étaient destinés à être convertis en Ubuntu. Bien sûr, Linux est Linux... mais je n'avais pas l'impression d'être aussi efficace que je le pouvais... J'ai tâtonné avec des installations Debian et j'ai souhaité qu'une distro basée sur RPM soit utilisée. J'ai eu des discussions animées sur les mérites des différentes plateformes (plaçant généralement Gentoo en bas de la liste).

Alors, qu'est-ce qui convient à VOTRE environnement ? Cela dépend. J'ai travaillé dans des entreprises où les ingénieurs systèmes prenaient les décisions, ainsi que dans des organisations où les développeurs étaient rois. Je pense que le meilleur arrangement est celui où les développeurs et les personnes qui soutiennent les systèmes s'accordent sur la plate-forme. Mais en dehors de cela, pensez au support à long terme, à la convivialité, à la communauté et à ce qui convient le mieux à votre pile d'applications.

Un développeur talentueux devrait être capable de travailler dans un environnement de type RHEL ou Debian. Et bien, les plateformes de développement devraient refléter l'environnement de production. Vous partez de là...