Terjemahan artikel disiapkan khusus untuk siswa kursus Praktek dan Alat DevOps .
Artikel ini membahas hubungan antara struktur kode dan struktur organisasi dalam pengembangan perangkat lunak. Saya membahas mengapa perangkat lunak dan tim tidak dapat mengukur dengan mudah, pelajaran apa yang dapat kita lihat di alam dan Internet, dan menunjukkan bagaimana kita dapat mengurangi konektivitas perangkat lunak dan tim untuk mengatasi masalah penskalaan.
Artikel ini didasarkan pada pengalaman saya selama 20 tahun dalam menciptakan sistem perangkat lunak besar dan pada kesan buku
"Percepat: Ilmu Perangkat Lunak Lean dan DevOps: Membangun dan Memperbesar Organisasi Teknologi Berkinerja Tinggi" (Nicole Forsgren, Jez Humble dan Gene Kim), yang bukti penelitian untuk mendukung sebagian besar klaim saya di sini. Buku ini sangat disarankan untuk dibaca.
Perangkat lunak dan perintah tidak berskala
Seringkali rilis pertama, mungkin ditulis oleh satu atau dua orang, ternyata sangat sederhana. Mungkin memiliki fungsi terbatas, tetapi ditulis dengan cepat dan memenuhi persyaratan pelanggan. Interaksi dengan pelanggan pada tahap ini sangat baik, karena pelanggan biasanya berhubungan langsung dengan pengembang. Setiap bug diperbaiki dengan cepat, dan fitur baru dapat ditambahkan tanpa rasa sakit. Setelah beberapa saat, langkahnya melambat. Versi 2.0 membutuhkan waktu yang lebih lama dari yang diharapkan. Lebih sulit untuk memperbaiki bug, dan fitur baru diberikan, itu tidak begitu sederhana. Jawaban alami untuk ini adalah menambahkan pengembang baru ke tim. Meskipun tampaknya setiap karyawan tambahan yang ditambahkan ke tim mengurangi produktivitas. Ada perasaan bahwa ketika kompleksitas perangkat lunak tumbuh, ia berhenti berkembang. Dalam kasus ekstrim, organisasi mungkin menemukan bahwa mereka menggunakan program dengan dukungan yang sangat mahal yang hampir tidak mungkin untuk melakukan perubahan. Masalahnya adalah Anda tidak perlu membuat "kesalahan" untuk mewujudkannya. Sangat umum sehingga dapat dikatakan bahwa ini adalah properti “alami” dari perangkat lunak.
Mengapa ini terjadi? Ada dua alasan: yang terkait dengan kode dan tim. Baik kode dan perintah tidak skala dengan baik.
Ketika basis kode bertambah, semakin sulit bagi satu orang untuk memahaminya. Ada batasan kognitif tetap seseorang. Dan, meskipun, satu orang dapat mengingat rincian sistem kecil, tetapi hanya sampai itu menjadi lebih dari jangkauan kognitifnya. Begitu sebuah tim tumbuh menjadi lima orang atau lebih, hampir mustahil bagi satu orang untuk menyadari bagaimana semua bagian dari sistem bekerja. Dan ketika tidak ada yang mengerti keseluruhan sistem, ketakutan muncul. Dalam sistem yang besar dan berpasangan ketat, sangat sulit untuk memahami efek dari setiap perubahan yang signifikan, karena hasilnya tidak terlokalisasi. Untuk meminimalkan dampak perubahan, pengembang mulai menggunakan solusi dan duplikasi kode alih-alih mengidentifikasi fitur umum, membuat abstraksi dan generalisasi. Ini semakin memperumit sistem, memperkuat tren negatif ini. Pengembang tidak lagi merasa bertanggung jawab atas kode yang tidak mereka pahami dan enggan melakukan refactoring. Utang teknis tumbuh. Ini juga membuat pekerjaan menjadi tidak menyenangkan dan tidak memuaskan dan merangsang "bakat menguras" ketika pengembang terbaik pergi yang dapat dengan mudah menemukan pekerjaan di tempat lain.
Tim juga tidak berskala. Seiring pertumbuhan tim, komunikasi menjadi lebih kompleks. Formula sederhana mulai digunakan:
c = n(n-1)/2(di mana n adalah jumlah orang, dan c adalah jumlah koneksi yang mungkin antara anggota tim)Ketika timnya tumbuh, kebutuhannya akan komunikasi dan koordinasi tumbuh secara eksponensial. Jika tim tertentu terlampaui, sangat sulit bagi satu tim untuk tetap menjadi struktur yang tidak terpisahkan, dan kecenderungan sosial manusia yang alami untuk membaginya menjadi kelompok-kelompok yang lebih kecil akan mengarah pada pembentukan subkelompok informal, bahkan jika manajemen tidak mengambil bagian di dalamnya. Komunikasi dengan kolega menjadi lebih sulit dan secara alami akan digantikan oleh pemimpin baru dan komunikasi top-down. Anggota tim ditransformasikan dari rekan kerja dalam sistem menjadi pekerja produksi reguler. Motivasi menderita, tidak ada rasa memiliki karena
efek difusi tanggung jawab .
Manajemen sering melakukan intervensi pada tahap ini dan secara formal mendekati pembentukan tim baru dan struktur manajemen. Tetapi, tidak masalah secara formal atau informal, sulit bagi organisasi besar untuk mempertahankan motivasi dan minat.
Biasanya pengembang yang tidak berpengalaman dan manajemen yang buruk menyalahkan patologi penskalaan ini. Tapi ini tidak adil. Masalah penskalaan adalah properti “alami” dari perangkat lunak yang tumbuh dan berkembang. Inilah yang selalu terjadi jika Anda tidak menemukan masalah pada tahap awal, tidak memahami titik penyimpangan, dan tidak berusaha untuk memecahkan masalah. Tim pengembangan perangkat lunak terus-menerus diciptakan, jumlah perangkat lunak di dunia terus berkembang, dan sebagian besar perangkat lunak relatif kecil. Oleh karena itu, cukup sering, produk yang sukses dan berkembang dibuat oleh tim yang tidak memiliki pengalaman dalam pengembangan skala besar. Dan itu tidak realistis untuk mengharapkan pengembang untuk mengenali titik belok dan memahami apa yang harus dilakukan ketika masalah skala mulai terwujud.
Pelajaran Penskalaan Alam
Baru-baru ini saya membaca buku
“Skala” Geoffrey Barat yang luar biasa . Ini berbicara tentang matematika skala dalam sistem biologis dan sosial ekonomi. Tesisnya adalah bahwa semua sistem besar yang kompleks mematuhi hukum dasar skala. Ini adalah bacaan yang menarik dan saya sangat merekomendasikannya. Dalam artikel ini, saya ingin fokus pada sudut pandangnya bahwa banyak sistem biologis dan skala sosial mengejutkan dengan sangat baik. Lihatlah tubuh mamalia. Semua mamalia memiliki jenis sel yang sama, struktur tulang, sistem saraf dan peredaran darah. Namun, perbedaan ukuran antara mouse dan paus biru adalah sekitar 10 ^ 7. Bagaimana alam menggunakan bahan dan struktur yang sama untuk organisme dengan ukuran yang berbeda? Jawabannya tampaknya bahwa evolusi telah menemukan struktur bercabang fraktal. Lihatlah pohon itu. Setiap bagiannya terlihat seperti pohon kecil. Hal yang sama berlaku untuk sistem peredaran darah dan sistem saraf mamalia, mereka adalah jaringan fraktal bercabang di mana sebagian kecil paru-paru atau pembuluh darah Anda tampak seperti versi yang lebih kecil dari keseluruhan.
Bisakah kita mengambil ide-ide ini dari alam dan menerapkannya pada perangkat lunak? Saya pikir kita bisa belajar pelajaran penting. Jika kita dapat membangun sistem besar yang terdiri dari bagian-bagian kecil yang kelihatannya seperti sistem lengkap, akan mungkin untuk mengandung patologi yang mempengaruhi sebagian besar program saat mereka tumbuh dan berkembang.
Apakah ada sistem perangkat lunak yang berhasil menskalakan berdasarkan beberapa urutan besarnya? Jawabannya jelas - Internet, sistem perangkat lunak global dengan jutaan node. Subnet benar-benar terlihat dan berfungsi seperti versi yang lebih kecil dari seluruh Internet.
Tanda-tanda perangkat lunak yang digabungkan secara longgar
Kemampuan untuk menyorot komponen yang digabungkan secara individu dalam sistem besar adalah metode utama untuk penskalaan yang sukses. Internet, pada kenyataannya, adalah contoh dari arsitektur yang digabungkan secara longgar. Ini berarti bahwa setiap node, layanan atau aplikasi di jaringan memiliki sifat-sifat berikut:
- Protokol komunikasi yang umum digunakan.
- Data ditransfer menggunakan kontrak yang jelas dengan node lain.
- Komunikasi tidak memerlukan pengetahuan tentang teknologi implementasi spesifik.
- Versi dan penerapannya independen.
Internet scalable karena merupakan jaringan node yang berkomunikasi melalui seperangkat protokol yang terdefinisi dengan baik. Node berinteraksi hanya dengan protokol, detail implementasi yang tidak boleh diketahui untuk berinteraksi node. Internet global tidak digunakan sebagai satu sistem. Setiap node memiliki versi dan prosedur penyebaran di dalamnya. Masing-masing node muncul dan menghilang secara independen satu sama lain. Ketundukan pada protokol internet adalah satu-satunya hal yang sangat penting bagi keseluruhan sistem. Siapa yang membuat setiap situs, ketika dibuat atau dihapus, versi apa yang dimilikinya, teknologi dan platform spesifik apa yang digunakannya, semua ini tidak ada hubungannya dengan Internet secara keseluruhan. Inilah yang kami maksud dengan perangkat lunak yang digabungkan secara longgar.
Tanda-tanda organisasi yang digabungkan secara longgar
Kami dapat mengukur tim dengan mengikuti prinsip yang sama:
- Setiap sub-tim harus terlihat seperti organisasi pengembangan perangkat lunak kecil.
- Proses internal dan komunikasi tim tidak boleh melampaui tim.
- Teknologi dan proses yang digunakan untuk mengimplementasikan perangkat lunak tidak boleh didiskusikan di luar tim.
- Tim harus berkomunikasi satu sama lain hanya pada masalah eksternal: protokol umum, fungsionalitas, tingkat layanan, dan sumber daya.
Tim pengembangan kecil lebih efektif daripada yang besar, jadi Anda perlu memecah tim besar menjadi kelompok yang lebih kecil. Pelajaran dari alam dan Internet adalah bahwa subkelompok harus terlihat seperti organisasi pengembangan perangkat lunak kecil. Seberapa kecil mereka? Idealnya, dari satu hingga lima orang.
Yang penting adalah bahwa setiap tim terlihat seperti organisasi pengembangan perangkat lunak kecil yang independen. Cara lain untuk mengatur tim kurang efektif. Seringkali ada godaan untuk membagi tim besar menjadi beberapa fungsi. Oleh karena itu, kami memiliki tim arsitek, tim pengembangan, tim DBA, tim penguji, tim penempatan, dan tim pendukung, tetapi ini tidak menyelesaikan masalah penskalaan yang kita bicarakan di atas. Semua tim harus berpartisipasi dalam pengembangan fitur dan sering iteratif jika Anda ingin menghindari manajemen proyek dengan gaya air terjun.
Hambatan komunikasi antara tim fungsional ini menjadi hambatan utama untuk pengiriman yang efisien dan tepat waktu. Tim terhubung erat karena mereka perlu berbagi detail internal penting untuk bekerja bersama. Selain itu, minat tim yang berbeda tidak sesuai: pengembang biasanya menerima penghargaan untuk fitur baru, penguji kualitas, dukungan untuk stabilitas. Kepentingan yang berbeda ini dapat menyebabkan konflik dan hasil yang buruk. Mengapa pengembang harus khawatir tentang log jika mereka tidak pernah membacanya? Mengapa penguji harus peduli dengan pengiriman jika mereka bertanggung jawab atas kualitas?
Sebagai gantinya, kita harus mengatur tim untuk layanan yang digabungkan secara longgar yang mendukung fungsi bisnis, atau untuk sekelompok fungsi logis. Setiap sub-perintah harus merancang, kode, menguji, menyebarkan dan memelihara perangkat lunaknya sendiri. Kemungkinan besar, anggota tim semacam itu akan menjadi spesialis dari profil yang luas, dan bukan spesialis yang sempit, karena dalam tim kecil akan diperlukan untuk memisahkan peran-peran ini. Mereka harus fokus pada otomatisasi proses semaksimal mungkin: pengujian otomatis, penerapan, pemantauan. Tim harus memilih alat mereka sendiri dan merancang arsitektur untuk sistem mereka. Meskipun protokol yang digunakan untuk interaksi layanan harus ditentukan di tingkat organisasi, pilihan alat yang digunakan untuk mengimplementasikannya harus didelegasikan kepada tim. Dan itu sangat cocok dengan model DevOps.
Tingkat kemandirian suatu tim adalah cerminan dari tingkat keterhubungan seluruh organisasi. Idealnya, organisasi harus menjaga fungsionalitas perangkat lunak dan, pada akhirnya, nilai bisnis yang disediakan oleh tim, serta biaya sumber daya tim.
Dalam hal ini, arsitek perangkat lunak memainkan peran penting. Seharusnya tidak fokus pada alat dan teknologi spesifik yang digunakan tim, atau mengganggu detail arsitektur internal layanan. Sebaliknya, ia harus fokus pada protokol dan interaksi antara berbagai layanan dan kesehatan sistem secara keseluruhan.
Hukum Terbalik Conway: Struktur Organisasi Harus Memodelkan Arsitektur Target
Bagaimana koherensi perangkat lunak yang lemah dan koherensi tim yang lemah cocok bersama?
Hukum Conway menyatakan:
"Organisasi yang merancang sistem terbatas pada desain yang meniru struktur komunikasi organisasi ini."
Ini didasarkan pada pengamatan bahwa arsitektur sistem perangkat lunak akan mencerminkan struktur organisasi yang menciptakannya. Kami dapat "meretas" hukum Conway dengan membaliknya. Atur tim kami untuk mencerminkan arsitektur yang kami inginkan. Dengan mengingat hal ini, kita harus menyelaraskan tim yang digabungkan secara longgar dengan komponen perangkat lunak yang digabungkan secara longgar. Tetapi haruskah itu hubungan satu-ke-satu? Saya pikir, idealnya, ya. Meskipun tampaknya baik jika tim kecil bekerja pada beberapa layanan yang digabungkan secara longgar. Saya akan mengatakan bahwa titik belok untuk penskalaan lebih besar untuk tim daripada perangkat lunak, sehingga gaya organisasi ini tampaknya dapat diterima. Penting agar komponen perangkat lunak tetap terpisah, dengan versi dan penyebarannya sendiri, bahkan jika beberapa di antaranya dikembangkan oleh satu tim. Kami ingin dapat membagi tim jika terlalu besar, dengan transfer layanan yang dikembangkan ke tim yang berbeda. Tetapi kami tidak dapat melakukan ini jika layanan digabungkan dengan erat atau berbagi proses, versi, atau penyebaran.
Kita harus menghindari pekerjaan beberapa tim pada komponen yang sama. Ini adalah pola anti. Dan, dalam arti tertentu, bahkan lebih buruk daripada pekerjaan satu tim besar dengan satu basis kode besar, karena hambatan komunikasi antara tim menyebabkan perasaan yang lebih kuat yaitu kurangnya kepemilikan dan kontrol.
Interaksi antara tim yang digabungkan secara longgar membuat perangkat lunak yang digabungkan secara longgar diminimalkan. Ambil contoh Internet lagi. Seringkali Anda dapat menggunakan API yang disediakan oleh perusahaan lain tanpa komunikasi langsung dengannya (jika prosesnya sederhana dan ada dokumentasi). Ketika tim berinteraksi, pengembangan tim internal dan proses implementasi tidak boleh didiskusikan. Sebagai gantinya, fungsionalitas, tingkat layanan, dan sumber daya harus didiskusikan.
Mengelola tim yang digabungkan secara longgar membuat perangkat lunak yang digabungkan secara longgar harus lebih mudah daripada alternatif. Organisasi besar harus fokus pada penyediaan tujuan dan persyaratan yang jelas bagi tim dalam hal fungsionalitas dan tingkat layanan. Persyaratan sumber daya harus berasal dari tim, meskipun mereka dapat digunakan oleh organisasi untuk mengukur laba atas investasi.
Tim yang digabungkan secara longgar mengembangkan perangkat lunak yang digabungkan secara longgar
Konektivitas yang lemah dalam perangkat lunak dan antar tim adalah kunci untuk membangun organisasi yang sangat efektif. Dan pengalaman saya menegaskan hal ini. Saya bekerja di organisasi di mana tim dibagi berdasarkan fungsi, tingkat perangkat lunak, atau bahkan di mana ada pemisahan pelanggan. Saya juga bekerja di tim kacau besar pada basis kode tunggal. Tetapi dalam semua kasus ini, ada masalah dengan penskalaan, yang disebutkan di atas. Pengalaman yang paling menyenangkan selalu ketika tim saya adalah unit penuh, secara independen terlibat dalam pembuatan, pengujian dan penyebaran layanan independen. Tapi kamu tidak perlu mengandalkan kisah hidupku. Accelerate (dijelaskan di atas) memiliki bukti penelitian untuk mendukung pandangan ini.
Jika Anda telah membaca materi ini sampai akhir, kami sarankan Anda menonton rekaman webinar terbuka dengan topik "One Day in the Life of DevOps" .