Pola Desain Operator Perangkat Lunak: Kekurangan – Bagian 5

Ubuntu


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.

informasi lebih lanjut



Source link

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.