AWS dan IBM: Perbandingan Layanan IoT: 4 Langkah

2024 Pengarang: John Day | [email protected]. Terakhir diubah: 2024-01-30 09:56

Hari ini kami membandingkan dua tumpukan yang memungkinkan untuk mengembangkan aplikasi IoT di bawah sudut pandang penawaran layanan yang berbeda.

Langkah 1: Berfungsi Sebagai Layanan

FaaS adalah kategori layanan cloud yang digunakan untuk membangun arsitektur "tanpa server". FaaS memungkinkan pelanggan untuk mengembangkan, menjalankan, dan mengelola fungsionalitas aplikasi tanpa membangun dan memelihara infrastruktur.

Amazon menawarkan AWS Lambda, IBM menawarkan IBM Cloud Functions. Layanan tersebut sangat mirip, namun Lambda adalah yang pertama dari jenis ini. Menggunakan FaaS Anda dapat menjalankan potongan kode di cloud dan setiap layanan mendukung bahasa pemrograman yang berbeda.

IBM Cloud Functions: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# dll.), Any via Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Any melalui Runtime API

IBM Mendukung lebih banyak bahasa dan dengan docker skrip yang ditulis dalam bahasa lain mudah digunakan. Ini dapat dilakukan juga dengan Lambda tetapi tidak langsung. Anda dapat membaca contohnya di sini:

Kedua layanan memiliki batas penggunaan, kami melaporkannya dalam tabel dan menyoroti yang terbaik.

Harga didasarkan pada GigaBytes per detik (RAM) dengan penambahan jumlah permintaan untuk AWS Lambda. Setiap layanan memiliki paket gratis dan hampir setara. Seperti yang Anda lihat, Lambda sedikit lebih murah untuk GB/s tetapi memiliki biaya yang terkait dengan permintaan yang tidak dimiliki Cloud Functions sehingga biayanya hampir sama secara umum. Tentu saja, jika Anda perlu menjalankan tugas yang memakan memori dan menggunakan sedikit permintaan, Anda harus menggunakan Lambda. Keunggulan utama IBM Cloud Function menurut kami adalah stack-nya bersifat open source. Ini sepenuhnya didasarkan pada Apache OpenWhisk dan dapat juga digunakan pada infrastruktur pribadi.

Langkah 2: Pembelajaran Mesin

Bidang di mana tumpukan IBM dan AWS menawarkan layanan serupa adalah bidang pembelajaran mesin: Amazon dengan SageMaker dan IBM dengan Pembelajaran Mesin Watson. Kedua layanan tersebut dalam banyak aspek sangat mirip: keduanya menampilkan diri sebagai alat untuk membantu ilmuwan dan pengembang data membangun, melatih, dan kemudian menerapkan model pembelajaran mesin mereka ke lingkungan siap produksi, tetapi filosofi yang diadopsi kedua perusahaan sedikit berbeda. Kedua layanan memungkinkan Anda memilih di antara tingkat kontrol yang berbeda pada model yang Anda gunakan. Di Watson ML, Anda memiliki beberapa model bawaan yang sudah dilatih untuk melakukan beberapa tugas yang sangat spesifik: misalnya, jika Anda ingin mengenali objek apa yang ada dalam gambar, Anda cukup mengimpor model VisualRecognitionV3 dan meneruskannya ke gambar yang Anda ingin menganalisis. Anda juga dapat membuat "model khusus", tetapi di Watson ML ini sebagian besar berarti mengambil model yang sudah dibuat dan melakukan pelatihan kami di atasnya, sehingga penyesuaiannya sangat terbatas. Penting untuk diperhatikan bahwa baik SageMaker maupun Watson ML bukanlah satu-satunya cara untuk melakukan pembelajaran mesin di tumpukan pengembang mereka, mereka hanyalah layanan yang bertujuan untuk membuat hidup para pengembang lebih mudah. Platform Watson ML juga mendukung banyak perpustakaan pembelajaran mesin paling populer, sehingga Anda bahkan dapat membuat model dari awal dengan PyTorch, Tensorflow, atau perpustakaan serupa. Anda dapat menggunakan perpustakaan tersebut secara langsung, atau menggunakan model yang telah dibuat sebelumnya, tidak ada jalan tengah. Watson ML juga tidak mendukung perpustakaan pilihan Amazon, Apache MXNet, yang sebaliknya memiliki dukungan kelas satu di SageMaker.

Pendekatan Amazon SageMaker, bahkan saat menggunakan opsi bawaan, sedikit lebih rendah: daripada membuat Anda memilih dari model yang dibuat sebelumnya, ini memungkinkan Anda memilih dari banyak algoritme pelatihan yang sudah diterapkan, yang dapat Anda gunakan saat membangun model dengan cara yang lebih tradisional. Jika ini tidak cukup, Anda juga dapat menggunakan algoritme Anda sendiri. Cara melakukan hal ini tentu membutuhkan lebih banyak pengetahuan tentang bagaimana pembelajaran mesin dilakukan dibandingkan dengan hanya menggunakan model terlatih di Watson ML.

Sepintas tampaknya Watson ML adalah cara yang “mudah dan cepat”, dengan Amazon SageMaker yang lebih rumit untuk disiapkan. Ini mungkin tidak sepenuhnya benar dari beberapa sudut pandang, karena SageMaker terstruktur untuk membuat semuanya berjalan di Notebook Jupyter, sedangkan untuk fitur yang sama di Watson ML Anda harus menyiapkan banyak sub-layanan berbeda dari UI web. Prapemrosesan data juga memiliki ruang khusus pada layanan IBM sementara SageMaker mengandalkan Anda untuk melakukan semuanya dari kode di notebook Anda. Ini ditambah fakta bahwa notebook Jupyter bukanlah pilihan terbaik dari sudut pandang rekayasa perangkat lunak, dapat mencegah SageMaker menskalakan dengan sangat baik dalam produksi. Kedua layanan memiliki mekanisme yang cukup bagus dan sederhana untuk menerapkan model Anda dan membuat API untuknya tersedia di dunia luar.

Kesimpulannya, Watson ML berkinerja lebih baik dalam proyek besar di mana notebook Jupyter mulai menunjukkan batasnya, dan di mana Anda tidak perlu banyak penyesuaian dalam apa yang dilakukan model itu sendiri. SageMaker jauh lebih baik saat Anda membutuhkan lebih banyak fleksibilitas dalam mendefinisikan algoritme, tetapi saat menggunakannya, Anda perlu mempertimbangkan fakta bahwa Anda harus mengandalkan Jupyter Notebooks, yang mungkin tidak berskala produksi dengan baik. Solusinya adalah dengan memisahkan sisa kode dari model sebanyak mungkin, sehingga kode di buku catatan yang sebenarnya tidak menjadi terlalu besar dan kami dapat mengatur perangkat lunak kami dengan lebih baik di modul lain yang hanya menggunakan API model kami..

Langkah 3: Streaming & Analisis Data

Layanan streaming data sangat penting dalam menangani dan menganalisis aliran data besar secara real time. Aliran ini bisa dari cloud ke perangkat pengguna, seperti streaming video, atau dari pengguna ke cloud, seperti telemetri IoT dan pembacaan sensor. Khususnya dalam kasus kedua, kita dapat memiliki situasi di mana sumber tunggal mengunggah sejumlah kecil data tetapi ketika kita mempertimbangkan throughput keseluruhan, yang berasal dari semua perangkat, itu menghabiskan bandwidth yang cukup besar, sehingga masuk akal untuk menggunakan layanan khusus untuk menangani seperti itu. aliran data. Tanpa menangani aliran kontinu ini secara langsung, kita harus menyangga informasi yang masuk ke dalam penyimpanan sementara dan untuk kedua kalinya memprosesnya dengan beberapa mesin komputasi. Masalah dari pendekatan terakhir ini adalah bahwa kita harus mengoordinasikan lebih banyak layanan yang berbeda untuk mencapai apa yang telah dilakukan oleh satu layanan aliran data saja, meningkatkan kompleksitas pemeliharaan dan konfigurasi aplikasi. Selain itu, buffering pada prinsipnya dapat membuat aplikasi kita tidak lagi secara real time, karena untuk suatu item yang akan diproses perlu semua item lainnya sebelum diproses juga, dan menambahkan kebijakan prioritas ke buffer dapat, lagi, meningkatkan kompleksitas secara drastis. Kesimpulannya, layanan data streaming menawarkan penanganan aliran data secara real time, dengan konfigurasi yang mudah, dan dapat memberikan analisis terhadap data yang masuk. Di sini kami membandingkan dua layanan streaming utama tumpukan IBM dan AWS, yaitu IBM Streams dan AWS Kinesis.

Kami mulai dengan mencatat bahwa semua fitur dasar yang mungkin kami inginkan dari layanan streaming ditawarkan oleh IBM dan AWS. Fitur-fitur ini mencakup kecepatan pemrosesan yang hampir tak terbatas, latensi rendah, dan analitik data waktu nyata. Karena kita berbicara tentang layanan profesional, keduanya menawarkan alat tingkat produksi untuk penerapan dan otomatisasi.

Berbicara tentang analitik data, kedua layanan menawarkannya sebagai opsional, membuat Anda hanya membayar apakah Anda membutuhkannya atau tidak. Dalam kasus Kinesis, ketika Anda tidak memerlukan analitik tetapi hanya penanganan aliran data, harga dikenakan per GB yang diproses alih-alih waktu pemrosesan, seperti dalam kasus IBM. Harga per GB umumnya akan lebih murah daripada harga per waktu, karena Anda hanya membayar untuk lalu lintas masuk. Untuk sisa posting ini, kami akan mempertimbangkan IBM Streams dan AWS Kinesis dengan fitur analitik data diaktifkan.

Streams dan Kinesis menyediakan integrasi dengan berbagai layanan untuk pra-pemrosesan dan pemfilteran data yang masuk sebelum meneruskannya ke analitik data, masing-masing dengan Apache Edget dan AWS Lambda. Meskipun layanan ini sangat berbeda satu sama lain, kami akan membahasnya hanya dari sudut pandang kedua layanan streaming. Perbedaan mendasar antara keduanya adalah Apache Edget dijalankan di perangkat, sementara AWS Lambda dijalankan di cloud. Ini membawa banyak pro dan kontra: dari sisi Lambda kami memiliki layanan yang fleksibel dan mudah digunakan dengan integrasi tanpa batas dengan Kinesis, tetapi memerlukan data yang sudah diunggah ke cloud, sehingga kehilangan efisiensi dan membayar Kinesis juga untuk data yang pada akhirnya akan dibuang. Dari sisi Edget, kami memiliki bahwa sebagian besar perhitungan dilakukan, baik, di tepi jaringan (dengan demikian pada perangkat) sebelum mengunggah data yang tidak berguna di cloud. Kelemahan utama adalah bahwa Edget adalah kerangka kerja yang besar, yang mungkin memerlukan waktu untuk menyiapkan dan mungkin rumit untuk dipelihara. Perbedaan lain yang mungkin relevan dalam pilihan platform adalah bahwa Edget sepenuhnya open source, Lambda tidak. Ini dapat dilihat baik sebagai pro, karena memiliki akses ke kode yang Anda atau pelanggan Anda akan jalankan selalu merupakan hal yang positif, baik sebagai penipu, karena mungkin ada situasi di mana Anda memerlukan dukungan mendesak yang tidak dapat diberikan dalam semua lingkungan sumber terbuka.

Fitur lain yang dapat kami sebutkan adalah skalabilitas otomatis Kinesis dari sumber daya yang dialokasikan. Memang, perangkat keras yang ditawarkannya terdiri dari sejumlah Kinesis Processing Unit (KPU) yang berjalan paralel, di mana satu KPU menawarkan 1 vCore dan RAM 4GB. Jumlah mereka tergantung pada kebutuhan aplikasi dan dialokasikan secara dinamis dan otomatis (yang Anda bayarkan memang waktu cpu dikalikan jumlah KPU), ingatlah bahwa kebijakan Kinesis untuk menagih Anda satu KPU lebih jika Anda menggunakan Java aplikasi. IBM Streams, sebaliknya, tidak memberikan fleksibilitas semacam ini, menawarkan Anda wadah dengan perangkat keras tetap, detail lebih lanjut ketika kita berbicara tentang harga. Di sisi lain, IBM Streams lebih terbuka daripada Kinesis, karena antarmuka ke WAN melalui protokol yang umum digunakan, seperti HTTP, MQTT, dan sebagainya, sementara Kinesis tertutup untuk ekosistem AWS.

Sebagai perbandingan terakhir, mari kita bicara tentang penetapan harga, dan izinkan saya memberi tahu bahwa IBM tidak bekerja dengan baik dalam hal ini. Kami telah mengonfigurasi solusi yang berbeda untuk tiga kategori berbeda (dasar, kelas atas, ultra kelas atas) untuk IBM dan AWS, dan kami akan membandingkan harganya. Dalam konfigurasi dasar kami memiliki satu AWS KPU, yang disebutkan sebelumnya, terhadap solusi IBM dengan perangkat keras yang sama. Untuk kelas atas, kami memiliki 8 KPU yang berjalan paralel untuk Kinesis dan 2 kontainer selalu paralel untuk IBM, masing-masing dengan 4 vCore dan RAM 12GB. Selalu IBM menawarkan di ultra-high-end satu wadah dengan 16 vCore dan 128GB RAM, sementara kami menghilangkan solusi yang setara untuk AWS, karena jika beberapa aplikasi memerlukan RAM sebesar ini, tidak mungkin untuk menjalankannya di KPU yang berbeda. Harga yang kami laporkan dinyatakan dalam $/bulan dengan mempertimbangkan penggunaan 24/7. Untuk konfigurasi dasar yang kami miliki untuk IBM dan AWS masing-masing 164$ dan 490$, untuk high-end 1320$ dan 3500$, untuk ultra-high-end AWS tidak dipertimbangkan dan hanya ada IBM dengan 6300$. Dari hasil ini kita dapat melihat bahwa Kinesis bekerja lebih baik untuk pengguna sehari-hari hingga tingkat perusahaan, sementara itu tidak memiliki opsi untuk menangani analitik data secara langsung yang membutuhkan daya komputasi yang sangat besar. Kinesis memberikan rasio kinerja/$ yang lebih baik daripada IBM Streams, dibantu juga oleh alokasi dinamis blok sumber daya kecil hanya bila diperlukan, sementara IBM menawarkan wadah tetap kepada Anda. Dengan cara ini, jika beban kerja Anda ditandai dengan puncak, dengan IBM Anda dipaksa untuk melebih-lebihkan kebutuhan aplikasi Anda dan mengonfigurasi solusi dalam skenario terburuk. IBM menawarkan biaya jam alih-alih membayar sebulan penuh, tetapi tidak otomatis seperti Kinesis.

Langkah 4: Arsitektur IoT

Konfigurasi perangkat untuk aws iot cukup mudah jika dibandingkan dengan ibm watson iot. Karena di ibm watson iot otentikasi adalah per perangkat dengan token dan sekali menampilkan token itu tidak akan pernah ditampilkan lagi. Datang ke bagian harga lagi ibm watson iot cukup mahal dibandingkan dengan aws iot. Jadi, harga dalam biaya ibm watson iot didasarkan pada per perangkat, penyimpanan data, lalu lintas data. Tapi di aws iot kami dapat membayar jumlah sekali dan kami dapat menambahkan lebih banyak perangkat dan data yang diterbitkan dari perangkat dan dikirim ke perangkat.

Mulailah dengan perangkat Anda- baik itu sensor, gateway, atau lainnya- dan biarkan kami membantu Anda terhubung dengan cloud.

Data perangkat Anda selalu aman saat Anda terhubung ke cloud menggunakan protokol perpesanan MGTT terbuka dan ringan atau HTTP. Dengan bantuan protokol dan node-red kami dapat menghubungkan perangkat kami dengan platform iot dan dapat mengakses data langsung dan historis.

Gunakan API aman kami untuk menghubungkan aplikasi Anda dengan data dari perangkat Anda.

Buat aplikasi dalam layanan cloud kami yang diberikan untuk menginterpretasikan data.