Industri teknologi sedang bergulat dengan kesadaran yang berkembang bahwa DevOps, yang dulunya dipuji sebagai pendekatan revolusioner untuk pengembangan perangkat lunak dan operasi, mungkin telah kehilangan arahnya. Apa yang dimulai sebagai gerakan untuk memberdayakan developer agar memiliki lingkungan produksi mereka sendiri telah berkembang menjadi sesuatu yang menurut banyak pihak justru mengalahkan tujuan aslinya.
Visi Awal vs Realitas Saat Ini
DevOps dimulai dengan ide sederhana: developer harus men-deploy kode mereka sendiri dan bertanggung jawab untuk menjaganya tetap berjalan. Ini berarti memantau sistem, merespons masalah, dan menggunakan keterampilan pemrograman untuk mengotomatisasi deployment dengan aman. Pendekatan ini sangat masuk akal, terutama karena layanan cloud membuat pembuatan server semudah memanggil API.
Namun, saat praktik ini mendapat nama formal, semuanya berubah. Perusahaan mulai membuat tim DevOps khusus dan mempekerjakan engineer DevOps, yang secara efektif menarik developer yang berpikiran produksi dari tim produk. Hal ini membuat tim pengembangan tanpa siapa pun yang fokus pada masalah produksi, menciptakan kembali silo yang seharusnya dihilangkan oleh DevOps.
Masalah Kesenjangan Keterampilan
Salah satu masalah paling signifikan yang mengganggu implementasi DevOps modern adalah ketidaksesuaian keterampilan yang mendasar. Banyak profesional dalam peran DevOps berasal dari latar belakang administrasi sistem tradisional tanpa kemampuan pemrograman yang kuat. Ini menciptakan hambatan di mana tim berjuang dengan tugas debugging dasar dan otomatisasi yang memerlukan keterampilan pengembangan yang sebenarnya.
Ekspektasi bahwa satu orang dapat menangani pengembangan, operasi, observabilitas, dan dukungan tidak dapat diskalakan dalam praktik. Yang sering terjadi adalah staf operasi dengan gelar baru yang mewah atau developer yang didorong ke wilayah yang tidak familiar, jarang mencapai perpaduan keterampilan yang sebenarnya dituntut oleh peran tersebut.
Masalah Umum Implementasi DevOps
- Ketidaksesuaian Keterampilan: Banyak profesional DevOps yang kurang memiliki kemampuan pemrograman yang kuat, berasal dari latar belakang sysadmin tradisional
- Silo Organisasi: Membuat tim DevOps terpisah justru menarik keahlian produksi menjauh dari tim pengembangan
- Masalah Kepercayaan: Implementasi modern sering kali membatasi daripada memberdayakan para developer
- Beban Kepatuhan: Persyaratan keamanan diimplementasikan melalui pembatasan daripada transparansi
- Kompleksitas Tool: Abstraksi internal yang tertinggal dari kemampuan penyedia layanan cloud
Masalah Kepercayaan dan Kontrol
Tim DevOps modern sering beroperasi dengan asumsi bahwa developer tidak dapat dipercaya dengan akses produksi. Pola pikir ini mengarah pada lapisan pembatasan dan proses persetujuan yang memperlambat pengembangan daripada memungkinkannya. Tim akhirnya membangun alat internal yang dirancang lebih untuk membatasi daripada memberdayakan, membungkus API cloud dalam abstraksi buatan sendiri yang tertinggal dari apa yang sudah ditawarkan penyedia.
Engineer tim produk saat ini merasa seperti anak manja, mereka tidak tahu bagaimana server berjalan, dan meminta hal-hal yang tidak masuk akal.
Ini menciptakan siklus setan di mana developer menjadi semakin terputus dari realitas produksi sementara tim DevOps menjadi penjaga gerbang daripada enabler.
Jebakan Kepatuhan
Persyaratan kepatuhan sering disalahkan untuk praktik yang membatasi, tetapi masalah sebenarnya terletak pada implementasi. Keamanan harus berasal dari visibilitas dan transparansi, bukan pintu yang terkunci. Ketika tim DevOps memiliki daftar periksa kepatuhan, mereka sering memasukkan ketidakpercayaan ke dalam aturan, menganggap developer sebagai pelaku jahat potensial daripada kolaborator.
Apa yang Bekerja Lebih Baik
Organisasi yang menemukan kesuksesan bergerak menjauh dari tim DevOps terpisah menuju model tertanam. Beberapa perusahaan memiliki engineer yang berpikiran produksi bekerja langsung dengan tim pengembangan, dengan gelar seperti systems engineer daripada DevOps engineer. Pendekatan ini menjaga keahlian operasional tetap dekat dengan produk sambil mempertahankan semangat kolaboratif yang membuat DevOps berharga di tempat pertama.
Tim yang paling efektif menggabungkan developer yang fokus pada fitur dengan anggota tim yang paham ops yang dapat men-deploy pekerjaan mereka sendiri, didukung oleh tim platform engineering khusus yang menyediakan alat dan infrastruktur tanpa menjadi hambatan.
Pendekatan Alternatif yang Berhasil
- Model Tertanam: Insinyur yang berpikiran produksi bekerja langsung dengan tim pengembangan
- Insinyur Sistem: Peran teknis yang fokus pada infrastruktur tanpa beban "DevOps"
- Platform Engineering: Tim khusus yang menyediakan alat dan infrastruktur tanpa menjadi hambatan
- Tanggung Jawab Bersama: Menggabungkan pengembang yang fokus pada fitur dengan anggota tim yang paham operasional
Melihat ke Depan
Industri tampaknya belajar dari kesalahan ini, meskipun perlahan. Platform Engineering muncul sebagai evolusi berikutnya, meskipun beberapa pihak khawatir hal itu mungkin mengulangi pola yang sama. Kuncinya tampaknya adalah mempertahankan semangat kolaboratif dan tanggung jawab bersama yang membuat DevOps berharga sambil menghindari silo organisasi yang merongrong itu.
Kesuksesan memerlukan kepemimpinan teknis yang kuat yang memahami pengembangan dan operasi, tujuan yang jelas, dan budaya yang menghargai kolaborasi daripada politik. Tanpa fondasi ini, model organisasi apa pun akan berjuang terlepas dari apa namanya.
Referensi: In retrospect, DevOps was a bad idea.