Dengan pola arsitektur hybrid lingkungan, Anda mempertahankan lingkungan produksi workload di pusat data yang ada. Kemudian, Anda menggunakan cloud publik untuk lingkungan pengembangan dan pengujian, atau lingkungan lainnya. Pola ini mengandalkan deployment aplikasi yang sama secara redundan di beberapa lingkungan komputasi. Tujuan deployment ini adalah untuk membantu meningkatkan kapasitas, fleksibilitas, dan ketahanan.
Saat menilai workload mana yang akan dimigrasikan, Anda mungkin mendapati kasus saat menjalankan aplikasi tertentu di cloud publik memunculkan tantangan:
- Batasan wilayah hukum atau peraturan mungkin mengharuskan Anda menyimpan data di negara tertentu.
- Persyaratan pemberian lisensi pihak ketiga mungkin mencegah Anda mengoperasikan software tertentu di lingkungan cloud.
- Aplikasi mungkin memerlukan akses ke perangkat hardware yang hanya tersedia secara lokal.
Dalam kasus tersebut, tidak hanya pertimbangkan lingkungan produksi, tetapi semua lingkungan yang terlibat dalam siklus proses aplikasi, termasuk sistem pengembangan, pengujian, dan staging. Batasan ini sering kali berlaku untuk lingkungan produksi dan datanya. Perubahan ini mungkin tidak berlaku untuk lingkungan lain yang tidak menggunakan data sebenarnya. Hubungi departemen kepatuhan organisasi Anda atau tim yang setara.
Diagram berikut menunjukkan pola arsitektur hybrid lingkungan yang umum:
Menjalankan sistem pengembangan dan pengujian di lingkungan yang berbeda dengan sistem produksi mungkin tampak berisiko dan dapat menyimpang dari praktik terbaik yang ada atau dari upaya Anda untuk meminimalkan perbedaan di antara lingkungan Anda. Meskipun kekhawatiran tersebut dibenarkan, kekhawatiran tersebut tidak berlaku jika Anda membedakan tahapan proses pengembangan dan pengujian:
Meskipun proses pengembangan, pengujian, dan deployment berbeda untuk setiap aplikasi, proses ini biasanya melibatkan variasi tahap berikut:
- Pengembangan: Membuat kandidat rilis.
- Pengujian fungsional atau pengujian penerimaan pengguna: Memverifikasi bahwa kandidat rilis memenuhi persyaratan fungsional.
- Pengujian performa dan keandalan: Memverifikasi bahwa kandidat rilis memenuhi persyaratan nonfungsi. Hal ini juga dikenal sebagai pengujian beban.
- Pengujian bertahap atau deployment: Memverifikasi bahwa prosedur deployment berfungsi.
- Produksi: Merilis aplikasi baru atau yang diupdate.
Menjalankan lebih dari satu tahap ini dalam satu lingkungan jarang terjadi, sehingga setiap tahap biasanya memerlukan satu atau beberapa lingkungan khusus.
Tujuan utama lingkungan pengujian adalah untuk menjalankan pengujian fungsional. Tujuan utama lingkungan staging adalah untuk menguji apakah prosedur deployment aplikasi Anda berfungsi sebagaimana mestinya. Pada saat rilis mencapai lingkungan staging, pengujian fungsi Anda harus sudah selesai. Penahapan adalah langkah terakhir sebelum Anda men-deploy software ke deployment produksi.
Untuk memastikan bahwa hasil pengujian bermakna dan berlaku untuk deployment produksi, kumpulan lingkungan yang Anda gunakan selama siklus proses aplikasi harus memenuhi aturan berikut, sejauh mungkin:
- Semua lingkungan setara secara fungsional. Artinya, arsitektur, API, dan versi sistem operasi dan library setara, dan sistem berperilaku sama di seluruh lingkungan. Kesetaraan ini menghindari situasi saat aplikasi bekerja di satu lingkungan, tetapi gagal di lingkungan lain, atau saat kerusakan tidak dapat direproduksi.
- Lingkungan yang digunakan untuk pengujian performa dan keandalan, staging, dan produksi setara secara non-fungsional. Artinya, performa, skala, dan konfigurasinya, serta cara pengoperasian dan pemeliharaannya, sama atau hanya berbeda dalam cara yang tidak signifikan. Jika tidak, pengujian performa dan staging tidak akan berguna.
Secara umum, tidak masalah jika lingkungan yang digunakan untuk pengembangan dan pengujian fungsi berbeda secara non-fungsional dari lingkungan lain.
Seperti yang diilustrasikan dalam diagram berikut, lingkungan pengujian dan pengembangan dibangun di atas Google Cloud. Database terkelola, seperti Cloud SQL, dapat digunakan sebagai opsi untuk pengembangan dan pengujian di Google Cloud. Pengembangan dan pengujian dapat menggunakan mesin dan versi database yang sama di lingkungan on-premise, yang secara fungsional setara, atau versi baru yang di-roll out ke lingkungan produksi setelah tahap pengujian. Namun, karena infrastruktur yang mendasari kedua lingkungan tidak identik, pendekatan pengujian beban performa ini tidak valid.
Skenario berikut dapat sangat cocok dengan pola hybrid lingkungan:
- Capai kesetaraan fungsional di semua lingkungan dengan mengandalkan
Kubernetes sebagai lapisan runtime umum jika berlaku dan memungkinkan.
Edisi Google Kubernetes Engine (GKE) Enterprise dapat menjadi teknologi pendukung utama untuk pendekatan ini.
- Memastikan portabilitas workload dan menghilangkan perbedaan antarlingkungan komputasi. Dengan mesh layanan zero trust, Anda dapat mengontrol dan mempertahankan pemisahan komunikasi yang diperlukan antara lingkungan yang berbeda.
- Jalankan lingkungan pengembangan dan pengujian fungsional di cloud publik. Lingkungan ini dapat setara secara fungsional dengan lingkungan lainnya, tetapi mungkin berbeda dalam aspek nonfungsional, seperti performa. Konsep ini diilustrasikan dalam diagram sebelumnya.
- Jalankan lingkungan untuk pengujian produksi, staging, serta performa (pengujian beban) dan keandalan di lingkungan komputasi pribadi, sehingga memastikan kesetaraan fungsional dan nonfungsi.
Pertimbangan Desain
- Kebutuhan bisnis: Setiap strategi deployment dan rilis untuk aplikasi memiliki kelebihan dan kekurangannya masing-masing. Untuk memastikan bahwa pendekatan yang Anda pilih sesuai dengan persyaratan spesifik Anda, dasarkan pilihan Anda pada penilaian menyeluruh terhadap kebutuhan dan batasan bisnis Anda.
- Perbedaan lingkungan: Sebagai bagian dari pola ini, tujuan utama penggunaan lingkungan cloud ini adalah untuk pengembangan dan pengujian. Status akhirnya adalah menghosting aplikasi yang diuji di lingkungan lokal pribadi (produksi). Untuk menghindari pengembangan dan pengujian kemampuan yang mungkin berfungsi seperti yang diharapkan di lingkungan cloud dan gagal di lingkungan produksi (di lokasi), tim teknis harus mengetahui dan memahami arsitektur serta kemampuan kedua lingkungan tersebut. Hal ini mencakup dependensi pada aplikasi lain dan pada infrastruktur hardware—misalnya, sistem keamanan yang melakukan inspeksi traffic.
- Tata kelola: Untuk mengontrol apa yang boleh dikembangkan perusahaan Anda di cloud dan data apa yang dapat digunakan untuk pengujian, gunakan proses persetujuan dan tata kelola. Proses ini juga dapat membantu perusahaan Anda memastikan bahwa perusahaan tidak menggunakan fitur cloud apa pun di lingkungan pengembangan dan pengujian yang tidak ada di lingkungan produksi lokal.
- Kriteria keberhasilan: Harus ada kriteria keberhasilan pengujian yang jelas, telah ditentukan sebelumnya, dan dapat diukur yang selaras dengan standar penjaminan kualitas software untuk organisasi Anda. Terapkan standar ini ke aplikasi apa pun yang Anda kembangkan dan uji.
- Redundansi: Meskipun lingkungan pengembangan dan pengujian mungkin tidak memerlukan keandalan sebanyak lingkungan produksi, lingkungan tersebut tetap memerlukan kemampuan redundan dan kemampuan untuk menguji berbagai skenario kegagalan. Persyaratan skenario kegagalan Anda dapat mendorong desain untuk menyertakan redundansi sebagai bagian dari lingkungan pengembangan dan pengujian Anda.
Kelebihan
Menjalankan workload pengembangan dan pengujian secara fungsional di cloud publik memiliki beberapa keuntungan:
- Anda dapat memulai dan menghentikan lingkungan secara otomatis sesuai kebutuhan.
Misalnya, Anda dapat menyediakan seluruh lingkungan untuk setiap commit atau
permintaan pull, mengizinkan pengujian berjalan, lalu menonaktifkannya lagi. Pendekatan ini
juga menawarkan keuntungan berikut:
- Anda dapat mengurangi biaya dengan menghentikan instance virtual machine (VM) saat tidak aktif, atau dengan menyediakan lingkungan hanya sesuai permintaan.
- Anda dapat mempercepat pengembangan dan pengujian dengan memulai lingkungan sementara untuk setiap permintaan pull. Tindakan ini juga mengurangi biaya pemeliharaan dan mengurangi inkonsistensi di lingkungan build.
- Menjalankan lingkungan ini di cloud publik membantu membangun pemahaman dan kepercayaan diri terhadap cloud dan alat terkait, yang dapat membantu memigrasikan workload lain. Pendekatan ini sangat membantu jika Anda memutuskan untuk mempelajari Portabilitas workload menggunakan container dan Kubernetes—misalnya, menggunakan GKE Enterprise di berbagai lingkungan.
Praktik terbaik
Agar berhasil menerapkan pola arsitektur hybrid lingkungan, pertimbangkan rekomendasi berikut:
- Tentukan persyaratan komunikasi aplikasi Anda, termasuk desain keamanan dan jaringan yang optimal. Kemudian, gunakan pola jaringan yang diduplikasi untuk membantu Anda mendesain arsitektur jaringan guna mencegah komunikasi langsung antara sistem dari lingkungan yang berbeda. Jika komunikasi diperlukan di seluruh lingkungan, komunikasi harus dilakukan secara terkontrol.
Strategi pengujian dan deployment aplikasi yang Anda pilih harus sesuai dengan tujuan dan persyaratan bisnis Anda. Hal ini mungkin melibatkan peluncuran perubahan tanpa periode nonaktif atau penerapan fitur secara bertahap ke lingkungan atau grup pengguna tertentu sebelum rilis yang lebih luas.
Untuk membuat workload menjadi portabel dan menghilangkan perbedaan antara lingkungan, Anda dapat menggunakan container dengan Kubernetes. Untuk mengetahui informasi selengkapnya, lihat Arsitektur referensi lingkungan hybrid GKE Enterprise.
Buat rantai alat umum yang berfungsi di seluruh lingkungan komputasi untuk men-deploy, mengonfigurasi, dan mengoperasikan workload. Dengan menggunakan Kubernetes, Anda mendapatkan konsistensi ini.
Pastikan pipeline CI/CD konsisten di seluruh lingkungan komputasi, dan kumpulan biner, paket, atau container yang sama persis di-deploy di seluruh lingkungan tersebut.
Saat menggunakan Kubernetes, gunakan sistem CI seperti Tekton untuk mengimplementasikan pipeline deployment yang di-deploy ke cluster dan berfungsi di seluruh lingkungan. Untuk mengetahui informasi selengkapnya, lihat Solusi DevOps di Google Cloud.
Untuk membantu Anda merilis aplikasi yang aman dan andal secara berkelanjutan, sertakan keamanan sebagai bagian integral dari proses DevOps (DevSecOps). Untuk mengetahui informasi selengkapnya, lihat Menyediakan dan mengamankan aplikasi yang menghadap internet dalam waktu kurang dari satu jam menggunakan Dev(Sec)Ops Toolkit.
Gunakan alat yang sama untuk logging dan pemantauan di seluruh Google Cloud dan lingkungan cloud yang sudah ada. Pertimbangkan untuk menggunakan sistem pemantauan open source. Untuk mengetahui informasi selengkapnya, lihat Pola pemantauan dan logging hybrid dan multicloud.
Jika workload pengujian dan produksi dikelola oleh tim yang berbeda, penggunaan alat yang terpisah mungkin dapat diterima. Namun, penggunaan alat yang sama dengan izin melihat yang berbeda dapat membantu mengurangi upaya dan kompleksitas pelatihan Anda.
Saat Anda memilih layanan database, penyimpanan, dan pesan untuk pengujian fungsional, gunakan produk yang memiliki padanan terkelola di Google Cloud. Mengandalkan layanan terkelola membantu mengurangi upaya administratif dalam mempertahankan lingkungan pengembangan dan pengujian.
Untuk melindungi informasi sensitif, sebaiknya enkripsi semua komunikasi dalam pengiriman. Jika enkripsi diperlukan di lapisan konektivitas, berbagai opsi tersedia berdasarkan solusi konektivitas hibrida yang dipilih. Opsi ini mencakup tunnel VPN, VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.
Tabel berikut menunjukkan produk Google Cloud yang kompatibel dengan produk OSS umum.
| Produk OSS | Kompatibel dengan Google Cloud produk |
|---|---|
| Apache HBase | Bigtable |
| Apache Beam | Dataflow |
| CDAP | Cloud Data Fusion |
| Apache Hadoop | Dataproc |
| MySQL, PostgreSQL | Cloud SQL |
| Redis Cluster, Redis, Memcached | Memorystore |
| Network File System (NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
| Kubernetes | GKE Enterprise |