Memigrasikan sistem warisan secara bertahap dengan mengganti bagian fungsionalitas tertentu secara bertahap dengan aplikasi dan layanan baru. Saat fitur dari sistem warisan diganti, sistem baru pada akhirnya menggantikan semua fitur sistem lama, menghentikan sistem lama dan memungkinkan Anda untuk menonaktifkannya.
Konteks dan masalah
Seiring bertambahnya usia sistem, alat pengembangan, teknologi hosting, dan bahkan arsitektur sistem tempat teknologi itu dibangun dapat menjadi semakin usang. Ketika fitur dan fungsionalitas baru ditambahkan, kompleksitas aplikasi ini dapat meningkat secara dramatis, membuatnya lebih sulit untuk mempertahankan atau menambahkan fitur baru.
Sepenuhnya mengganti sistem yang kompleks bisa menjadi sangat merepotkan. Seringkali, Anda memerlukan migrasi bertahap ke sistem baru, sambil mempertahankan sistem lama untuk menangani fitur yang belum dimigrasikan. Namun, menjalankan dua versi aplikasi yang terpisah berarti bahwa klien harus tahu di mana fitur-fitur tertentu berada. Setiap kali fitur atau layanan dimigrasikan, klien perlu diperbarui untuk menunjuk ke lokasi baru.
Solusi
Secara bertahap ganti bagian fungsionalitas tertentu dengan aplikasi dan layanan baru. Buat fasad yang menghentikan permintaan yang masuk ke sistem warisan backend. Faade mengarahkan permintaan ini ke aplikasi warisan atau layanan baru. Fitur yang ada dapat dimigrasikan ke sistem baru secara bertahap, dan konsumen dapat terus menggunakan antarmuka yang sama, tanpa menyadari bahwa telah terjadi migrasi.
Pola ini membantu meminimalkan risiko dari migrasi, dan menyebarkan upaya pengembangan dari waktu ke waktu. Dengan fasad yang merutekan pengguna dengan aman ke aplikasi yang benar, Anda dapat menambahkan fungsionalitas ke sistem baru dengan kecepatan apa pun yang Anda suka, sambil memastikan aplikasi warisan terus berfungsi. Seiring waktu, saat fitur dipindahkan ke sistem baru, sistem warisan akhirnya "dihentikan" dan tidak lagi diperlukan. Setelah proses ini selesai, sistem warisan dapat dihentikan dengan aman.
Masalah dan pertimbangan
- Pertimbangkan cara menangani layanan dan penyimpanan data yang berpotensi digunakan oleh sistem baru dan warisan. Pastikan keduanya dapat mengakses sumber daya ini secara berdampingan.
- Susun aplikasi dan layanan baru sedemikian rupa sehingga dapat dengan mudah dihentikan dan diganti dalam migrasi gambar strangler di masa mendatang.
- Pada titik tertentu, ketika migrasi selesai, fasad gambar strangler akan hilang atau berkembang menjadi adaptor untuk klien warisan.
- Pastikan fasad mengikuti proses migrasi.
- Pastikan fasad tidak menjadi satu titik kegagalan atau hambatan performa.
Kapan menggunakan pola ini
Gunakan pola ini saat memigrasikan aplikasi back-end ke arsitektur baru secara bertahap.
Pola ini mungkin tidak cocok:
- Ketika permintaan ke sistem back-end tidak dapat dihentikan.
- Untuk sistem yang lebih kecil di mana kompleksitas penggantian grosir rendah.
Desain beban kerja
Arsitek harus mengevaluasi bagaimana pola Strangler Fig dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:
| Pilar | Bagaimana pola ini mendukung tujuan pilar |
|---|---|
| Keputusan desain keandalan membantu beban kerja Anda menjadi tahan terhadap kerusakan dan untuk memastikan bahwa keputusan tersebut pulih ke status berfungsi penuh setelah kegagalan terjadi. | Pendekatan inkremental pola ini dapat membantu mengurangi risiko selama transisi komponen vs perubahan sistemik besar. - Pengujian RE:08 |
| Pengoptimalan Biaya difokuskan untuk mempertahankan dan meningkatkan pengembalian beban kerja Anda pada investasi. | Tujuan dari pendekatan ini adalah untuk memaksimalkan penggunaan investasi yang ada dalam sistem yang sedang berjalan sambil memodernisasi secara bertahap, dengan demikian memungkinkan Anda untuk melakukan penggantian ROI tinggi sebelum penggantian ROI rendah. - Biaya komponen CO:07 - Biaya LINGKUNGAN CO:08 |
| Keunggulan Operasional membantu memberikan kualitas beban kerja melalui proses standar dan kohesi tim. | Pola ini memberikan pendekatan peningkatan berkelanjutan, di mana penggantian bertambah bertahap dengan perubahan kecil dari waktu ke waktu lebih disukai daripada perubahan sistemik besar yang lebih berisiko untuk diterapkan. - Pengembangan beban kerja OE:06 - Praktik penyebaran Brankas OE:11 |
Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.
Langkah berikutnya
- Posting blog Martin Fowler di StranglerFigApplication