Pendekatan arsitektur untuk IoT dalam solusi multipenyewa

Solusi IoT multipenyewa hadir dalam berbagai ragam dan ukuran. Anda mungkin memiliki banyak persyaratan dan batasan, mulai dari kepemilikan infrastruktur, hingga isolasi data pelanggan, hingga kepatuhan. Mungkin sulit untuk menentukan pola yang memenuhi semua batasan desain ini, dan sering kali membutuhkan mempertimbangkan beberapa dimensi. Artikel ini menjelaskan beberapa pendekatan yang umumnya digunakan untuk menyelesaikan pertimbangan multitenansi untuk solusi berbasis IoT. Dokumen ini mencakup contoh arsitektur multipenyewa yang memanfaatkan komponen umum, sesuai dengan Arsitektur Referensi IoT.

Pertimbangan dan persyaratan utama

Pertimbangan dan persyaratan ini disajikan dalam urutan di mana mereka biasanya diprioritaskan untuk desain solusi.

Tata kelola dan kepatuhan

Pertimbangan tata kelola dan kepatuhan mungkin mengharuskan Anda menggunakan pola atau set sumber daya IoT tertentu. Tidak semua layanan IoT memiliki sertifikasi atau kemampuan yang sama. Jika Anda perlu memenuhi standar kepatuhan tertentu, Anda mungkin perlu memilih layanan tertentu. Informasi tentang tata kelola dan kepatuhan dibahas dalam artikel khusus tentang topik tersebut.

Tata kelola di IoT juga dapat mengambil formulir tambahan, seperti kepemilikan dan manajemen perangkat. Apakah pelanggan memiliki perangkat atau apakah penyedia solusi? Siapa yang memiliki manajemen perangkat tersebut? Pertimbangan dan implikasi ini unik untuk setiap penyedia solusi dan dapat menyebabkan berbagai pilihan dalam teknologi, pola penyebaran, dan pola multitenansi yang Anda gunakan.

Sisik

Penting untuk merencanakan skala solusi Anda. Skala sering dipertimbangkan di ketiga dimensi ini:

• Kuantitas perangkat: Semua layanan manajemen perangkat Azure - Azure IoT Central, Azure IoT Hub Device Provisioning Service (DPS), dan Azure IoT Hub - memiliki batasan jumlah perangkat yang didukung dalam satu instans.

  Tip

  Lihat dokumentasi skala tinggi, jika Anda berencana untuk menyebarkan sejumlah besar perangkat.

• Throughput perangkat: Perangkat yang berbeda, bahkan dalam solusi yang sama, mungkin memiliki persyaratan throughput yang berbeda. "Throughput" dalam konteks ini mengacu pada jumlah pesan selama periode waktu tertentu dan ukuran pesan. Misalnya, dalam solusi bangunan pintar, termostat kemungkinan akan melaporkan data pada frekuensi yang lebih rendah daripada lift, sementara dalam solusi kendaraan yang terhubung, pesan data perekaman kamera kendaraan kemungkinan akan lebih besar dari pesan telemetri navigasi. Jika pesan Anda dibatasi sehubungan dengan frekuensi, Anda mungkin perlu memperluas skala ke lebih banyak instans layanan tertentu, tetapi jika pesan dibatasi sehubungan dengan ukuran, Anda mungkin perlu meningkatkan skala ke instans yang lebih besar dari layanan tertentu.

• Penyewa: Skala penyewa tunggal mungkin kecil, tetapi ketika dikalikan dengan jumlah penyewa, skala dapat dengan cepat tumbuh.

Performa dan keandalan

Isolasi penyewa

Solusi yang sepenuhnya dibagikan dapat memiliki tetangga yang bising. Dalam kasus IoT Hub dan IoT Central, ini dapat mengakibatkan kode respons HTTP 429 ("Terlalu Banyak Permintaan"), yang merupakan kegagalan keras yang dapat menyebabkan efek berkapasitas. Untuk informasi selengkapnya, lihat Kuota dan Pembatasan.

Dalam solusi multipenyewa sepenuhnya, efek ini dapat bertingkat. Ketika pelanggan berbagi aplikasi IoT Hubs atau IoT Central, maka semua pelanggan pada infrastruktur bersama akan mulai menerima kesalahan. Karena IoT Hub dan IoT Central biasanya merupakan titik masuk untuk data ke cloud, sistem hilir lainnya yang bergantung pada data ini kemungkinan juga gagal. Seringkali, kemunculan yang paling umum untuk hal ini terjadi adalah ketika batas kuota pesan telah terlampaui. Dalam situasi ini, perbaikan tercepat dan paling sederhana untuk solusi IoT Hub adalah meningkatkan SKU IoT Hub, meningkatkan jumlah unit IoT Hub, atau keduanya. Untuk solusi IoT Central, solusi secara otomatis menskalakan sesuai kebutuhan, hingga jumlah pesan yang didokumentasikan yang didukung.

Anda dapat mengisolasi dan mendistribusikan penyewa di seluruh bidang kontrol, manajemen, dan komunikasi IoT dengan menggunakan kebijakan alokasi kustom DPS. Selanjutnya, ketika Anda mengikuti panduan untuk solusi IoT skala tinggi, Anda dapat mengelola distribusi alokasi tambahan di tingkat penyeimbang beban DPS.

Penyimpanan data, kueri, penggunaan, dan retensi

Solusi IoT cenderung sangat intensif data, baik saat streaming maupun saat tidak aktif. Untuk informasi selengkapnya tentang mengelola data dalam solusi multipenyewa, lihat Pendekatan arsitektur untuk penyimpanan dan data dalam solusi multipenyewa.

Keamanan

Solusi IoT sering memiliki pertimbangan keamanan di beberapa lapisan, terutama dalam solusi yang disebarkan dalam solusi Purdue Enterprise Reference Architecture atau Industry 4.0 yang dimodifikasi cloud. Pendekatan desain yang dipilih dari yang di bawah ini akan berdampak pada lapisan dan batas jaringan apa yang ada; setelah desain fisik dipilih, implementasi keamanan dapat dipilih. Alat yang dapat digunakan dalam pendekatan apa pun meliputi:

• Pertahanan Microsoft untuk IoT, solusi pemantauan IoT komprehensif yang harus Anda pertimbangkan yang menawarkan lisensi EIoT per perangkat dan lisensi situs OT untuk setiap perangkat pelanggan dan/atau situs. Bergantung pada pendekatan yang dipilih nanti dalam artikel ini, skenario lisensi pengguna bernama Microsoft 365 mungkin tidak dimungkinkan. Dalam hal ini, opsi lisensi per perangkat dan situs tersedia, yang merupakan opsi lisensi independen dari lisensi penyewa Microsoft 365.

• Azure Firewall atau appliance firewall pihak ketiga, yang harus Anda pertimbangkan untuk mengisolasi lapisan jaringan serta memantau lalu lintas jaringan. Pilihan pendekatan yang tepat akan berdampak di mana beban kerja akan memiliki isolasi jaringan versus jaringan bersama, seperti yang dibahas di bawah ini.

• Azure IoT Edge atau Operasi Azure IoT, yang harus Anda pertimbangkan sebagai bagian dari konektivitas perangkat ke layanan yang dihosting Azure tanpa langsung mengekspos perangkat untuk mengarahkan akses Internet. Karena Operasi Azure IoT sedang dalam pratinjau saat ini, dokumen ini tidak menjelaskan penggunaan penawaran tersebut secara umum. Revisi dokumen ini di masa mendatang akan membahas hal ini.

Sebagian besar topik keamanan ini berlaku dalam solusi multipenyewa yang mirip dengan bagaimana mereka akan dalam satu solusi penyewa, dengan variasi yang terkait dengan pendekatan yang dipilih. Salah satu komponen yang kemungkinan besar akan berbeda secara substansial dalam solusi IoT keseluruhan adalah identitas pengguna dan aplikasi. Pendekatan arsitektur untuk identitas dalam solusi multipenyewa membahas aspek solusi multipenyewa secara keseluruhan ini.

Pendekatan yang perlu dipertimbangkan

Semua pertimbangan yang biasanya Anda buat dalam arsitektur IoT, untuk semua komponen utama (seperti manajemen, penyerapan, pemrosesan, penyimpanan, keamanan, dan sebagainya), adalah semua pilihan yang masih harus Anda buat saat mengejar solusi multipenyewa. Perbedaan utamanya adalah bagaimana Anda mengatur dan menggunakan komponen untuk mendukung multitenansi. Misalnya, poin keputusan umum untuk penyimpanan mungkin memutuskan apakah akan menggunakan SQL Server atau Azure Data Explorer, atau mungkin pada tingkat penyerapan dan manajemen, Anda akan memilih antara IoT Hub dan IoT Central.

Sebagian besar solusi IoT cocok dalam pola arsitektur akar, yang merupakan kombinasi dari target penyebaran, model penyewaan, dan pola penyebaran. Faktor-faktor ini ditentukan oleh persyaratan dan pertimbangan utama yang dijelaskan di atas.

Salah satu poin keputusan terbesar yang perlu dibuat, dalam ruang IoT, adalah memilih antara pendekatan application-platform-as-a-service (aPaaS) dan platform-as-a-service (PaaS). Untuk informasi selengkapnya, lihat Membandingkan pendekatan solusi Internet of Things (IoT) (PaaS vs. aPaaS).

Ini adalah dilema "build vs. buy" umum yang dihadapi banyak organisasi di banyak proyek. Penting untuk mengevaluasi kelebihan dan kekurangan dari kedua opsi.

Konsep dan pertimbangan untuk solusi aPaaS

Solusi aPaaS umum menggunakan Azure IoT Central, sebagai inti solusi, mungkin menggunakan layanan Azure PaaS dan aPaaS berikut:

• Azure Event Hubs sebagai mesin olahpesan lintas platform, olahpesan tingkat perusahaan, dan aliran data.
• Azure Logic Apps sebagai platform integrasi sebagai layanan, atau iPaaS, menawarkan.
• Azure Data Explorer sebagai platform analitik data.
• Power BI sebagai platform visualisasi dan pelaporan.

Dalam diagram sebelumnya, penyewa berbagi lingkungan IoT Central, Azure Data Explorer, Power BI, dan Azure Logic Apps.

Pendekatan ini umumnya merupakan cara tercepat untuk mendapatkan solusi pasar. Ini adalah layanan skala tinggi yang mendukung multipenyewa dengan menggunakan organisasi.

Penting untuk dipahami bahwa karena IoT Central adalah penawaran aPaaS, ada keputusan tertentu yang berada di luar kontrol pelaksana. Keputusan ini meliputi:

• IoT Central menggunakan ID Microsoft Entra sebagai penyedia identitasnya.
• Penyebaran IoT Central dicapai menggunakan operasi kontrol dan sarana data, yang menggabungkan dokumen deklaratif dengan kode imperatif.
• Dalam pola multipenyewa, batas node maksimum IoT Central (yang berlaku untuk induk dan daun) dan kedalaman pohon maksimum, dapat memaksa penyedia layanan untuk memiliki beberapa instans IoT Central. Dalam hal ini, Anda harus mempertimbangkan untuk mengikuti pola Stempel Penyebaran.
• IoT Central memberlakukan batas panggilan API, yang mungkin berdampak pada implementasi besar.

Konsep dan pertimbangan untuk solusi PaaS

Pendekatan berbasis PaaS mungkin menggunakan layanan Azure berikut:

• Azure IoT Hub sebagai konfigurasi perangkat inti dan platform komunikasi.
• Azure IoT Device Provisioning Service sebagai penyebaran perangkat dan platform konfigurasi awal.
• Azure Data Explorer untuk menyimpan dan menganalisis data rangkaian waktu jalur hangat dan dingin dari perangkat IoT.
• Azure Stream Analytics untuk menganalisis data jalur panas dari perangkat IoT.
• Azure IoT Edge untuk menjalankan kecerdasan buatan (AI), layanan pihak ketiga, atau logika bisnis Anda sendiri di perangkat IoT Edge.

Dalam diagram sebelumnya, setiap penyewa terhubung ke aplikasi web bersama, yang menerima data dari IoT Hubs dan aplikasi fungsi. Perangkat terhubung ke Device Provisioning Service dan ke IoT Hubs.

Pendekatan ini membutuhkan lebih banyak upaya pengembang untuk membuat, menyebarkan, dan memelihara solusi (versus pendekatan aPaaS). Lebih sedikit kemampuan yang dibangun sebelumnya untuk kenyamanan pelaksana. Ini berarti bahwa pendekatan ini juga menawarkan lebih banyak kontrol, karena lebih sedikit asumsi yang disematkan di platform yang mendasar.

Pola arsitektur akar

Tabel berikut mencantumkan pola umum untuk solusi IoT multipenyewa. Setiap pola mencakup informasi berikut:

• Nama Pola, yang didasarkan pada kombinasi jenis target, model, dan penyebaran.
• Target Penyebaran, mewakili Langganan Azure untuk menyebarkan sumber daya.
• Model Penyewaan yang dirujuk oleh pola, seperti yang dijelaskan pada model Multitenancy
• Pola Penyebaran, mengacu pada penyebaran sederhana dengan pertimbangan penyebaran minimal, pola Geode, atau pola Stempel Penyebaran.

Pola	Target penyebaran	Model penyewaan	Pola penyebaran
SaaS Sederhana	Langganan penyedia layanan	Sepenuhnya multipenyewa	Sederhana
Horizontal SaaS	Langganan penyedia layanan	Dipartisi secara horizontal	Stempel Penyebaran
Penyewa tunggal otomatis	Langganan penyedia layanan atau pelanggan	Penyewa tunggal per pelanggan	Sederhana

SaaS Sederhana

Target Penyebaran	Model Penyewaan	Pola Penyebaran
Langganan penyedia layanan	Sepenuhnya multipenyewa	Sederhana

Pendekatan SaaS Sederhana adalah implementasi paling sederhana untuk SaaS IoT Solution. Seperti yang ditunjukkan diagram sebelumnya, semua infrastruktur dibagikan, dan infrastruktur tidak memiliki stempel geografis atau skala yang diterapkan. Seringkali, infrastruktur berada dalam satu langganan Azure.

Azure IoT Central mendukung konsep organisasi. Organisasi memungkinkan penyedia solusi untuk dengan mudah memisahkan penyewa dengan cara yang aman dan hierarkis, sambil berbagi desain aplikasi dasar di semua penyewa.

Komunikasi ke sistem di luar IoT Central, seperti untuk analisis data jangka panjang, di sepanjang jalur dingin atau konektivitas dengan operasi bisnis, dilakukan melalui penawaran Microsoft PaaS dan aPaaS lainnya. Penawaran tambahan ini mungkin mencakup layanan berikut:

• Azure Event Hubs sebagai mesin olahpesan lintas platform, olahpesan tingkat perusahaan, dan aliran data.
• Azure Logic Apps sebagai platform integrasi sebagai layanan, atau iPaaS.
• Azure Data Explorer sebagai platform analitik data.
• Power BI sebagai platform visualisasi dan pelaporan.

Jika Anda membandingkan pendekatan SaaS Sederhana dengan model aPaaS otomatis penyewa tunggal, banyak karakteristik serupa. Perbedaan utama antara kedua model adalah bahwa dalam model otomatis penyewa tunggal, Anda menyebarkan instans IoT Central yang berbeda untuk setiap penyewa, sementara di SaaS Sederhana dengan model aPaaS , Anda sebaliknya menyebarkan instans bersama untuk beberapa pelanggan, dan Anda membuat organisasi IoT Central untuk setiap penyewa.

Saat berbagi tingkat data multipenyewa dalam model ini, Anda harus menerapkan keamanan tingkat baris, seperti yang dijelaskan dalam Pendekatan arsitektur untuk penyimpanan dan data dalam solusi multipenyewa, untuk mengisolasi data pelanggan.

Keuntungan:

• Lebih mudah dikelola dan beroperasi relatif terhadap pendekatan lain yang disajikan di sini.

Risiko:

• Pendekatan ini mungkin tidak mudah diskalakan ke jumlah perangkat, pesan, atau penyewa yang sangat tinggi.

• Karena semua layanan dan komponen dibagikan, kegagalan dalam komponen apa pun dapat memengaruhi semua penyewa Anda. Ini adalah risiko terhadap keandalan solusi Anda dan ketersediaan tinggi.

• Penting untuk mempertimbangkan bagaimana Anda mengelola kepatuhan, operasi, siklus hidup penyewa, dan keamanan sub-armada perangkat. Pertimbangan ini menjadi penting karena sifat bersama dari jenis solusi ini pada bidang kontrol, manajemen, dan komunikasi.

Horizontal SaaS

Target penyebaran	Model penyewaan	Pola penyebaran
Langganan penyedia layanan	Dipartisi secara horizontal	Stempel Penyebaran

Pendekatan skalabilitas umum adalah mempartisi solusi secara horizontal. Ini berarti Anda memiliki beberapa komponen bersama dan beberapa komponen per pelanggan.

Dalam solusi IoT, ada banyak komponen yang dapat dipartisi secara horizontal. Subsistem yang dipartisi secara horizontal biasanya diatur menggunakan pola stempel penyebaran yang terintegrasi dengan solusi yang lebih besar.

Contoh SaaS horizontal

Contoh arsitektur di bawah ini mempartisi IoT Central per pelanggan akhir, yang berfungsi sebagai manajemen perangkat, komunikasi perangkat, dan portal administrasi. Ini sering dilakukan sewaktu-waktu sehingga pelanggan akhir yang mengonsumsi solusi memiliki kontrol penuh atas penambahan, penghapusan, dan pembaruan perangkat itu sendiri, tanpa intervensi vendor perangkat lunak. Solusi lainnya mengikuti pola infrastruktur bersama standar, yang memecahkan untuk analisis jalur panas, integrasi bisnis, manajemen SaaS, dan kebutuhan analisis perangkat.

Setiap penyewa memiliki organisasi IoT Central mereka sendiri, yang mengirim telemetri ke aplikasi fungsi bersama dan membuatnya tersedia untuk pengguna bisnis penyewa melalui aplikasi web.

Keuntungan:

• Umumnya mudah dikelola dan dioperasikan, meskipun manajemen tambahan mungkin diperlukan untuk komponen penyewa tunggal.
• Opsi penskalakan yang fleksibel, karena lapisan diskalakan seperlunya.
• Dampak kegagalan komponen berkurang. Meskipun kegagalan komponen bersama berdampak pada semua pelanggan, komponen yang diskalakan secara horizontal hanya berdampak pada pelanggan yang terkait dengan instans skala tertentu.
• Meningkatkan wawasan konsumsi per penyewa untuk komponen yang dipartisi.
• Komponen yang dipartisi memberikan penyesuaian per penyewa yang lebih mudah.

Risiko:

• Pertimbangkan skala solusi, terutama untuk komponen bersama apa pun.
• Keandalan dan ketersediaan tinggi berpotensi terdampak. Satu kegagalan dalam komponen bersama dapat memengaruhi semua penyewa sekaligus.
• Penyesuaian komponen yang dipartisi per penyewa memerlukan DevOps jangka panjang dan pertimbangan manajemen.

Di bawah ini adalah komponen paling umum yang biasanya cocok untuk partisi horizontal.

Database

Anda dapat memilih untuk mempartisi database. Seringkali itu adalah penyimpanan data telemetri dan perangkat yang dipartisi. Seringkali, beberapa penyimpanan data digunakan untuk tujuan tertentu yang berbeda, seperti penyimpanan arsip versus hangat, atau untuk informasi status langganan penyewaan.

Pisahkan database untuk setiap penyewa, untuk manfaat berikut:

• Mendukung standar kepatuhan. Data setiap penyewa diisolasi di seluruh instans penyimpanan data.
• Meremediasi masalah tetangga yang berisik.

Manajemen, komunikasi, dan administrasi perangkat

Aplikasi Azure IoT Hub Device Provisioning Service, IoT Hub, dan IoT Central sering kali dapat disebarkan sebagai komponen yang dipartisi secara horizontal. Jika Anda mengikuti pendekatan ini, Anda harus memiliki layanan tambahan untuk mengalihkan perangkat ke Device Provisioning Service yang sesuai untuk manajemen, kontrol, dan bidang telemetri penyewa tertentu. Untuk informasi selengkapnya, lihat laporan resmi, Menskalakan solusi Azure IoT untuk mendukung jutaan perangkat.

Hal ini sering dilakukan untuk memungkinkan pelanggan akhir mengelola dan mengontrol armada perangkat mereka sendiri yang lebih langsung dan sepenuhnya terisolasi.

Jika bidang komunikasi perangkat dipartisi secara horizontal, data telemetri harus diperkaya dengan data untuk penyewa sumber, sehingga prosesor aliran mengetahui aturan penyewa mana yang akan diterapkan ke aliran data. Misalnya, jika pesan telemetri menghasilkan pemberitahuan di prosesor stream, prosesor stream harus menentukan jalur pemberitahuan yang tepat untuk penyewa terkait.

Pemrosesan aliran

Dengan mempartisi pemrosesan aliran, Anda mengaktifkan penyesuaian per penyewa analisis dalam prosesor stream.

Penyewa tunggal otomatis

Pendekatan otomatis penyewa tunggal didasarkan pada proses keputusan serupa dan desain ke solusi perusahaan.

Setiap penyewa memiliki lingkungannya sendiri yang identik dan terisolasi, dengan organisasi IoT Central dan komponen lain yang didedikasikan untuk mereka.

Target Penyebaran	Model Penyewaan	Pola Penyebaran
Langganan penyedia layanan atau pelanggan	Penyewa tunggal per pelanggan	Sederhana

Titik keputusan penting dalam pendekatan ini adalah memilih langganan Azure mana yang harus disebarkan oleh komponen. Jika komponen disebarkan ke langganan Anda, Anda memiliki lebih banyak kontrol dan visibilitas yang lebih baik ke dalam biaya solusi, tetapi mengharuskan Anda untuk memiliki lebih banyak masalah keamanan dan tata kelola solusi. Sebaliknya, jika solusi disebarkan dalam langganan pelanggan Anda, pelanggan pada akhirnya bertanggung jawab atas keamanan dan tata kelola penyebaran.

Pola ini mendukung tingkat skalabilitas yang tinggi. Ini karena persyaratan penyewa dan langganan umumnya merupakan faktor pembatasan di sebagian besar solusi. Oleh karena itu, isolasi setiap penyewa untuk memberikan cakupan besar untuk menskalakan beban kerja setiap penyewa, tanpa upaya besar di pihak Anda, sebagai pengembang solusi.

Pola ini umumnya juga memiliki latensi rendah, jika dibandingkan dengan pola lain, karena Anda dapat menyebarkan komponen solusi berdasarkan geografi pelanggan Anda. Afinitas geografis memungkinkan jalur jaringan yang lebih pendek antara perangkat IoT dan penyebaran Azure Anda.

Jika perlu, Anda dapat memperluas penyebaran otomatis untuk mendukung latensi atau skala yang ditingkatkan, dengan memungkinkan penyebaran cepat instans tambahan solusi, untuk pelanggan di geografi yang ada atau baru.

Pendekatan otomatis penyewa tunggal mirip dengan model SaaS aPaaS sederhana. Perbedaan utama antara kedua model adalah bahwa dalam pendekatan otomatis penyewa tunggal, Anda menyebarkan instans IoT Central yang berbeda untuk setiap penyewa, sementara dalam SaaS sederhana dengan model aPaaS, Anda menyebarkan instans bersama IoT Central dengan beberapa organisasi IoT Central.

Keuntungan:

• Relatif mudah dikelola dan dioperasikan.
• Isolasi penyewa pada dasarnya dijamin.

Risiko:

• Otomatisasi awal dapat rumit untuk staf pengembangan baru.
• Keamanan kredensial lintas pelanggan untuk manajemen penyebaran tingkat yang lebih tinggi harus diberlakukan, atau kompromi dapat diperluas di seluruh pelanggan.
• Biaya diperkirakan akan lebih tinggi, karena manfaat skala infrastruktur bersama di seluruh pelanggan tidak tersedia.
• Jika penyedia solusi memiliki pemeliharaan setiap instans, Anda mungkin memiliki banyak instans untuk dipertahankan.

Meningkatkan skala SaaS

Ketika Anda memperluas skala solusi untuk penyebaran yang sangat besar, ada tantangan khusus yang muncul berdasarkan batas layanan, masalah geografis, dan faktor lainnya. Untuk informasi selengkapnya tentang arsitektur penyebaran IoT skala besar, lihat Menskalakan solusi Azure IoT untuk mendukung jutaan perangkat.

Kontributor

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

Penulis utama:

• Michael C. Bazarewsky | Insinyur Pelanggan Senior, FastTrack untuk Azure
• David Crook | Teknisi Pelanggan Utama, FastTrack untuk Azure

Kontributor lain:

• John Downs | Insinyur Perangkat Lunak Utama
• Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure

Langkah berikutnya

• Tinjau panduan untuk multitenansi dan Azure Cosmos DB.
• Pelajari tentang jalur data panas, hangat, dan dingin dengan IoT di Azure.
• Lihat arsitektur referensi Azure IoT.
• Tinjau dokumentasi tentang cara Menskalakan solusi IoT dengan stempel penyebaran.