Bagaimana seharusnya departemen TI memilih distribusi Linux standar?

Ada banyak perasaan masyarakat tentang apa distribusi Linux yang tepat untuk lingkungan server produksi dan yang tidak, bagaimanapun, banyak perasaan ini tampaknya berdasarkan agama, dan jarang disajikan dengan bukti yang mendukung.

Dengan asumsi bahwa kami mencoba memilih distribusi Linux untuk distandarisasi (karena kami memiliki minat dalam menjaga lingkungan kami seromogen mungkin), kriteria apa yang penting, dan bagaimana Anda membuat keputusan tentang seberapa baik distribusi yang berbeda memenuhi kriteria tersebut?

Saat ini saya bekerja di lingkungan yang telah menggunakan Linux selama lebih dari satu dekade. Semua orang di kantor menggunakan distro yang berbeda pada desktop mereka dan juga server. Dengan demikian, pilihan distribusi cenderung berputar di sekitar sejumlah hal tanpa urutan tertentu:

1. Sejarah - Jelas sistem seperti RedHat dan Debian telah ada sejak lama. Dengan demikian, pepatah "jika tidak rusak, jangan diperbaiki" dapat digunakan untuk ini. Upgrade menjadi lebih mudah jika perangkat lunak didukung dengan baik pada distro.
2. Keakraban - Mirip dengan Sejarah, namun kita semua memiliki favorit kami. Saya memotong gigi saya di Debian, dan bermigrasi ke Ubuntu (keputusan sulit pada saat itu karena saya cenderung berkomitmen untuk komunitas). Sebaliknya, sulit untuk mengingat bagaimana melakukan hal-hal pada selusin distro yang berbeda (belum lagi yang dibuat dari awal).
3. Dukungan - Saya bermigrasi ke Ubuntu terutama karena saya menghargai apa yang mereka lakukan sejauh menawarkan dukungan berbayar. Itu adalah titik penjualan jika klien memiliki kekhawatiran tentang menjalankan sistem jangka panjang. Mirip dengan pendekatan RedHat (tapi RPM sih sedang terjadi saat itu). Kami memiliki sejumlah server RedHat karena alasan ini juga.
4. Dependency - Beberapa software lebih mudah digunakan pada beberapa distro hanya karena paket dependen lebih mudah didapat atau dibangun. Sebagai contohnya adalah oVirt di RedHat. Tidak ada paket untuk beberapa perangkat lunak pada beberapa distro. Dan Anda dapat mengkompilasinya, tetapi mengapa Anda jika paket itu ada di sana pada distro lain?
5. Granularity - Distro seperti Gentoo menawarkan kontrol yang lebih baik atas versi dan granularitas peralihan perangkat lunak. Distro lain telah "menyematkan" dalam berbagai bentuk, tetapi itu masih tidak dapat dikontrol atau dapat diandalkan.
6. Binding - Meskipun mungkin untuk dikompilasi dari sumber pada sebagian besar distro, beberapa distro lebih baik daripada yang lain. Ini dapat memiliki efek, katakanlah, jika proyek Anda menambal pustaka yang ada untuk fungsionalitas tambahan.
7. Prettiness - Beberapa distro hanya terlihat lebih baik. Setiap geek tahu itu hanya fluff (dan Anda mungkin bisa melakukannya dengan aplikasi web akhir-akhir ini) tetapi beberapa klien kagum dengan hal ini, dan kita semua tahu itu.
8. Stabilitas - Beberapa distro streaming versi "stabil" dari perangkat lunak yang bertentangan dengan "pengujian", "eksperimental", dll. Ini dapat berarti banyak jika Anda tahu bahwa versi yang Anda bangun pada akhirnya akan mencapai konsensus tentang stabilitas. Anda dapat mengembangkan "eksperimental" dengan mengetahui bahwa pada saat proyek Anda selesai, ia akan mencapai "stabil" dan bagus untuk diandalkan.
9. Manajemen paket - Jika Anda mengembangkan sesuatu setiap hari, dan itu akan keluar ke 1000-an mesin dalam satu pukulan, maka Anda mungkin menginginkan sesuatu yang membuatnya mudah untuk membangun, memelihara, dan melacak paket di seluruh sistem itu.
10. Konsistensi - Ini lebih merupakan argumen untuk distro yang sama . Semakin sedikit kesalahan yang dibuat (dan lebih sedikit kesalahan dalam keamanan) ketika orang dapat fokus pada satu distro dibandingkan dengan beberapa.
11. Jadwal rilis yang dapat diprediksi - Jika Anda ingin memastikan bahwa perangkat lunak Anda tetap didukung, upgrade terencana menawarkan jenis stabilitas tertentu.
12. Keamanan - Beberapa distro memiliki tim keamanan aktif yang tugasnya untuk segera merespons risiko keamanan asli dalam setiap paket yang disetujui.

Itu hanya beberapa hal yang keluar dari kepala saya mengenai alasan mengapa masing-masing sistem dipilih. Saya tidak melihat ada satu panduan cahaya atau preferensi satu distro di atas yang lain dalam keputusan ini. Keragaman dan pilihan bisa menjadi hal yang luar biasa dan menawarkan kepada Anda beberapa opsi yang sangat bagus untuk memulai proyek dengan cepat, tetapi juga jeratan yang dapat menghambat Anda. Pastikan Anda memikirkan apa yang akan Anda butuhkan. Rencanakan apa kebutuhan sistem serta kapan sistem akan ditingkatkan atau dihentikan. Jangan menganggap Anda akan selalu menjadi orang yang merawatnya.

Saya akan membagikan pengalaman saya bekerja sebagai teknolog di beberapa bidang yang berbeda ...

(Perhatian: ini adalah kisah tentang Red Hat dan bagaimana saya tumbuh secara profesional dengannya)

Saya mulai bekerja dengan Linux secara profesional pada 2000-2002. Ini terjadi selama adopsi Red Hat dan Red Hat Professional Editions (6.x, 7.x, 8.0) . Ini tersedia untuk diunduh gratis serta set paket dalam kotak. Mereka dapat dengan mudah ditemukan di toko-toko ritel komputer.

Bagi saya, ini memiliki manfaat melibatkan penggemar dan pengguna rumahan dengan produk yang sama yang mulai muncul di perusahaan. Pekerjaan saya saat ini adalah memindahkan sistem server pelanggan dari Unit komersial (HP-UX, AIX dan SCO) ke platform Red Hat.

Penghematan biaya sangat besar! Mengganti server $ 100k + HP9000 PA-RISC dengan server Intel Compaq ProLiant $ 40k adalah kemenangan mutlak dalam hal biaya dan kinerja.

Jadi, mengapa Red Hat?

Red Hat adalah yang pertama ke pasar ini, mendapatkan dukungan bisnis, vendor, dan perangkat keras yang kritis. Melihat vendor aplikasi besar menggunakan Red Hat sebagai platform target menyegel kesepakatan. Pengguna penghobi seperti saya dapat mentransfer keterampilan yang diasah di rumah ke lingkungan kerja kami dengan mudah. Komunitas itu berkembang. Tumpukan Slashdot , Freshmeat dan LAMP memerintah! Itu waktu yang tepat untuk Linux.

Pada titik ini, saya bertanggung jawab untuk pengembangan dan evaluasi distribusi Linux sebagai platform untuk solusi perangkat lunak ERP berpemilik. Saya terjebak dengan Red Hat. Seringkali, saya akan mencoba distro lain ( Mandrake , SuSE , Debian , Gentoo ), tetapi akan menemukan masalah dengan pengemasan, dukungan perangkat keras (server atau periferal), komunitas (ukuran komunitas ) atau pemecah kesepakatan lainnya.

Contoh: Saya menggunakan perangkat keras Compaq / HP ProLiant yang dilengkapi dengan kartu PCI-X ekspansi Digi Serial dan perangkat lunak faks produksi Esker VSIfax . Dua yang terakhir hanya memiliki dukungan driver untuk sistem operasi Red Hat. Dalam beberapa kasus, perangkat lunak hanya dikirim dalam bentuk biner atau RPM, menghalangi penggunaan yang mudah pada varian Linux lainnya.

Momentum penting di Dunia Teknologi Informasi
Tidak seorang pun ingin menjadi orang yang merekomendasikan solusi atau proyek yang hilang yang akhirnya menjadi yatim, sehingga Anda tetap dengan pilihan yang aman. Saya mengelola tumpukan teknologi yang perlu bekerja dengan andal dan memiliki beberapa lapisan dukungan. Memilih distribusi yang berbeda pada saat itu akan tepat. telah. tidak bertanggung jawab.

Bulan madu Red Hat berakhir untuk saya pada tahun 2003 dengan penghentian edisi profesional perangkat lunak. Red Hat Enterprise Linux adalah penggantinya dan datang dengan sedikit barang bawaan ... Biaya (model berbasis berlangganan yang mahal), aksesibilitas (menyusutkan basis pengguna dan komunitas) dan kebingungan umum tentang masa depan ...

Saya mulai mencari alternatif, mengevaluasi kembali Gentoo, Debian dan SuSE. Saya tidak bisa mendapatkan dukungan yang tepat pada semua komponen tumpukan teknologi kami. Saya dipaksa untuk tetap dengan ekosistem Red Hat ... Karena perubahan biaya liar yang terkait dengan Red Hat Enterprise Linux, saya akhirnya menjalankan Red Hat 8.0 yang sangat dimodifikasi selama bertahun - tahun melewati akhir masa pakainya. Tidak sampai klon RHEL jatuh tempo ( Whitebox Linux , dan kemudian, CentOS ) saya menyiapkan langkah nyata dari standar saya.

Keuntungan utama turunan Red Hat adalah kompatibilitas biner dengan versi RHEL berbayar. Bahkan dimungkinkan untuk melakukan konversi di tempat antara RHEL dan CentOS, dan sebaliknya. Saya terus bekerja dengan sistem seperti RHEL sampai saya membuat langkah karier selanjutnya ...

Saya kemudian menemukan diri saya di industri perdagangan keuangan frekuensi tinggi , di mana saya bertanggung jawab untuk R&D dan rekayasa Linux untuk sistem perdagangan otomatis yang kritis. Penekanan di dunia ini adalah kecepatan , melalui pengujian dan penyetelan yang cermat. Sekali lagi, dukungan perangkat keras adalah kuncinya. Saya punya kartu jaringan khusus , perangkat keras khusus, pustaka perangkat keras atau aplikasi server yang hanya disertifikasi untuk sistem RHEL atau seperti RHEL. Bahkan dalam kasus-kasus di mana hal-hal dapat dikompilasi untuk varian Linux lainnya, faktor komunitas muncul. Ketika saya berada di titik di mana saya perlu meneliti masalah, sering kali masalah itu dapat ditelusuri ke catatan atau komentar dalam laporan Red Hat Bugzilla, atau kadang-kadang, saya cukup mengirimkan tambalan atau meminta rilis berikutnya .

Ketika saya mulai mempelajari jaringan laten yang rendah dan penyetelan kernel, saya mulai membedah kernel RHEL stock dan kernel RHEL MRG Realtime . Saya perhatikan berapa banyak yang berhasil ketika masuk ke dalam rilis ... 200+ tambalan ke kernel vanilla kernel.org. Baca komentar dan komit catatan. Anda mungkin memiliki hal-hal kecil seperti sysctlparameter terbuka atau lebih banyak standar waras diterapkan. Red Hat membayar orang untuk menambal, menguji, dan memperbaiki masalah ini. Saya tidak melihat komitmen yang sama dari distribusi Linux lainnya ... Tambahkan fakta bahwa platform perusahaan dijamin memiliki keamanan nyata, perbaikan bug, dan dukungan backport selama bertahun - tahun .

Jadi saya akhirnya pindah ke firma keuangan lain yang hampir semuanya Gentoo di server dan desktop ... Itu bencana bagi saya. Berasal dari dunia Red Hat dan CentOS, saya menemukan banyak masalah stabilitas dan manajemen dengan pengaturan Gentoo. Kontrol versi adalah masalah terbesar, tetapi berkurangnya dukungan masyarakat dan kurangnya pengujian nyata juga menjadi perhatian. Saya mulai memperkenalkan RHEL ke lingkungan karena beberapa perangkat lunak pihak ketiga kami mengharuskannya ...

Tetapi ada masalah ... Pengembang saya terbiasa dengan Gentoo dan memiliki jalur peningkatan yang relatif mudah untuk pustaka inti dan versi aplikasi. Mereka tidak dapat menyesuaikan diri untuk memiliki versi utama tetap yang distandarisasi Red Hat Enterprise Linux. Proses pengembangan dan rilis terganggu dengan pertanyaan tentang mengapa GLIBC 2.7 tidak dapat dicangkokkan ke RHEL 5.x atau mengapa versi kompiler atau pustaka tertentu tidak tersedia. Ketika diberitahu bahwa pembaruan antara versi utama RHEL / CentOS pada dasarnya membutuhkan pembangunan kembali penuh , mereka kehilangan banyak kepercayaan pada solusi.

Pada titik ini, saya menyadari bahwa Red Hat bergerak terlalu lambat untuk pengembang yang ingin berada di ujung tombak. RHEL 6.x adalah pembaruan yang sangat dibutuhkan dan disambut baik, tetapi tema ini menjadi lebih jelas setelah saya mulai mewawancarai perusahaan baru dan perusahaan yang mengikuti prinsip-prinsip DevOps .

Hari ini ...
Semakin banyak pengembang dan pengguna Linux yang berasal dari lingkungan Linux non-Red Hat, non-SuSE, non-perusahaan.

• Mereka menggunakan Ubuntu atau Debian ...
• Mereka tidak harus berurusan dengan perangkat keras jadul atau dukungan vendor besar.
• Mereka menulis aplikasi mereka sendiri dari bawah ke atas (mandiri).
• Virtualisasi dan komputasi awan mengabstraksi lapisan perangkat keras, jadi kekhawatiran tentang driver pengontrol RAID yang funky, periferal PCI-X, atau agen manajemen terdistribusi biner bahkan tidak ada dalam radar.
• Para pengguna ini menginginkan alat dan tanah pengguna yang biasa mereka gunakan.

Jadi ada konflik ... Pengguna ini tidak mengerti mengapa mereka akan dibatasi pada aplikasi atau versi perpustakaan. Administrator sekolah lama masih menyesuaikan diri dengan paradigma baru . Argumen yang tampaknya berakar dalam agama sebenarnya hanyalah fungsi dari bagaimana orang mengembangkan keterampilan mereka masing-masing.

Saya melihat iklan pekerjaan hari ini untuk posisi insinyur DevOps Linux yang sangat senior yang membaca:

Harus ahli dalam distribusi Linux berbasis Debian (Ubuntu dan varian oke. Red Hat lumayan , tapi tidak disukai)

Jadi saya kira itu bekerja dua arah ... Saya telah meninggalkan peluang kerja karena 800 server CentOS yang akan saya kelola akan dikonversi ke Ubuntu. Tentu, Linux adalah Linux ... tapi saya tidak merasa bahwa saya akan seefektif mungkin ... Saya telah gagal dengan instalasi Debian dan berharap bahwa distro berbasis RPM sedang digunakan. Saya memiliki argumen panas tentang manfaat dari berbagai platform (biasanya menempatkan Gentoo di bagian bawah daftar).

Jadi apa yang tepat untuk lingkungan ANDA? Tergantung. Saya pernah berada di perusahaan-perusahaan di mana para insinyur sistem mendorong keputusan, serta organisasi di mana para pengembangnya adalah raja. Saya pikir pengaturan terbaik adalah ketika pengembang dan orang-orang yang mendukung sistem sepakat pada platform. Tetapi di luar itu, pikirkan tentang dukungan jangka panjang, kegunaan, komunitas dan apa yang mengakomodasi tumpukan aplikasi Anda dengan cara yang paling tepat.

Pengembang yang berbakat harus dapat bekerja di lingkungan seperti-RHEL atau seperti-Debian. Dan, platform pengembangan harus mencerminkan lingkungan produksi. Anda pergi dari sana ...