Dokumen ini membahas keterbatasan umum aplikasi monolitik dan menjelaskan proses yang bertahap dan terstruktur untuk memodernisasinya.
Dokumen ini ditujukan untuk arsitek cloud, administrator sistem, dan CTO yang tidak asing dengan Windows dan ekosistem .NET, serta ingin lebih lanjut mempelajari apa saja yang tercakup ke dalam modernisasi. Meskipun dokumen ini berfokus pada aplikasi server yang dibuat khusus (seperti aplikasi ASP.NET atau Windows Services), Anda dapat menerapkan pelajaran ini ke kasus penggunaan lainnya.
Aplikasi lama versus aplikasi modern: Mengapa harus melakukan modernisasi?
Memodernisasi aplikasi lama adalah sebuah perjalanan. Tempat Anda memulai dan mengakhiri perjalanan tersebut, serta manfaat yang Anda peroleh, sebagian besar bergantung pada status aplikasi Anda serta waktu dan upaya yang dapat Anda investasikan untuk memodernisasi.
Dalam konteks aplikasi .NET, apa yang dimaksud dengan lama dan apa yang dimaksud dengan modern? Setiap aplikasi memiliki kebutuhan modernisasi dan sistem lama yang berbeda. Namun, aplikasi lama memiliki beberapa batasan umum.
Diagram berikut merangkum karakteristik aplikasi lama dan aplikasi berbasis cloud modern.
Aplikasi .NET lama biasanya berupa monolit yang dibangun di .NET Framework, dihosting di server Microsoft Windows lokal, dan terhubung ke server lokal yang menjalankan Microsoft SQL Server. Detail arsitektur Anda mungkin berbeda dari karakteristik umum ini, tetapi sebagian besar aplikasi monolitik memiliki batasan berikut:
- Kebutuhan untuk mengelola server lokal yang menjalankan Windows dan SQL Server.
- Lingkungan deployment terbatas dan biaya lisensi yang terkait dengan ketergantungan pada Windows.
- Kesulitan mengupgrade aplikasi lama yang dibangun di arsitektur monolitik.
- Kurang fleksibel dalam merencanakan, menganggarkan, dan menskalakan dengan resource lokal.
Aplikasi yang dibangun untuk arsitektur berbasis cloud menawarkan beberapa manfaat:
- Overhead pengelolaan minimal dengan mengintegrasikan layanan terkelola.
- Mobilitas penuh dengan .NET dan container serta tanpa dependensi Windows atau biaya lisensi.
- Jalur upgrade berkecepatan tinggi berdasarkan microservice yang dapat di-deploy secara independen.
- Kelincahan penuh untuk menskalakan dan menganggarkan dengan arsitektur serverless.
Dibandingkan dengan pendekatan lokal konvensional, arsitektur cloud menawarkan cara yang lebih hemat biaya, efisien, dan tangguh untuk menjalankan aplikasi Anda. Dengan pendekatan berbasis cloud, Anda memiliki lebih banyak fleksibilitas untuk memilih tempat dan waktu men-deploy aplikasi.
Jalur modernisasi
Meskipun manfaat arsitektur berbasis cloud sudah jelas, jalur menuju cloud mungkin tidak demikian. Modernisasi dari arsitektur .NET lama ke arsitektur berbasis cloud tidak mengikuti satu pola yang cocok untuk semua. Seperti yang ditunjukkan pada diagram berikut, modernisasi melibatkan serangkaian langkah, di mana setiap langkah menghilangkan batasan, meningkatkan kemampuan aplikasi, dan membuka peluang untuk fase modernisasi selanjutnya.
Langkah-langkah modernisasi dikelompokkan menjadi tiga fase:
- Menghosting ulang di cloud (juga dikenal sebagai lift and shift)
- Memindahkan platform
- Merancang ulang dan membangun ulang
Penilaian dan pembelajaran pra-modernisasi
Sebelum melakukan modernisasi, Anda harus bersiap. Langkah pertama adalah menilai aplikasi dan dependensinya untuk menentukan aplikasi mana yang cocok untuk dimodernisasi dan aplikasi mana yang tidak dapat diubah atau dipindahkan (biasanya karena alasan terkait sistem lama atau peraturan). Untuk mengetahui informasi selengkapnya, lihat Migrasi ke Google Cloud: Menilai dan menemukan workload Anda.
Secara paralel dengan penilaian ini, tim Anda perlu mempelajari kemampuan cloud. Google Cloud menawarkan sertifikasi, panduan teknis, dan codelab khusus Windows dan .NET yang dapat membantu mempercepat proses pembelajaran.
Setelah mengidentifikasi aplikasi yang akan dimodernisasi, Anda dapat mulai memigrasikan aplikasi konvensional ke cloud apa adanya atau dengan perubahan minimal pada kode atau konfigurasi aplikasi.
Tahap 1: Meng-rehost di cloud
Tujuan utama fase pertama ini adalah memindahkan beban pengelolaan server dari resource lokal Anda ke infrastruktur cloud. Pada fase ini, Anda memastikan bahwa infrastruktur Anda siap untuk cloud sehingga Anda dapat mengoptimalkannya untuk cloud pada fase berikutnya.
Migrasi manual versus migrasi berbasis alat
Migrasi lift and shift aplikasi .NET berbasis Windows biasanya dimulai dengan memindahkan instance Windows Server dan SQL Server lokal ke instance virtual machine (VM) Compute Engine. Anda dapat melakukan proses ini secara manual atau mengotomatiskannya dengan bantuan alat migrasi.
Dalam migrasi manual, Anda dapat menggunakan image Windows Server Compute Engine untuk memulai instance. Google Cloud Marketplace juga memiliki solusi yang siap di-deploy ke Compute Engine, seperti solusi ASP.NET Framework untuk mendapatkan VM Windows Server yang mencakup IIS, SQL Express, dan ASP.NET.
Demikian pula, Anda dapat memulai instance SQL Server dari image SQL Server, atau Anda dapat langsung menggunakan solusi yang lebih terkelola—Cloud SQL untuk SQL Server.
Google Cloud juga menawarkan alat migrasi seperti Migrate to Virtual Machines atau VMware Engine untuk membantu Anda memindahkan VM VMware lokal ke lingkungan VMware di Google Cloud.
Setelah mengonfigurasi VM, Anda biasanya membuat image VM kustom sehingga dapat membuat ulang instance baru sesuai permintaan. Langkah ini juga penting untuk template instance, yang dibahas nanti dalam dokumen ini.
Jika Anda memerlukan layanan domain di cloud, Anda dapat men-deploy Lingkungan Microsoft Active Directory yang toleran terhadap kesalahan di Compute Engine dengan Virtual Private Cloud (VPC) atau langsung membuka Managed Service for Microsoft Active Directory.
Konektivitas lokal dan cloud
Saat memigrasikan VM ke cloud, terkadang Anda menyimpan beberapa beban kerja secara lokal. Misalnya, saat Anda memiliki aplikasi yang memerlukan hardware atau software lama, atau saat Anda perlu memenuhi kepatuhan dan persyaratan peraturan lokal. Anda memerlukan solusi VPN atau Interconnect untuk menghubungkan resource lokal dan cloud secara aman. Untuk mengetahui berbagai cara membuat dan mengelola koneksi ini, serta implikasi lain dari menjalankan workload hybrid cloud dan lokal, lihat Migrasi ke Google Cloud: Membangun fondasi Anda.
Manfaat awal
Di akhir Fase 1, Anda akan memiliki infrastruktur dasar yang berjalan di cloud, yang memberikan manfaat seperti berikut:
- Pengoptimalan biaya. Anda dapat membuat jenis mesin kustom (CPU, memori, dan penyimpanan) dan membayar sesuai penggunaan; memulai dan menghentikan VM serta lingkungan pemulihan bencana sesuai keinginan dan hanya membayar saat VM berjalan; serta mendapatkan rekomendasi penyesuaian ukuran sebelum migrasi.
- Peningkatan efisiensi operasional. Anda dapat melampirkan persistent disk ke VM dan membuat snapshot untuk menyederhanakan pencadangan dan pemulihan.
- Keandalan yang lebih baik. Anda tidak perlu lagi menjadwalkan periode pemeliharaan karena fitur migrasi langsung.
Manfaat awal ini berguna, tetapi manfaat lainnya akan didapatkan saat Anda mulai mengoptimalkan cloud.
Fase 2: Berpindah platform
Saat melakukan replatform, Anda mengoptimalkan aplikasi dengan mengupgrade bagian komponen aplikasi, seperti database, lapisan caching, atau sistem penyimpanan, tanpa mengubah arsitektur aplikasi dan dengan perubahan minimal pada codebase. Tujuan Fase 2 adalah mulai menggunakan fitur cloud untuk pengelolaan, ketahanan, skalabilitas, dan elastisitas aplikasi yang lebih baik tanpa merestrukturisasi secara signifikan atau keluar dari lingkungan VM.
Manfaatkan Compute Engine
Compute Engine menyediakan beberapa fitur standar yang berguna untuk dipelajari. Misalnya, Anda dapat menggunakan template instance di Compute Engine untuk membuat template dari konfigurasi VM yang ada. Grup instance adalah sekumpulan VM identik yang memungkinkan Anda menskalakan performa dan redundansi aplikasi secara efisien. Selain load balancing dan redundansi, grup instance terkelola memiliki fitur skalabilitas seperti penskalaan otomatis, fitur ketersediaan tinggi seperti autohealing, deployment regional, dan fitur keamanan seperti update otomatis.
Dengan fitur ini, Anda dapat tetap berada di dunia VM, tetapi meningkatkan ketahanan, redundansi, dan ketersediaan aplikasi tanpa perlu menyusun ulang aplikasi sepenuhnya.
Mencari penggantian di tempat
Saat memindahkan aplikasi ke cloud, Anda perlu mencari peluang untuk mengganti infrastruktur yang dihosting dengan opsi cloud terkelola dari Google dan partner pihak ketiga di Cloud Marketplace, termasuk:
- Cloud SQL daripada SQL Server, MySQL, atau Postgres yang dihosting sendiri. Cloud SQL memungkinkan Anda berfokus pada pengelolaan database, bukan pengelolaan infrastruktur (seperti melakukan patching pada VM database untuk keamanan atau mengelola cadangan) dengan manfaat tambahan berupa penghapusan persyaratan lisensi Windows.
- Managed Service for Microsoft Active Directory daripada Active Directory yang dihosting sendiri.
- Memorystore daripada instance Redis yang dihosting sendiri.
Penggantian ini tidak memerlukan perubahan kode dan hanya memerlukan perubahan konfigurasi minimal, serta memiliki keuntungan berupa pengelolaan minimal, keamanan yang ditingkatkan, dan skalabilitas.
Langkah-langkah awal menggunakan container Windows
Setelah mengoptimalkan fungsi dasar untuk cloud, Anda dapat mulai beralih dari VM ke container.
Container adalah paket ringan yang berisi aplikasi dan semua dependensinya. Dibandingkan dengan menjalankan aplikasi Anda secara langsung di VM, container memungkinkan Anda menjalankan aplikasi di berbagai lingkungan dan dengan cara yang lebih konsisten, dapat diprediksi, dan efisien (terutama saat Anda menjalankan beberapa container di host yang sama). Ekosistem di sekitar container (seperti Kubernetes, Istio, dan Knative) juga menyediakan sejumlah fitur pengelolaan, ketahanan, dan pemantauan yang dapat lebih mempercepat transformasi aplikasi Anda dari satu monolit menjadi serangkaian microservice yang terfokus.
Selama beberapa waktu, containerisasi adalah fitur khusus Linux. Aplikasi Windows tidak dapat memanfaatkan container. Hal itu berubah dengan adanya container Windows dan dukungan berikutnya di Kubernetes dan Google Kubernetes Engine (GKE).
Container Windows adalah opsi jika Anda tidak ingin memigrasikan aplikasi .NET Framework ke .NET, tetapi tetap menginginkan manfaat container (seperti ketangkasan, portabilitas, dan kontrol). Anda perlu memilih OS yang tepat untuk ditargetkan bergantung pada versi .NET Framework, dan Anda perlu mengingat bahwa tidak semua stack Windows didukung di container Windows. Untuk mengetahui batasan pendekatan ini dan alternatifnya, lihat Kontainer.NET dan Linux di bagian selanjutnya dalam dokumen ini.
Setelah Anda membuat aplikasi .NET Framework ke dalam container Windows, sebaiknya Anda menjalankannya di cluster Kubernetes. Kubernetes menyediakan fitur standar seperti mendeteksi saat Pod container tidak berfungsi dan membuat ulang Pod, penskalaan otomatis Pod, peluncuran atau rollback otomatis, dan pemeriksaan kondisi. GKE menambahkan fitur seperti penskalaan otomatis cluster, cluster regional, bidang kontrol yang sangat tersedia, serta dukungan multi-cloud dan hybrid dengan GKE Enterprise. Jika memutuskan untuk menggunakan GKE atau GKE Enterprise, Anda dapat menggunakan Migrate to Containers untuk menyederhanakan dan mempercepat migrasi VM Windows ke container. Migrate to Containers mengotomatiskan ekstraksi aplikasi dari VM ke dalam container tanpa mengharuskan Anda menulis ulang atau merancang ulang aplikasi.
Meskipun Anda dapat memperoleh banyak manfaat dengan menggunakan fitur yang tepat di Compute Engine, beralih ke container dan GKE akan membantu Anda menggunakan VM sepenuhnya dengan mengemas beberapa Pod ke VM yang sama. Strategi ini berpotensi menghasilkan lebih sedikit VM dan biaya lisensi Windows yang lebih rendah.
Mengelola container Windows dan Linux secara deklaratif dengan Kubernetes dan GKE juga dapat menyederhanakan pengelolaan infrastruktur Anda. Dengan adanya containerisasi, tim Anda siap untuk fase modernisasi berikutnya.
Tahap 3: Merancang ulang dan membangun ulang
Replatforming hanyalah permulaan untuk mendapatkan manfaat penuh dari cloud. Mengubah arsitektur Anda ke platform berbasis cloud menawarkan beberapa keuntungan, seperti berikut:
- Meningkatkan pengoptimalan biaya dengan menggunakan container Kubernetes dan Linux, bukan container Windows, serta memindahkan workload untuk dijalankan di serverless computing.
- Meningkatkan keandalan dan ketersediaan dengan mengganti VM yang dikelola sendiri dengan layanan terkelola yang menyediakan ketersediaan multi-regional, perjanjian tingkat layanan (SLA) yang lebih kuat, dan keamanan yang lebih baik.
- Mempercepat pengiriman produk dengan meningkatkan produktivitas developer dan kualitas software menggunakan alat integrasi berkelanjutan. Anda dapat menggunakan alat ini untuk membuat build otomatis, menjalankan pengujian, menyediakan lingkungan, dan memindai artefak untuk mendeteksi kerentanan keamanan—semuanya dalam beberapa menit.
- Kemampuan untuk mengatasi masalah pemblokiran aplikasi Anda dengan pergudangan data berskala petabyte, database yang dapat diskalakan secara global untuk konsistensi yang kuat, dan solusi penyimpanan multiregional dan dengan ketersediaan tinggi.
Perpindahan ke layanan terkelola
Saat Anda mulai menulis ulang bagian aplikasi, sebaiknya Anda mulai beralih dari layanan yang di-hosting ke layanan terkelola. Misalnya, Anda dapat menggunakan hal berikut:
- Cloud Storage daripada mengandalkan network attached storage (NAS).
- Pub/Sub alih-alih menghosting sendiri MSMQ, RabbitMQ, atau Kafka.
- Identity-Aware Proxy (IAP) daripada mengodekan lapisan autentikasi ke dalam aplikasi Anda.
- Cloud Key Management Service (Cloud KMS) dan Secret Manager daripada menyimpan rahasia dan kunci enkripsi Anda secara lokal dengan aplikasi Anda.
Meskipun Anda memerlukan kode tambahan untuk mengintegrasikan aplikasi dengan layanan ini, hal ini merupakan investasi yang berharga, karena Anda mengalihkan beban pengelolaan platform ke Google Cloud. Google Cloud Library klien.NET, Tools for Visual Studio, dan Cloud Code untuk Visual Studio Code dapat membantu Anda tetap berada dalam ekosistem dan alat .NET saat berintegrasi dengan layanan ini.
Layanan terkelola juga dapat mendukung operasi untuk aplikasi Anda. Anda dapat menyimpan log aplikasi di Cloud Logging dan mengirim metrik aplikasi ke Cloud Monitoring, tempat Anda dapat membuat dasbor dengan metrik server dan aplikasi. Google Cloud menawarkan library klien .NET untuk Cloud Logging, Cloud Monitoring, dan Cloud Trace.
.NET dan container Linux
Jika aplikasi Anda adalah aplikasi .NET Framework lama yang hanya berjalan di Windows, Anda mungkin tergoda untuk terus menjalankannya di server Windows di Compute Engine atau di container Windows Server di GKE. Meskipun pendekatan ini mungkin berhasil dalam jangka pendek, pendekatan ini dapat sangat membatasi Anda dalam jangka panjang. Windows dilengkapi dengan biaya lisensi dan footprint resource yang lebih besar secara keseluruhan daripada Linux, dan faktor-faktor ini dapat mengakibatkan biaya kepemilikan yang lebih tinggi dalam jangka panjang.
.NET adalah versi modern dan modular dari .NET Framework. Meskipun Microsoft berencana mendukung .NET Framework, semua fitur baru hanya akan ditambahkan ke .NET (dan akhirnya .NET 5). Meskipun Anda masih ingin menjalankan di Windows, pengembangan baru harus dilakukan di .NET.
Salah satu aspek terpenting .NET adalah bahwa .NET bersifat multiplatform. Anda dapat mengemas aplikasi .NET ke dalam container Linux. Container Linux lebih ringan daripada container Windows, dan berjalan di lebih banyak platform secara lebih efisien. Faktor ini menciptakan opsi deployment untuk aplikasi .NET dan memungkinkan Anda terbebas dari ketergantungan pada Windows dan biaya lisensi yang terkait dengannya.
Meng-porting aplikasi .NET Framework ke .NET
Cara yang tepat untuk mulai beralih ke .NET adalah dengan membaca Ringkasan porting dari .NET Framework ke .NET. Alat seperti .NET Portability Analyzer dan .NET API Analyzer dapat membantu Anda menentukan apakah assembly dan API dapat di-porting. Alat porting lainnya seperti dotnet try-convert dapat membantu.
Alat eksternal dapat membantu Anda mengidentifikasi masalah kompatibilitas dan memutuskan komponen mana yang akan dimigrasikan terlebih dahulu. Pada akhirnya, Anda perlu membuat project .NET, memindahkan kode .NET Framework secara bertahap ke project baru, dan memperbaiki ketidakcocokan yang terjadi selama proses tersebut. Sebelum memindahkan kode, Anda harus membuat pengujian dan menguji fungsionalitas setelah memindahkan kode. Sebaiknya gunakan pengujian A/B untuk menguji kode lama dan baru. Dengan pengujian A/B, Anda dapat terus menjalankan aplikasi lama sambil mengarahkan sebagian pengguna ke aplikasi baru. Dengan pendekatan ini, Anda dapat menguji output, skalabilitas, dan ketahanan aplikasi baru. Untuk membantu pengujian A/B, Google Cloud menawarkan solusi load balancing seperti Cloud Service Mesh.
Transformasi Budaya
Transformasi dari .NET Framework dan server Windows ke .NET dan penampung Linux bukan hanya sekadar teknis. Perubahan ini memerlukan transformasi budaya dalam organisasi Anda. Staf yang mungkin terbiasa dengan lingkungan khusus Windows perlu beradaptasi dengan lingkungan multiplatform. Transformasi budaya ini memerlukan waktu dan anggaran untuk pelatihan alat .NET, Linux, dan container seperti Docker dan Kubernetes. Namun, transformasi dari organisasi yang hanya menggunakan Windows menjadi organisasi multi-platform memungkinkan Anda mengakses serangkaian alat dan keterampilan yang lebih besar.
Dekomposisi monolit
Perpindahan dari .NET Framework ke .NET dapat menimbulkan beberapa pertanyaan, termasuk berikut ini:
- Apakah Anda menulis ulang seluruh aplikasi di .NET?
- Apakah Anda memecah aplikasi menjadi layanan yang lebih kecil dan menuliskannya di .NET?
- Apakah Anda hanya menulis layanan baru di .NET?
Cara Anda memutuskan pertanyaan ini harus memperhitungkan manfaat, waktu, dan biaya yang terkait dengan setiap pendekatan. Sebaiknya gunakan pendekatan yang seimbang agar Anda tidak menulis ulang semuanya sekaligus. Sebagai gantinya, Anda dapat menulis layanan baru. NET dan memecah monolit yang ada menjadi layanan yang lebih kecil di .NET saat peluang muncul. Dokumen teknis berikut dapat membantu Anda saat membuat rencana:
Opsi deployment untuk container .NET
Seperti yang dinyatakan dalam Men-deploy aplikasi .NET di Google Cloud, Anda memiliki berbagai opsi untuk men-deploy container .NET di Google Cloud. Saat mendekonstruksi aplikasi monolitik menjadi microservice, Anda dapat memutuskan untuk menggunakan lebih dari satu solusi hosting, bergantung pada arsitektur dan desain microservice Anda.
Menjawab pertanyaan berikut dapat membantu Anda memutuskan strategi hosting terbaik:
- Apa yang memicu aplikasi Anda? Semua solusi hosting cocok untuk HTTP(S) standar, tetapi jika protokol Anda adalah TCP/UDP atau protokol eksklusif, GKE mungkin menjadi satu-satunya opsi Anda.
- Apakah aplikasi Anda memerlukan hardware tertentu? Cloud Run menawarkan RAM dan CPU dalam jumlah yang wajar, tetapi terbatas untuk setiap permintaan. Layanan Knative menawarkan opsi penyesuaian lebih lanjut seperti GPU, lebih banyak memori, dan ruang disk.
- Apa ekspektasi Anda terkait penskalaan? Jika aplikasi Anda memiliki periode tidak aktif, solusi serverless seperti Cloud Run dapat menawarkan opsi untuk menskalakan ke nol.
- Seberapa penting latensi dan seberapa toleran aplikasi Anda terhadap cold start? Jika toleransi terhadap cold start rendah, Anda perlu mempertimbangkan untuk menggunakan jumlah minimum instance di Cloud Run atau GKE dengan penskalaan otomatis.
Sebaiknya Anda membaca dokumentasi untuk setiap lingkungan hosting agar memahami kemampuan, kelebihan dan kekurangan, serta model harganya.
Sebagai aturan umum, jika Anda ingin membuat mikroservice yang melayani permintaan HTTP, Anda harus men-deploy ke Cloud Run jika memungkinkan dan melakukan penggantian ke GKE jika ingin tetap berada di ekosistem Kubernetes atau memerlukan lebih banyak opsi penyesuaian. GKE juga merupakan pilihan default jika Anda memiliki proses yang berjalan lama, seperti proses yang memantau antrean, atau aplikasi yang menggunakan protokol selain HTTP(S).
Cloud Run Functions juga merupakan opsi deployment serverless yang baik, tetapi tidak dibahas di sini, karena Cloud Run menyediakan sebagian besar fitur yang disediakan oleh Cloud Run Functions, dan Cloud Run Functions tidak mendukung .NET versi terbaru.
Kubernetes dan GKE
Jika Anda ingin menjalankan di lingkungan yang dioptimalkan untuk container, pendekatan tersebut kemungkinan melibatkan Kubernetes dan versi terkelolanya, GKE. Kubernetes dan GKE sangat cocok jika Anda berencana men-deploy banyak container dengan persyaratan yang berbeda dan menginginkan kontrol terperinci tentang cara setiap container di-deploy dan dikelola.
Kubernetes dirancang untuk menjalankan container dalam skala besar dan menyediakan blok penyusun seperti Pod, Layanan, Deployment, dan set replika. Memahami dan menggunakan konstruksi ini dengan benar bisa jadi sulit, tetapi konstruksi ini memungkinkan Anda mengalihkan sebagian besar beban pengelolaan container ke Kubernetes. Deployment juga cocok untuk arsitektur microservice, di mana microservice adalah Deployment dengan sekumpulan Pod yang di-load balance di belakang Layanan.
Selain Kubernetes, GKE menawarkan fitur seperti penskalaan otomatis cluster, perbaikan otomatis, dan upgrade otomatis untuk menyederhanakan pengelolaan Kubernetes, serta fitur keamanan seperti isolasi container dan registry pribadi. Meskipun Anda ditagih untuk setiap node dalam cluster di GKE, GKE mendukung VM yang dapat di-preempt untuk mengurangi biaya.
GKE dapat mengelola container Windows dan Linux. Kemampuan ini berguna jika Anda ingin mempertahankan satu lingkungan hybrid untuk aplikasi berbasis Windows dan berbasis Linux modern.
Knative dan Cloud Run
Untuk container .NET stateless Anda, Knative dan versi terkelolanya, Cloud Run, menyediakan lingkungan container serverless. Container serverless menawarkan manfaat seperti penyediaan, penskalaan otomatis, dan load balancing tanpa overhead pengelolaan infrastruktur.
Untuk men-deploy container di cluster Kubernetes, Knative menyediakan permukaan API yang lebih tinggi dan lebih kecil daripada Kubernetes. Dengan demikian, Knative dapat membantu Anda menghindari kompleksitas Kubernetes, sehingga memudahkan deployment container Anda.
Cloud Run mengikuti Knative API, tetapi berjalan di infrastruktur Google, sehingga tidak memerlukan cluster Kubernetes. Cloud Run menyediakan opsi serverless untuk container. Secara default, container di Cloud Run diskalakan otomatis dan ditagih selama durasi permintaan. Waktu deployment dalam detik. Cloud Run juga menyediakan fitur yang berguna, seperti revisi dan pemisahan traffic.
Layanan Knative adalah versi Cloud Run yang lebih fleksibel yang menawarkan kesederhanaan Knative dan Cloud Run dengan fleksibilitas operasional Kubernetes. Misalnya, Cloud Run di GKE Enterprise memungkinkan Anda menambahkan GPU ke instance pokok yang menjalankan container atau menskalakan aplikasi Anda ke banyak container.
Cloud Run terintegrasi dengan layanan lain seperti Pub/Sub, Cloud Scheduler, Cloud Tasks, dan backend seperti Cloud SQL. Layanan ini dapat digunakan untuk frontend web yang diskalakan otomatis atau mikroservice internal yang dipicu oleh peristiwa.
Modernisasi operasi
Modernisasi tidak hanya terkait dengan kode aplikasi Anda. Hal ini berlaku untuk seluruh siklus proses aplikasi Anda—cara aplikasi dibangun, diuji, di-deploy, dan dipantau. Oleh karena itu, saat memikirkan modernisasi, Anda perlu mempertimbangkan operasi.
Cloud Build dapat membantu Anda memodernisasi dan mengotomatiskan siklus build-test-deploy aplikasi. Selain menyediakan builder untuk .NET, Cloud Build juga terintegrasi dengan Pemindai Kerentanan Container Registry dan Otorisasi Biner untuk mencegah image yang dibuat dari kode sumber yang tidak diketahui atau repositori yang tidak aman berjalan di lingkungan deployment Anda.
Google Cloud Observability (sebelumnya bernama Stackdriver) menawarkan beberapa layanan yang memungkinkan Anda memodernisasi kemampuan pengamatan aplikasi:
- Cloud Logging untuk log aplikasi dan sistem
- Cloud Monitoring untuk pemantauan performa
- Cloud Trace untuk pengelolaan performa aplikasi
Anda dapat menggunakan library Google.Cloud.Diagnostics.AspNetCore untuk mengekspor log, metrik, dan rekaman aktivitas ke Google Cloud untuk aplikasi ASP.NET Anda. Untuk mengekspor metrik OpenTelemetry ke Google Cloud, Anda dapat menggunakan library OpenTelemetry.Exporter.Stackdriver.
Untuk mengetahui informasi selengkapnya tentang cara modernisasi diterapkan pada proses dan budaya tim, lihat Google Cloud solusi untuk DevOps.
Langkah berikutnya
- Pelajari cara Men-deploy aplikasi .NET di Google Cloud.
- Baca selengkapnya tentang .NET di Google Cloud.
- Coba codelab Windows dan .NET.
- Baca selengkapnya tentang container Windows Server di GKE.
- Baca selengkapnya tentang Knative dan Cloud Run.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.