Berkenalan dengan Deployment Strategies: Canary vs Blue Green
Saat ini telah banyak perusahaan, organisasi, atau tim pengembang perangkat lunak yang ingin melakukan rilis aplikasi ke pasar secara efisien, hemat waktu, minimal risiko, serta tanpa downtime. Hal tersebut diiringi dengan frekuensi rilis yang lebih sering, dan juga dari segi kebutuhan arsitektur maupun code tim pengembang agar bisa secara paralel melakukan penulisan kode dan deploy dalam waktu bersamaan. Dengan penerapan yang lebih sering, kemungkinan besar kode yang dideploy dapat memengaruhi realibility aplikasi atau user experience. Hal tersebut menjadi tantangan tersendiri bagi tim engineering untuk melakukan delivery perangkat lunak ke user dengan minimal risiko terhadap produk dan user.
Secara konvesional tanpa adanya strategi deployment, tim pengembang perangkat lunak menjadikan aplikasi offline saat akan melakukan pembaharuan. Sehingga dalam waktu sesaat user tidak dapat mengakses, hal tersebut yang mengakibatkan waktu henti (downtime). Nah untuk itu, di era sekarang ini agar proses deployment aplikasi bisa lebih andal dibutuhkannya deployment strategies. Deployment strategies sebenarnya ada banyak seperti canary, rolling-back, big-bang, rolling, blue-green, and etc. Namun yang akan kita eksplor pada topik kali ini ialah canary dan blue green.
Canary
Secara umum Canary dan Blue Green sama-sama memiliki teknik untuk meng-eliminate downtime dan juga mengurangi risiko saat melakukan pembaharuan perangkat lunak.
Namun penerapan canary sedikit berbeda yaitu merilis aplikasi atau layanan secara bertahap ke sekelompok fitur diperbarui dalam fase kecil (misalnya: 10%, 25%, 75%, 100%).
Saat proses build, deploy, dan testing akan ada semacam limited of time dan limited of group untuk melihat kondisi aplikasi ketika sebagian pembaharuan dari aplikasi apakah sudah berfungsi dengan proper atau justru ada dampak lain yang muncul.
Ketika tim pengembang ditugaskan untuk menupgrade aplikasi ke v2 dengan beberapa perubahan fitur:
- penambahan input shipping transaksi (PR-1)
- penambahan input discount transaksi (PR-2)
- penambahan input tags transaksi (PR-3)
*Catatan: PR (Pull Request)
Didalam canary environment tersebut mendeploy versi terbaru (V2). Hanya beberapa subset user yang masuk ke sebagian server/node canary (misal 5% dari total keseluruhan pengguna aplikasi). Kemudian dari tim QA bisa jalankan smoke test, dan test lainnya di environment canary dengan pointing domain yang berbeda dari production. Apabila semuanya terlihat ok, dari tim infrastruktur akan secara meluncurkan versi V2 secara bertahap/penuh ke seluruh pengguna.
Rilis dengan startegi canary bisa dibilang memiliki risiko rendah dan lebih hemat dari segi cost, karena tidak membutuhkan environment tambahan yang identik seperti production atau primary environment. Karena, secara infrastruktur menggunakan spesifikasi dan environment yang sama. Dari setiap kali ada changes kecil-kecil bisa secara bertahap dilakukan monitoring, dan apabila ada major issue akan lebih mudah dilakukan rollback ke versi sebelumnya pada canary environment.
FYI, biasanya untuk bisa mengakses canary akan disediakan pointing domain yang berbeda dari primary environment (production). Serta domainnya hanya tim internal atau grup tertentu saja yang dapat melakukan akses kesana.
Contoh:
- Canary enviroment => www.canary123-testing.com
- Primary Production => www.testing.com
Blue Green
Sama halnya dengan canary, dari metode blue green ini bisa meng-eliminasi downtime aplikasi. Hanya saja melakukan pergantian aplikasi membutuhkan 2 environment identik. Simpelnya, kita mempunyai dua environment yang identik (infrastruktur). Nah, lalu kenapa penamaan strateginya dengan Blue Green?
Green environment atau environment hijau yang dimaksudkan merupakan primary environment yang berada sekarang di production (aplikasi V1), yaitu environment yang sedang dipakai user.
Ketika tim pengembang akan melakukan menupgrade aplikasi ke v2 , maka dari tim infra menyiapkan satu environment identik untuk dilakukan perubahan versi aplikasi terbaru di blue environment. Didalam blue environment tersebut kita akan mendeploy versi terbaru secara penuh (app v2). Kemudian tim QA menjalan smoke test, dan test lainnya. Ketika semuanya terlihat ok dan tidak ada issue, tim infra dapat mengganti pointing loadbalancer ke blue environment (status menjadi primary environment). Namun ternyata jika ada issue, tim bisa dengan cepat untuk rollback ke green environment dengan cara mengubah pointing loadbalancer kembali. Environment hijau balik menjadi versi 1.
Conclusion
Strategi deployment dengan canary maupun blue green sudah cukup populer dan membantu proses deployment aplikasi tanpa adanya downtime. Untuk mencapai tujuan ini memerlukan kemampuan khusus terkait teknologi infra, khususnya arsitektur load balancing dan stateless.
Implementasi canary memungkinkan tim untuk menguji secara berdampingan menggunakan production server yang utama. Hanya beberapa server/node saja yang terpakai untuk dapat hasil pembaharuan dari versi terbaru. Dari segi cost, ini lebih murah. Namun, dalam implementasinya canary lebih rumit, butuh scripting dan konfigurasi yang complex. Terutama untuk menentukan berapa persen pada server/node group tertentu yang terkena rollout dari fitur-fitur yang ikut deploy.
Kalau untuk green environment lebih mudah diimplementasikan. Dari 2 environment identik yang sudah tersedia, jika terjadi suatu isu akan lebih mudah mengembalikan dengan cukup membalik traffic ke environment yang lama dengan kondisi versi sebelumnya. Namun, dibutuhkannya cost yang lebih besar untuk membangun environment baru seperti primary environment — production.
Pada akhirnya, dari beberapa opsi diatas balik lagi ke kebutuhan dan kemampuan perusahaan/tim untuk menentukan deployment strategies yang akan diimplementasikan. Sekian pengenalan dari strategi deployment. Semoga bermanfaat. Terima kasih.
Referensi:
