Menggunakan Azure Front Door dalam solusi multipenyewa

  • Artikel

Azure Front Door adalah jaringan pengiriman konten cloud (CDN) modern yang menyediakan akses cepat dan andal antara pengguna dan konten web statis dan dinamis aplikasi di seluruh dunia. Artikel ini menjelaskan beberapa fitur Azure Front Door yang berguna saat Anda bekerja di sistem multipenyewa. Ini juga menyediakan tautan ke panduan dan contoh tambahan.

Saat Anda menggunakan Azure Front Door sebagai bagian dari solusi multipenyewa, Anda perlu membuat beberapa keputusan berdasarkan desain dan persyaratan solusi Anda. Anda perlu mempertimbangkan faktor-faktor berikut:

  • Berapa banyak penyewa yang Anda miliki, dan berapa banyak yang Anda harapkan untuk dimiliki di masa depan?
  • Apakah Anda berbagi tingkat aplikasi di antara beberapa penyewa, menyebarkan banyak instans aplikasi penyewa tunggal, atau menyebarkan stempel penyebaran terpisah yang dibagikan oleh beberapa penyewa?
  • Apakah penyewa Anda ingin membawa nama domain mereka sendiri?
  • Apakah Anda akan menggunakan domain wildcard?
  • Apakah Anda perlu menggunakan sertifikat TLS Anda sendiri, atau apakah Microsoft akan mengelola sertifikat TLS Anda?
  • Sudahkah Anda mempertimbangkan kuota dan batasan yang berlaku untuk Azure Front Door? Apakah Anda tahu batas mana yang akan Anda dekati saat tumbuh? Jika Anda menduga bahwa Anda akan mendekati batas ini, pertimbangkan untuk menggunakan beberapa profil Azure Front Door. Atau pertimbangkan apakah Anda dapat mengubah cara Anda menggunakan Azure Front Door untuk menghindari batas. Perhatikan bahwa SKU Premium memiliki batas yang lebih tinggi daripada SKU Standar.
  • Apakah Anda atau penyewa Anda memiliki persyaratan untuk pemfilteran alamat IP, pemblokiran geografis, atau menyesuaikan aturan WAF?
  • Apakah semua server aplikasi penyewa Anda menghadap internet?

Fitur Azure Front Door yang mendukung multitenansi

Bagian ini menjelaskan beberapa fitur utama Azure Front Door yang berguna untuk solusi multipenyewa. Ini menjelaskan bagaimana Azure Front Door dapat membantu Anda mengonfigurasi domain kustom, termasuk informasi tentang domain wildcard dan sertifikat TLS. Ini juga meringkas bagaimana Anda dapat menggunakan kemampuan perutean Azure Front Door untuk mendukung multitenansi.

Domain kustom

Azure Front Door menyediakan nama host default untuk setiap titik akhir yang Anda buat, misalnya, contoso.z01.azurefd.net. Untuk sebagian besar solusi, Anda mengaitkan nama domain Anda sendiri dengan titik akhir Azure Front Door. Nama domain kustom memungkinkan Anda menggunakan branding Anda sendiri dan mengonfigurasi perutean berdasarkan nama host yang disediakan dalam permintaan klien.

Dalam solusi multipenyewa, Anda mungkin menggunakan nama domain atau subdomain khusus penyewa, dan mengonfigurasi Azure Front Door untuk merutekan lalu lintas penyewa ke grup asal yang benar untuk beban kerja penyewa tersebut. Misalnya, Anda dapat mengonfigurasi nama domain kustom seperti tenant1.app.contoso.com. Dengan Azure Front Door, Anda dapat mengonfigurasi beberapa domain kustom pada satu profil Azure Front Door.

Untuk mengetahui informasi selengkapnya, lihat Menambahkan domain kustom ke Front Door Anda.

Domain wildcard

Domain wildcard menyederhanakan konfigurasi catatan DNS dan konfigurasi perutean lalu lintas Azure Front Door saat Anda menggunakan domain batang bersama dan subdomain khusus penyewa. Misalnya, penyewa Anda mengakses aplikasi mereka dengan menggunakan subdomain seperti tenant1.app.contoso.com dan tenant2.app.contoso.com. Anda dapat mengonfigurasi domain wildcard, *.app.contoso.com, alih-alih mengonfigurasi setiap domain khusus penyewa satu per satu.

Azure Front Door mendukung pembuatan domain kustom yang menggunakan wildcard. Anda kemudian dapat mengonfigurasi rute untuk permintaan yang tiba di domain wildcard. Saat Anda melakukan onboarding penyewa baru, Anda tidak perlu mengonfigurasi ulang server DNS Anda, menerbitkan sertifikat TLS baru, atau memperbarui konfigurasi profil Azure Front Door Anda.

Domain wildcard berfungsi dengan baik jika Anda mengirim semua lalu lintas Anda ke satu grup asal. Tetapi jika Anda memiliki stempel terpisah dari solusi Anda, domain wildcard tingkat tunggal tidak cukup. Anda perlu menggunakan domain batang multi-tingkat atau menyediakan konfigurasi tambahan dengan, misalnya, mengganti rute yang akan digunakan untuk subdomain setiap penyewa. Untuk informasi selengkapnya, lihat Pertimbangan saat menggunakan nama domain dalam solusi multipenyewa.

Azure Front Door tidak mengeluarkan sertifikat TLS terkelola untuk domain wildcard, jadi Anda perlu membeli dan menyediakan sertifikat Anda sendiri.

Untuk informasi selengkapnya, lihat Domain wildcard.

Sertifikat TLS terkelola

Memperoleh dan menginstal sertifikat TLS dapat menjadi kompleks dan rawan kesalahan. Dan sertifikat TLS kedaluwarsa setelah jangka waktu tertentu, biasanya satu tahun, dan perlu diterbitkan kembali dan diinstal ulang untuk menghindari gangguan pada lalu lintas aplikasi. Saat Anda menggunakan sertifikat TLS terkelola Azure Front Door, Microsoft bertanggung jawab untuk menerbitkan, menginstal, dan memperbarui sertifikat untuk domain kustom Anda.

Aplikasi asal Anda mungkin dihosting di layanan Azure lain yang juga menyediakan sertifikat TLS terkelola, seperti Azure App Service. Azure Front Door secara transparan bekerja dengan layanan lain untuk menyinkronkan sertifikat TLS Anda.

Jika Anda mengizinkan penyewa untuk menyediakan domain kustom mereka sendiri dan Anda ingin Azure Front Door menerbitkan sertifikat untuk nama domain ini, penyewa Anda tidak boleh mengonfigurasi catatan CAA di server DNS mereka yang mungkin memblokir Azure Front Door agar tidak menerbitkan sertifikat atas nama mereka. Untuk informasi selengkapnya, lihat Sertifikat TLS/SSL.

Untuk informasi selengkapnya tentang sertifikat TLS, lihat TLS end-to-end dengan Azure Front Door.

Perutean

Aplikasi multipenyewa mungkin memiliki satu atau beberapa stempel aplikasi yang melayani penyewa. Stempel sering digunakan untuk mengaktifkan penyebaran multi-wilayah dan untuk mendukung penskalaan solusi ke sejumlah besar penyewa.

Azure Front Door memiliki serangkaian kemampuan perutean yang kuat yang dapat mendukung sejumlah arsitektur multipenyewa. Anda dapat menggunakan perutean untuk mendistribusikan lalu lintas di antara asal dalam stempel, atau untuk mengirim lalu lintas ke stempel yang benar untuk penyewa tertentu. Anda dapat mengonfigurasi perutean berdasarkan nama domain individual, nama domain wildcard, dan jalur URL. Dan Anda dapat menggunakan mesin aturan untuk menyesuaikan perilaku perutean lebih lanjut.

Untuk informasi selengkapnya, lihat Gambaran umum arsitektur perutean.

Mesin aturan

Anda dapat menggunakan mesin aturan Azure Front Door untuk menyesuaikan cara Azure Front Door memproses permintaan di tepi jaringan. Mesin aturan memungkinkan Anda menjalankan blok kecil logika dalam alur pemrosesan permintaan Azure Front Door. Anda dapat menggunakan mesin aturan untuk mengambil alih konfigurasi perutean untuk permintaan. Anda juga dapat menggunakan mesin aturan untuk memodifikasi elemen permintaan sebelum dikirim ke asal, dan untuk memodifikasi beberapa bagian respons sebelum dikembalikan ke klien.

Misalnya, Anda menyebarkan tingkat aplikasi multipenyewa tempat Anda juga menggunakan subdomain wildcard khusus penyewa, seperti yang dijelaskan dalam contoh skenario berikut. Anda dapat menggunakan mesin aturan untuk mengekstrak pengidentifikasi penyewa dari subdomain permintaan dan menambahkannya ke header permintaan. Aturan ini dapat membantu tingkat aplikasi menentukan penyewa mana asal permintaan.

Untuk informasi selengkapnya, lihat Apa itu mesin aturan Azure Front Door?.

Skenario contoh

Contoh skenario berikut menggambarkan bagaimana Anda dapat mengonfigurasi berbagai arsitektur multipenyewa di Azure Front Door, dan bagaimana keputusan yang Anda buat dapat memengaruhi konfigurasi DNS dan TLS Anda.

Banyak solusi multipenyewa menerapkan pola Stempel Penyebaran. Saat Anda menggunakan pendekatan penyebaran ini, Anda biasanya menyebarkan satu profil Azure Front Door bersama dan menggunakan Azure Front Door untuk merutekan lalu lintas masuk ke stempel yang sesuai. Model penyebaran ini adalah yang paling umum, dan skenario 1 hingga 4 dalam artikel ini menunjukkan bagaimana Anda dapat menggunakannya untuk memenuhi berbagai persyaratan.

Namun, dalam beberapa situasi, Anda mungkin menyebarkan profil Azure Front Door di setiap stempel solusi Anda. Skenario 5 menjelaskan model penyebaran ini.

Skenario 1: Domain wildcard yang dikelola penyedia, stempel tunggal

Contoso sedang membangun solusi multipenyewa kecil. Perusahaan menyebarkan stempel tunggal di satu wilayah, dan stempel itu melayani semua penyewanya. Semua permintaan dirutekan ke server aplikasi yang sama. Contoso memutuskan untuk menggunakan domain wildcard untuk semua penyewa, seperti tenant1.contoso.com dan tenant2.contoso.com.

Contoso menyebarkan Azure Front Door dengan menggunakan konfigurasi ini:

Diagram that shows an Azure Front Door configuration that has a single custom domain, route, and origin group and a wildcard TLS certificate in Azure Key Vault.

Konfigurasi DNS

Konfigurasi satu kali: Contoso mengonfigurasi dua entri DNS:

  • Catatan TXT kartubebas untuk *.contoso.com. Ini diatur ke nilai yang ditentukan oleh Azure Front Door selama proses onboarding domain kustom.
  • Catatan CNAME kartubebas, *.contoso.com, itu adalah alias untuk titik akhir Azure Front Door Contoso: contoso.z01.azurefd.net.

Saat penyewa baru di-onboarding: Tidak diperlukan konfigurasi tambahan.

Konfigurasi TLS

Konfigurasi satu kali: Contoso membeli sertifikat TLS wildcard, menambahkannya ke brankas kunci, dan memberikan akses Azure Front Door ke vault.

Saat penyewa baru di-onboarding: Tidak diperlukan konfigurasi tambahan.

Konfigurasi Azure Front Door

Konfigurasi satu kali: Contoso membuat profil Azure Front Door dan satu titik akhir. Mereka menambahkan satu domain kustom dengan nama *.contoso.com dan mengaitkan sertifikat TLS wildcard mereka dengan sumber daya domain kustom. Mereka kemudian mengonfigurasi satu grup asal yang berisi satu asal untuk server aplikasi mereka. Terakhir, mereka mengonfigurasi rute untuk menyambungkan domain kustom ke grup asal.

Saat penyewa baru di-onboarding: Tidak diperlukan konfigurasi tambahan.

Keuntungan

  • Konfigurasi ini relatif mudah dikonfigurasi dan menyediakan URL bermerk Contoso kepada pelanggan.
  • Pendekatan ini mendukung sejumlah besar penyewa.
  • Saat penyewa baru di-onboarding, Contoso tidak perlu membuat perubahan pada sertifikat Azure Front Door, DNS, atau TLS.

Kekurangan

  • Pendekatan ini tidak mudah diskalakan di luar satu stempel atau wilayah aplikasi.
  • Contoso perlu membeli sertifikat TLS kartubebas dan memperbarui dan menginstal sertifikat saat kedaluwarsa.

Skenario 2: Domain wildcard yang dikelola penyedia, beberapa stempel

Proseware sedang membangun solusi multipenyewa di beberapa stempel yang disebarkan ke Australia dan Eropa. Semua permintaan dalam satu wilayah dilayani oleh stempel di wilayah tersebut. Seperti Contoso, Proseware memutuskan untuk menggunakan domain wildcard untuk semua penyewa, seperti tenant1.proseware.com dan tenant2.proseware.com.

Proseware menyebarkan Azure Front Door dengan menggunakan konfigurasi ini:

Diagram that shows an Azure Front Door configuration that has multiple custom domains, routes, and origin groups and a wildcard TLS certificate in Key Vault.

Konfigurasi DNS

Konfigurasi satu kali: Proseware mengonfigurasi dua entri DNS:

  • Catatan TXT kartubebas untuk *.proseware.com. Ini diatur ke nilai yang ditentukan oleh Azure Front Door selama proses onboarding domain kustom.
  • Catatan CNAME kartubebas, *.proseware.com, itu adalah alias untuk titik akhir Azure Front Door Proseware: proseware.z01.azurefd.net.

Saat penyewa baru di-onboarding: Tidak diperlukan konfigurasi tambahan.

Konfigurasi TLS

Konfigurasi satu kali: Proseware membeli sertifikat TLS wildcard, menambahkannya ke brankas kunci, dan memberikan akses Azure Front Door ke vault.

Saat penyewa baru di-onboarding: Tidak diperlukan konfigurasi tambahan.

Konfigurasi Azure Front Door

Konfigurasi satu kali: Proseware membuat profil Azure Front Door dan satu titik akhir. Perusahaan mengonfigurasi beberapa grup asal, satu per stempel/server aplikasi di setiap wilayah.

Saat penyewa baru di-onboarding: Proseware menambahkan sumber daya domain kustom ke Azure Front Door. Mereka menggunakan nama *.proseware.com dan mengaitkan sertifikat TLS wildcard mereka dengan sumber daya domain kustom. Mereka kemudian membuat rute untuk menentukan grup asal (stempel) mana yang harus diarahkan oleh permintaan penyewa. Dalam diagram sebelumnya, tenant1.proseware.com rute ke grup asal di wilayah Australia, dan tenant2.proseware.com rute ke grup asal di wilayah Eropa.

Keuntungan

  • Saat penyewa baru di-onboarding, tidak diperlukan perubahan konfigurasi DNS atau TLS.
  • Proseware mempertahankan satu instans Azure Front Door untuk merutekan lalu lintas ke beberapa stempel di beberapa wilayah.

Kekurangan

  • Proseware perlu mengonfigurasi ulang Azure Front Door setiap kali penyewa baru di-onboarding.
  • Proseware perlu memperhatikan kuota dan batasan Azure Front Door, terutama pada jumlah rute dan domain kustom, dan batas perutean komposit.
  • Proseware perlu membeli sertifikat TLS kartubebas.
  • Proseware bertanggung jawab untuk memperbarui dan menginstal sertifikat saat kedaluwarsa.

Skenario 3: Subdomain wildcard berbasis stempel yang dikelola penyedia

Fabrikam sedang membangun solusi multipenyewa. Perusahaan menyebarkan stempel di Australia dan Amerika Serikat. Semua permintaan dalam satu wilayah akan dilayani oleh stempel di wilayah tersebut. Fabrikam akan menggunakan domain batang berbasis stempel, seperti tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.com, dan tenant3.us.fabrikam.com.

Perusahaan menyebarkan Azure Front Door dengan menggunakan konfigurasi ini:

Diagram that shows an Azure Front Door configuration that has multiple custom stamp-based stem domains, routes, origin groups, and wildcard TLS certificate in Key Vault.

Konfigurasi DNS

Konfigurasi satu kali: Fabrikam mengonfigurasi dua entri DNS wildcard berikut untuk setiap stempel.

  • Catatan TXT kartubebas untuk setiap stempel: *.australia.fabrikam.com dan *.us.fabrikam.com. Mereka diatur ke nilai yang ditentukan oleh Azure Front Door selama proses onboarding domain kustom.
  • Catatan CNAME kartubebas untuk setiap stempel, *.australia.fabrikam.com dan *.us.fabrikam.com, yang keduanya adalah alias untuk titik akhir Azure Front Door: fabrikam.z01.azurefd.net.

Saat penyewa baru di-onboarding: Tidak diperlukan konfigurasi tambahan.

Konfigurasi TLS

Konfigurasi satu kali: Fabrikam membeli sertifikat TLS wildcard untuk setiap stempel, menambahkannya ke brankas kunci, dan memberikan akses Azure Front Door ke vault.

Saat penyewa baru di-onboarding: Tidak diperlukan konfigurasi tambahan.

Konfigurasi Azure Front Door

Konfigurasi satu kali: Fabrikam membuat profil Azure Front Door dan satu titik akhir. Mereka mengonfigurasi grup asal untuk setiap stempel. Mereka membuat domain kustom, menggunakan kartubebas, untuk setiap subdomain berbasis stempel: *.australia.fabrikam.com dan *.us.fabrikam.com. Mereka membuat rute untuk domain kustom setiap stempel untuk mengirim lalu lintas ke grup asal yang sesuai.

Saat penyewa baru di-onboarding: Tidak diperlukan konfigurasi tambahan.

Keuntungan

  • Pendekatan ini memungkinkan Fabrikam untuk menskalakan ke sejumlah besar penyewa di beberapa stempel.
  • Saat penyewa baru di-onboarding, tidak diperlukan perubahan konfigurasi DNS atau TLS.
  • Fabrikam mempertahankan satu instans Azure Front Door untuk merutekan lalu lintas ke beberapa stempel di beberapa wilayah.

Kekurangan

  • Karena URL menggunakan struktur domain batang multibagian, URL bisa lebih kompleks untuk dikerjakan pengguna.
  • Fabrikam perlu membeli beberapa sertifikat TLS kartubebas.
  • Fabrikam bertanggung jawab untuk memperbarui dan menginstal sertifikat TLS ketika kedaluwarsa.

Skenario 4: Domain vanity

Adventure Works Cycles sedang membangun solusi multipenyewa. Perusahaan menyebarkan stempel di beberapa wilayah, seperti Australia dan Amerika Serikat. Semua permintaan dalam satu wilayah akan dilayani oleh stempel di wilayah tersebut. Adventure Works akan memungkinkan penyewanya untuk membawa nama domain mereka sendiri. Misalnya, penyewa 1 mungkin mengonfigurasi nama domain kustom seperti tenant1app.tenant1.com.

Perusahaan menyebarkan Azure Front Door dengan menggunakan konfigurasi ini:

Diagram that shows an Azure Front Door configuration that has multiple custom vanity domains, routes, and origin groups and a combination of TLS certificates in Key Vault and TLS certificates that are managed by Azure Front Door.

Konfigurasi DNS

Konfigurasi satu kali: Tidak ada.

Saat penyewa baru di-onboarding: Penyewa perlu membuat dua rekaman di server DNS-nya sendiri:

  • Catatan TXT untuk validasi domain. Misalnya, penyewa 1 perlu mengonfigurasi catatan TXT bernama tenant1app.tenant1.com dan mengaturnya ke nilai yang ditentukan oleh Azure Front Door selama proses onboarding domain kustom.
  • Catatan CNAME yang diberi alias ke titik akhir Adventure Works Azure Front Door. Misalnya, penyewa 1 perlu mengonfigurasi data CNAME bernama tenant1app.tenant1.com dan memetakannya ke adventureworks.z01.azurefd.net.

Konfigurasi TLS

Adventure Works dan penyewanya perlu memutuskan siapa yang mengeluarkan sertifikat TLS:

  • Opsi term mudah adalah menggunakan Azure Front Door untuk mengeluarkan dan mengelola sertifikat, tetapi penyewa tidak boleh mengonfigurasi catatan CCA di server DNS mereka. Jika mereka melakukannya, catatan mungkin mencegah otoritas sertifikasi Azure Front Door mengeluarkan sertifikat.
  • Atau, penyewa dapat menyediakan sertifikat mereka sendiri. Mereka perlu bekerja dengan Adventure Works untuk mengunggah sertifikat ke brankas kunci dan menyediakan akses ke Azure Front Door.

Konfigurasi Azure Front Door

Konfigurasi satu kali: Adventure Works membuat profil Azure Front Door dan satu titik akhir. Mereka mengonfigurasi grup asal untuk setiap stempel. Mereka tidak membuat sumber daya atau rute domain kustom.

Saat penyewa baru di-onboarding: Adventure Works menambahkan sumber daya domain kustom ke Azure Front Door. Mereka menggunakan nama domain yang disediakan penyewa dan mengaitkan sertifikat TLS yang sesuai dengan sumber daya domain kustom. Mereka kemudian membuat rute untuk menentukan grup asal (stempel) mana yang harus diarahkan oleh permintaan penyewa. Dalam diagram sebelumnya, tenant1app.tenant1.com dirutekan ke grup asal di wilayah Australia, dan tenant2app.tenant3.com dirutekan ke grup asal di wilayah AS.

Keuntungan

  • Pelanggan dapat memberikan nama domain mereka sendiri. Azure Front Door secara transparan merutekan permintaan ke solusi multipenyewa.
  • Adventure Works mempertahankan satu instans Azure Front Door untuk merutekan lalu lintas ke beberapa stempel di beberapa wilayah.

Kekurangan

  • Adventure Works perlu mengonfigurasi ulang Azure Front Door setiap kali penyewa baru di-onboarding.
  • Penyewa perlu terlibat dalam proses onboarding. Mereka perlu membuat perubahan DNS dan mungkin mengeluarkan sertifikat TLS.
  • Penyewa mengontrol catatan DNS mereka. Perubahan pada rekaman DNS dapat memengaruhi kemampuan mereka untuk mengakses solusi Adventure Works.
  • Adventure Works perlu memperhatikan kuota dan batasan Azure Front Door, terutama pada jumlah rute dan domain kustom, dan batas perutean komposit.

Skenario 5: Profil Azure Front Door per stempel

Anda dapat menyebarkan profil Azure Front Door untuk setiap stempel. Jika Anda memiliki 10 stempel, Anda menyebarkan 10 instans Azure Front Door. Pendekatan ini dapat berguna jika Anda perlu membatasi akses manajemen konfigurasi Azure Front Door setiap stempel. Ini juga dapat berguna jika Anda perlu menggunakan beberapa profil Azure Front Door untuk menghindari melebihi kuota atau batas sumber daya.

Tip

Azure Front Door adalah sumber daya global. Bahkan jika Anda menyebarkan stempel yang dilingkup secara regional, setiap profil Azure Front Door didistribusikan secara global. Anda harus mempertimbangkan apakah Anda benar-benar perlu menyebarkan beberapa profil Azure Front Door, dan keuntungan apa yang Anda peroleh dengan melakukannya.

Jika Anda memiliki stempel yang melayani beberapa penyewa, Anda perlu mempertimbangkan bagaimana Anda merutekan lalu lintas ke setiap penyewa. Tinjau pendekatan yang dijelaskan dalam skenario sebelumnya, dan pertimbangkan untuk menggabungkan pendekatan agar sesuai dengan kebutuhan Anda.

Keuntungan

  • Jika Anda memperluas konfigurasi di beberapa profil, kemungkinan besar Anda lebih kecil untuk mencapai batas sumber daya Azure Front Door. Misalnya, jika Anda perlu mendukung sejumlah besar domain kustom, Anda dapat membagi domain di antara beberapa profil Azure Front Door dan tetap berada dalam batas setiap profil.
  • Pendekatan ini memungkinkan Anda untuk mencakup izin manajemen sumber daya Azure Front Door Anda. Anda dapat menggunakan kontrol akses berbasis peran Azure (RBAC) untuk memberi administrator akses ke profil stempel tunggal.

Kekurangan

  • Pendekatan ini biasanya dikenakan biaya tinggi karena Anda menyebarkan lebih banyak profil. Untuk informasi selengkapnya, lihat Memahami tagihan Front Door.
  • Ada batasan jumlah profil Azure Front Door yang dapat Anda sebarkan ke dalam satu langganan Azure. Untuk informasi selengkapnya, lihat Kuota dan batas Front Door.
  • Anda perlu mengonfigurasi profil Azure Front Door setiap stempel secara terpisah, dan Anda perlu mengelola konfigurasi DNS, sertifikat TLS, dan konfigurasi TLS untuk setiap stempel.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

  • Raj Nemani | Direktur, Strategi Teknologi Mitra
  • John Downs | Teknisi Pelanggan Utama, FastTrack untuk Azure

Kontributor lain:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya