Я поділюсь своїм досвідом роботи технологом у кількох різних сферах ...
(Застереження: це історія про Red Hat та про те, як я професійно виріс із нею)
Я почав професійно працювати з Linux у 2000-2002 роках. Це було під час широкого прийняття Red Hat та Red Hat Professional Edition (6.x, 7.x, 8.0) . Вони були доступні для безкоштовного завантаження, а також упаковані в комплекті набори. Їх можна було легко знайти в магазинах комп'ютерних роздрібних продажів.
Для мене це принесло користь залученню любителів та домашніх користувачів з тим самим продуктом, який почав з’являтися на підприємстві. Моєю роботою в цей час було переміщення серверних систем клієнтів з комерційних Unices (HP-UX, AIX та SCO) на платформу Red Hat.
Економія коштів була істотною! Заміна 100 000 доларів + серверів PA-RISC HP9000 на 40 000 доларів серверів Compaq ProLiant Intel стала абсолютною виграшею у вартості та продуктивності.
Отже, чому Red Hat?
Red Hat був першим на цьому ринку, заручившись критичною підтримкою бізнесу, постачальників та обладнання. Бачачи великих постачальників додатків, компанія Red Hat використовує як цільову платформу, яка уклала угоду. Користувачі-любителі, як я, змогли з легкістю перенести навички, відточені вдома, у наше робоче середовище. Громада зростала. Правила стеки Slashdot , Freshmeat та LAMP ! Настав гарний час для Linux.
До цього моменту я відповідав за розробку та оцінку дистрибутивів Linux як платформи для фірмового програмного рішення ERP. Я застряг з Червоною Шапочкою. Кожен так часто, я б спробував інший дистрибутив ( Mandrake , SuSE , Debian , Gentoo ), але виявив би проблеми з упаковкою, апаратною підтримкою (сервери або периферійні пристрої), (розміром) спільноти чи іншим вимикачем угод.
Приклад: я використовував апаратне забезпечення Compaq / HP ProLiant, оснащене картами PCI-X для розширення Digi Serial та факсом програмного забезпечення для виробництва Esker VSIfax . Останні два мали лише підтримку драйверів для операційних систем Red Hat. У деяких випадках програмне забезпечення постачалося лише у двійковій або RPM-формі, що виключає просте використання в інших варіантах Linux.
Імпульс у світі інформаційних технологій
Ніхто не хоче бути тим, хто рекомендує програє рішення чи проект, який врешті-решт стає сиротою, тому ви дотримуєтесь безпечного вибору. Я керував стеком технологій, який потребував надійної роботи та підтримки декількох шарів. Вибір іншого розподілу в цей момент був би просто. були. безвідповідально.
Медовий місяць Red Hat закінчився для мене в 2003 році припиненням професійних видань програмного забезпечення. Red Hat Enterprise Linux замінив і прийшов з досить багажем ... Вартість (дорога модель, що базується на підписці), доступність (скорочення бази користувачів та спільноти) та загальна плутанина щодо майбутнього ...
Я почав шукати альтернативи, переоцінюючи Gentoo, Debian і SuSE. Я не зміг отримати належну підтримку для всіх компонентів нашої технології. Мене змусили дотримуватися екосистеми Red Hat ... Через дикі зміни у витратах, пов’язані з Red Hat Enterprise Linux, я в кінцевому підсумку запустив високомодифіковану Red Hat 8.0 за роки, що минули після її закінчення. Тільки поки не дозріли клони RHEL ( Whitebox Linux , а пізніше, CentOS ), я підготував справжній відхід від свого стандарту.
Основною перевагою похідних Red Hat була і є бінарна сумісність з платними версіями RHEL. Можна навіть здійснити перетворення на місці між RHEL та CentOS, і навпаки. Я продовжував працювати з системами, схожими на RHEL, поки не зробив наступного кроку в кар'єрі ...
Пізніше я опинився у високочастотній фінансовій торгівлі , де відповідав за розробку науково-дослідних розробок та Linux за критичні автоматизовані торгові системи. Акцентом у цьому світі була швидкість , за допомогою ретельного тестування та налаштування. Знову ж таки ключовою була підтримка обладнання. У мене були б конкретні мережеві карти , спеціалізоване обладнання, серверне обладнання або бібліотеки додатків, які були сертифіковані лише для систем RHEL або RHEL. Навіть у випадках, коли речі могли бути складені для інших варіантів Linux, виникав фактор спільноти. Коли я був у точці, коли мені потрібно було дослідити проблему, часто виникала проблема, яку можна було простежити до приміток чи коментарів у звітах Red Hat Bugzilla, а іноді я просто надіслала патч або запит на наступний реліз .
Коли я почав заглиблюватися в мережу з низькою затримкою та налаштування ядра, я почав розчленувати запаси ядер RHEL та ядер RHEL MRG Realtime . Я помітив, як багато працює над випусками ... 200+ виправлень на ядро vanilla kernel.org. Прочитайте коментарі та робіть примітки. Можливо, у вас застосовані дрібниці, наприклад sysctlпараметри, або застосовано більше розумних стандартних параметрів. Red Hat платить людям виправити, випробувати і виправити ці проблеми. Я не бачив такого ж зобов'язання в інших дистрибутивах Linux ... Додайте той факт, що корпоративна платформа гарантовано підтримує реальну безпеку, виправлення помилок і підтримку задніх років .
Тож я врешті-решт перейшов до іншої фінансової фірми, яка майже все-Gentoo була на сервері та на робочому столі ... Це було для мене катастрофою. Походячи зі світу Red Hat та CentOS, я зіткнувся з численними проблемами стабільності та управління під час налаштування Gentoo. Контроль версій був найбільшою проблемою, але зменшення підтримки громади та відсутність реального тестування також були проблемою. Я почав впроваджувати RHEL у навколишнє середовище, тому що деякі наші сторонні програми вимагали цього ...
Але виникла проблема ... Мої розробники звикли до Gentoo і мали відносно прості шляхи оновлення основних бібліотек та версій додатків. Вони не змогли налаштувати встановлені основні версії, які Red Hat Enterprise Linux стандартизує. Процес розробки та випуску зазнав питань, чому GLIBC 2.7 не може бути прищеплений на RHEL 5.x або чому певна компілятор чи версія бібліотеки недоступна. Коли їм сказали, що оновлення між основними версіями RHEL / CentOS по суті потребують повної перебудови , вони втратили велику впевненість у рішенні.
У цей момент я зрозумів, що Red Hat рухається надто повільно для розробників, які хотіли бути на кращому рівні. RHEL 6.x був дуже потрібним і бажаним оновленням, але ця тема стала більш очевидною, коли я почав інтерв'ю зі стартапами та фірмами, які підписалися на принципи DevOps .
Сьогодні ...
Зростаюча кількість розробників та користувачів Linux надходить із середовищ Red-Hat, не-SuSE, непідприємницьких Linux.
- Вони використовують Ubuntu або Debian ...
- Їм не доводилося мати справу зі старим шкільним обладнанням чи підтримкою великих постачальників.
- Вони пишуть власні програми з нуля (самопідтримуються).
- Віртуалізація та хмарні обчислення абстрагують апаратний рівень, тому хвилювань щодо прикольних драйверів RAID-контролерів, периферійних пристроїв PCI-X або бінарних розподілених агентів управління навіть немає на радарі.
- Ці користувачі хочуть тих інструментів та області користування, до якої вони звикли.
Отже, виникає конфлікт ... Ці користувачі не розуміють, чому їх обмежують версії додатків чи бібліотеки. Адміністратори старої школи все ще пристосовуються до нової парадигми . Аргументи, які, здається, вкорінені в релігію, - це справді лише функції того, як люди розвивали свої набори навичок.
Сьогодні я побачив оголошення про роботу для дуже старшого посади інженера DevOps Linux, який писав:
Повинно бути досвідченим експертом у дистрибутивах Linux на базі Debian (Ubuntu та варіанти добре. Red Hat прохідний , але не бажаний)
Тож я думаю, що це працює в обох напрямках ... Я пішов від можливостей роботи, оскільки 800 серверів CentOS, якими я керував, були перетворені на Ubuntu. Звичайно, Linux - це Linux ... але я не відчував, що буду настільки ефективним, що можу бути ... Я спіткався з установками Debian і хотів, щоб використовувався дистрибутив на основі RPM. У мене були гарячі аргументи щодо достоїнств різних платформ (зазвичай розміщуючи Gentoo внизу списку).
Отже, що підходить для вашого середовища? Це залежить. Я був у фірмах, де системні інженери приймають рішення, а також в організаціях, де розробники є королем. Я думаю, що найкраща угода - це коли розробники та люди, що підтримують системи, домовляються про платформу. Але поза цим, подумайте про довгострокову підтримку, зручність використання, спільність та те, що вміщує ваш стек додатків найбільш відповідним чином.
Талановитий розробник повинен мати можливість працювати в середовищі, подібному до RHEL або Debian. Ну і платформи розвитку повинні відображати виробниче середовище. Ви йдете звідти ...