Memilih lingkungan runtime penampung terkelola

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

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

PenawaranGoogle Cloud dari yang paling terkelola hingga yang paling tidak terkelola.

Diagram menunjukkan hal berikut:

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

    Opsi ini dikelola oleh Google, tanpa pengelolaan pengguna atas 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 A3 virtual machine yang dioptimalkan akselerator untuk workload machine learning (ML) dan komputasi berperforma tinggi (HPC).

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

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

Ringkasan lingkungan

Bagian ini memberikan ringkasan tentang kemampuan Cloud Run dan GKE Autopilot. Cloud Run dan GKE Autopilot keduanya 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 jaringan pribadi yang lebih terperinci merupakan persyaratan. Kedua platform tersebut hanya akan mengenakan biaya sesuai resource yang digunakan untuk aplikasi Anda.

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

Karena kedua platform ini memiliki kesamaan, Anda dapat memanfaatkan keunggulan masing-masing platform tersebut dengan mengadopsi pendekatan yang fleksibel di mana 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 dapat Anda gunakan untuk 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 setelah pekerjaan selesai.

Dengan kedua 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 deployment yang mendukung FaaS dan kemampuan membangun dari sumber, bersama dengan kemampuan runtime container bawaan. Saat Anda menggunakan Cloud Run dengan cara ini, langkah-langkah untuk mem-build dan men-deploy image container aplikasi yang akan dijalankan sepenuhnya otomatis, dan tidak memerlukan konfigurasi khusus dari Anda.

Autopilot GKE

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

Autopilot GKE mendukung workload yang mungkin tidak sesuai untuk Cloud Run. Misalnya, GKE Autopilot biasanya mendukung workload berumur panjang atau stateful.

Memilih lingkungan runtime

Secara umum, jika karakteristik workload Anda sesuai untuk platform terkelola, lingkungan runtime serverless Cloud Run merupakan solusi yang ideal. Penggunaan Cloud Run dapat menghasilkan pengelolaan infrastruktur yang lebih sedikit, konfigurasi yang dikelola sendiri, dan overhead operasional yang 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 andal, 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 lebih lanjut tentang beberapa kriteria yang dapat membantu Anda menjawab pertanyaan ini, terutama pertanyaan tentang apakah beban kerja cocok untuk serverless. Mengingat kesamaan antara Autopilot dan Cloud Run yang dijelaskan di bagian sebelumnya, migrasi antarplatform menjadi tugas yang mudah jika tidak ada penghalang teknis atau pemblokir 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 harus memperhitungkan pertimbangan teknis dan pertimbangan organisasi. Pertimbangan teknis adalah karakteristik aplikasi Anda atau Google Cloud lingkungan runtime. Pertimbangan organisasi adalah karakteristik non-teknis dari organisasi atau tim Anda yang mungkin mempengaruhi keputusan.

Pertimbangan teknis

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

  • Kontrol dan kemampuan konfigurasi: Perincian kontrol lingkungan eksekusi.
  • Pengelolaan dan perutean traffic jaringan: Kemampuan konfigurasi interaksi melalui jaringan.
  • Skalabilitas horizontal dan vertikal: Dukungan untuk meningkatkan kapasitas dan menyusutkan kapasitas secara dinamis.
  • Dukungan untuk aplikasi stateful: Kemampuan untuk menyimpan status persisten.
  • Arsitektur CPU: Dukungan untuk berbagai jenis CPU.
  • Pelepasan akselerator (GPU dan TPU): Kemampuan untuk mengalihkan komputasi ke hardware khusus.
  • Kapasitas memori tinggi, CPU, dan resource lainnya: Tingkat berbagai resource yang digunakan.
  • Dependensi eksplisit di 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 sudah lama aktif.

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

Kontrol dan kemampuan konfigurasi

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

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

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

Jika ingin mengurangi waktu yang dihabiskan untuk konfigurasi dan administrasi, sebaiknya pilih Cloud Run sebagai lingkungan runtime. Cloud Run memiliki opsi konfigurasi yang lebih sedikit daripada Autopilot, sehingga dapat membantu Anda memaksimalkan produktivitas developer dan mengurangi beban operasional.

Pengelolaan traffic dan pemilihan rute

Cloud Run dan GKE Autopilot terintegrasi dengan Google Cloud Load Balancing. Namun, Autopilot GKE juga menyediakan serangkaian primitif yang lengkap dan andal untuk mengonfigurasi lingkungan jaringan untuk komunikasi layanan-ke-layanan. Opsi konfigurasi mencakup izin terperinci dan segregasi pada 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 kuat atas cara traffic dirutekan ke dan di antara layanan di cluster.

Karena sangat dapat dikonfigurasi, Autopilot dapat menjadi opsi terbaik jika Anda memiliki beberapa layanan dengan tingkat kodependensi jaringan yang tinggi, atau persyaratan yang rumit tentang cara perutean traffic 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 semacam ini, 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 menghilangkan daya pemrosesan tambahan saat tidak diperlukan. Untuk workload standar, Cloud Run biasanya dapat melakukan penyebaran skala dengan lebih cepat daripada Autopilot GKE untuk merespons lonjakan jumlah permintaan per detik. Sebagai contoh, demonstrasi video "Apa yang Baru di Komputasi Serverless?" 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, aplikasi Anda 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 hingga ke nol replika saat tidak digunakan. Hal ini berguna untuk kasus penggunaan tertentu yang khusus berfokus pada pengoptimalan biaya. Karena karakteristik cara aplikasi Anda dapat diskalakan hingga nol, ada beberapa langkah pengoptimalan yang dapat Anda ambil untuk meminimalkan waktu antara kedatangan permintaan dan waktu saat aplikasi Anda aktif dan berjalan, dan dapat memproses permintaan tersebut.

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 menyertakan kemampuan untuk memasang bucket objek penyimpanan 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 lokal dalam memori dibagikan dengan memori aplikasi Anda. Oleh karena itu, baik sistem file efemeral maupun penggunaan memori container dan aplikasi berkontribusi terhadap penggunaan batas memori. Anda dapat menghindari masalah ini jika menggunakan volume dalam memori khusus dengan batas ukuran.

Layanan Cloud Run atau container tugas memiliki waktu tunggu tugas maksimum. Container yang berjalan dalam pod di cluster Autopilot dapat dijadwalkan ulang, sesuai dengan batasan apa pun yang dikonfigurasi dengan Pod Disruption Budgets (PDB). Namun, pod dapat berjalan hingga tujuh hari jika pod dilindungi dari penghapusan yang disebabkan oleh upgrade otomatis node atau peristiwa penurunan skala. Biasanya, waktu tunggu tugas lebih mungkin menjadi pertimbangan untuk workload batch di Cloud Run. Untuk beban kerja yang berumur panjang, dan untuk tugas batch yang tidak dapat diselesaikan dalam durasi tugas maksimum, Autopilot mungkin merupakan opsi terbaik.

Arsitektur CPU

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

Pemindahan akselerator

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

Persyaratan memori tinggi, CPU, dan resource lainnya

Dibandingkan dengan batas permintaan resource GKE Autopilot, resource CPU dan memori maksimum yang dapat digunakan oleh satu layanan atau tugas Cloud Run (satu instance) bersifat terbatas. Bergantung pada karakteristik workload Anda, Cloud Run mungkin memiliki batasan 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 batas tersebut 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 disebabkan oleh 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 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 atau persyaratan organisasi 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 dalam 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 secara terus-menerus.
  • Profil tim pengembangan: Keahlian dan pengalaman developer.
  • Dukungan operasional: Kemampuan dan fokus tim operasi.

Bagian berikut menjelaskan pertimbangan organisasional ini untuk membantu Anda memilih lingkungan.

Strategi teknis yang luas

Organisasi atau tim mungkin telah menyetujui strategi untuk lebih memilih teknologi tertentu daripada teknologi lain. Misalnya, jika tim memiliki perjanjian untuk menstandardisasikan jika memungkinkan, baik tanpa server maupun Kubernetes, perjanjian 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 peringatan yang menyertainya:

  • Merancang ulang beban kerja. Namun, jika beban kerja tidak cocok, tindakan ini dapat menyebabkan performa, biaya, keamanan, atau karakteristik lainnya yang tidak optimal.
  • Daftarkan beban kerja sebagai pengecualian terhadap tujuan strategis. Namun, jika pengecualian digunakan secara berlebihan, melakukan hal tersebut dapat menghasilkan portofolio teknologi yang berbeda.
  • Pertimbangkan kembali strategi. Namun, tindakan tersebut dapat mengakibatkan overhead kebijakan yang dapat menghalangi atau memblokir progres.

Memanfaatkan ekosistem Kubernetes

Sebagai bagian dari strategi teknis luas yang dijelaskan sebelumnya, organisasi atau tim mungkin memutuskan untuk memilih Kubernetes sebagai platform pilihan mereka karena ekosistem yang signifikan dan 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 mengutamakan komunitas yang aktif, alat pihak ketiga yang lengkap, serta standar dan portabilitas yang kuat. Memanfaatkan ekosistem Kubernetes dapat mempercepat kecepatan pengembangan dan mengurangi waktu penyiapan produk.

Alat internal yang sudah ada

Dalam beberapa kasus, Anda dapat menggunakan ekosistem alat yang ada di organisasi atau tim Anda (untuk lingkungan mana pun) dapat menguntungkan. Misalnya, jika 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 yang lama untuk diterapkan ke lingkungan target alternatif.

Profil tim pengembangan

Tim aplikasi atau workload mungkin memiliki pengalaman sebelumnya dengan Kubernetes yang dapat mempercepat kecepatan dan kemampuan tim untuk menjalankan Autopilot. Tim memerlukan waktu untuk menjadi ahli dengan lingkungan runtime baru. Bergantung pada model operasi, hal tersebut 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 diperlukan perekrutan premium. 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 tim SRE, DevOps, dan 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 pusat atau engineering platform dapat menangani Upgrade Kubernetes Autopilot. Meskipun upgrade dilakukan secara otomatis, staf operasional biasanya akan memantaunya dengan cermat untuk meminimalkan gangguan pada workload Anda. Beberapa organisasi memilih untuk mengupgrade versi bidang kontrol secara manual. GKE Enterprise juga mencakup kemampuan untuk menyederhanakan dan menyederhanakan pengelolaan aplikasi di berbagai cluster.

Berbeda dengan Autopilot, Cloud Run tidak memerlukan overhead pengelolaan yang sedang berlangsung 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 kepentingan untuk mendukung lingkungan runtime tersebut.

Pilihan

Untuk memulai proses seleksi, bicarakan dengan berbagai pemangku kepentingan. Untuk setiap aplikasi, kumpulkan kelompok kerja yang terdiri dari developer, staf operasional, perwakilan grup tata kelola teknologi pusat, konsumen dan pengguna 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 untuk menggabungkan karakteristik aplikasi, dan membagikan hasilnya sebelum sesi. Sebaiknya pilih grup kerja kecil yang hanya mencakup pemangku kepentingan yang diperlukan. Mungkin tidak semua perwakilan diwajibkan untuk setiap sesi kerja.

Ada baiknya Anda juga menyertakan perwakilan dari tim atau grup lain yang memiliki pengalaman dalam membangun dan menjalankan aplikasi dengan Autopilot atau Cloud Run, atau keduanya. Gunakan pertimbangan teknis dan organisasi 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 men-deploy aplikasi Anda di lingkungan baru.

Langkah berikutnya

Kontributor

Penulis: Henry Bell | Cloud Solutions Architect

Kontributor lainnya: