Solution 1 :
Je partagerai mes expériences de travail en tant que technologue dans différents domaines...
(Attention :ceci est une histoire sur Red Hat et comment j'ai grandi professionnellement avec)
J'ai commencé à travailler professionnellement avec Linux en 2000-2002. C'était lors de l'adoption à grande échelle de Red Hat et des éditions professionnelles de Red Hat (6.x, 7.x, 8.0). Ceux-ci étaient disponibles en téléchargement gratuit ainsi que des ensembles emballés en boîte. Ils pourraient facilement être trouvés dans les magasins de vente au détail d'ordinateurs.
Pour moi, cela a eu l'avantage d'engager les amateurs et les utilisateurs à domicile avec le même produit qui commençait à émerger dans l'entreprise. Mon travail à cette époque consistait à déplacer les systèmes de serveurs des clients des systèmes Unice commerciaux (HP-UX, AIX et SCO) vers la plate-forme Red Hat.
Les économies de coûts étaient substantielles ! Le remplacement de serveurs HP9000 PA-RISC à 100 000 $ et plus par des serveurs Compaq ProLiant Intel à 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 sur ce marché, obtenant un support commercial, fournisseur et matériel essentiel. 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 dans nos environnements de travail. La communauté grandissait. Les piles Slashdot, Freshmeat et LAMP ont dominé ! C'était une bonne époque pour Linux.
À ce stade, j'étais responsable du développement et de l'évaluation des distributions Linux en tant que plate-forme 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 je trouvais des problèmes avec l'empaquetage, le support matériel (serveurs ou périphériques), la (taille du) communauté ou un autre facteur décisif.
Un exemple :j'utilisais du matériel Compaq/HP ProLiant équipé de cartes PCI-X d'extension Digi Serial et du logiciel de télécopie de production Esker VSIfax. Les deux derniers ne prenaient en charge que les pilotes pour les systèmes d'exploitation Red Hat. Dans certains cas, le logiciel n'était livré que sous forme binaire ou RPM, ce qui empêchait une utilisation facile sur d'autres variantes de Linux.
La dynamique compte dans le monde des technologies de l'information
Personne ne veut être celui qui recommande de perdre une solution ou un projet qui finit par devenir orphelin, vous vous en tenez donc à des choix sûrs. Je gérais une pile technologique qui devait fonctionner de manière fiable et avoir plusieurs couches de support. Choisir une distribution différente à ce moment-là aurait juste. a été. irresponsable.
La lune de miel de Red Hat s'est terminée pour moi en 2003 avec l'arrêt des éditions professionnelles du logiciel. Red Hat Enterprise Linux était le remplaçant et était livré avec pas mal de bagages... Coût (modèle coûteux basé sur un abonnement), accessibilité (réduction de la base d'utilisateurs et de la communauté) et confusion générale sur l'avenir...
J'ai commencé à chercher des alternatives, réévaluant Gentoo, Debian et SuSE. Je n'ai pas pu obtenir le bon support sur tous les composants de notre pile technologique. J'ai été obligé de m'en tenir à l'écosystème Red Hat... En raison de la forte augmentation des coûts associée à Red Hat Enterprise Linux, j'ai fini par utiliser une Red Hat 8.0 hautement modifiée pendant des années passé sa fin de vie. Ce n'est que lorsque les clones RHEL ont mûri (Whitebox Linux, et plus tard, CentOS) que j'ai préparé un véritable éloignement de mon standard.
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 change de carrière...
Plus tard, je me suis retrouvé dans l'industrie du trading financier à haute fréquence, où j'étais responsable de la R&D et de l'ingénierie Linux pour les systèmes de trading automatisés critiques. L'accent dans ce monde était la vitesse , au moyen de tests et de réglages minutieux. Encore une fois, le support matériel était la clé. J'aurais des cartes réseau spécifiques, du matériel spécialisé, du matériel serveur ou des bibliothèques d'applications qui n'étaient certifiées que pour les systèmes RHEL ou de type RHEL. Même dans les cas où les choses pourraient être compilées pour d'autres variantes de Linux, le facteur communautaire est apparu. Lorsque j'étais au point où j'avais besoin de rechercher un problème, il s'agissait souvent d'un problème qui pouvait être attribué à des notes ou des commentaires dans les rapports Red Hat Bugzilla, ou parfois, je soumettais simplement un correctif ou demandais la prochaine version .
Alors que je commençais à me plonger dans les réseaux à faible latence et le réglage du noyau, j'ai commencé à disséquer les noyaux RHEL d'origine et les noyaux RHEL MRG Realtime. J'ai remarqué la quantité de travail dans les versions... plus de 200 correctifs pour un noyau vanille kernel.org. Lisez les commentaires et les notes de validation. 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 les gens pour corriger, tester et résoudre ces problèmes. Je n'ai pas vu le même engagement de la part d'autres distributions Linux... Ajoutez le fait que la plate-forme d'entreprise est garantie d'avoir une véritable prise en charge de la sécurité, des corrections de bogues et du rétroportage pendant des années .
J'ai donc finalement déménagé dans une autre société financière qui était presque entièrement Gentoo sur le serveur et desktop... C'était un désastre pour moi. Venant du monde Red Hat et CentOS, j'ai rencontré de nombreux problèmes de stabilité et de gestion avec l'installation de Gentoo. Le contrôle de version était le plus gros problème, mais la diminution du soutien 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 avaient des chemins de mise à niveau relativement faciles pour les bibliothèques de base et les versions d'application. Ils ne pouvaient pas s'adapter aux versions majeures fixes sur lesquelles Red Hat Enterprise Linux se standardise. Le processus de développement et de publication a été en proie à des questions sur les raisons pour lesquelles GLIBC 2.7 ne pouvait pas être greffé sur RHEL 5.x ou pourquoi une certaine version du compilateur ou de la bibliothèque n'était pas disponible. Lorsqu'on leur a dit que les mises à niveau entre les versions majeures de RHEL/CentOS nécessitaient essentiellement des reconstructions complètes, ils ont perdu beaucoup de confiance dans la solution.
À ce stade, j'ai réalisé que Red Hat avançait beaucoup trop lentement pour les développeurs qui voulaient être à la pointe de la technologie. RHEL 6.x était une mise à niveau indispensable et bienvenue, mais ce thème est devenu plus évident une fois que j'ai commencé à interviewer des startups et des entreprises qui ont souscrit aux principes DevOps.
Aujourd'hui...
Un nombre croissant de développeurs et d'utilisateurs de Linux proviennent d'environnements Linux non Red Hat, non SuSE et non professionnels.
- Ils utilisent Ubuntu ou Debian...
- Ils n'ont pas eu à faire face à du matériel à l'ancienne ou à l'assistance d'un gros fournisseur.
- Ils écrivent leurs propres applications à partir de zéro (autosuffisance).
- La virtualisation et le cloud computing font abstraction de la couche matérielle, de sorte que les inquiétudes concernant les pilotes de contrôleur RAID, les périphériques PCI-X ou les agents de gestion distribués binaires 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 sur les versions de l'application ou de la bibliothèque. Les administrateurs de la vieille école sont encore en train de s'adapter au nouveau paradigme. Arguments qui semblent être enraciné dans la religion ne sont en réalité 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 expérimenté qui disait :
Doit être compétent à expert dans les distributions Linux basées sur Debian (Ubuntu et ses variantes d'accord. Red Hat passable , mais pas préféré)
Donc je suppose que cela fonctionne dans les deux sens... J'ai abandonné les opportunités d'emploi parce que les 800 serveurs CentOS que je gérerais devaient être convertis en Ubuntu. Bien sûr, Linux est Linux ... mais je ne pensais pas être aussi efficace que possible ... J'ai tâtonné avec les installations de Debian et j'aurais souhaité qu'une distribution basée sur RPM soit utilisée. J'ai eu des discussions animées sur les mérites de diverses plates-formes (plaçant généralement Gentoo au bas de la liste).
Alors, qu'est-ce qui convient à VOTRE environnement ? Ça dépend. J'ai travaillé dans des entreprises où les ingénieurs système dirigent les décisions, ainsi que dans des organisations où les développeurs sont rois. Je pense que le meilleur arrangement est lorsque les développeurs et les personnes qui prennent en charge 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 s'adapte le mieux à votre pile d'applications.
Un développeur talentueux doit être capable de travailler dans un environnement de type RHEL ou Debian. Et bien, les plates-formes de développement devraient refléter l'environnement de production. Vous partez de là...
Solution 2 :
Je travaille actuellement dans un environnement qui utilise Linux depuis plus d'une décennie. Tout le monde au bureau utilise différentes distributions sur leurs ordinateurs de bureau ainsi que sur les serveurs. Ainsi, les choix de distribution ont tendance à s'articuler autour d'un certain nombre de choses sans ordre particulier :
- Historique - De toute évidence, des systèmes comme RedHat et Debian existent depuis longtemps. En tant que tel, l'adage "si ce n'est pas cassé, ne le répare pas" peut être utilisé pour ceux-ci. La mise à niveau devient plus facile si le logiciel est bien pris en charge sur une distribution.
- Connaissance - Semblable à l'histoire, mais nous avons tous nos favoris. Je me suis fait les dents sur Debian et j'ai migré vers Ubuntu (une décision difficile à l'époque car j'ai tendance à m'engager dans une communauté). À l'inverse, il est pénible de devoir se rappeler comment faire les choses sur une douzaine de distributions différentes (sans parler de celles construites à partir de rien).
- Assistance - J'ai migré vers Ubuntu principalement parce que j'appréciais ce qu'ils faisaient en matière d'offre de support payant. C'était un argument de vente si jamais un client avait des inquiétudes quant à l'exploitation d'un système à long terme. Semblable à l'approche de RedHat (mais l'enfer RPM se déroulait à l'époque). Nous avons également un certain nombre de serveurs RedHat pour cette raison.
- Dépendances - Certains logiciels sont plus faciles à utiliser sur certaines distributions simplement parce que les packages dépendants sont plus faciles à obtenir ou à construire. Par exemple, oVirt sur RedHat. Il n'y a pas de packages pour certains logiciels sur certaines distributions. Et vous pourriez le compiler, mais pourquoi le feriez-vous si le paquet était là sur une autre distribution ?
- Granularité - Les distributions comme Gentoo offrent un contrôle plus fin sur la gestion des versions et la granularité du changement de logiciel. D'autres distributions ont "l'épinglage" sous diverses formes, mais ce n'est toujours pas aussi contrôlable ou fiable.
- Contraignant - Bien qu'il soit possible de compiler à partir de la source sur la plupart des distributions, certaines distributions sont meilleures que d'autres. Cela peut avoir un effet, par exemple, si votre projet corrige des bibliothèques existantes pour des fonctionnalités étendues.
- Jolie - Certaines distributions sont juste plus belles. Tous les geeks savent que ce n'est que du blabla (et vous pourriez probablement vous en sortir en tant qu'application Web de nos jours), mais certains clients sont impressionnés par ce genre de choses, et nous le savons tous.
- Stabilité - Certaines distributions diffusent des versions "stables" de logiciels par opposition aux "tests", "expérimentaux", etc. Cela peut signifier beaucoup si vous savez que la version sur laquelle vous construisez finira par atteindre un consensus sur la stabilité. Vous pouvez développer sur "expérimental" en sachant qu'au moment où votre projet sera terminé, il sera devenu "stable" et sur lequel vous pourrez compter.
- Gestion des packages - Si vous développez quelque chose au quotidien et qu'il est destiné à des milliers de machines d'un seul coup, vous souhaitez probablement quelque chose qui facilite la création, la maintenance et le suivi des packages sur ces systèmes.
- Cohérence - C'est plus un argument pour le même distribution. Moins d'erreurs sont commises (et moins d'erreurs de sécurité) lorsque les utilisateurs peuvent se concentrer sur une seule distribution plutôt que sur plusieurs.
- Calendrier de diffusion prévisible - Si vous voulez être sûr que votre logiciel reste pris en charge, les mises à niveau planifiées offrent un certain type de stabilité.
- Sécurité - Certaines distributions ont des équipes de sécurité actives dont le travail consiste à répondre immédiatement aux risques de sécurité réels dans tout package approuvé.
Ce ne sont là que quelques éléments qui me viennent à l'esprit concernant les raisons pour lesquelles chaque système a été choisi. Je ne vois aucune lumière directrice ou préférence d'une distribution par rapport à une autre dans cette décision. La diversité et le choix peuvent être formidables et vous offrir de très bonnes options pour démarrer un projet rapidement, mais c'est aussi l'étau qui peut vous accrocher. Assurez-vous de penser à l'avance à ce dont vous aurez besoin. Planifiez les besoins du système ainsi que le moment où le système sera mis à niveau ou retiré. Ne présumez pas que vous serez toujours celui qui le maintiendra.