Sebuah perbandingan idempotensi dan ketidakberubahan

Banyak di DevOps menerapkan mentalitas bukan-hewan peliharaan dengan menerapkan infrastruktur yang tidak dapat diubah dan mempekerjakan kembali ketika perubahan diperlukan (alih-alih memodifikasi).

Manajemen konfigurasi memiliki prinsip idempoten yang serupa . Apa manfaat komparatif, persamaan dan kelemahan dari ketidakberdayaan vs impotensi dan mana yang lebih efisien? Apakah ini dapat digunakan secara sinergis (mis., Penghapusan dan pemindahan berkala kontainer VM atau Docker menggunakan manajemen konfigurasi?)

Kedua istilah itu sangat berbeda.

Mari kita mulai dengan immutability, yang secara harfiah berarti "tidak ada mutasi" atau "tidak ada perubahan". Dalam arti DevOps, itu berarti bahwa setelah Anda membuat artefak, baik itu gambar kontainer, atau gambar VM, atau mungkin paket dari kode yang dikompilasi - Anda menyatakan bahwa Anda tidak akan pernah mengubahnya. Seringkali jika ada perubahan yang diperlukan, Anda menyatakan bahwa versi "barang" baru akan dibuat sebagai gantinya.

Istilah ini idempotenceberarti bahwa ketika perubahan diterapkan beberapa kali, negara dimutasi (diubah) hanya sekali . Pertama, itu sudah mengasumsikan bahwa akan ada perubahan yang diterapkan yang berarti bahwa Anda tidak dapat memiliki sesuatu yang abadi dan memiliki tindakan idempoten dilakukan untuk itu (tidak ada tindakan yang dilakukan untuk itu dengan kontrak).

Dalam penggunaan alat manajemen konfigurasi, idempotencedigunakan dalam beberapa kasus ketika menerapkan perubahan yang sama beberapa kali. Seperti menambahkan baris yang mengatakan localhostke /etc/hostsfile, Anda tidak benar-benar membutuhkan banyak baris seperti itu dan jika sudah ada, aman untuk tidak mencoba menambahkan lagi.

Juga idempotentmerupakan istilah yang digunakan untuk menggambarkan tindakan yang berusaha mengubah sesuatu, sementara immutabledigunakan untuk menggambarkan kata benda (objek) yang diatur terhadap perubahan yang dilakukan padanya.

Mengapa immutableobjek bermanfaat? Karena ketika Anda menyalinnya, misalnya dari lingkungan pengembang ke qa ke produksi. Anda sudah tahu cukup banyak (tetapi tidak semuanya) tentang bagaimana hal itu akan berperilaku. Dalam banyak kasus, bagian-bagian yang bekerja akan konsisten, dan bagian-bagian yang rusak akan konsisten juga.

Mengapa idempotenttindakan bermanfaat? Karena ketika Anda ingin mengubah keadaan suatu objek, dalam banyak kasus, hanya berguna untuk memverifikasi bahwa perubahan tersebut telah diterapkan dan menerapkan perubahan jika diperlukan. Misalnya, ketika item konfigurasi dalam file hilang atau memiliki nilai yang salah, ada baiknya menambahkannya sekali saja atau mengubahnya sekali saja saat menerapkan tindakan beberapa kali. Dalam banyak kasus lain, seperti file log , Anda tidak ingin memiliki tindakan idempoten karena Anda sering ingin menambahkan baris lain setiap kali beberapa peristiwa terjadi.

Infrastruktur yang tidak dapat diubah, dalam pikiran saya, merupakan pola yang berbeda dengan Manajemen Konfigurasi. Meskipun mereka dapat digunakan bersama, mereka secara alami mendekati masalah dengan dua cara berbeda.

Konsep Immefable Artifacts memiliki sejarah panjang, sistem Unix telah menggunakannya selama beberapa dekade untuk menyebarkan paket perangkat lunak. Tetapi begitu mereka dikerahkan, file-file konfigurasi diubah sehingga semuanya menjadi bisa berubah. Idempotency memberikan beberapa jaminan yang bagus dengan file yang bisa berubah, kita dapat mengetahui kapan hal-hal telah berubah dan hanya memperbarui hal-hal yang perlu diperbarui. Namun itu tidak menyelesaikan semua masalah objek yang bisa berubah, kita masih perlu memenuhi jumlah kasus tepi yang tampaknya tak terbatas. Karena segala sesuatu dapat berubah dan kita menjadi idempoten, kita perlu menentukan terlebih dahulu perubahan apa yang perlu dilakukan, kemudian melaksanakannya secara umum dalam urutan yang sangat spesifik. Saat menggunakan paket perangkat lunak, khususnya dengan penerapan zero down time, kita perlu mengatur perubahan dengan hati-hati untuk mencegah permintaan dibatalkan.

Kompleksitas ini pada akhirnya dapat dihindari dengan menggunakan artefak abadi alih-alih memutasikannya di tempat, karena kita hanya mengganti beberapa objek dengan yang lain (apakah itu biner, atau wadah atau Mesin Virtual), bawa ke dalam layanan dan pensiunkan yang lama . Ini hanyalah salah satu contoh dari penerapan zero down time.

Dengan kemajuan dalam perkakas untuk memungkinkan kami menggunakan artefak yang tidak dapat diubah ke ribuan sistem dalam waktu yang sangat kecil, kami melihat menggunakan alat yang tidak dapat diubah untuk mengelola sistem sebagai jauh lebih layak daripada manajemen konfigurasi. Namun tooling belum ada dan masih ada use case untuk keduanya. Saya melakukan pembicaraan tentang hal ini yang menjelaskan perkembangan linier dari sepenuhnya bisa berubah menjadi sepenuhnya tidak berubah, itu spektrum dan setiap perusahaan akan memilih mana yang paling cocok untuk mereka.