Pola hybrid lingkungan

Last reviewed 2023-12-14 UTC

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 bergantung pada deployment aplikasi yang sama secara redundan di beberapa lingkungan komputasi. Tujuan deployment 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 pada lingkungan produksi dan datanya. Pengujian 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:

Data yang mengalir dari lingkungan pengembangan yang dihosting di Google Cloud ke lingkungan produksi yang berada di infrastruktur lokal atau di lingkungan cloud lain.

Menjalankan sistem pengembangan dan pengujian di lingkungan yang berbeda dengan sistem produksi mungkin tampak berisiko dan dapat menyimpang dari praktik terbaik yang sudah ada atau dari upaya Anda untuk meminimalkan perbedaan antara lingkungan. Meskipun dibenarkan, kekhawatiran tersebut tidak berlaku jika Anda membedakan tahap 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. Pengujian ini juga dikenal sebagai pengujian beban.
  • Pengujian staging atau deployment: Memverifikasi bahwa prosedur deployment berfungsi.
  • Produksi: Merilis aplikasi baru atau yang telah 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 seharusnya sudah selesai. Staging 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 nonfungsional. 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 nonfungsional dari lingkungan lain.

Seperti yang diilustrasikan dalam diagram berikut, lingkungan pengujian dan pengembangan di-build di 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 diluncurkan ke lingkungan produksi setelah tahap pengujian. Namun, karena infrastruktur dasar dari kedua lingkungan tersebut tidak identik, pendekatan ini untuk pengujian beban performa tidak valid.

Tim pengembangan dan QA mengirim data melalui instance pengujian dan QA Google Cloud ke sistem produksi lokal yang tidak valid.

Skenario berikut dapat 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 utama yang memungkinkan pendekatan ini.
    • Pastikan portabilitas workload dan abstraksi perbedaan antar-lingkungan komputasi. Dengan zero trust service mesh, Anda dapat mengontrol dan mempertahankan pemisahan komunikasi yang diperlukan di antara berbagai lingkungan.
  • Jalankan lingkungan pengembangan dan pengujian fungsional di cloud publik. Lingkungan ini secara fungsional setara dengan lingkungan lainnya, tetapi mungkin berbeda dalam aspek nonfungsional, seperti performa. Konsep ini diilustrasikan dalam diagram sebelumnya.
  • Jalankan lingkungan untuk pengujian produksi, staging, 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 sendiri. Untuk memastikan bahwa pendekatan yang Anda pilih sesuai dengan persyaratan spesifik Anda, dasari pilihan Anda pada penilaian menyeluruh terhadap kebutuhan dan batasan bisnis Anda.
  • Perbedaan lingkungan: Sebagai bagian dari pola ini, tujuan utama menggunakan lingkungan cloud ini adalah untuk pengembangan dan pengujian. Status akhir 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 dan kemampuan kedua lingkungan tersebut. Hal ini mencakup dependensi pada aplikasi lain dan pada infrastruktur hardware—misalnya, sistem keamanan yang melakukan inspeksi traffic.
  • Pemerintahan: Untuk mengontrol apa yang diizinkan perusahaan Anda untuk dikembangkan di cloud dan data apa yang dapat digunakan untuk pengujian, gunakan proses persetujuan dan pemerintahan. 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 jaminan 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 masih memerlukan kemampuan redundan dan kemampuan untuk menguji berbagai skenario kegagalan. Persyaratan skenario kegagalan Anda mungkin 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 otomatis memulai dan menghentikan lingkungan 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 overhead 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 seluruh lingkungan.

Praktik terbaik

Agar berhasil menerapkan pola arsitektur hybrid lingkungan, pertimbangkan rekomendasi berikut:

  • Tentukan persyaratan komunikasi aplikasi Anda, termasuk desain jaringan dan keamanan 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 diperlukan di seluruh lingkungan, komunikasi harus dilakukan dengan cara yang terkontrol.
  • Strategi pengujian dan deployment aplikasi yang Anda pilih harus selaras 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 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 penampung 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 informasi selengkapnya, lihat Solusi DevOps di Google Cloud.

  • Untuk membantu Anda merilis aplikasi yang aman dan andal secara berkelanjutan, masukkan keamanan sebagai bagian integral dari proses DevOps (DevSecOps). Untuk mengetahui informasi selengkapnya, lihat Mengirimkan dan mengamankan aplikasi yang ditayangkan di internet dalam waktu kurang dari satu jam menggunakan Toolkit Dev(Sec)Ops.

  • 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 informasi selengkapnya, lihat Pola pemantauan dan logging hybrid dan multicloud.

  • Jika workload pengujian dan produksi dikelola oleh tim yang berbeda, penggunaan alat terpisah mungkin dapat diterima. Namun, penggunaan alat yang sama dengan izin tampilan yang berbeda dapat membantu mengurangi kompleksitas dan upaya 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 mengenkripsi semua komunikasi dalam pengiriman. Jika enkripsi diperlukan di lapisan konektivitas, berbagai opsi tersedia yang didasarkan pada solusi konektivitas hybrid 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 produk Google Cloud
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