Contoh di halaman ini menunjukkan beberapa skenario hipotesis menggunakan fleet yang menggambarkan beberapa konsep dan praktik terbaik dari panduan kami. Sebelum membaca panduan ini, Anda harus sudah memahami konsep dalam Memperkenalkan fleet dan Persyaratan perangkat dan praktik terbaik.
Contoh 1: Armada dengan resource produksi, staging, dan pengembangan
Pada contoh pertama, ada empat klaster. Dua cluster adalah untuk produksi (di dua region untuk redundansi), satu untuk staging dan pengujian, dan yang terakhir untuk pengembangan. Semua cluster dimiliki dan dikelola
secara terpusat oleh tim platform. Dalam contoh sederhana ini, ada dua layanan: frontend dan backend. Namun, skenario yang lebih kompleks mungkin memiliki
jumlah layanan dan cluster yang lebih besar.
Pendekatan 1: Armada terpisah untuk produksi, staging, dan pengembangan
Salah satu pendekatan yang dapat dilakukan untuk memanfaatkan fleet adalah dengan membuat fleet terpisah untuk resource produksi, staging, dan pengembangan.
Untuk melakukannya, kita membuat tiga project host fleet yang terpisah, dan salah satu dari resource tempat dalam project tersebut. Atau, untuk cluster pengembangan lokal, daftarkan cluster ke project example-dev. Kami tidak perlu mengatasi banyak masalah kesamaan namespace dan kesamaan layanan karena perincian dalam contoh ini, tetapi kami memastikan bahwa namespace cluster prod-east dan prod-west dinormalisasi dengan baik.
Keuntungan dari pendekatan ini adalah bahwa kami memiliki isolasi yang sangat kuat antara setiap fleet. Kelemahan utama dari pendekatan ini adalah kami perlu mengelola tiga fleet yang berbeda, sehingga mempersulit pencapaian konsistensi antara produksi, staging, dan pengembangan. Untuk tim pengembangan, juga lebih sulit untuk mengembangkannya dengan layanan bertahap.
Pendekatan 2: Satu fleet untuk semua resource
Dalam pendekatan ini, kita membuat satu fleet untuk semua resource.
Untuk melakukannya, kita dapat membiarkan resource dalam project example, dan membuat
fleet dalam project tersebut. Kita dapat memisahkan resource produksi dan staging dengan menempatkannya di project host fleet lain dan memanfaatkan VPC Bersama, tetapi kami memilih tidak melakukannya demi kemudahan dalam contoh ini.
Dengan pendekatan ini, kami perlu memastikan bahwa namespace dan layanan kami
dinormalisasi di seluruh fleet. Misalnya, kami mengganti nama frontend generik
menjadi frontend-prod dan frontend-staging masing-masing
di cluster produksi dan staging. Terakhir, meskipun kami dapat mempertahankan nama asli untuk
namespace pengembangan, kami memberikan nama yang lebih jelas (seperti frontend-dev-alice) untuk
menunjukkan bahwa nama tersebut adalah namespace pengembangan.
Dengan pendekatan ini, kami mengorbankan isolasi untuk kemudahan pengelolaan. Kami mengandalkan otorisasi mesh layanan untuk mencegah komunikasi antarlayanan yang tidak diinginkan, tetapi kami dapat dengan mudah mengelola keseluruhan sistem dengan satu armada. Pengaturan ini memungkinkan kami menerapkan kebijakan di semua resource, yang dapat memberi kami keyakinan bahwa pengembangan terlihat dan terasa sangat mirip dengan produksi.
Pendekatan 3: Perangkat terpisah untuk produksi dan non-produksi
Dalam pendekatan ini, kami mengambil jalan tengah yang menggabungkan resource staging dan pengembangan menjadi fleet non-produksi sekaligus menempatkan produksi di fleet yang terpisah.
Untuk melakukannya, kami membuat dua project host fleet, yaitu satu untuk produksi dan satu untuk non-produksi. Kami juga menempatkan resource langsung ke dalam project tersebut, dengan
cluster dev secara lokal yang terdaftar ke fleet non-produksi kami. Kita
perlu menormalisasi namespace dan layanan antara resource staging dan
pengembangan untuk memberikan kejelasan; misalnya, kita mengganti nama frontend menjadi
frontend-staging di cluster staging.
Keuntungannya di sini adalah produksi terpisah dengan baik dari non-produksi. Misalnya, kita dapat mengaktifkan layanan pengembangan untuk berkomunikasi dengan layanan staging, sehingga frontend developer Alice dapat berkomunikasi dengan backend bertahap selagi dia mengembangkan layanannya.
Ringkasan
Masing-masing pendekatan yang diuraikan dalam Contoh 1 adalah valid. Mana yang dipilih organisasi Anda bergantung pada isolasi versus konsistensi (dan kemudahan pengelolaan); dengan kata lain, seberapa banyak isolasi yang diperlukan antara jenis resource yang berbeda dibandingkan seberapa banyak konsistensi yang diperlukan di seluruh resource. Konsistensi lebih mudah dicapai dengan armada yang lebih sedikit. Pendekatan ketiga ditawarkan sebagai kemungkinan penyusupan, sehingga produksi tetap terisolasi sepenuhnya sekaligus memberi developer kemampuan untuk bekerja terhadap layanan bertahap.
Contoh 2: Armada dengan pemilik resource yang berbeda
Untuk contoh ini, kita memiliki dua tim, tim-a dan tim-b. Tim ini memiliki dan
mengelola cluster mereka sendiri, dan keduanya telah menggunakan namespace frontend dan
backend untuk layanan yang mereka hasilkan. Namun, baik frontend maupun backend tim-a sebenarnya tidak sama dengan tim-b. Kedua tim ini ingin membuat mesh layanan agar layanan mereka dapat berinteraksi.
Tanpa intervensi, tidak ada cara untuk membuat cluster ini menjadi bagian dari
mesh yang sama. Salah satu titik awal yang baik adalah mentransfer kepemilikan cluster ke
tim platform terpusat untuk membangun kepercayaan di antara mereka. Atau, jika
tim-a dan tim-b saling percaya, mereka juga dapat berkoordinasi untuk membentuk kepercayaan ini.
Langkah berikutnya adalah menormalisasi penggunaan namespace sehingga frontend dan
backend tidak lagi kelebihan beban di cluster kedua tim ini. Setelah ini
selesai, mereka dapat membuat satu fleet di seluruh resource dan membuat
mesh layanannya.
Jika tingkat kepercayaan ini tidak dapat dibangun, tim-a dan tim-b harus membentuk dua fleet terpisah yang menggunakan dua project host fleet yang berbeda. Kelemahan pendekatan ini adalah bahwa sekarang metode ini perlu memanfaatkan federasi mesh yang lebih sulit dikelola daripada mesh tunggal. Manfaatnya adalah tidak ada tim yang perlu menormalisasi namespace dan layanan yang di-deploy, dan hanya komunikasi eksplisit dan resmi yang dapat dilakukan.
