Jalur modernisasi untuk aplikasi .NET Framework di Google Cloud

Last reviewed 2023-07-13 UTC

Dokumen ini membahas batasan umum aplikasi monolitik dan menjelaskan proses modernisasi secara bertahap namun terstruktur.

Dokumen ini ditujukan untuk arsitek cloud, administrator sistem, dan CTO yang sudah memahami Windows dan ekosistem .NET serta ingin mempelajari lebih lanjut hal yang terlibat 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 memodernisasi?

Memodernisasi aplikasi lama adalah sebuah perjalanan. Tempat Anda memulai dan mengakhiri perjalanan tersebut, serta manfaat yang Anda peroleh, sangat bergantung pada status aplikasi serta waktu dan upaya yang dapat Anda investasikan untuk memodernisasinya.

Dalam konteks aplikasi .NET Framework, konsep lama dan modern bukanlah hal yang pasti. Setiap aplikasi memiliki kebutuhan lama dan modernisasi yang berbeda. Namun, aplikasi lama memiliki beberapa batasan umum.

Diagram berikut merangkum karakteristik aplikasi lama dan aplikasi modern berbasis cloud.

Perbedaan antara aplikasi monolitik dan berbasis cloud modern.

Aplikasi .NET Framework 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 mungkin berbeda dari karakteristik umum ini, tetapi sebagian besar aplikasi monolitik memiliki batasan berikut:

  • Kebutuhan untuk mengelola server lokal yang menjalankan Windows dan Server SQL.
  • Lingkungan deployment yang terbatas dan biaya lisensi yang terkait dengan dependensi pada Windows.
  • Kesulitan melakukan upgrade aplikasi lama yang dibangun di arsitektur monolitik.
  • Sedikit ketangkasan untuk melakukan perencanaan, anggaran, dan penskalaan dengan resource lokal.

Aplikasi yang dibangun untuk arsitektur berbasis cloud menawarkan beberapa manfaat:

  • Biaya pengelolaan minimal melalui integrasi dengan layanan terkelola.
  • Mobilitas penuh dengan .NET dan container tanpa dependensi Windows, atau biaya lisensi.
  • Jalur upgrade berkecepatan tinggi berdasarkan microservice yang dapat di-deploy secara independen.
  • Fleksibilitas penuh untuk melakukan penskalaan dan menentukan anggaran dengan arsitektur serverless.

Dibandingkan dengan pendekatan lokal konvensional, arsitektur cloud menawarkan cara yang lebih hemat biaya, efisien, dan tangguh untuk menjalankan aplikasi Anda. Dalam pendekatan berbasis cloud, Anda memiliki lebih banyak fleksibilitas untuk memilih lokasi dan waktu untuk men-deploy aplikasi.

Jalur modernisasi

Meskipun manfaat arsitektur berbasis cloud sudah jelas, jalur ke cloud mungkin tidak jelas. Modernisasi dari arsitektur .NET Framework lama ke arsitektur berbasis cloud tidak mengikuti pola tunggal satu ukuran untuk semua. Seperti yang ditunjukkan diagram berikut, modernisasi melibatkan serangkaian langkah, dengan setiap langkah menghilangkan batasan, meningkatkan kemampuan aplikasi, dan membuka peluang untuk fase modernisasi berikutnya.

Proses, teknologi, dan layanan yang terlibat dalam proses modernisasi.

Langkah-langkah modernisasi dikelompokkan menjadi tiga fase:

  1. Hosting ulang di cloud (juga dikenal sebagai lift-and-shift)
  2. Memindahkan platform
  3. Merancang ulang dan membangun ulang

Penilaian dan pembelajaran pramodernisasi

Sebelum melakukan modernisasi, Anda harus mempersiapkan diri. Langkah pertama adalah menilai aplikasi Anda dan dependensinya untuk menentukan aplikasi mana yang sesuai untuk dimodernisasi dan mana yang tidak dapat diubah atau dipindahkan (biasanya karena alasan terkait lama atau peraturan). Untuk mengetahui informasi selengkapnya, lihat Migrasi ke Google Cloud: Menilai dan menemukan workload Anda.

Sejalan dengan penilaian ini, tim Anda perlu mempelajari kemampuan cloud. Google Cloud menawarkan sertifikasi, panduan teknis, serta 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 sedikit perubahan pada kode atau konfigurasi aplikasi.

Tahap 1: Hosting ulang di cloud

Tujuan utama tahap pertama ini adalah mentransfer beban pengelolaan server dari resource lokal ke infrastruktur cloud. Pada fase ini, Anda memastikan infrastruktur Anda siap digunakan dengan cloud sehingga Anda dapat mengoptimalkannya untuk cloud di fase berikutnya.

Migrasi manual versus migrasi berbasis alat

Operasi lift-and-shift aplikasi .NET Framework berbasis Windows biasanya dimulai dengan memindahkan instance Windows Server dan SQL Server lokal ke instance virtual machine (VM) Compute Engine. Anda dapat menjalankan 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 menyertakan IIS, SQL Express, dan ASP.NET.

Demikian pula, Anda dapat memulai instance SQL Server dari image SQL Server, atau langsung membuka 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 agar dapat membuat ulang instance baru sesuai permintaan. Langkah ini juga penting untuk template instance, yang akan dibahas nanti dalam dokumen ini.

Jika memerlukan layanan domain di cloud, Anda dapat men-deploy lingkungan Microsoft Active Directory Fault-tolerant di Compute Engine dengan Virtual Private Cloud (VPC) atau langsung membuka Layanan Terkelola untuk 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 VPN atau solusi interkoneksi untuk menghubungkan resource lokal dan cloud dengan aman. Untuk mengetahui berbagai cara dalam membuat dan mengelola koneksi ini, serta implikasi lain saat menjalankan workload hybrid cloud dan lokal, lihat Migrasi ke Google Cloud: Membangun fondasi.

Manfaat awal

Pada akhir Tahap 1, Anda memiliki infrastruktur dasar yang berjalan di cloud, yang memberikan manfaat sebagai berikut:

  • Pengoptimalan biaya. Anda dapat membuat jenis mesin kustom (CPU, memori, dan penyimpanan) dan membayar sesuai yang Anda gunakan; memulai dan menghentikan VM serta lingkungan pemulihan dari bencana sesuai keinginan dan hanya membayar saat berjalan; serta mendapatkan rekomendasi penyesuaian sebelum migrasi.
  • Peningkatan efisiensi operasional. Anda dapat memasang persistent disk ke VM dan membuat snapshot untuk pencadangan dan pemulihan yang disederhanakan.
  • Keandalan yang ditingkatkan. Anda tidak perlu lagi menjadwalkan masa pemeliharaan karena fitur migrasi langsung.

Manfaat awal ini berguna, tetapi lebih banyak manfaat yang akan didapatkan saat Anda mulai melakukan pengoptimalan untuk cloud.

Fase 2: Berpindah platform

Saat melakukan replatform, Anda mengoptimalkan aplikasi dengan mengupgrade bagian-bagian komponen aplikasi—seperti database, lapisan cache, atau sistem penyimpanannya—tanpa mengubah arsitektur aplikasi dan dengan perubahan minimal pada codebase. Tujuan Tahap 2 adalah mulai menggunakan fitur cloud untuk mendapatkan pengelolaan, ketahanan, skalabilitas, dan elastisitas aplikasi yang lebih baik tanpa merestrukturisasi aplikasi secara signifikan atau meninggalkan lingkungan VM.

Memanfaatkan Compute Engine

Compute Engine menyediakan beberapa fitur standar yang berguna untuk dijelajahi. Misalnya, Anda dapat menggunakan template instance di Compute Engine untuk membuat template dari konfigurasi VM yang ada. Grup instance adalah fleet VM identik yang memungkinkan Anda menskalakan redundansi dan performa aplikasi secara efisien. Selain load balancing dan redundansi yang sederhana, grup instance terkelola memiliki fitur skalabilitas seperti penskalaan otomatis, fitur ketersediaan tinggi seperti autohealing, deployment regional, dan fitur keamanan seperti update otomatis.

Dengan fitur-fitur ini, Anda dapat tetap berada di dunia VM tetapi meningkatkan ketahanan, redundansi, dan ketersediaan aplikasi tanpa perlu merestrukturisasi aplikasi Anda sepenuhnya.

Cari perangkat pengganti 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, bukan SQL Server, MySQL, atau Postgres yang dihosting sendiri. Dengan Cloud SQL, Anda dapat berfokus pada pengelolaan database, bukan pengelolaan infrastruktur (seperti mem-patch VM database untuk keamanan atau mengelola cadangan) dengan manfaat tambahan, yaitu menghapus persyaratan untuk lisensi Windows.
  • Layanan Terkelola untuk Microsoft Active Directory, bukan Active Directory yang dihosting sendiri.
  • Memorystore, bukan instance Redis yang dihosting sendiri.

Penggantian ini tidak memerlukan perubahan kode dan hanya perlu melakukan perubahan konfigurasi yang minimal. Selain itu, penggantian ini memiliki keunggulan pengelolaan, keamanan yang ditingkatkan, dan skalabilitas.

Langkah pertama dengan container Windows

Setelah mengoptimalkan fungsi dasar untuk cloud, Anda dapat mulai berpindah dari VM ke container.

Container adalah paket ringan yang berisi aplikasi dan semua dependensinya. Dibandingkan dengan menjalankan aplikasi langsung di VM, container memungkinkan Anda menjalankan aplikasi di berbagai lingkungan dengan cara yang lebih konsisten, dapat diprediksi, dan efisien (terutama jika Anda menjalankan beberapa container di host yang sama). Ekosistem seputar container (seperti Kubernetes, Istio, dan Knative) juga menyediakan sejumlah fitur pengelolaan, ketahanan, dan pemantauan yang dapat makin mempercepat transformasi aplikasi Anda dari satu monolit ke serangkaian microservice yang difokuskan.

Untuk beberapa waktu, containerization adalah fitur khusus Linux. Aplikasi Windows tidak dapat memanfaatkan container. Hal itu berubah dengan container Windows dan dukungannya berikutnya di Kubernetes dan Google Kubernetes Engine (GKE).

Penampung Windows adalah opsi jika Anda tidak ingin memigrasikan aplikasi .NET Framework ke .NET, tetapi masih menginginkan manfaat container (seperti kegesitan, portabilitas, dan kontrol). Anda harus memilih OS yang tepat untuk ditargetkan, bergantung pada versi .NET Framework, dan perlu diingat bahwa tidak semua stack Windows didukung di penampung Windows. Untuk mengetahui batasan pendekatan ini dan alternatifnya, lihat container.NET dan Linux nanti dalam dokumen ini.

Setelah memasukkan aplikasi .NET Framework ke dalam container ke dalam container Windows, sebaiknya jalankan aplikasi .NET Framework di cluster Kubernetes. Kubernetes menyediakan fitur standar seperti mendeteksi saat Pod container tidak aktif dan dibuat ulang, Pod penskalaan otomatis, peluncuran atau rollback otomatis, dan health check. GKE menambahkan fitur seperti penskalaan otomatis cluster, cluster regional, bidang kontrol yang sangat tersedia, serta dukungan hybrid dan multi-cloud 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, berpindah ke container dan GKE membantu Anda sepenuhnya menggunakan VM 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 menerapkan containerization, tim Anda siap untuk fase modernisasi berikutnya.

Tahap 3: Merancang ulang dan membangun ulang

Peralihan platform ini hanyalah permulaan untuk mendapatkan manfaat penuh dari cloud. Mengubah arsitektur Anda menjadi platform berbasis cloud menawarkan beberapa manfaat, seperti berikut:

Peralihan ke layanan terkelola

Saat mulai menulis ulang bagian-bagian aplikasi, sebaiknya Anda mulai beralih dari layanan yang dihosting ke layanan terkelola. Misalnya, Anda dapat menggunakan hal berikut:

Meskipun Anda memerlukan kode tambahan untuk mengintegrasikan aplikasi dengan layanan ini, ini adalah investasi yang berharga, karena Anda mengalihkan beban pengelolaan platform ke Google Cloud. Library Google Cloud untuk .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 membangun dasbor dengan metrik server dan aplikasi. Google Cloud menawarkan library klien .NET untuk Cloud Logging, Cloud Monitoring, dan Cloud Trace.

Container .NET dan Linux

Jika aplikasi Anda adalah aplikasi .NET Framework lama yang hanya berjalan di Windows, Anda mungkin tergoda untuk tetap menjalankannya di server Windows di Compute Engine atau dalam container Windows Server di GKE. Meskipun pendekatan ini mungkin berhasil dalam jangka pendek, tetapi dapat sangat membatasi Anda dalam jangka panjang. Windows memiliki biaya lisensi dan jejak resource yang lebih besar secara keseluruhan daripada Linux, dan faktor-faktor ini dapat menghasilkan biaya kepemilikan yang lebih tinggi dalam jangka panjang.

Salah satu aspek terpenting dari .NET adalah multi-platform. Anda dapat memasukkan aplikasi .NET ke dalam container Linux. Penampung Linux lebih ringan daripada container Windows, dan berjalan di lebih platform yang lebih efisien. Faktor ini membuat opsi deployment untuk aplikasi .NET dan memungkinkan Anda terbebas dari dependensi pada Windows serta biaya pemberian lisensi yang terkait dengannya.

Melakukan 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 Penganalisis kompatibilitas platform dapat membantu Anda menentukan apakah assembly dan API dapat portabel. Alat porting lainnya seperti uji coba dotnet dapat membantu.

Alat eksternal dapat membantu Anda mengidentifikasi masalah kompatibilitas dan menentukan komponen yang harus dimigrasikan terlebih dahulu. Pada akhirnya, Anda perlu membuat project .NET, memindahkan kode .NET Framework secara bertahap ke project baru, dan memperbaiki ketidakcocokan selama proses berlangsung. Sebelum mentransfer kode, sangat penting untuk menerapkan pengujian, lalu menguji fungsi Anda setelah melakukan porting. Sebaiknya gunakan pengujian A/B untuk menguji kode lama dan baru. Dengan pengujian A/B, Anda dapat terus menjalankan aplikasi lama sambil mengarahkan beberapa pengguna ke aplikasi baru. Pendekatan ini memungkinkan Anda menguji output, skalabilitas, dan ketahanan aplikasi baru. Untuk membantu pengujian A/B, Google Cloud menawarkan solusi load balancing seperti Load Balancer Aplikasi eksternal global.

Transformasi Budaya

Transformasi dari server .NET Framework dan Windows ke container .NET dan Linux tidak hanya bersifat teknis. Pergeseran ini membutuhkan transformasi budaya di organisasi Anda. Staf yang mungkin terbiasa dengan lingkungan khusus Windows perlu beradaptasi dengan lingkungan multi-platform. Transformasi budaya ini memerlukan waktu dan anggaran untuk berlatih di .NET, Linux, dan alat container seperti Docker dan Kubernetes. Namun, transformasi dari khusus Windows ke organisasi multi-platform memungkinkan Anda mengakses kumpulan alat dan keterampilan yang lebih besar.

Dekomposisi monolit

Peralihan dari .NET Framework ke .NET dapat menimbulkan beberapa pertanyaan, termasuk hal berikut:

  • Apakah Anda menulis ulang seluruh aplikasi di .NET?
  • Apakah Anda memecah aplikasi menjadi beberapa layanan yang lebih kecil dan menulisnya di .NET?
  • Apakah Anda hanya menulis layanan baru di .NET?

Saat Anda mempertimbangkan pertanyaan-pertanyaan ini, perhitungkan manfaat, waktu, dan biaya yang terkait dengan masing-masing pendekatan. Ada baiknya memiliki pendekatan yang seimbang di mana Anda tidak menulis ulang semuanya sekaligus. Sebagai gantinya, Anda dapat menulis service baru di .NET dan memecah monolit yang ada menjadi service yang lebih kecil di .NET saat peluang muncul. Sesuai rencana Anda, dokumen berikut dapat membantu:

Opsi deployment untuk container .NET

Seperti yang dinyatakan Men-deploy aplikasi .NET di Google Cloud, Anda memiliki berbagai opsi untuk men-deploy container .NET di Google Cloud. Saat mendekonstruksi aplikasi monolitik ke microservice, Anda mungkin memutuskan untuk menggunakan lebih dari satu solusi hosting, bergantung pada arsitektur dan desain microservice.

Menjawab pertanyaan berikut dapat membantu Anda memutuskan strategi hosting yang 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 pilihan Anda.
  • Apakah aplikasi Anda memerlukan hardware tertentu? Cloud Run menawarkan RAM dan CPU dalam jumlah yang wajar tetapi terbatas untuk setiap permintaan. Cloud Run for Anthos menawarkan opsi penyesuaian lebih lanjut seperti GPU, lebih banyak memori, dan kapasitas disk.
  • Apa ekspektasi penskalaan Anda? Jika aplikasi Anda tidak aktif selama beberapa waktu, solusi serverless seperti Cloud Run dapat menawarkan opsi untuk menurunkan skala ke nol.
  • Seberapa penting latensi dan seberapa toleran aplikasi Anda terhadap cold start? Jika toleransi terhadap cold start rendah, Anda perlu mempertimbangkan salah satu opsi berikut:

Sebaiknya baca dokumentasi untuk setiap lingkungan hosting untuk memahami kemampuan, kekuatan dan kelemahan, serta model harganya.

Sebagai aturan umum, jika ingin membuat microservice yang melayani permintaan HTTP, Anda harus men-deploy ke Cloud Run jika memungkinkan dan kembali ke GKE jika ingin tetap berada dalam 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 Functions juga merupakan opsi deployment serverless yang baik, tetapi tidak dibahas di sini, karena Cloud Run menyediakan sebagian besar fitur yang disediakan oleh Cloud Functions, dan Cloud Functions tidak mendukung setiap versi .NET.

Kubernetes dan GKE

Jika Anda ingin menjalankan aplikasi di lingkungan yang dioptimalkan untuk container, pendekatan tersebut mungkin akan melibatkan Kubernetes dan versi terkelolanya, yaitu GKE. Kubernetes dan GKE sangat berguna jika Anda berencana untuk men-deploy banyak container dengan persyaratan berbeda dan menginginkan kontrol terperinci atas cara deployment dan pengelolaan setiap container.

Kubernetes dirancang untuk menjalankan container dalam skala besar dan menyediakan elemen penyusun seperti Pod, Service, Deployment, dan kumpulan replika. Memahami dan menggunakan konstruksi ini dengan benar bukanlah hal yang mudah, tetapi konstruksi tersebut memungkinkan Anda mengalihkan sebagian besar beban pengelolaan container ke Kubernetes. Layanan ini juga sangat cocok untuk arsitektur microservice ketika microservice adalah Deployment dengan kumpulan Pod dengan load balancing di belakang Service.

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 dikenai biaya untuk setiap node pada cluster di GKE, GKE mendukung Spot VM 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 modern berbasis Linux.

Knative dan Cloud Run

Untuk container .NET stateless Anda, Knative dan versi terkelolanya, Cloud Run, sediakan 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 platform API yang levelnya lebih tinggi dan lebih kecil dari Kubernetes. Dengan demikian, Knative dapat membantu Anda menghindari kerumitan Kubernetes, sehingga deployment container Anda menjadi lebih mudah.

Cloud Run mengikuti Knative API, tetapi berjalan di infrastruktur Google, sehingga tidak perlu adanya cluster Kubernetes. Cloud Run menyediakan opsi serverless untuk container. Secara default di Cloud Run, container diskalakan otomatis dan dikenai biaya sesuai durasi permintaan. Waktu deployment dalam hitungan detik. Cloud Run juga menyediakan fitur yang berguna, seperti revisi dan pemisahan traffic.

Cloud Run for Anthos adalah versi Cloud Run yang lebih fleksibel bagi pelanggan yang menginginkan kesederhanaan Knative dan Cloud Run dengan fleksibilitas operasional Kubernetes. Misalnya, Cloud Run di GKE Enterprise dapat Anda gunakan untuk menambahkan GPU ke instance dasar yang menjalankan container, atau memungkinkan Anda mengakses VM lain atau cluster GKE di VPC yang sama.

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 dengan penskalaan otomatis atau microservice internal yang dipicu oleh peristiwa.

Modernisasi operasi

Modernisasi tidak hanya terkait kode aplikasi Anda. 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 deployment pengujian build aplikasi. Cloud Build tidak hanya menyediakan builder untuk .NET, Cloud Build juga terintegrasi dengan Vulnerability Scanner dari Artifact Registry serta dengan Otorisasi Biner untuk mencegah image yang dibangun dari kode sumber yang tidak dikenal atau repositori yang tidak aman agar tidak berjalan di lingkungan deployment Anda.

Kemampuan observasi Google Cloud (sebelumnya bernama Stackdriver) menawarkan beberapa layanan yang memungkinkan Anda memodernisasi kemampuan observasi aplikasi Anda:

Anda dapat menggunakan library Google.Cloud.Diagnostics.AspNetCore untuk mengekspor log, metrik, dan trace ke Google Cloud untuk aplikasi ASP.NET. Untuk mengekspor metrik OpenTelemetry ke Google Cloud, Anda dapat menggunakan library OpenTelemetry.Exporter.Stackdriver.

Untuk mengetahui informasi selengkapnya tentang penerapan modernisasi pada proses dan budaya tim, lihat Solusi Google Cloud untuk DevOps.

Langkah selanjutnya