AWS dan IBM: Perbandingan Perkhidmatan IoT: 4 Langkah

2024 Pengarang: John Day | [email protected]. Diubah suai terakhir: 2024-01-30 11:09

Hari ini kami membandingkan dua timbunan yang memungkinkan untuk mengembangkan aplikasi IoT berdasarkan pandangan tawaran perkhidmatan yang berbeza.

Langkah 1: Berfungsi Sebagai Perkhidmatan

FaaS adalah kategori perkhidmatan cloud yang digunakan untuk membina seni bina "tanpa server". FaaS membolehkan pelanggan mengembangkan, menjalankan, dan menguruskan fungsi aplikasi tanpa membina dan menyelenggara infrastruktur.

Amazon menawarkan AWS Lambda, IBM menawarkan Fungsi Cloud IBM. Perkhidmatan tersebut agak serupa, namun Lambda adalah yang pertama seumpamanya. Dengan menggunakan FaaS, anda dapat menjalankan potongan kod di awan dan setiap perkhidmatan menyokong bahasa pengaturcaraan yang berbeza.

Fungsi Awan IBM: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C # F # dll), Mana-mana melalui Docker AWS Lambda: JavaScript, Java, C #, F #, Go, Python, Ruby, PowerShell, Any melalui Runtime API

IBM Menyokong lebih banyak bahasa dan dengan docker skrip yang mudah digunakan ditulis dalam bahasa lain. Ini boleh dilakukan juga dengan Lambda tetapi tidak segera. Anda boleh membaca contoh di sini:

Kedua-dua perkhidmatan mempunyai had penggunaan, kami melaporkannya dalam jadual dan menyoroti yang terbaik.

Harganya berdasarkan GigaBytes per saat (RAM) dengan penambahan jumlah permintaan untuk AWS Lambda. Setiap perkhidmatan mempunyai rancangan percuma dan mereka hampir setara. Seperti yang anda lihat, Lambda sedikit lebih murah untuk GB / s tetapi ia mempunyai kos yang berkaitan dengan permintaan bahawa Cloud Functions tidak mempunyai kos sehingga hampir sama. Sudah tentu, jika anda perlu menjalankan tugas yang memakan memori dan menggunakan beberapa permintaan, anda harus menggunakan Lambda. Kelebihan utama IBM Cloud Function, menurut pendapat kami, ialah timbunannya adalah sumber terbuka. Ini sepenuhnya berdasarkan pada Apache OpenWhisk dan juga dapat digunakan pada infrastruktur swasta.

Langkah 2: Pembelajaran Mesin

Bidang di mana tumpukan IBM dan AWS menawarkan perkhidmatan yang serupa dengan pembelajaran mesin: Amazon dengan SageMaker dan IBM dengan Pembelajaran Mesin Watson. Kedua-dua perkhidmatan itu dalam banyak aspek sangat serupa: kedua-duanya menampilkan diri sebagai alat untuk membantu para saintis dan pembangun data membina, melatih dan kemudian menyebarkan ke dalam persekitaran siap produksi model pembelajaran mesin mereka, tetapi falsafah yang diamalkan oleh kedua-dua syarikat itu sedikit berbeza. Kedua-dua perkhidmatan ini membolehkan anda memilih antara tahap kawalan yang berbeza pada model yang anda gunakan. Di Watson ML, anda mempunyai beberapa model bawaan yang sudah dilatih untuk melakukan beberapa tugas yang sangat spesifik: sebagai contoh, jika anda ingin mengenali objek apa yang ada dalam gambar, anda hanya mengimport model VisualRecognitionV3 dan menyampaikannya gambar yang anda mahu menganalisis. Anda juga boleh membina "model khusus", tetapi di Watson ML ini bererti mengambil model yang sudah dibina dan melatihnya, jadi penyesuaiannya agak terhad. Penting untuk diperhatikan walaupun SageMaker dan Watson ML bukan satu-satunya cara untuk melakukan pembelajaran mesin di tumpukan pembangun mereka, mereka hanyalah perkhidmatan yang bertujuan untuk mempermudah kehidupan pengembang. Platform Watson ML juga menyokong banyak perpustakaan pembelajaran mesin yang paling popular, jadi anda juga boleh membina model dari awal dengan PyTorch, Tensorflow atau perpustakaan serupa. Anda sama ada menggunakan perpustakaan tersebut secara langsung, atau menggunakan model yang telah dibuat sebelumnya, tidak ada jalan tengah. Watson ML juga tidak menyokong perpustakaan pilihan Amazon, Apache MXNet, yang sebaliknya mempunyai sokongan kelas pertama di SageMaker.

Pendekatan Amazon SageMaker, walaupun menggunakan pilihan terbina dalam, adalah tahap yang lebih rendah: daripada membuat anda memilih dari model pra-buatan, ini membolehkan anda memilih dari banyak algoritma latihan yang sudah dilaksanakan, yang boleh anda gunakan semasa membina model dengan cara yang lebih tradisional. Sekiranya ini tidak mencukupi, anda juga boleh menggunakan algoritma anda sendiri. Cara melakukan perkara ini tentunya memerlukan lebih banyak pengetahuan tentang bagaimana pembelajaran mesin dilakukan berbanding dengan hanya menggunakan model terlatih di Watson ML.

Pada pandangan pertama, nampaknya Watson ML adalah cara "mudah dan cepat", dengan Amazon SageMaker menjadi cara yang lebih kompleks untuk disiapkan. Ini mungkin tidak sepenuhnya benar dari beberapa sudut pandang, kerana SageMaker disusun untuk menjadikan semuanya berjalan di Jupyter Notebook, sementara untuk ciri yang sama di Watson ML, anda harus menyediakan banyak sub-perkhidmatan yang berbeza dari UI web. Praproses data juga mempunyai ruang khusus pada perkhidmatan IBM sementara SageMaker bergantung pada anda melakukan semuanya dari kod dalam buku nota anda. Ini ditambah dengan fakta bahawa buku nota Jupyter bukanlah pilihan terbaik dari sudut pandang kejuruteraan perisian, boleh menghalang SageMaker daripada membuat pengeluaran dengan baik. Kedua-dua perkhidmatan mempunyai mekanisme yang cukup baik dan sederhana untuk menggunakan model anda dan menyediakan API untuknya tersedia di dunia luar.

Kesimpulannya, Watson ML berprestasi lebih baik dalam projek besar di mana notebook Jupyter mula menunjukkan hadnya, dan di mana anda tidak memerlukan banyak penyesuaian dalam apa yang dilakukan oleh model itu sendiri. SageMaker jauh lebih baik apabila anda memerlukan lebih banyak fleksibiliti dalam menentukan algoritma, tetapi ketika menggunakannya, anda harus mempertimbangkan fakta bahawa anda harus bergantung pada Jupyter Notebook, yang mungkin tidak sesuai dengan pengeluaran. Penyelesaiannya adalah dengan mencabut selebihnya kod dari model sebanyak mungkin, supaya kod dalam buku nota yang sebenarnya tidak terlalu besar dan kita dapat mengatur perisian kita dengan lebih baik di modul lain yang hanya menggunakan API model kita..

Langkah 3: Penstriman & Analisis Data

Perkhidmatan streaming data sangat penting dalam menangani dan menganalisis aliran data dalam masa nyata. Aliran ini dapat dari awan ke perangkat pengguna, seperti streaming video, atau dari pengguna ke awan, seperti telemetri IoT dan pembacaan sensor. Terutama dalam kes kedua, kita mungkin mempunyai situasi di mana satu sumber memuat naik sejumlah kecil data tetapi apabila kita mempertimbangkan keseluruhan throughput, yang berasal dari semua peranti, ia menggunakan lebar jalur yang cukup besar, oleh itu masuk akal untuk menggunakan perkhidmatan yang khusus untuk menangani aliran data. Tanpa mengendalikan aliran berterusan ini secara langsung, kita harus menyimpan maklumat masuk ke dalam simpanan sementara dan dalam proses kedua memprosesnya dengan beberapa mesin komputasi. Masalah pendekatan terakhir ini adalah bahawa kita harus mengkoordinasikan perkhidmatan yang lebih berbeza untuk mencapai apa yang telah dilakukan oleh satu-satunya perkhidmatan aliran data sahaja, meningkatkan kerumitan penyelenggaraan dan konfigurasi aplikasi. Sebagai tambahan, buffering pada prinsipnya dapat membuat aplikasi kita tidak lagi dalam waktu nyata, kerana untuk item yang akan diproses, perlu semua item lain sebelum diproses juga, dan menambahkan kebijakan keutamaan pada buffer dapat, sekali lagi, meningkatkan kerumitan secara drastik. Ringkasnya, perkhidmatan streaming data menawarkan penanganan aliran data dalam waktu nyata, dengan konfigurasi yang mudah, dan dapat memberikan analisis mengenai data yang masuk. Di sini kita membandingkan dua perkhidmatan streaming utama stack IBM dan AWS, iaitu IBM Streams dan AWS Kinesis.

Kita mulakan dengan menyatakan bahawa semua ciri asas yang mungkin kita mahukan dari perkhidmatan streaming ditawarkan oleh IBM dan AWS. Ciri-ciri ini merangkumi kadar pemprosesan yang hampir tidak terbatas, latensi rendah dan analisis data masa nyata. Oleh kerana kita bercakap mengenai perkhidmatan profesional, mereka berdua menawarkan alat peringkat pengeluaran untuk penggunaan dan automasi.

Bercakap mengenai analisis data, kedua-dua perkhidmatan menawarkannya sebagai pilihan, menjadikan anda membayar hanya sama ada anda memerlukannya atau tidak. Sekiranya Kinesis, apabila anda tidak memerlukan analisis tetapi hanya pengendalian aliran data, harga dikenakan setiap GB yang diproses dan bukannya masa memproses, seperti dalam kes IBM. Harga per GB pada umumnya akan lebih murah daripada harga setiap masa, kerana anda hanya membayar untuk lalu lintas yang masuk. Untuk sepanjang catatan ini, kami akan mempertimbangkan IBM Streams dan AWS Kinesis dengan ciri analisis data diaktifkan.

Streams dan Kinesis menyediakan integrasi dengan perkhidmatan yang berbeza untuk memproses dan menyaring data yang masuk sebelum menyampaikannya ke analisis data, masing-masing dengan Apache Edgent dan AWS Lambda. Walaupun perkhidmatan ini sangat berbeza antara satu sama lain, kami akan membincangkannya hanya dari sudut pandang kedua perkhidmatan streaming. Perbezaan asas antara keduanya adalah bahawa Apache Edgent dijalankan pada peranti, sementara AWS Lambda dijalankan di awan. Ini membawa banyak kebaikan dan keburukan: dari sisi Lambda kami mempunyai perkhidmatan yang fleksibel dan mudah digunakan dengan integrasi yang lancar dengan Kinesis, tetapi ia memerlukan data yang telah dimuat naik ke awan, sehingga kehilangan kecekapan dan membayar Kinesis juga untuk data yang akhirnya akan dibuang. Sebaliknya, dari sisi Edgent, kita membuat sebahagian besar pengiraan dilakukan, di tepi rangkaian (dengan demikian pada peranti) sebelum memuat naik data yang tidak berguna di awan. Kelemahan utama adalah bahawa Edgent adalah kerangka besar, yang mungkin memerlukan waktu untuk disiapkan dan mungkin kompleks untuk dikekalkan. Perbezaan lain yang mungkin relevan dalam pilihan platform adalah bahawa Edgent adalah sumber terbuka sepenuhnya, Lambda tidak. Ini dapat dilihat baik sebagai profesional, kerana memiliki akses ke kod yang akan Anda atau pelanggan anda laksanakan selalu menjadi hal yang positif, baik sebagai penipu, kerana mungkin ada situasi di mana anda memerlukan sokongan segera yang tidak dapat diberikan di semua persekitaran sumber terbuka.

Ciri-ciri lain yang dapat kita sebutkan adalah kemampuan automatik Kinesis dari sumber yang diperuntukkan. Sesungguhnya, perkakasan yang ditawarkannya disusun oleh sejumlah Unit Pemprosesan Kinesis (KPU) yang berjalan secara selari, di mana satu KPU menawarkan 1 vCore dan 4GB RAM. Jumlah mereka bergantung pada keperluan aplikasi dan diperuntukkan secara dinamis dan automatik (apa yang anda bayar sememangnya cpu kali kali jumlah KPU), ingatlah bahawa itu adalah kebijakan Kinesis untuk mengenakan satu KPU lebih banyak jika anda menggunakan Java permohonan. Aliran IBM, sebaliknya, tidak memberikan fleksibiliti seperti ini, menawarkan wadah dengan perkakasan tetap, lebih banyak perincian ketika kita membincangkan mengenai harga. Sebaliknya, Aliran IBM lebih terbuka daripada Kinesis, kerana ia menghubungkan ke WAN melalui protokol yang biasa digunakan, seperti HTTP, MQTT dan sebagainya, sementara Kinesis ditutup ke ekosistem AWS.

Sebagai perbandingan terakhir, mari kita bincangkan mengenai harga, dan saya beritahu bahawa IBM tidak berfungsi dengan baik pada masa ini. Kami telah mengkonfigurasi penyelesaian yang berbeza untuk tiga kategori yang berbeza (asas, mewah, ultra-mewah) untuk IBM dan AWS, dan kami akan membandingkan harganya. Dalam konfigurasi asas kita mempunyai satu KPU AWS, yang disebutkan sebelumnya, terhadap penyelesaian IBM dengan perkakasan yang sama. Untuk kelas atas kami mempunyai 8 KPU yang berjalan selari untuk Kinesis dan 2 kontena sentiasa selari untuk IBM, masing-masing dengan 4 vCores dan 12GB RAM. Sentiasa IBM menawarkan dalam satu wadah ultra-high-end dengan 16 vCores dan 128GB RAM, sementara kami menghilangkan penyelesaian yang setara untuk AWS, kerana jika beberapa aplikasi memerlukan sejumlah besar RAM, tidak mungkin menjalankannya pada KPU yang berbeza. Harga yang kami laporkan dinyatakan dalam $ / bulan dengan mempertimbangkan penggunaan 24/7. Untuk konfigurasi asas yang kami miliki untuk IBM dan AWS masing-masing 164 $ dan 490 $, untuk $ 1320 mewah dan 3500 $, untuk AWS kelas atas tidak dipertimbangkan dan hanya IBM dengan $ 6300. Dari hasil ini kita dapat melihat bahawa Kinesis berfungsi lebih baik untuk pengguna sehari-hari hingga tingkat perusahaan, sementara kekurangan pilihan untuk mengendalikan analisis data secara langsung yang memerlukan sejumlah besar daya pengkomputeran. Kinesis memberikan nisbah prestasi / $ yang lebih baik daripada IBM Streams, dibantu juga oleh peruntukan dinamik blok sumber kecil hanya apabila diperlukan, sementara IBM menawarkan anda wadah tetap. Dengan cara ini, jika beban kerja anda dicirikan oleh puncak, dengan IBM, anda terpaksa menilai terlebih dahulu keperluan aplikasi anda dan mengkonfigurasi penyelesaian dalam senario terburuk. IBM menawarkan bayaran berjam-jam dan bukannya membayar sebulan penuh, tetapi tidak automatik seperti Kinesis.

Langkah 4: Senibina IoT

Konfigurasi untuk peranti aws iot cukup mudah jika dibandingkan dengan ibm watson iot. Kerana di ibm watson, pengesahan adalah untuk setiap peranti dengan token dan setelah ia memaparkan token, ia tidak akan dipaparkan lagi. Datang ke harga lagi ibm watson iot agak mahal berbanding aws iot. Oleh itu, harga dalam caj ibm watson iot berdasarkan pada setiap peranti, penyimpanan data, lalu lintas data. Tetapi dalam masa yang sama kita dapat membayar jumlahnya sekali dan kita dapat menambahkan lebih banyak peranti dan data yang diterbitkan dari peranti dan dihantar ke peranti.

Mulakan dengan peranti anda - sama ada sensor, pintu masuk, atau yang lain- dan biarkan kami membantu anda untuk berhubung dengan awan.

Data peranti anda sentiasa selamat ketika anda menyambung ke awan menggunakan protokol pesanan terbuka atau ringan MGTT atau HTTP. Dengan bantuan protokol dan simpul-merah kita dapat menghubungkan peranti kita dengan platform iot dan dapat mengakses data langsung dan sejarah.

Gunakan API selamat kami untuk menghubungkan aplikasi anda dengan data dari peranti anda.

Buat aplikasi dalam perkhidmatan cloud kami untuk mentafsirkan data.