Teknologi

Pengembang tidak ingin melakukan operasi

Dengan tugas pengembangan perangkat lunak yang semakin kompleks, mungkin sudah saatnya bagi spesialis dev dan ops untuk berpisah sekali lagi. Tapi bisakah itu dilakukan tanpa mengulangi kesalahan masa lalu?

Devops muncul seiring dengan munculnya metodologi tangkas dan komputasi awan di akhir tahun 2000-an, sebagai perangkat lunak mulai memakan dunia. Sebuah portmanteau rapi dari “pengembangan” dan “operasi,” devops berusaha untuk menyatukan dua kelompok yang sebelumnya terpisah yang bertanggung jawab untuk membangun dan menyebarkan perangkat lunak. Ini juga bertepatan dengan, atau bahkan secara tidak sengaja didorong ke depan, kebutuhan para insinyur perangkat lunak untuk memperketat loop umpan balik pengguna mereka dan mendorong pembaruan ke produksi lebih sering.

Sementara banyak organisasi mengambil kesempatan ini untuk menyatukan dua set spesialis untuk memecahkan masalah umum dengan kecepatan yang sebelumnya tidak mungkin, yang lain mengambil kebangkitan devops sebagai lisensi bagi pengembang untuk bertanggung jawab atas tugas-tugas operasi dan berusaha membangun tim super penuh semi-mitos. -pengembang tumpukan.

“Pengembang tidak ingin berurusan dengan masalah operasional, sebagian besar,” tweeted Pengembang untuk Dummies penulis dan kepala keterlibatan komunitas di Amazon Web Services, Emily Freeman.

Freeman jelas terpukul, dengan ratusan balasan mengalir dari pengembang yang juga tidak ingin melakukan operasi.

“Saya seorang pengembang dan saya tidak ingin berurusan dengan masalah operasi,” Scott Pantall, seorang insinyur perangkat lunak di perusahaan makanan cepat saji Chipotle, menjawab.

“Pengembang dan ops harus bekerja sama dengan baik sambil memiliki peran yang berbeda. Empati antar tim adalah poin yang sebenarnya, ”Andrew Gracey, seorang penginjil pengembang di SUSE, menimbang.

Sementara konsep mengalihkan lebih banyak masalah operasional dan keamanan “ke kiri” dan ke dalam domain pengembang perangkat lunak jelas memiliki kelebihan, namun juga berpotensi menciptakan hambatan yang berbahaya.

“Jika Kamu menarik pengembang ke terlalu banyak area yang berbeda, Kamu akhirnya menembak diri sendiri. Mereka adalah keahlian yang berbeda,” James Brown, kepala produk untuk spesialis penyimpanan Kubernetes, Ondat, mengatakan kepada InfoWorld.

Atau seperti yang dikatakan Nick Durkin, CTO lapangan di Harness, “Orang-orang mulai menyadari bahwa kami tidak akan menyewa tukang listrik untuk melakukan pemipaan kami.”

Peningkatan ‘besar-besaran’ dalam tanggung jawab

Sementara stok pengembang perangkat lunak perusahaan tidak pernah lebih tinggi, keahlian khusus operasi teknis agak memudar ke latar belakang, bahkan ketika beban kerja mereka meningkat.

Sebagai insinyur pengembang dan mantan administrator sistem Mathew Duggan tulis tahun lalusementara operator “masih memiliki semua tanggung jawab yang kami miliki sebelumnya, memastikan aplikasi tersedia, dipantau, aman, dan sesuai”, mereka juga telah ditugaskan untuk membangun dan memelihara jalur pengiriman perangkat lunak, “meletakkan dasar untuk memberdayakan pengembangan untuk mendapatkan kode keluar dengan cepat dan aman tanpa kita terlibat.”

Tanggung jawab yang diperluas ini melibatkan upaya pelatihan ulang massal, di mana rekayasa dan infrastruktur cloud sebagai keterampilan kode menjadi yang terpenting.

“Menurut pendapat saya, situasinya tidak pernah sesuram ini,” tulis Duggan. “Pengembangan telah benar-benar kewalahan dengan peningkatan besar-besaran dalam lingkup tanggung jawab mereka (RIP QA) tetapi juga dengan harapan yang tidak realistis oleh manajemen mengenai kecepatan.”

Tekanan itu mungkin mulai terlihat.

“Sangat menantang untuk membangun sebuah organisasi yang mencapai tingkat keselarasan berulang yang berlangsung untuk periode yang berkelanjutan,” menulis Tyler Jewell, direktur pelaksana di Dell Technologies Capital dalam sebuah catatan penelitian. “Ketika sistem tumbuh dalam kompleksitas dan umpan balik pengguna akhir meningkat, menjadi semakin sulit bagi manusia untuk menalar tentang dampak perubahan yang mungkin terjadi pada sistem.”

Mengenali masalah

Situasinya mungkin tidak seputus asa seperti yang diyakini Duggan dan yang lainnya, meskipun mungkin memerlukan penataan kembali tim teknik dan tanggung jawab mereka secara signifikan.

“Tujuannya bukan untuk membebani pengembang, ini untuk memberdayakan pengembang dengan informasi yang tepat pada waktu yang tepat,” kata Durkin dari Harness. “Mereka tidak ingin mengonfigurasi semuanya, tetapi mereka menginginkan informasi dari sistem tersebut pada waktu yang tepat untuk memungkinkan tim operasi dan keamanan dan infrastruktur bekerja dengan tepat. Pengembang seharusnya tidak peduli kecuali ada yang rusak.”

Nigel Simpson, mantan direktur strategi teknologi perusahaan di Walt Disney Company, ingin melihat perusahaan “mengenali masalah ini dan bekerja untuk mengeluarkan pengembang dari bisnis yang mengkhawatirkan cara kerja mesin—dan kembali membangun perangkat lunak, yang apa yang terbaik dari mereka.”

Penting untuk diingat bahwa devops adalah kontinum dan implementasinya akan bervariasi dari satu organisasi ke organisasi lainnya. Hanya karena pengembang dapat melakukan beberapa operasi sekarang tidak berarti mereka harus selalu melakukannya.

“Kontrol pengembang atas infrastruktur bukanlah proposisi semua-atau-tidak sama sekali,” Analis Gartner Lydia Leong menulis. “Tanggung jawab dapat dibagi di seluruh siklus hidup aplikasi, sehingga Kamu bisa mendapatkan manfaat dari ‘Kamu membangunnya, Kamu menjalankannya’ tanpa harus menerjunkan pengembang Kamu ke hutan belantara yang liar dan tidak dikenal dan berharap mereka beruntung dalam bertahan karena itu ‘bukan infrastruktur dan masalah tim operasi’ lagi.”

Dengan kata lain, “Tidak apa-apa untuk mengizinkan pengembang Kamu mengakses layanan mandiri penuh ke lingkungan pengembangan dan pengujian, dan kemampuan untuk membangun infrastruktur sebagai templat kode untuk produksi, tanpa membuat mereka bertanggung jawab penuh atas produksi,” tulis Leong.

Seperti yang dilihat oleh Brown di Ondat, orkestrasi container dengan Kubernetes muncul sebagai lapisan di antara kedua tim ini, memisahkan kekhawatiran sehingga developer dapat fokus pada kode mereka, dan operasi dapat memastikan bahwa infrastruktur dan pipeline yang mendasarinya dioptimalkan untuk menjalankannya. “Jangan mundur ke tim-tim yang tidak berbicara satu sama lain,” kata Brown.

Bahkan menurut Laporan “State of Kubernetes in 2022” dari VMware54% dari 776 responden mengatakan bahwa efisiensi pengembang yang lebih baik adalah alasan utama untuk mengadopsi Kubernetes, dan lebih dari sepertiga (37%) mengatakan mereka ingin meningkatkan efisiensi operator.

“Jangan terjerumus pada kekeliruan mencoba menjadikan semua orang ahli,” Kaspar von Grunberg, pendiri Humanitec, tulis di buletin emailnya. “Di tim berkinerja tinggihanya ada sedikit pakar terkemuka di Kubernetes, dan ada tingkat abstraksi yang tinggi untuk menjaga beban kognitif tetap rendah untuk semua orang.”

Devop sudah mati

Jika era devops memang akan segera berakhir, atau bahkan jika kilapnya baru mulai hilang, apa yang akan terjadi selanjutnya?

Rekayasa keandalan situs (SRE), yang muncul dari Google ketika mengalami kesulitan tumbuh terkait devops sendiri, telah membuktikan solusi yang populer.

“Pada dasarnya, itulah yang terjadi ketika Kamu meminta seorang insinyur perangkat lunak untuk merancang fungsi operasi,” kata Ben Treynor, wakil presiden teknik di Google dan bapak baptis SRE, sering dikutip.

Ambil contoh dua lembaga keuangan besar, Vanguard dan Morgan Stanley, yang mengalami kesulitan untuk menyeimbangkan tanggung jawab pengembang dan operasi saat mereka beralih ke praktik cloud-native yang lebih banyak.

Memasukkan selimut pengaman SRE di tingkat operasi pusat dan di dalam tim pengembang individu telah membantu kedua perusahaan membangun keyakinan bahwa mereka mencapai keseimbangan yang tepat antara kecepatan pengembang dan stabilitas operasional.

Namun, fungsi SRE juga menuai beberapa kritik. Menetapkan prinsip-prinsip SRE adalah “terkadang disalahpahami sebagai rebranding tim operasi,” seperti yang diamati Trevor Brosnan, kepala devops dan arsitektur teknologi perusahaan di Morgan Stanley.

“Ini adalah masalah yang bernuansa untuk dipecahkan,” Christina Yakomin, seorang insinyur keandalan situs di Vanguard, mengatakan. “Memperkenalkan SRE memang membuat orang merasa seperti kita menyelipkan operasi lagi ke dalam peran itu.” Sebaliknya, Yakomin ingin mendorong pengembang dan spesialis operasi Vanguard untuk berbagi tanggung jawab atas keamanan dan memastikan bahwa tim dengan platform bersama mengambil tanggung jawab operasional penuh untuk mereka.

Rekayasa platform berumur panjang

Ide platform pengembang internal, atau disiplin rekayasa platform, juga muncul sebagai cara bagi organisasi untuk memberi pengembang alat yang mereka butuhkan, lengkap dengan pagar organisasi yang sesuai untuk memungkinkan pengembang melakukan pekerjaan terbaik mereka.

Platform pengembang internal biasanya terdiri dari API, alat, layanan, pengetahuan, dan dukungan yang dibutuhkan pengembang untuk memasukkan kode mereka ke dalam produksi, digabungkan ke dalam platform standar perusahaan yang dikelola oleh tim spesialis khusus, atau pemilik produk .

“Devops sudah mati, rekayasa platform berumur panjang,” tweeted insinyur perangkat lunak dan komentator devops Sid Palas. “Pengembang tidak suka berurusan dengan infra, perusahaan perlu mengontrol infra mereka saat mereka tumbuh. Rekayasa platform memungkinkan dua fakta ini untuk hidup berdampingan.”

Brandon Byars, kepala teknologi di konsultan perangkat lunak Thoughtworks, mengatakan dia sering “melihat divisi itu bekerja dengan baik dalam tim rekayasa platform, yang berupaya menghilangkan gesekan bagi pengembang, sambil memberi mereka panggilan untuk berputar.” Namun, dia menambahkan, “Di mana itu tidak bekerja dengan baik adalah dengan meminta pengembang untuk melakukan semua pekerjaan itu tanpa keahlian terpusat dan dukungan alat.”

Tindakan penyeimbangan antara pengembangan perangkat lunak dan tim operasi akan akrab bagi organisasi mana pun yang telah bekerja untuk menerapkan prinsip-prinsip pengembangan di seluruh tim tekniknya. Ini juga merupakan tindakan penyeimbang yang menjadi semakin canggih di era kompleksitas cloud-native.

Hak Cipta © 2022 Idya.live, Inc.

Leave A Reply

Your email address will not be published.