Eulogi untuk DevOps

Konsep dan sejarah DevOps

• DevOps adalah konsep yang diperkenalkan sekitar tahun 2007, dengan tujuan menghapus batas antara orang yang mengelola hardware dan orang yang menulis software
• Pada awalnya, ini merupakan upaya untuk meningkatkan keamanan deployment kode dengan meniru prosedur dan ide dari NASA
• Pada saat itu, proses deployment software adalah sebagai berikut:
  • Tim pengembang menyiapkan rilis software server, tim QA mengujinya, lalu didistribusikan ke pelanggan
  • Tim operasi menerima playbook yang mencakup perubahan software dan cara menangani masalah jika terjadi
  • Pembaruan di-rollout secara bertahap di dalam data center sambil dipantau
  • Tanggal deployment ditentukan, lalu dilakukan pemantauan setelah deployment

Masalah DevOps

• DevOps sangat padat karya
• Dibutuhkan kolaborasi antara tim pengembang, tim QA, penulis teknis, dan tim operasi
• Deployment fitur berjalan lambat, dan pembaruan penting diprioritaskan
• Banyak organisasi mengadopsi DevOps karena alasan berikut:
  • Tenaga teknis tidak mudah digantikan
  • Perekrutan sulit dan mahal
  • Vendor SaaS mengurangi kompleksitas
  • Mereka menonjolkan keunggulan platform cloud
  • Pengembang tidak puas karena perubahan kecil butuh waktu lama sampai bisa dideploy

Wujud nyata DevOps

• DevOps bertujuan agar tim pengembang dan tim operasi terintegrasi menjadi satu tim
• Tim QA diberhentikan, dan periode pengujian internal dipersingkat melalui deployment cepat dan feedback
• DevOps kadang disamakan dengan SRE milik Google, tetapi SRE memiliki pendekatan yang lebih terstruktur dan ketat
• Proses DevOps yang nyata adalah sebagai berikut:
  • Pengembang membuat branch di git dan menambahkan fitur
  • Membuka PR, lalu setelah ditinjau rekan tim, digabungkan ke main
  • Sistem CI/CD memulai build dan mendorong container ke registry
  • Sistem CD memberi tahu server tentang rilis baru, dan memantau apakah deployment berhasil
  • Perubahan setelah deployment dipantau melalui metrik kesadaran rilis

Faktor kegagalan DevOps

• Pengembang menguji di lingkungan lokal lalu mendeploy ke server Linux, sehingga muncul perbedaan kecil
• Tim operasi tidak memantau deployment, sehingga penyelesaian masalah menjadi sulit
• Pengembang kurang memiliki pengetahuan tentang pengoperasian sistem
• Pengenalan container menyelesaikan sebagian masalah, tetapi kompleksitas operasi tetap ada

Pengenalan container dan keterbatasannya

• Container menyelesaikan masalah "berjalan dengan baik di komputer saya"
• Ini menyederhanakan komponen konfigurasi server Linux
• Masalah yang masih tersisa
  • Operate: membutuhkan keahlian untuk pemeliharaan infrastruktur, upgrade, dan lainnya
  • Observe: sulit membangun dan mengelola sistem monitoring yang kompleks
  • Feedback berkelanjutan: penanganan feedback internal masih kurang
  • Discover: kurangnya berbagi pengetahuan antartim
  • Plan: sulit membuat perencanaan yang terpusat

Munculnya Platform Engineering

• Platform Engineering adalah konsep lanjutan dari DevOps. Alih-alih tim pengembang harus memahami operasional platform dan memecahkan masalahnya, tugas itu ditangani oleh tim platform
• Pendekatan ini secara jelas memisahkan tanggung jawab tim pengembang dan operasi platform sehingga pembagian peran lebih tegas, tetapi tetap menuntut banyak keterampilan teknis
• Baik pengembang maupun tim operasi harus mengerjakan lebih banyak hal

Kesimpulan

• Di ranah infrastruktur, kecenderungan untuk mencari alat yang sederhana dan tidak terikat pada platform tertentu semakin meningkat
• Banyak organisasi meninggalkan teknologi kompleks seperti Kubernetes dan kembali ke workflow yang lebih sederhana
• Platform Engineering bukan solusi serba bisa, dan organisasi perlu membedakan mana yang benar-benar dibutuhkan dan mana yang tidak
• Keunggulan pendekatan DevOps perlu dipertahankan sambil memfokuskan diri pada penyederhanaan dan stabilitas

Pendapat GN⁺

1. Evolusi DevOps dan kondisinya saat ini menunjukkan dengan baik perubahan tren di industri teknologi. Menarik melihat bagaimana kesenjangan antara tujuan ideal awal dan realitas disadari, lalu dicari pendekatan yang lebih praktis

2. Peralihan ke Platform Engineering tampak sebagai upaya untuk mengakui keterbatasan DevOps dan mencari solusi baru. Namun ini juga bukan solusi sempurna, sehingga dibutuhkan pendekatan yang disesuaikan dengan skala dan karakteristik tiap organisasi

3. Seiring meningkatnya kompleksitas teknologi cloud-native dan arsitektur microservices, kesederhanaan dan stabilitas kembali dievaluasi. Ini menunjukkan bahwa dalam memilih teknologi, nilai bisnis dan efisiensi operasional perlu dipertimbangkan dengan lebih serius

4. Perubahan dalam DevOps dan Platform Engineering menekankan pentingnya pembelajaran dan adaptasi berkelanjutan dalam pengembangan dan operasi software. Para praktisi teknis perlu mengembangkan bukan hanya pemahaman atas alat dan metodologi baru, tetapi juga kemampuan menyeimbangkan kebutuhan bisnis dan kompleksitas teknis

5. Ke depan, cara pengembangan dan pengoperasian software diperkirakan akan mengadopsi pendekatan yang lebih fleksibel dan kontekstual. Alih-alih organisasi besar dan startup kecil mengikuti cara yang sama, tren memilih proses dan alat yang paling sesuai dengan situasi masing-masing akan semakin menguat

[kaydash]

Cukup sering
para manajer
berharap bahwa hanya dengan mengadopsi konsep DevOps
tanpa usaha pun inovasi besar akan muncul
(pada perusahaan lama, baik besar maupun kecil)
sebuah cara pikir yang keliru

[GN⁺]

Komentar Hacker News

• Poin utamanya adalah fokus pada "build, test, deploy" dalam diagram "devops cycle"

  • Penekanannya ada pada kecepatan, tanpa mempertimbangkan keunggulan rekayasa
  • Tim operasi dipecat dan QA direstrukturisasi
  • Semua tim akhirnya memiliki jadwal on-call
  • Perubahan yang kacau dimasukkan ke sistem demi keuntungan jangka pendek
  • Beberapa bulan kemudian, setiap perubahan menimbulkan masalah
  • Alat devops berguna, tetapi mahal dan membuat frustrasi
  • Pengembang baru tidak tahu devops, tetapi tahu container

• Ini adalah pendapat yang didasarkan pada masalah yang dialami tim devops

  • Seharusnya bisa menambahkan layanan baru dan mengelola infrastruktur dengan aman
  • Devops telah menjadi standar, dan pekerjaan administrator sistem yang bersifat manual tidak lagi diperlukan

• Kritik terhadap Kubernetes itu keliru

  • Kubernetes adalah contoh rekayasa perangkat lunak yang hebat, didukung dengan baik, dan dapat dijalankan di mana saja
  • Lebih baik mempelajari Kubernetes daripada menggunakan skrip bash secara acak

• Devops adalah tentang menghilangkan hambatan agar deployment perangkat lunak menjadi lebih mudah

  • Deployment harian membantu merilis kode dengan kualitas lebih tinggi
  • Opsi untuk hanya melakukan deployment saat kode sudah siap itu penting
  • Rilis bulanan menciptakan tekanan yang dapat menyebabkan pilihan yang tidak efisien

• Devops adalah filosofi, bukan metodologi

  • Tujuannya adalah mengintegrasikan operasi ke dalam SDLC
  • Cloud membuat hal ini lebih mudah
  • Munculnya tim "DevOps" telah mendistorsi filosofi aslinya

• Seruan kepemimpinan untuk "meruntuhkan silo" hampir bersifat seremonial

  • Wewenang tanpa tanggung jawab tidak efektif
  • Talenta devops terbaik senang menggantikan dirinya sendiri dengan kode
  • Alat devops sudah matang dan terdokumentasi dengan baik
  • Pengembang yang tidak mempelajari Kubernetes sama seperti pengembang yang tidak tahu perintah Linux

• Jika pengguna bisa menjadi tester, maka seharusnya demikian

  • Hanya ada persoalan ekonomi
  • Jika pelanggan banyak, biarkan pengguna yang menguji; jika pelanggan sedikit, harus diuji sendiri

• Tim platform hanya memungkinkan di perusahaan besar

  • Perusahaan kecil dan menengah kekurangan tenaga devops sehingga harus menanggung stres dan risiko
  • Ketiadaan tim platform menyebabkan banyak masalah

• Devops adalah filosofi, bukan metodologi

  • Pengalaman bekerja dalam tim yang tersilo membuktikan perlunya devops
  • Devops memungkinkan tim memahami proyek sepenuhnya dan melakukan deployment

• Devops memiliki niat yang baik

  • Loop umpan balik yang cepat penting bagi kecepatan pengembangan
  • Harus menemukan solusi terbaik yang sesuai dengan organisasi dan produk