Pola hybrid lingkungan

Last reviewed 2023-12-14 UTC

Dengan pola arsitektur hybrid lingkungan, Anda mempertahankan lingkungan produksi dari suatu workload di pusat data yang ada. Kemudian, gunakan cloud publik untuk lingkungan pengembangan dan pengujian, atau lingkungan lainnya. Pola ini bergantung pada deployment redundan dari aplikasi yang sama di beberapa lingkungan komputasi. Tujuan deployment ini adalah untuk membantu meningkatkan kapasitas, ketangkasan, dan ketahanan.

Saat menilai workload mana yang akan dimigrasikan, Anda mungkin melihat kasus saat menjalankan aplikasi tertentu di cloud publik yang menimbulkan tantangan:

  • Batasan yurisdiksi 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 seperti itu, pertimbangkan tidak hanya lingkungan produksi, tetapi semua lingkungan yang terlibat dalam siklus proses aplikasi, termasuk pengembangan, pengujian, dan sistem staging. Batasan ini sering berlaku untuk lingkungan produksi dan datanya. Kebijakan tersebut mungkin tidak berlaku untuk lingkungan lain yang tidak menggunakan data aktual. Hubungi departemen kepatuhan organisasi Anda atau tim yang setara.

Diagram berikut menunjukkan pola arsitektur hibrid lingkungan 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 Anda mungkin tampak berisiko dan dapat menyimpang dari praktik terbaik yang sudah ada atau upaya Anda untuk meminimalkan perbedaan di antara lingkungan Anda. Meskipun dapat dibenarkan, masalah tersebut tidak berlaku jika Anda membedakan antara tahap proses pengembangan dan pengujian:

Meskipun proses pengembangan, pengujian, dan deployment berbeda untuk setiap aplikasi, proses tersebut 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 nonfungsional. Pengujian ini juga dikenal sebagai pengujian beban.
  • Pengujian bertahap atau deployment: Memverifikasi apakah 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 dari lingkungan staging adalah untuk menguji apakah prosedur deployment aplikasi Anda berfungsi sebagaimana mestinya. Pada saat rilis mencapai lingkungan staging, pengujian fungsional Anda harus selesai. Staging adalah langkah terakhir sebelum 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 memungkinkan:

  • Semua lingkungan setara secara fungsional. Artinya, arsitektur, API, serta 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 kerusakan tidak dapat direproduksi.
  • Lingkungan yang digunakan untuk pengujian performa dan keandalan, staging, serta produksi setara secara tidak berfungsi. Artinya, performa, skala, dan konfigurasinya, serta cara pengoperasian dan pemeliharaannya sama, atau hanya berbeda dalam hal yang tidak signifikan. Jika tidak, pengujian performa dan staging tidak akan berguna.

Secara umum, tidak masalah jika lingkungan yang digunakan untuk pengujian pengembangan dan fungsional berbeda secara non-fungsional dengan lingkungan lainnya.

Seperti yang digambarkan dalam diagram berikut, lingkungan pengujian dan pengembangan di-build di Google Cloud. Database terkelola seperti Cloud SQL dapat digunakan sebagai opsi pengembangan dan pengujian di Google Cloud. Pengembangan dan pengujian dapat menggunakan mesin database dan versi yang sama di lingkungan lokal, yang secara fungsional setara, atau versi baru yang diluncurkan ke lingkungan produksi setelah tahap pengujian. Namun, karena infrastruktur dasar dari kedua lingkungan tidak identik, pendekatan terhadap pengujian beban performa ini tidak valid.

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

Skenario berikut sangat cocok dengan pola campuran lingkungan:

  • Capai kesetaraan fungsional di semua lingkungan dengan mengandalkan Kubernetes sebagai lapisan runtime umum jika memungkinkan dan memungkinkan. Edisi Google Kubernetes Engine (GKE) Enterprise dapat menjadi teknologi pendukung utama untuk pendekatan ini.
    • Memastikan portabilitas workload dan menghilangkan perbedaan di antara lingkungan komputasi. Dengan mesh layanan zero-trust, Anda dapat mengontrol dan mempertahankan pemisahan komunikasi yang diperlukan antara berbagai lingkungan.
  • Jalankan lingkungan pengembangan dan pengujian fungsional di cloud publik. Lingkungan ini dapat secara fungsional setara dengan lingkungan lainnya, tetapi mungkin berbeda dalam aspek nonfungsional, seperti performa. Konsep ini diilustrasikan dalam diagram sebelumnya.
  • Jalankan lingkungan untuk produksi, staging, dan performa (pengujian beban) serta pengujian keandalan di lingkungan komputasi pribadi, yang memastikan kesetaraan fungsional dan nonfungsional.

Pertimbangan Desain

  • Kebutuhan bisnis: Setiap strategi deployment dan rilis untuk aplikasi memiliki kelebihan dan kekurangan masing-masing. Untuk memastikan pendekatan yang Anda pilih selaras dengan persyaratan spesifik Anda, dasarkan pilihan Anda pada penilaian menyeluruh terhadap kebutuhan dan kendala bisnis Anda.
  • Perbedaan lingkungan: Sebagai bagian dari pola ini, sasaran utama penggunaan lingkungan cloud ini adalah untuk pengembangan dan pengujian. Status terakhir 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 (lokal), 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 pemeriksaan 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 untuk tidak menggunakan fitur cloud apa pun di lingkungan pengembangan dan pengujian yang tidak ada di lingkungan produksi lokal Anda.
  • Kriteria keberhasilan: Harus ada kriteria keberhasilan pengujian yang jelas, telah ditetapkan, dan terukur yang sesuai 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 production, lingkungan tersebut tetap memerlukan kemampuan yang redundan dan kemampuan untuk menguji berbagai skenario kegagalan. Persyaratan skenario kegagalan 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 saat diperlukan. 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 on demand.
    • Anda dapat mempercepat pengembangan dan pengujian dengan memulai lingkungan sementara untuk setiap permintaan pull. Cara ini juga mengurangi overhead pemeliharaan dan mengurangi inkonsistensi di lingkungan build.
  • Menjalankan lingkungan ini di cloud publik membantu membangun pemahaman dan keyakinan terhadap cloud dan alat terkait, yang dapat membantu memigrasikan workload lain. Pendekatan ini sangat membantu jika Anda memutuskan untuk mempelajari Portabilitas beban kerja 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 keamanan dan jaringan yang optimal. Kemudian, gunakan pola jaringan yang diduplikasi untuk membantu Anda mendesain arsitektur jaringan guna mencegah komunikasi langsung antarsistem dari lingkungan yang berbeda. Jika komunikasi 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 mencakup peluncuran perubahan tanpa periode nonaktif atau penerapan fitur secara bertahap ke lingkungan atau grup pengguna tertentu sebelum merilisnya secara lebih luas. Untuk informasi selengkapnya, Lihat Strategi pengujian dan deployment aplikasi.

  • Untuk membuat workload portabel dan menghilangkan perbedaan antarlingkungan, Anda dapat menggunakan container dengan Kubernetes. Untuk mengetahui informasi selengkapnya, lihat arsitektur referensi lingkungan hybrid GKE Enterprise.

  • Bangun rantai alat umum yang bekerja di seluruh lingkungan komputasi untuk men-deploy, mengonfigurasi, dan mengoperasikan workload. Penggunaan Kubernetes akan memberi Anda konsistensi ini.

  • Pastikan pipeline CI/CD konsisten di seluruh lingkungan komputasi, dan sekumpulan 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 bekerja di seluruh lingkungan. Untuk mengetahui informasi selengkapnya, lihat Solusi DevOps di Google Cloud.

  • Untuk membantu Anda dengan rilis aplikasi yang aman dan andal secara berkelanjutan, gabungkan keamanan sebagai bagian integral dari proses DevOps (DevSecOps). Untuk informasi selengkapnya, lihat Mengirim dan mengamankan aplikasi yang terhubung ke internet dalam waktu kurang dari satu jam menggunakan Dev(Sec)Ops Toolkit.

  • Gunakan alat yang sama untuk logging dan pemantauan di Google Cloud dan lingkungan cloud yang ada. Pertimbangkan untuk menggunakan sistem pemantauan open source. Untuk mengetahui informasi selengkapnya, lihat Pola pemantauan dan logging hybrid dan multicloud.

  • Jika tim yang berbeda mengelola beban kerja pengujian dan produksi, penggunaan alat terpisah mungkin dapat diterima. Namun, penggunaan alat yang sama dengan izin lihat yang berbeda dapat membantu mengurangi upaya dan kerumitan 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 Anda mengenkripsi semua komunikasi dalam pengiriman. Jika enkripsi diperlukan pada lapisan konektivitas, tersedia berbagai opsi berdasarkan solusi konektivitas hibrid yang dipilih. Opsi ini mencakup tunnel VPN, VPN 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
CDA Cloud Data Fusion
Apache Hadoop Dataproc
MySQL, PostgreSQL Cloud SQL
Cluster Redis, Redis, Memcached Memorystore
Network File System (NFS) Filestore
JMS, Kafka Pub/Sub
Kubernetes GKE Enterprise