Operator perangkat lunak adalah templat desain – ini adalah desain yang telah terbukti yang telah diterapkan dalam banyak situasi dan diimplementasikan oleh beberapa kerangka kerja. Penerimaannya yang luas dalam industri memungkinkan kita untuk mempelajari konsekuensinya, baik dan buruk. Ini penting karena pengembang perangkat lunak dan arsitek TI perlu mengetahui kapan desain merupakan pilihan yang baik dan kapan sebaiknya menghindarinya. Posting blog sebelumnya dalam seri ini telah membahas pola desain dengan cara yang berbeda:
Bagian ini mencakup kelemahan dari pendekatan desain ini dan berkontribusi pada diskusi yang lebih besar tentang pola desain operator.
Kekurangan adalah peringatan, bukan kegagalan
Penting untuk dipahami bahwa kekurangan adalah peringatan. Kekurangan tidak selalu relevan dalam implementasi template desain operator perangkat lunak. Tetapi ketika mereka relevan dan tidak diperhatikan, mereka dapat menyebabkan banyak usaha ekstra. Jika kekurangan template diketahui, operator TI dan pengembang perangkat lunak dapat mempelajari cara menghindarinya. Melihat kerugiannya membantu setiap orang untuk menerapkan pola desain operator secara lebih efektif.
Bruce Warrington telah menerima peringatan. Tidak jelas apakah ini relevan bagi Anda.
Operator perangkat lunak membutuhkan investasi
Tanpa operator perangkat lunak, tugas operasional dilakukan secara manual, langkah demi langkah, di lingkungan eksekusi atau di infrastruktur manajemen seperti kubectl, antarmuka baris perintah untuk cluster Kubernetes. Faktanya, salah satu kuliah saya baru-baru ini tentang operator perangkat lunak pribadi bertanya, “Apakah saya benar bahwa Anda menawarkan sesuatu yang dapat dengan mudah saya dapatkan dengan menghubungi kubectl?” Meskipun pertanyaan ini menunjukkan bahwa operator perangkat lunak tidak berguna, karena setiap langkah dapat dilakukan dengan alat lain, sebenarnya ini menunjukkan trik ini.
Ya, ini tentang menjalankan sejumlah perintah pada alat dan API tertentu untuk menyelesaikan tugas. Jika tugas diulang berulang kali, atau jika rumit dan rawan kesalahan, masuk akal untuk mengotomatiskannya.
Jika tugasnya tidak rumit, otomatisasi mungkin tidak masuk akal. Karena, pada gilirannya, lebih banyak perangkat lunak berarti lebih banyak kebutuhan pemeliharaan. Selain itu, rilis perangkat lunak memerlukan komunikasi dan presentasi yang tepat. Oleh karena itu, rasional atau tidaknya otomatisasi tergantung pada situasi. Anda tidak perlu menginvestasikan waktu dan sumber daya untuk mengotomatiskan tugas yang mudah dilakukan secara manual.
Menggunakan kembali perangkat lunak melibatkan penggunaan kembali bug
Adalah baik untuk mengotomatisasi tugas operasional dengan kode sumber untuk menghindari tugas yang berulang. Namun, ketika kode sumber mengandung kesalahan, itu tidak hanya mempengaruhi kasus operasional, tetapi berpotensi semua pengguna operator perangkat lunak ini secara bersamaan.
Kita semua tahu bahwa tidak mungkin membangun sistem yang sempurna dan 100% bebas kesalahan. Skala ekonomi untuk operator perangkat lunak dapat membuat operasi lebih efisien, tetapi mereka juga dapat memaksakan tuntutan yang lebih tinggi pada keselamatan operasional – sama seperti produk lain yang mendapat manfaat dari skala ekonomi. Pada saat yang sama, misalnya, disarankan untuk lebih berhati-hati saat menggunakan pustaka keamanan.
Eksperimen dan komunitas: cara penting untuk mengurangi kerugian ini
Sejauh ini, kita telah membahas dua kelemahan terbesar dari operator perangkat lunak: mereka membutuhkan investasi, dan Anda perlu memastikan bahwa mereka sebebas mungkin dari kesalahan. Untungnya, ada cara yang efektif untuk memperbaiki kekurangan ini.
Operator perangkat lunak diuji tidak hanya dengan pengujian unit tetapi juga dengan pengujian integrasi. Proyek pengembangan perangkat lunak dengan CI secara signifikan meningkatkan keandalan. Selain itu, pengembangan perangkat lunak open source (OSS) yang melibatkan komunitas memberikan transparansi dan mengundang pakar operator untuk secara kolaboratif meningkatkan implementasi. Last but not least, mengembangkan operator perangkat lunak sebagai OSS juga merupakan cara yang bagus untuk membagi upaya pengembangan ke banyak pihak.
Randy Fett mencontohkan bagaimana membuat segala sesuatunya lebih efektif bersama-sama.
Kapan masuk akal untuk menggunakan operator perangkat lunak?
Posting blog dalam seri ini dengan jelas menunjukkan bahwa kekuatan desain tertentu membenarkan upaya untuk mengimplementasikan operator perangkat lunak. Tetapi mengimplementasikan operator perangkat lunak membutuhkan biaya.
Jika Anda tidak mengharapkan operasi jarak jauh, Anda mungkin tidak membutuhkannya. Demikian juga, mereka mungkin tidak diperlukan jika aplikasi Anda diperbarui tetapi tidak (secara operasional) berubah selama masa pakainya. Dalam kasus ini, menggunakan alat manajemen paket sederhana seperti snap mungkin merupakan alternatif yang lebih baik.
Dengarkan alarmnya
Kami akan melanjutkan seri ini dengan membahas lebih banyak aspek dari pola desain ini.
