4 strategi penerapan untuk layanan mikro yang tangguh

Membangun aplikasi dengan layanan mikro memberi pengembang kecepatan dan ketangkasan yang lebih tinggi daripada arsitektur tradisional. Namun, setiap perubahan kode masih menimbulkan risiko, menyiapkan panggung untuk potensi kegagalan jika masalah kualitas kode tidak ditemukan dan ditangani. Untuk mengurangi risiko tersebut, tim aplikasi harus mengimplementasikan strategi perutean cloud-native modern yang mempermudah pengujian bahaya dan memastikan bahwa aplikasi benar-benar siap untuk diterapkan di lingkungan produksi.

Empat strategi penerapan berikut menggunakan teknik perutean untuk memperkenalkan layanan dan fitur baru dengan aman, menguji fungsionalitas dan membuat peningkatan berulang, mengidentifikasi dan menghilangkan kerentanan, dan banyak lagi. Bersama-sama, pendekatan ini adalah kotak alat virtual yang dapat dijangkau oleh tim aplikasi untuk mengurangi risiko selama pengembangan dan penerapan aplikasi yang dipicu oleh layanan mikro. Memahami perbedaan dan persamaan mereka akan menjadi kunci untuk mengetahui cara memanfaatkan mereka sebaik mungkin di lingkungan Anda sendiri.

Penerapan Canary

Dinamai berdasarkan praktik historis pengiriman burung yang sebenarnya ke tambang batu bara untuk melihat apakah kualitas udara aman bagi manusia, penyebaran burung kenari adalah cara untuk menguji penyebaran produksi aktual dengan dampak atau risiko minimal. Yang disebut canary adalah versi kandidat dari layanan yang menangkap beberapa persentase subset dari permintaan masuk (katakanlah, 1%) untuk mencoba fitur atau build baru. Tim kemudian dapat memeriksa hasilnya, dan jika semuanya berjalan lancar, secara bertahap tingkatkan penerapan hingga 100% server atau node. Dan jika tidak? Lalu lintas dapat dengan cepat dialihkan dari penerapan canary sementara kode yang melanggar ditinjau dan di-debug.

Penerapan Canary dapat diimplementasikan melalui integrasi dengan komponen perutean tepi yang bertanggung jawab untuk memproses lalu lintas pengguna yang masuk. Misalnya, di lingkungan Kubernetes, penerapan canary dapat mengetuk konfigurasi pengontrol masuk untuk menetapkan persentase tertentu dari permintaan lalu lintas ke penerapan stabil dan canary. Merutekan lalu lintas dengan cara ini memastikan bahwa layanan baru memiliki kesempatan untuk membuktikan dirinya sendiri sebelum menerima peluncuran penuh. Jika tidak, mereka dikirim kembali untuk memperbaiki masalah dan kemudian menjalani putaran lain pengujian penerapan canary saat siap.

Pengujian A / B

Pengujian A / B mirip dengan penerapan canary, dengan satu perbedaan penting. Meskipun penerapan canary cenderung berfokus pada identifikasi bug dan hambatan kinerja, pengujian A / B berfokus pada pengukuran penerimaan pengguna atas fitur aplikasi baru. Misalnya, pengembang mungkin ingin tahu apakah fitur baru populer di kalangan pengguna, apakah mereka mudah ditemukan, atau apakah UI berfungsi dengan baik.

Pola ini menggunakan perutean perangkat lunak untuk mengaktifkan dan menguji fitur tertentu dengan segmen lalu lintas yang berbeda, menampilkan fitur baru ke persentase lalu lintas tertentu, atau ke grup terbatas. Segmen perutean A dan B mungkin mengirimkan lalu lintas ke build perangkat lunak yang berbeda, atau instance layanan bahkan mungkin menggunakan build perangkat lunak yang sama tetapi dengan atribut konfigurasi yang berbeda (seperti yang ditentukan di orchestrator atau di tempat lain).

Penerapan biru-hijau

Pola penerapan biru-hijau melibatkan pengoperasian dua lingkungan produksi secara paralel: satu untuk rilis stabil saat ini (biru) dan satu untuk tahap dan melakukan pengujian pada rilis berikutnya (hijau). Strategi ini memungkinkan versi perangkat lunak yang diperbarui untuk dirilis dengan cara yang dapat diulangi dengan mudah. Tim pengembang dapat menggunakan teknik ini untuk mengotomatiskan peluncuran versi baru menggunakan pipeline CI / CD.

Dengan strategi biru-hijau, pengembang menerapkan versi layanan baru bersama dengan instance yang ada yang saat ini menangani lalu lintas produksi. Pipa CI / CD harus diatur untuk melakukan tes asap otomatis untuk memverifikasi bahwa versi baru berhasil dalam fungsionalitas utamanya. Setelah layanan baru lulus pengujian terakhir, lalu lintas dapat dengan aman dan otomatis dialihkan ke sana, menggunakan perutean perangkat lunak untuk mengelola peralihan lalu lintas dari biru ke hijau dengan mulus. Yang tidak kalah pentingnya adalah, dalam kasus masalah menit terakhir yang kritis, mudah untuk mengembalikan penerapan ke versi biru jika masalah kritis muncul.

Bayangan lalu lintas

Bayangan lalu lintas mirip dengan penerapan biru-hijau, tetapi alih-alih menggunakan pengujian sintetis untuk memvalidasi lingkungan "hijau", teknologi perutean menduplikasi semua lalu lintas produksi yang masuk dan mencerminkannya ke penerapan uji terpisah yang belum bersifat publik. Jadi bayangan lalu lintas menciptakan gambaran yang akurat tentang apa yang akan terjadi jika versi baru diterapkan, berdasarkan lalu lintas asli. Pada saat yang sama, bayangan lalu lintas memastikan bahwa pengujian tidak berdampak pada produksi aktual. Dalam praktiknya, pengembang dapat memilih untuk menduplikasi sekumpulan persentase permintaan ke layanan pengujian, di mana mereka kemudian dapat melakukan pengujian integrasi dan tolok ukur kinerja (baik secara manual atau dalam kerangka kerja pipeline CI / CD otomatis).

Pengembang perusahaan telah memanfaatkan berbagai teknik pengujian yang dirancang untuk memastikan bahwa kode aplikasi baru memenuhi persyaratan tertentu. Uji unit dan fungsional, misalnya, tetap merupakan ukuran penting yang harus dihapus kode. Namun, sifat arsitektur berbasis layanan mikro membuat pengujian integrasi ujung ke ujung menjadi lebih penting dari sebelumnya. Mengingat volume saling ketergantungan dan risiko penyimpangan antarmuka jangka panjang yang melekat pada arsitektur layanan mikro, pengujian sintetis masih memiliki nilai tetapi pada akhirnya akan gagal mewakili secara akurat semua interaksi antara layanan di lingkungan produksi.

Empat strategi, satu tujuan

Semua teknik perutean ini menawarkan metode yang berbeda, namun terkait untuk membantu dalam penemuan, mitigasi, dan pengujian cacat dalam aplikasi berbasis layanan mikro. Mereka adalah alat yang ampuh untuk mengatasi bug, masalah kinerja, dan kerentanan keamanan, terutama ketika diterapkan sebagai bagian dari pipeline integrasi dan pengiriman berkelanjutan (CI / CD) ujung ke ujung.

Manakah dari metode berikut yang paling sesuai untuk kasus Anda sendiri yang akan sangat bergantung pada masalah apa yang paling penting. Misalnya, perombakan UI besar bisa mendapatkan keuntungan besar dari pengujian A / B, sementara penerapan biru-hijau bisa sangat berharga untuk melihat bagaimana fitur baru dapat memengaruhi kinerja penyimpanan data yang ada.

Seringkali, kombinasi dari teknik ini mungkin menawarkan cakupan terbaik. Namun, penting untuk mempertimbangkan seberapa baik masing-masing akan berintegrasi dengan model pengembangan yang ada. Penerapan Canary dari fitur individu mungkin lebih cocok untuk metode pengembangan tangkas daripada penerapan versi penuh biru-hijau, misalnya. Dan meskipun bayangan lalu lintas dapat memberikan visibilitas yang sangat baik ke dalam kinerja aplikasi sebelum penerapan, penerapannya dapat menjadi sulit dan memakan waktu serta mahal dalam hal sumber daya komputasi.

Bagaimanapun Anda menerapkannya, teknik perutean seperti ini dapat menjadi bagian yang tak ternilai dari proses pengembangan perangkat lunak, terutama karena industri beralih dari aplikasi monolitik tradisional ke sistem cloud-native berdasarkan layanan mikro. Dengan menerapkan satu, beberapa, atau semua teknik ini sambil tetap memperhatikan keunggulan spesifiknya, tim aplikasi dapat lebih memastikan integritas dan keberhasilan proyek mereka dan bergerak lebih percaya diri ke dalam produksi.

Manuel Zapf adalah kepala produk OSS di Containous, perusahaan jaringan cloud-native di balik proyek open source Traefik dan Maesh.

-

Forum Teknologi Baru menyediakan tempat untuk mengeksplorasi dan mendiskusikan teknologi perusahaan yang sedang berkembang secara mendalam dan luas. Pemilihannya subjektif, berdasarkan pilihan teknologi yang kami yakini penting dan paling menarik bagi pembaca. tidak menerima jaminan pemasaran untuk publikasi dan berhak untuk mengedit semua konten yang dikontribusikan. Kirim semua pertanyaan ke [email protected]