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 penampung target Google Cloud untuk workload mereka. Anda dianggap sudah memahami Kubernetes dan Google Cloud, serta memiliki pengetahuan tentang lingkungan runtime serverless cloud seperti Cloud Run, fungsi Cloud Run, atau AWS Lambda.

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

Penawaran Google Cloud dari yang paling terkelola hingga yang paling tidak terkelola.

Diagram menunjukkan hal berikut:

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

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

  • Lingkungan runtime yang paling tidak dikelola:

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

    Opsi ini memerlukan tingkat pengelolaan infrastruktur tingkat pengguna 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 untuk memenuhi persyaratan Anda.

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

Ringkasan lingkungan

Bagian ini memberikan ringkasan tentang 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 tersebut 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 jaringan pribadi yang lebih terperinci diperlukan. Kedua platform tersebut hanya mengenakan biaya sesuai 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 bahwa aplikasi Anda di-deploy dengan aman dan andal ke produksi. Artinya, Anda dan tim Anda memiliki keputusan build dan deployment.

Karena kesamaan antara kedua platform tersebut, Anda mungkin ingin memanfaatkan kekuatan masing-masing dengan mengadopsi 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 menjalankan satu atau beberapa tugas latar belakang, lalu keluar saat pekerjaan selesai.

Dengan dua model deployment ini, Cloud Run dapat mendukung berbagai arsitektur aplikasi sekaligus mengaktifkan praktik terbaik dan memungkinkan 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 menggabungkan kemampuan build dan deploy yang mendukung FaaS dan kemampuan untuk mem-build dari sumber, bersama dengan kemampuan runtime penampung bawaan. Saat Anda menggunakan Cloud Run dengan cara ini, langkah-langkah mem-build 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. Autopilot memungkinkan Anda menjalankan aplikasi di Kubernetes tanpa overhead pengelolaan infrastruktur. Saat Anda menggunakan Autopilot, Google akan 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. Autopilot terus memantau dan mengoptimalkan penyediaan resource 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 berumur panjang.

Memilih lingkungan runtime

Secara umum, jika karakteristik beban kerja Anda cocok untuk platform terkelola, lingkungan runtime serverless Cloud Run adalah solusi yang ideal. Penggunaan Cloud Run dapat menghasilkan lebih sedikit infrastruktur yang harus dikelola, lebih sedikit konfigurasi yang dikelola sendiri, sehingga overhead operasional menjadi lebih rendah. Kecuali jika Anda secara khusus menginginkan atau memerlukan Kubernetes, sebaiknya pertimbangkan serverless terlebih dahulu sebagai lingkungan runtime target Anda. Meskipun Kubernetes menyediakan abstraksi platform terbuka yang canggih, penggunaannya akan 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 Cloud. Pertimbangan organisasi adalah karakteristik non-teknis organisasi atau tim Anda yang mungkin memengaruhi keputusan Anda.

Pertimbangan teknis

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

  • Kontrol dan kemampuan konfigurasi: Tingkat perincian kontrol lingkungan eksekusi.
  • Pengelolaan dan pemilihan rute traffic jaringan: Kemampuan konfigurasi interaksi melalui jaringan.
  • Skalabilitas horizontal dan vertikal: Dukungan untuk kapasitas yang meningkat dan menurun secara dinamis.
  • Dukungan untuk aplikasi stateful: Kemampuan untuk menyimpan status persisten.
  • Arsitektur CPU: Dukungan untuk berbagai jenis CPU.
  • Pemindahan beban akselerator (GPU dan TPU): Kemampuan untuk memindahkan beban 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 penampung maksimum: Durasi eksekusi aplikasi atau komponen yang berumur panjang.

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

Kontrol dan kemampuan konfigurasi

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

Cloud Run secara langsung mendukung sebagian platform 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 tersebut 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 dihabiskan untuk konfigurasi dan administrasi, pertimbangkan untuk memilih Cloud Run sebagai lingkungan runtime Anda. Cloud Run memiliki lebih sedikit opsi konfigurasi dibandingkan dengan 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 Load Balancing Google Cloud. Namun, GKE Autopilot juga menyediakan kumpulan primitif yang kaya dan canggih untuk mengonfigurasi lingkungan jaringan bagi komunikasi layanan ke layanan. Opsi konfigurasi mencakup izin terperinci dan pemisahan 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 Autopilot sangat dapat dikonfigurasi, Autopilot dapat menjadi opsi terbaik jika Anda memiliki beberapa layanan dengan tingkat kodependensi jaringan yang tinggi, atau persyaratan kompleks seputar cara traffic dirutekan di antara komponen aplikasi Anda. Contoh pola ini adalah aplikasi terdistribusi yang diurai menjadi banyak microservice yang memiliki pola interdependensi yang kompleks. Dalam skenario tersebut, opsi konfigurasi jaringan Autopilot dapat membantu Anda mengelola dan mengontrol interaksi antarlayanan.

Skalabilitas horizontal dan vertikal

Cloud Run dan GKE Autopilot mendukung penskalaan horizontal manual dan otomatis untuk layanan dan tugas. Penskalaan horizontal memberikan peningkatan daya pemrosesan saat diperlukan, dan menghapus daya pemrosesan tambahan saat tidak diperlukan. Untuk beban kerja standar, Cloud Run biasanya dapat diskalakan lebih cepat daripada GKE Autopilot untuk merespons lonjakan jumlah permintaan per detik. Sebagai contoh, demonstrasi video "What's New in Serverless Compute?" menunjukkan penskalaan Cloud Run dari nol menjadi 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, aplikasi tersebut mungkin lebih cocok untuk Autopilot. Autopilot mendukung penskalaan vertikal untuk secara dinamis memvariasikan jumlah daya pemrosesan yang tersedia tanpa meningkatkan jumlah instance aplikasi yang berjalan.

Cloud Run dapat otomatis menskalakan aplikasi Anda menjadi 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 aplikasi Anda aktif dan berjalan, serta dapat memproses permintaan.

Dukungan untuk aplikasi stateful

Autopilot menawarkan dukungan Volume Kubernetes lengkap, yang didukung oleh Disk Persisten 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 menyertakan kemampuan untuk memasang bucket object-store 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, sistem file sementara serta penggunaan memori aplikasi dan penampung berkontribusi terhadap habisnya batas memori. Anda dapat menghindari masalah ini jika menggunakan volume dalam memori khusus dengan batas ukuran.

Penampung tugas atau layanan Cloud Run memiliki waktu tunggu tugas maksimum. Penampung 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, waktu tunggu tugas lebih cenderung menjadi pertimbangan untuk workload batch di Cloud Run. Untuk workload yang berumur panjang, dan untuk tugas batch yang tidak dapat diselesaikan dalam durasi tugas maksimum, Autopilot mungkin adalah 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.

Offload 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) dibatasi. Bergantung pada karakteristik beban kerja 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 Kubernetes API, atau menggunakan resource kustom Kubernetes).
  2. Persyaratan alat yang digunakan untuk mengonfigurasi atau men-deploy aplikasi (seperti Helm).
  3. Persyaratan dukungan dari 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 atau persyaratan yang sangat kompleks untuk multi-tenancy, gunakan Autopilot agar Anda dapat memanfaatkan Role-Based Access Control (RBAC) Kubernetes. Untuk opsi yang lebih sederhana, Anda dapat menggunakan kemampuan keamanan dan pemisahan yang terintegrasi ke 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 ada: Penggunaan alat tertentu oleh perusahaan lama.
  • Profil tim pengembangan: Kumpulan keterampilan dan pengalaman developer.
  • Dukungan operasional: Fokus dan kemampuan tim operasi.

Bagian berikut menjelaskan pertimbangan organisasi ini 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 menstandarkan jika memungkinkan di serverless atau Kubernetes, kesepakatan tersebut dapat memengaruhi atau bahkan menentukan lingkungan runtime target.

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

  • Mendesain ulang beban kerja. Namun, jika beban kerja tidak cocok, tindakan tersebut dapat menyebabkan performa, biaya, keamanan, atau karakteristik lainnya yang tidak optimal.
  • Mendaftarkan beban kerja sebagai pengecualian terhadap arah strategis. Namun, jika pengecualian digunakan secara berlebihan, hal tersebut dapat menghasilkan portofolio teknologi yang berbeda.
  • Pertimbangkan kembali strateginya. Namun, hal ini 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 mungkin 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 beragam, 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, ada baiknya menggunakan ekosistem alat yang ada di organisasi atau tim Anda (untuk lingkungan apa pun). Misalnya, jika menggunakan Kubernetes, Anda dapat memilih untuk terus menggunakan alat deployment seperti ArgoCD, alat keamanan dan kebijakan seperti Gatekeeper, serta 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 di 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 Autopilot. Diperlukan waktu bagi tim untuk menjadi mahir dengan lingkungan runtime baru. Bergantung pada model operasi, tindakan ini berpotensi menyebabkan keandalan platform yang lebih rendah selama periode peningkatan keterampilan.

Untuk tim yang berkembang, kemampuan perekrutan dapat memengaruhi pilihan platform organisasi. Di beberapa pasar, keterampilan Kubernetes mungkin langka sehingga memerlukan premium perekrutan. 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, 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 pusat atau engineer platform 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 panel kontrol secara manual. GKE Enterprise juga mencakup kemampuan untuk menyederhanakan dan menyederhanakan pengelolaan aplikasi di beberapa cluster.

Berbeda dengan Autopilot, Cloud Run tidak memerlukan overhead pengelolaan berkelanjutan atau upgrade bidang kontrol. Dengan menggunakan Cloud Run, Anda dapat menyederhanakan proses operasi. Dengan memilih satu lingkungan runtime, Anda dapat lebih menyederhanakan 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, bicarakan dengan berbagai pemangku kepentingan. Untuk setiap aplikasi, kumpulkan grup kerja yang terdiri dari developer, staf operasional, perwakilan dari grup tata kelola teknologi pusat, pengguna dan konsumen aplikasi internal, keamanan, tim pengoptimalan keuangan cloud, dan peran atau grup lain dalam organisasi Anda yang mungkin relevan. Anda dapat memilih untuk mengedarkan survei pengumpulan informasi guna mengumpulkan karakteristik aplikasi, dan membagikan hasilnya sebelum sesi. Sebaiknya Anda memilih grup kerja kecil yang hanya menyertakan pemangku kepentingan yang diperlukan. Semua perwakilan mungkin tidak diperlukan untuk setiap sesi kerja.

Anda mungkin juga merasa perlu menyertakan perwakilan dari tim atau grup lain yang memiliki pengalaman dalam mem-build dan menjalankan aplikasi di Autopilot atau Cloud Run, atau keduanya. Gunakan pertimbangan teknis dan organisasional dari dokumen ini untuk memandu percakapan dan mengevaluasi kesesuaian aplikasi Anda untuk setiap platform potensial.

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

Langkah selanjutnya

Kontributor

Penulis: Henry Bell | Cloud Solutions Architect

Kontributor lainnya: