Memilih lingkungan runtime penampung terkelola

Last reviewed 2024-08-30 UTC

Dokumen ini membantu Anda menilai persyaratan aplikasi dan memilih antara Cloud Run dan Google Kubernetes Engine (GKE) Autopilot, berdasarkan pertimbangan teknis dan organisasi. Dokumen ini ditujukan untuk arsitek cloud yang perlu memilih lingkungan runtime container target untuk workload mereka. Google Cloud Anda dianggap sudah memahami Kubernetes dan Google Cloud, serta memiliki beberapa pengetahuan tentang lingkungan runtime serverless cloud seperti Cloud Run, Cloud Run Functions, atau AWS Lambda.

Google Cloud menawarkan beberapa opsi lingkungan runtime yang memiliki berbagai kemampuan. Diagram berikut menunjukkan rentang penawaran terkelola: Google Cloud

PenawaranGoogle Cloud dari yang paling dikelola hingga yang paling sedikit dikelola.

Diagram menunjukkan hal berikut:

  • Lingkungan runtime yang paling dikelola (fokus panduan ini):

    Opsi ini dikelola oleh Google, tanpa pengelolaan pengguna pada infrastruktur komputasi yang mendasarinya.

  • Lingkungan runtime yang paling sedikit dikelola:

    • GKE Standard, yang dioptimalkan untuk beban kerja perusahaan dan menawarkan skalabilitas cluster tunggal hingga 65.000 node.
    • Compute Engine, yang mencakup kelompok mesin virtual A3 yang dioptimalkan untuk akselerator bagi workload machine learning (ML) dan komputasi berperforma tinggi (HPC).

    Opsi ini memerlukan pengelolaan infrastruktur tingkat pengguna dalam tingkat tertentu, seperti virtual machine (VM) yang mendasari kemampuan komputasi. VM di GKE Standard adalah node cluster Kubernetes. VM di Compute Engine adalah penawaran platform inti, yang dapat Anda sesuaikan agar sesuai dengan kebutuhan Anda.

Panduan ini membantu Anda memilih antara lingkungan runtime yang paling dikelola, Cloud Run dan GKE Autopilot. Untuk melihat lingkungan runtime Google Cloud secara lebih luas, lihat panduan Google Cloud Opsi Hosting Aplikasi.

Ringkasan lingkungan

Bagian ini memberikan ringkasan kemampuan Cloud Run dan GKE Autopilot. Cloud Run dan GKE Autopilot terintegrasi erat dalam Google Cloud, sehingga ada banyak kesamaan di antara keduanya. Kedua platform mendukung beberapa opsi untuk load balancing dengan layanan load balancing Google yang sangat andal dan skalabel. Keduanya juga mendukung jaringan VPC, Identity-Aware Proxy (IAP), dan Google Cloud Armor jika diperlukan jaringan pribadi yang lebih terperinci. Kedua platform ini hanya mengenakan biaya untuk resource yang Anda gunakan untuk aplikasi.

Dari perspektif pengiriman software, sebagai lingkungan runtime container, Cloud Run dan GKE Autopilot didukung oleh layanan yang membentuk ekosistem container. Google Cloud Layanan ini mencakup Cloud Build, Artifact Registry, Binary Authorization, dan continuous delivery dengan Cloud Deploy, untuk membantu memastikan aplikasi Anda di-deploy dengan aman dan andal ke produksi. Artinya, Anda dan tim Anda memiliki keputusan terkait build dan deployment.

Karena kesamaan antara kedua platform, Anda mungkin ingin memanfaatkan keunggulan masing-masing dengan menerapkan pendekatan yang fleksibel untuk tempat Anda men-deploy aplikasi, seperti yang dijelaskan dalam panduan Menggunakan GKE dan Cloud Run bersama-sama. Bagian berikut menjelaskan aspek unik Cloud Run dan Autopilot.

Cloud Run

Cloud Run adalah platform komputasi terkelola serverless yang memungkinkan Anda menjalankan aplikasi langsung di atas infrastruktur Google yang skalabel. Cloud Run menyediakan otomatisasi dan penskalaan untuk dua jenis aplikasi utama:

  • Layanan Cloud Run: Untuk kode yang merespons permintaan web.
  • Tugas Cloud Run: Untuk kode yang melakukan satu atau beberapa tugas latar belakang, lalu keluar saat pekerjaan selesai.

Dengan dua model deployment ini, Cloud Run dapat mendukung berbagai arsitektur aplikasi sekaligus memungkinkan praktik terbaik dan membiarkan developer berfokus pada kode.

Cloud Run juga mendukung deployment kode aplikasi dari sumber berikut:

  • Fungsi ringan individual
  • Aplikasi lengkap dari kode sumber
  • Aplikasi dalam container

Cloud Run menyertakan kemampuan build dan deployment yang mendukung FaaS dan kemampuan untuk membangun dari sumber, bersama dengan kemampuan runtime container yang telah dibuat sebelumnya. Saat Anda menggunakan Cloud Run dengan cara ini, langkah-langkah membangun dan men-deploy image container aplikasi yang akan dieksekusi sepenuhnya otomatis, dan tidak memerlukan konfigurasi kustom dari Anda.

Autopilot GKE

GKE Autopilot adalah mode operasi cluster default dan yang direkomendasikan di GKE. Dengan Autopilot, Anda dapat menjalankan aplikasi di Kubernetes tanpa overhead pengelolaan infrastruktur. Saat Anda menggunakan Autopilot, Google mengelola aspek dasar utama konfigurasi cluster Anda, termasuk penyediaan dan penskalaan node, postur keamanan default, dan setelan lainnya yang telah dikonfigurasi sebelumnya. Dengan Autopilot yang mengelola resource node, Anda hanya membayar resource yang diminta oleh workload Anda. Autopilot terus memantau dan mengoptimalkan penyediaan sumber daya infrastruktur untuk memastikan kesesuaian terbaik sekaligus memberikan SLA untuk workload Anda.

GKE Autopilot mendukung workload yang mungkin tidak cocok untuk Cloud Run. Misalnya, GKE Autopilot biasanya mendukung workload stateful atau yang berjalan lama.

Pilih lingkungan runtime

Secara umum, jika karakteristik workload Anda cocok untuk platform terkelola, lingkungan runtime serverless Cloud Run sangat ideal. Penggunaan Cloud Run dapat menghasilkan lebih sedikit infrastruktur yang perlu dikelola, lebih sedikit konfigurasi yang dikelola sendiri, dan oleh karena itu, overhead operasional yang lebih rendah. Kecuali jika Anda secara khusus menginginkan atau membutuhkan Kubernetes, sebaiknya pertimbangkan serverless terlebih dahulu sebagai lingkungan runtime target Anda. Meskipun Kubernetes menyediakan abstraksi yang canggih dari platform terbuka, penggunaannya menambah kompleksitas. Jika Anda tidak memerlukan Kubernetes, sebaiknya pertimbangkan apakah aplikasi Anda cocok untuk serverless. Jika ada kriteria yang membuat workload Anda kurang cocok untuk serverless, sebaiknya gunakan Autopilot.

Bagian berikut memberikan detail selengkapnya tentang beberapa kriteria yang dapat membantu Anda menjawab pertanyaan ini, terutama pertanyaan apakah workload cocok untuk serverless. Mengingat kesamaan antara Autopilot dan Cloud Run yang dijelaskan di bagian sebelumnya, migrasi antar-platform adalah tugas yang mudah jika tidak ada pemblokir teknis atau lainnya. Untuk mempelajari opsi migrasi secara lebih mendetail, lihat Bermigrasi dari Cloud Run ke GKE dan Bermigrasi dari Kubernetes ke Cloud Run.

Saat memilih lingkungan runtime untuk workload, Anda perlu mempertimbangkan pertimbangan teknis dan pertimbangan organisasi. Pertimbangan teknis adalah karakteristik aplikasi Anda atau lingkungan runtime. Google CloudPertimbangan organisasi adalah karakteristik non-teknis organisasi atau tim Anda yang dapat memengaruhi keputusan Anda.

Pertimbangan teknis

Beberapa pertimbangan teknis yang akan memengaruhi pilihan platform Anda adalah sebagai berikut:

  • Kontrol dan kemampuan konfigurasi: Granularitas kontrol lingkungan eksekusi.
  • Pengelolaan dan perutean traffic jaringan: Kemampuan konfigurasi interaksi melalui jaringan.
  • Skalabilitas horizontal dan vertikal: Dukungan untuk kapasitas yang bertambah dan berkurang secara dinamis.
  • Dukungan untuk aplikasi stateful: Kemampuan untuk menyimpan status persisten.
  • Arsitektur CPU: Dukungan untuk berbagai jenis CPU.
  • Offload akselerator (GPU dan TPU): Kemampuan untuk meng-offload komputasi ke hardware khusus.
  • Kapasitas memori, CPU, dan resource lainnya yang tinggi: Tingkat berbagai resource yang digunakan.
  • Dependensi eksplisit pada Kubernetes: Persyaratan untuk penggunaan Kubernetes API.
  • RBAC kompleks untuk multi-tenancy: Dukungan untuk berbagi resource gabungan.
  • Waktu tunggu tugas container maksimum: Durasi eksekusi aplikasi atau komponen yang berjalan lama.

Bagian berikut menjelaskan pertimbangan teknis ini secara mendetail untuk membantu Anda memilih lingkungan runtime.

Kontrol dan kemampuan konfigurasi

Dibandingkan dengan Cloud Run, GKE Autopilot memberikan kontrol yang lebih terperinci atas lingkungan eksekusi untuk workload Anda. Dalam konteks Pod, Kubernetes menyediakan banyak primitif yang dapat dikonfigurasi yang dapat Anda sesuaikan untuk memenuhi persyaratan aplikasi Anda. Opsi konfigurasi mencakup tingkat hak istimewa, parameter kualitas layanan, handler kustom untuk peristiwa siklus proses penampung, dan berbagi namespace proses di antara beberapa penampung.

Cloud Run secara langsung mendukung sebagian kecil permukaan Kubernetes Pod API, yang dijelaskan dalam YAML referensi untuk objek Layanan Cloud Run dan dalam YAML referensi untuk objek Tugas Cloud Run. Panduan referensi ini dapat membantu Anda mengevaluasi kedua platform bersama dengan persyaratan aplikasi Anda.

Kontrak container untuk lingkungan eksekusi Cloud Run relatif mudah dan akan sesuai dengan sebagian besar beban kerja penayangan. Namun, kontrak menentukan beberapa persyaratan yang harus dipenuhi. Jika aplikasi atau dependensinya tidak dapat memenuhi persyaratan tersebut, atau jika Anda memerlukan tingkat kontrol yang lebih baik atas lingkungan eksekusi, Autopilot mungkin lebih cocok.

Jika Anda ingin mengurangi waktu yang Anda habiskan untuk konfigurasi dan administrasi, pertimbangkan untuk memilih Cloud Run sebagai lingkungan runtime Anda. Cloud Run memiliki lebih sedikit opsi konfigurasi daripada Autopilot, sehingga dapat membantu Anda memaksimalkan produktivitas developer dan mengurangi overhead operasional.

Pengelolaan dan pemilihan rute traffic jaringan

Cloud Run dan GKE Autopilot terintegrasi dengan Google Cloud Load Balancing. Namun, GKE Autopilot juga menyediakan sekumpulan primitif yang kaya dan canggih untuk mengonfigurasi lingkungan jaringan bagi komunikasi layanan-ke-layanan. Opsi konfigurasi mencakup izin dan pemisahan terperinci di lapisan jaringan menggunakan namespace dan kebijakan jaringan, pemetaan ulang port, dan penemuan layanan DNS bawaan dalam cluster. GKE Autopilot juga mendukung Gateway API yang sangat dapat dikonfigurasi dan fleksibel. Fungsi ini memberikan kontrol yang efektif atas cara traffic dirutekan ke dalam dan di antara layanan dalam cluster.

Karena sangat dapat dikonfigurasi, Autopilot dapat menjadi opsi terbaik jika Anda memiliki beberapa layanan dengan tingkat saling ketergantungan jaringan yang tinggi, atau persyaratan kompleks terkait cara traffic dirutekan di antara komponen aplikasi Anda. Contoh pola ini adalah aplikasi terdistribusi yang diurai menjadi banyak microservice yang memiliki pola saling ketergantungan yang kompleks. Dalam skenario seperti itu, opsi konfigurasi jaringan Autopilot dapat membantu Anda mengelola dan mengontrol interaksi antar-layanan.

Skalabilitas horizontal dan vertikal

Cloud Run dan GKE Autopilot sama-sama mendukung penskalaan horizontal manual dan otomatis untuk layanan dan tugas. Penskalaan horizontal memberikan peningkatan daya pemrosesan saat diperlukan, dan menghapus peningkatan daya pemrosesan saat tidak diperlukan. Untuk workload umum, Cloud Run biasanya dapat melakukan penskalaan horizontal lebih cepat daripada GKE Autopilot untuk merespons lonjakan jumlah permintaan per detik. Sebagai contoh, demonstrasi video "Yang Baru di Serverless Compute?" menunjukkan penskalaan Cloud Run dari nol hingga lebih dari 10.000 instance dalam waktu sekitar 10 detik. Untuk meningkatkan kecepatan penskalaan horizontal di Kubernetes (dengan biaya tambahan), Autopilot memungkinkan Anda menyediakan kapasitas komputasi tambahan.

Jika aplikasi Anda tidak dapat diskalakan dengan menambahkan lebih banyak instance untuk meningkatkan level resource yang tersedia, maka aplikasi tersebut mungkin lebih cocok untuk Autopilot. Autopilot mendukung penskalaan vertikal untuk mengubah jumlah daya pemrosesan yang tersedia secara dinamis tanpa meningkatkan jumlah instance aplikasi yang berjalan.

Cloud Run dapat otomatis menskalakan aplikasi Anda hingga nol replika saat tidak digunakan, yang berguna untuk kasus penggunaan tertentu yang memiliki fokus khusus pada pengoptimalan biaya. Karena karakteristik cara aplikasi Anda dapat diskalakan ke nol, ada beberapa langkah pengoptimalan yang dapat Anda lakukan untuk meminimalkan waktu antara kedatangan permintaan dan waktu saat aplikasi Anda aktif dan berjalan, serta dapat memproses permintaan.

Dukungan untuk aplikasi stateful

Autopilot menawarkan dukungan Volume Kubernetes lengkap, yang didukung oleh Persistent Disk yang memungkinkan Anda menjalankan berbagai deployment stateful, termasuk database yang dikelola sendiri. Cloud Run dan GKE Autopilot memungkinkan Anda terhubung dengan layanan lain seperti bucket Filestore dan Cloud Storage. Keduanya juga mencakup kemampuan untuk memasang bucket penyimpanan objek ke dalam sistem file dengan Cloud Storage FUSE.

Cloud Run menggunakan sistem file dalam memori, yang mungkin tidak cocok untuk aplikasi yang memerlukan sistem file lokal persisten. Selain itu, sistem file dalam memori lokal dibagikan dengan memori aplikasi Anda. Oleh karena itu, penggunaan memori sistem file sementara dan aplikasi serta penampung berkontribusi terhadap habisnya batas memori. Anda dapat menghindari masalah ini jika menggunakan volume dalam memori khusus dengan batas ukuran.

Container layanan atau tugas Cloud Run memiliki waktu tunggu tugas maksimum. Container yang berjalan dalam pod di cluster Autopilot dapat dijadwalkan ulang, tunduk pada batasan apa pun yang dikonfigurasi dengan Anggaran Gangguan Pod (PDB). Namun, pod dapat berjalan hingga tujuh hari jika dilindungi dari penghapusan yang disebabkan oleh upgrade otomatis node atau peristiwa penurunan skala. Biasanya, task timeout lebih mungkin menjadi pertimbangan untuk workload batch di Cloud Run. Untuk workload yang berjalan lama, dan untuk tugas batch yang tidak dapat diselesaikan dalam durasi tugas maksimum, Autopilot mungkin merupakan opsi terbaik.

Arsitektur CPU

Semua platform komputasi Google Cloud mendukung arsitektur CPU x86. Cloud Run tidak mendukung prosesor arsitektur Arm, tetapi Autopilot mendukung node terkelola yang didukung oleh arsitektur Arm. Jika workload Anda memerlukan arsitektur Arm, Anda harus menggunakan Autopilot.

Pengurangan beban akselerator

Autopilot mendukung penggunaan GPU dan penggunaan TPU, termasuk kemampuan untuk menggunakan resource yang dicadangkan. Cloud Run mendukung penggunaan GPU dengan beberapa batasan.

Persyaratan memori, CPU, dan resource lainnya yang tinggi

Dibandingkan dengan batas permintaan resource GKE Autopilot, resource CPU dan memori maksimum yang dapat digunakan oleh satu layanan atau tugas Cloud Run (satu instance) terbatas. Bergantung pada karakteristik workload Anda, Cloud Run mungkin memiliki batas lain yang membatasi resource yang tersedia. Misalnya, waktu tunggu startup dan jumlah maksimum koneksi keluar mungkin dibatasi dengan Cloud Run. Dengan Autopilot, beberapa batas mungkin tidak berlaku atau mungkin memiliki nilai yang diizinkan lebih tinggi.

Dependensi eksplisit pada Kubernetes

Beberapa aplikasi, library, atau framework mungkin memiliki dependensi eksplisit pada Kubernetes. Dependensi Kubernetes mungkin merupakan hasil dari salah satu hal berikut:

  1. Persyaratan aplikasi (misalnya, aplikasi memanggil API Kubernetes, atau menggunakan resource kustom Kubernetes).
  2. Persyaratan alat yang digunakan untuk mengonfigurasi atau men-deploy aplikasi (seperti Helm).
  3. Persyaratan dukungan kreator atau pemasok pihak ketiga.

Dalam skenario ini, Autopilot adalah lingkungan runtime target karena Cloud Run tidak mendukung Kubernetes.

RBAC kompleks untuk multi-tenancy

Jika organisasi Anda memiliki struktur organisasi yang sangat kompleks atau persyaratan multi-tenancy, gunakan Autopilot agar Anda dapat memanfaatkan Role-Based Access Control (RBAC) Kubernetes. Untuk opsi yang lebih sederhana, Anda dapat menggunakan kapabilitas keamanan dan pemisahan yang dibuat di Cloud Run.

Pertimbangan organisasi

Berikut adalah beberapa pertimbangan organisasi yang akan memengaruhi pilihan lingkungan Anda:

  • Strategi teknis yang luas: Arah teknis organisasi Anda.
  • Memanfaatkan ekosistem Kubernetes: Minat untuk memanfaatkan komunitas OSS.
  • Alat internal yang sudah ada: Penggunaan alat tertentu oleh incumbent.
  • Profil tim pengembangan: Kumpulan keterampilan dan pengalaman developer.
  • Dukungan operasional: Kemampuan dan fokus tim operasi.

Bagian berikut menjelaskan pertimbangan organisasi ini secara mendetail untuk membantu Anda memilih lingkungan.

Strategi teknis yang luas

Organisasi atau tim mungkin memiliki strategi yang disepakati untuk lebih memilih teknologi tertentu daripada yang lain. Misalnya, jika tim memiliki kesepakatan untuk menstandardisasi jika memungkinkan pada serverless atau Kubernetes, kesepakatan tersebut dapat memengaruhi atau bahkan menentukan target lingkungan runtime.

Jika beban kerja tertentu tidak cocok untuk lingkungan runtime yang ditentukan dalam strategi, Anda dapat memutuskan untuk melakukan satu atau beberapa hal berikut, dengan peringatan yang menyertainya:

  • Mendesain ulang workload. Namun, jika workload tidak cocok, tindakan tersebut dapat menyebabkan performa, biaya, keamanan, atau karakteristik lainnya menjadi tidak optimal.
  • Daftarkan workload sebagai pengecualian terhadap arah strategis. Namun, jika pengecualian digunakan secara berlebihan, hal itu dapat menghasilkan portofolio teknologi yang berbeda-beda.
  • Pertimbangkan kembali strategi. Namun, melakukannya dapat menyebabkan overhead kebijakan yang dapat menghambat atau memblokir progres.

Memanfaatkan ekosistem Kubernetes

Sebagai bagian dari strategi teknis yang luas yang dijelaskan sebelumnya, organisasi atau tim dapat memutuskan untuk memilih Kubernetes sebagai platform pilihan mereka karena ekosistemnya yang signifikan dan terus berkembang. Pilihan ini berbeda dengan memilih Kubernetes karena dependensi aplikasi teknis, seperti yang dijelaskan di bagian sebelumnya Dependensi eksplisit pada Kubernetes. Pertimbangan untuk menggunakan ekosistem Kubernetes menekankan pada komunitas yang aktif, alat pihak ketiga yang kaya, serta standar dan portabilitas yang kuat. Memanfaatkan ekosistem Kubernetes dapat mempercepat kecepatan pengembangan dan mengurangi waktu penyiapan produk.

Alat internal yang ada

Dalam beberapa kasus, akan lebih menguntungkan jika Anda menggunakan ekosistem alat yang ada di organisasi atau tim Anda (untuk lingkungan apa pun). Misalnya, jika Anda menggunakan Kubernetes, Anda dapat memilih untuk terus menggunakan alat deployment seperti ArgoCD, alat keamanan dan kebijakan seperti Gatekeeper, dan pengelolaan paket seperti Helm. Alat yang ada mungkin mencakup aturan yang ditetapkan untuk otomatisasi kepatuhan organisasi dan fungsi lain yang mungkin mahal atau memerlukan waktu tunggu yang lama untuk diterapkan pada lingkungan target alternatif.

Profil tim pengembangan

Tim aplikasi atau beban kerja mungkin memiliki pengalaman sebelumnya dengan Kubernetes yang dapat mempercepat kecepatan dan kemampuan tim untuk memberikan hasil di Autopilot. Tim memerlukan waktu untuk menjadi mahir dalam menggunakan lingkungan runtime baru. Bergantung pada model operasi, tindakan ini berpotensi menurunkan keandalan platform selama periode peningkatan keterampilan.

Untuk tim yang berkembang, kemampuan merekrut dapat memengaruhi pilihan platform organisasi. Di beberapa pasar, keterampilan Kubernetes mungkin langka dan oleh karena itu memerlukan biaya perekrutan yang lebih tinggi. Memilih lingkungan seperti Cloud Run dapat membantu Anda menyederhanakan proses perekrutan dan memungkinkan pertumbuhan tim yang lebih cepat sesuai anggaran Anda.

Dukungan operasional

Saat memilih lingkungan runtime, pertimbangkan pengalaman dan kemampuan SRE, DevOps, dan tim platform Anda, serta staf operasional lainnya. Kemampuan tim operasional untuk mendukung lingkungan produksi secara efektif sangat penting dari perspektif keandalan. Tim operasional juga harus dapat mendukung lingkungan praproduksi untuk memastikan kecepatan developer tidak terhambat oleh periode nonaktif, ketergantungan pada proses manual, atau mekanisme deployment yang rumit.

Jika Anda menggunakan Kubernetes, tim operasi atau platform engineering pusat dapat menangani upgrade Kubernetes Autopilot. Meskipun upgrade bersifat otomatis, staf operasional biasanya akan memantaunya dengan cermat untuk memastikan gangguan minimal pada workload Anda. Beberapa organisasi memilih untuk mengupgrade versi bidang kontrol secara manual. GKE Enterprise juga mencakup kemampuan untuk menyederhanakan dan mempermudah pengelolaan aplikasi di beberapa cluster.

Berbeda dengan Autopilot, Cloud Run tidak memerlukan overhead pengelolaan atau upgrade bidang kontrol yang berkelanjutan. Dengan menggunakan Cloud Run, Anda dapat menyederhanakan proses operasi. Dengan memilih satu lingkungan runtime, Anda dapat menyederhanakan lebih lanjut proses operasi. Jika memilih untuk menggunakan beberapa lingkungan runtime, Anda harus memastikan bahwa tim memiliki kapasitas, kemampuan, dan minat untuk mendukung lingkungan runtime tersebut.

Pilihan

Untuk memulai proses pemilihan, bicaralah dengan berbagai pemangku kepentingan. Untuk setiap aplikasi, bentuk grup kerja yang terdiri dari developer, staf operasional, perwakilan dari grup tata kelola teknologi pusat, pengguna dan konsumen aplikasi internal, tim pengoptimalan keuangan cloud, serta peran atau grup lain dalam organisasi Anda yang mungkin relevan. Anda dapat memilih untuk menyebarkan survei pengumpulan informasi untuk mengumpulkan karakteristik aplikasi, dan membagikan hasilnya sebelum sesi. Sebaiknya pilih grup kerja kecil yang hanya mencakup pemangku kepentingan yang diperlukan. Tidak semua perwakilan mungkin diperlukan untuk setiap sesi kerja.

Anda juga dapat menyertakan perwakilan dari tim atau grup lain yang memiliki pengalaman dalam membangun dan menjalankan aplikasi di Autopilot atau Cloud Run, atau keduanya. Gunakan pertimbangan teknis dan organisasi dari dokumen ini untuk memandu percakapan Anda dan mengevaluasi kesesuaian aplikasi Anda untuk setiap platform potensial.

Sebaiknya Anda menjadwalkan diskusi setelah beberapa bulan berlalu untuk mengonfirmasi atau meninjau kembali keputusan berdasarkan hasil deployment aplikasi Anda di lingkungan baru.

Langkah berikutnya

Kontributor

Penulis: Henry Bell | Cloud Solutions Architect

Kontributor lainnya: