Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pertimbangan lainnya

Sejauh ini, kita telah membahas menggunakan API Gateway dan Windows kontainer untuk memodernisasi layanan web ASP.NET warisan Anda padaAWS. Berikut adalah beberapa pertimbangan lain yang perlu dipertimbangkan:

Ini dibahas di bagian berikut.

Autentikasi dan otorisasi

API modern umumnya memanfaatkan standar otentikasi dan otorisasi berbasis token (JSON Web Token atau JWT) seperti OAuth 2.0 dan OpenID Connect, sedangkan layanan web ASP.NET lama secara tradisional mengandalkan otentikasi dasar atau otentikasi terpadu Windows ke domain Windows Active Directory. Sebagai praktik terbaik, dalam kasus di mana pendekatan otentikasi dan otorisasi lama dan baru tidak kompatibel, kami sarankan Anda meningkatkan mekanisme keamanan ini sebelum Anda memodernisasi layanan web AndaAWS. Mencoba memetakan identitas atau mencoba mentransfer status keamanan dengan aman antara sistem lama dan baru mungkin bukan upaya yang signifikan, tetapi mungkin menimbulkan kerentanan keamanan.

Desain berbasis domain

Saat memecah monolit menjadi layanan individual, desain berbasis domain (DDD) adalah praktik terbaik yang sering digunakan untuk memodelkan sistem ke dalam domain bisnis yang kohesif. DDD adalah pendekatan untuk mengembangkan perangkat lunak untuk kebutuhan yang kompleks dengan menghubungkan implementasi untuk model berkembang dari konsep bisnis inti. Premisnya adalah menempatkan fokus utama proyek pada domain inti dan logika domain, dan untuk mendasarkan desain sistem pada model yang mencerminkan bisnis. Jika Anda menggunakan DDD ketika Anda memodernisasi aplikasi monolitik yang ada, Anda perlu bekerja mundur dari fitur dan arus pengguna monolit. Anda dapat menggunakan DDD dalam kombinasi dengan pola strangler untuk memandu proses melanggar monolit dan menentukan layanan untuk mencekik, maka istilah desain domain-driven.

Status sementara dan status target

Ketika Anda memodernisasi lebih dari beberapa layanan web ASP.NET padaAWS, itu adalah praktik yang baik untuk pertama menentukan apa arsitektur negara target Anda akan setelah semua layanan dimodernisasi. Namun, arsitektur status target belum tentu status akhir atau keadaan akhir, karena konteks bisnis sering berubah dan status target sistem harus diperbarui sesuai kebutuhan untuk tetap selaras dengan tujuan bisnis. Ketika Anda telah menentukan status target, Anda dapat bekerja mundur dari sana untuk menentukan arsitektur interim-state yang secara bertahap memenuhi visi status target. Anda dapat menganggap arsitektur interim-state ini sebagai perkembangan pohon ara pencekik di atas pohon saat bertemu dan menelan sebagian besar pohon inang. Arsitektur interim-state sering memperkenalkan konstruksi sementara atau tumpang tindih yang tidak akan menjadi bagian dari arsitektur end-state untuk memfasilitasi evolusi ke status target. Modernisasi layanan web ASP.NET berbasis SOAP memberikan contoh ini: Wadah berbasis Windows diperkenalkan sementara untuk menjembatani kesenjangan antara sistem panggilan yang bergantung pada layanan lama sampai mereka dapat ditingkatkan ke REST API baru.