AWS และ IBM: การเปรียบเทียบบริการ IoT: 4 ขั้นตอน

2024 ผู้เขียน: John Day | [email protected]. แก้ไขล่าสุด: 2024-01-30 13:05

วันนี้ เรากำลังเปรียบเทียบสองสแต็กที่ทำให้สามารถพัฒนาแอปพลิเคชัน IoT ภายใต้มุมมองของข้อเสนอบริการต่างๆ

ขั้นตอนที่ 1: ทำหน้าที่เป็นบริการ

FaaS เป็นบริการคลาวด์ประเภทหนึ่งที่ใช้สร้างสถาปัตยกรรม "ไร้เซิร์ฟเวอร์" FaaS ช่วยให้ลูกค้าสามารถพัฒนา เรียกใช้ และจัดการฟังก์ชันแอปพลิเคชันโดยไม่ต้องสร้างและบำรุงรักษาโครงสร้างพื้นฐาน

Amazon เสนอ AWS Lambda, IBM มี IBM Cloud Functions บริการเหล่านั้นค่อนข้างคล้ายกัน แต่ Lambda เป็นบริการแรกในประเภทนี้ การใช้ FaaS คุณสามารถเรียกใช้โค้ดบางส่วนในคลาวด์ และทุกบริการรองรับภาษาการเขียนโปรแกรมที่แตกต่างกัน

ฟังก์ชัน IBM Cloud: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# เป็นต้น), ใดก็ได้ผ่าน Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Any ผ่านรันไทม์ API

IBM รองรับภาษาต่างๆ มากขึ้น และด้วย docker นั้นง่ายต่อการใช้สคริปต์ที่เขียนในภาษาอื่น สิ่งนี้สามารถทำได้ด้วยแลมบ์ดา แต่ไม่ใช่ในทันที คุณสามารถอ่านตัวอย่างได้ที่นี่:

บริการทั้งสองมีขีดจำกัดการใช้งาน เรารายงานในตารางและเน้นสิ่งที่ดีที่สุด

ราคาขึ้นอยู่กับ GigaBytes ต่อวินาที (RAM) โดยเพิ่มจำนวนคำขอสำหรับ AWS Lambda แต่ละบริการมีแผนบริการฟรีและเกือบจะเท่ากัน อย่างที่คุณเห็น Lambda นั้นถูกกว่าเล็กน้อยสำหรับ GB/s แต่มีค่าใช้จ่ายที่เกี่ยวข้องกับคำขอที่ Cloud Functions ไม่มี ดังนั้นค่าใช้จ่ายโดยทั่วไปจึงเกือบเท่ากัน แน่นอน หากคุณต้องการเรียกใช้งานที่กินหน่วยความจำและใช้คำขอเพียงเล็กน้อย คุณควรใช้ Lambda ข้อได้เปรียบหลักของ IBM Cloud Function ในความเห็นของเราคือสแต็กเป็นโอเพ่นซอร์ส มันใช้ Apache OpenWhisk อย่างสมบูรณ์และยังสามารถปรับใช้บนโครงสร้างพื้นฐานส่วนตัวได้อีกด้วย

ขั้นตอนที่ 2: การเรียนรู้ของเครื่อง

สาขาที่กอง IBM และ AWS ให้บริการที่คล้ายกันคือการเรียนรู้ของเครื่อง: Amazon ที่มี SageMaker และ IBM พร้อม Watson Machine Learning บริการทั้งสองนี้มีความคล้ายคลึงกันในหลาย ๆ ด้าน: ทั้งสองนำเสนอตัวเองเป็นเครื่องมือที่จะช่วยให้นักวิทยาศาสตร์ข้อมูลและนักพัฒนาสามารถสร้าง ฝึกอบรม และปรับใช้ในสภาพแวดล้อมที่พร้อมสำหรับการผลิตในรูปแบบการเรียนรู้ของเครื่อง แต่ปรัชญาที่ทั้งสองบริษัทนำมาใช้นั้นแตกต่างกันเล็กน้อย บริการทั้งสองให้คุณเลือกระดับการควบคุมที่แตกต่างกันสำหรับรุ่นที่คุณใช้ ใน Watson ML คุณมีโมเดลในตัวที่ได้รับการฝึกฝนให้ทำงานเฉพาะเจาะจงอยู่แล้ว ตัวอย่างเช่น หากคุณต้องการทราบว่าวัตถุใดบ้างที่มีอยู่ในรูปภาพ คุณเพียงแค่นำเข้าโมเดล VisualRecognitionV3 และส่งภาพให้คุณ ต้องการวิเคราะห์ คุณยังสามารถสร้าง "โมเดลแบบกำหนดเอง" ได้ แต่ใน Watson ML นี่หมายถึงการใช้โมเดลที่สร้างไว้แล้วและทำการฝึกอบรมของเรา ดังนั้นการปรับแต่งจึงค่อนข้างจำกัด สิ่งสำคัญคือต้องสังเกตว่าทั้ง SageMaker และ Watson ML ไม่ใช่วิธีเดียวในการทำการเรียนรู้ด้วยเครื่องบนสแต็กของนักพัฒนา แต่เป็นเพียงบริการที่มีจุดมุ่งหมายเพื่อทำให้ชีวิตของนักพัฒนาง่ายขึ้น แพลตฟอร์ม Watson ML ยังรองรับไลบรารีแมชชีนเลิร์นนิงยอดนิยมมากมาย คุณจึงสามารถสร้างแบบจำลองตั้งแต่เริ่มต้นด้วย PyTorch, Tensorflow หรือไลบรารีที่คล้ายกัน คุณใช้ไลบรารีเหล่านั้นโดยตรง หรือใช้โมเดลที่สร้างไว้ล่วงหน้า ไม่มีจุดกึ่งกลาง นอกจากนี้ Watson ML ยังไม่รองรับไลบรารีทางเลือกของ Amazon, Apache MXNet ซึ่งมีการรองรับระดับเฟิร์สคลาสใน SageMaker แทน

วิธีการของ Amazon SageMaker แม้จะใช้ตัวเลือกในตัว ก็ยังอยู่ในระดับต่ำ: แทนที่จะให้คุณเลือกจากแบบจำลองที่สร้างไว้ล่วงหน้า วิธีนี้ทำให้คุณสามารถเลือกจากอัลกอริธึมการฝึกอบรมที่นำไปใช้แล้วมากมาย ซึ่งคุณสามารถใช้เมื่อสร้าง ในรูปแบบดั้งเดิมมากขึ้น หากไม่เพียงพอ คุณยังสามารถใช้อัลกอริทึมของคุณเองได้ วิธีการทำสิ่งนี้ต้องการความรู้เพิ่มเติมเกี่ยวกับวิธีการเรียนรู้ของเครื่อง เมื่อเทียบกับการใช้โมเดลที่ได้รับการฝึกอบรมใน Watson ML

ในแวบแรก อาจดูเหมือนว่า Watson ML เป็นวิธีที่ "ง่ายและรวดเร็ว" โดยที่ Amazon SageMaker เป็นวิธีการตั้งค่าที่ซับซ้อนกว่า สิ่งนี้อาจไม่เป็นความจริงทั้งหมดจากมุมมองบางอย่าง เนื่องจาก SageMaker มีโครงสร้างเพื่อให้ทุกอย่างทำงานบน Jupyter Notebook ในขณะที่คุณสมบัติเดียวกันใน Watson ML คุณต้องตั้งค่าบริการย่อยต่างๆ จาก UI ของเว็บ การประมวลผลข้อมูลล่วงหน้ายังมีพื้นที่เฉพาะบนบริการของ IBM ในขณะที่ SageMaker อาศัยคุณทำทุกอย่างจากโค้ดในโน้ตบุ๊กของคุณ บวกกับข้อเท็จจริงที่ว่าโน้ตบุ๊ก Jupyter ไม่ใช่ตัวเลือกที่ดีที่สุดจากมุมมองทางวิศวกรรมซอฟต์แวร์ อาจทำให้ SageMaker ไม่สามารถปรับขนาดได้ดีมากในการผลิต บริการทั้งสองมีกลไกที่ดีและเรียบง่ายในการปรับใช้โมเดลของคุณและทำให้ API พร้อมใช้งานในโลกภายนอก

โดยสรุป Watson ML ทำงานได้ดีกว่าในโครงการขนาดใหญ่ที่โน้ตบุ๊ก Jupyter เริ่มแสดงขีดจำกัด และในส่วนที่คุณไม่จำเป็นต้องปรับแต่งอะไรมากในสิ่งที่ตัวโมเดลทำ SageMaker ดีกว่ามากเมื่อคุณต้องการความยืดหยุ่นมากขึ้นในการกำหนดอัลกอริธึม แต่เมื่อใช้งาน คุณต้องคำนึงถึงข้อเท็จจริงที่ว่าคุณต้องพึ่งพา Jupyter Notebooks ซึ่งอาจไม่สามารถปรับขยายได้ดีในการผลิต วิธีแก้ปัญหาอาจเป็นการแยกโค้ดที่เหลือออกจากโมเดลให้มากที่สุด เพื่อให้โค้ดในโน้ตบุ๊กไม่ใหญ่เกินไป และเราสามารถจัดระเบียบซอฟต์แวร์ของเราในโมดูลอื่นๆ ที่ใช้ API ของโมเดลของเราได้ดียิ่งขึ้น.

ขั้นตอนที่ 3: การสตรีมข้อมูล & การวิเคราะห์

บริการสตรีมข้อมูลมีความสำคัญในการจัดการและวิเคราะห์กระแสข้อมูลปริมาณมากแบบเรียลไทม์ ขั้นตอนนี้อาจมาจากระบบคลาวด์ไปยังอุปกรณ์ของผู้ใช้ เช่น การสตรีมวิดีโอ หรือจากผู้ใช้ไปยังระบบคลาวด์ เช่น การวัดและส่งข้อมูลทางไกลของ IoT และการอ่านเซ็นเซอร์ โดยเฉพาะอย่างยิ่งในกรณีที่สอง เราอาจมีสถานการณ์ที่แหล่งเดียวอัปโหลดข้อมูลจำนวนเล็กน้อย แต่เมื่อเราพิจารณาปริมาณงานโดยรวมที่มาจากอุปกรณ์ทั้งหมด มันใช้แบนด์วิดท์มาก ดังนั้นจึงเหมาะสมที่จะใช้บริการที่เชี่ยวชาญในการจัดการดังกล่าว การไหลของข้อมูล หากปราศจากการจัดการโฟลว์ที่ต่อเนื่องนี้โดยตรง เราจะต้องบัฟเฟอร์ข้อมูลที่เข้ามาไว้ในที่เก็บข้อมูลชั่วคราว และในครั้งที่สองจะประมวลผลด้วยเอ็นจิ้นการคำนวณ ปัญหาของแนวทางสุดท้ายนี้คือ เราจะต้องประสานงานบริการต่างๆ มากขึ้น เพื่อให้บรรลุสิ่งที่บริการสตรีมข้อมูลเดียวทำอยู่แล้วโดยลำพัง เพิ่มความซับซ้อนของการบำรุงรักษาและการกำหนดค่าของแอปพลิเคชัน นอกจากนี้ โดยหลักการแล้วการบัฟเฟอร์อาจทำให้แอปพลิเคชันของเราไม่ทำงานแบบเรียลไทม์อีกต่อไป เนื่องจากสำหรับรายการที่จะประมวลผล มีความจำเป็นที่รายการอื่นๆ ทั้งหมดก่อนที่จะดำเนินการเช่นกัน และเพิ่มนโยบายลำดับความสำคัญให้กับบัฟเฟอร์อีกครั้ง เพิ่มความซับซ้อนอย่างมาก โดยสรุป บริการสตรีมข้อมูลนำเสนอการจัดการโฟลว์ข้อมูลแบบเรียลไทม์ ด้วยการกำหนดค่าที่ง่ายดาย และสามารถให้การวิเคราะห์ข้อมูลขาเข้า ที่นี่เราเปรียบเทียบบริการสตรีมหลักสองบริการของสแต็ค IBM และ AWS คือ IBM Streams และ AWS Kinesis

เราเริ่มต้นด้วยการสังเกตว่าทั้ง IBM และ AWS นำเสนอฟีเจอร์พื้นฐานทั้งหมดที่เราต้องการจากบริการสตรีม คุณสมบัติเหล่านี้รวมถึงอัตราการประมวลผลที่แทบไม่สิ้นสุด เวลาแฝงต่ำ และการวิเคราะห์ข้อมูลแบบเรียลไทม์ เนื่องจากเรากำลังพูดถึงบริการระดับมืออาชีพ ทั้งสองจึงมีเครื่องมือระดับการผลิตสำหรับการปรับใช้และระบบอัตโนมัติ

เมื่อพูดถึงการวิเคราะห์ข้อมูล ทั้งสองบริการนำเสนอเป็นตัวเลือก ทำให้คุณจ่ายได้เฉพาะเมื่อคุณต้องการหรือไม่ ในกรณีของ Kinesis เมื่อคุณไม่ต้องการการวิเคราะห์แต่เพียงแค่การจัดการโฟลว์ข้อมูล ราคาจะถูกเรียกเก็บต่อ GB ที่ประมวลผลแทนเวลาในการประมวลผล เช่นในกรณีของ IBM โดยทั่วไป ราคาต่อ GB จะถูกกว่าราคาต่อครั้ง เนื่องจากคุณจะจ่ายเฉพาะการรับส่งข้อมูลขาเข้าเท่านั้น สำหรับส่วนที่เหลือของโพสต์นี้ เราจะพิจารณาทั้ง IBM Streams และ AWS Kinesis โดยเปิดใช้ฟีเจอร์การวิเคราะห์ข้อมูล

Streams และ Kinesis ให้การผสานรวมกับบริการต่างๆ สำหรับการประมวลผลล่วงหน้าและการกรองข้อมูลที่เข้ามาก่อนที่จะส่งต่อไปยังการวิเคราะห์ข้อมูล ตามลำดับด้วย Apache Edgent และ AWS Lambda แม้ว่าบริการเหล่านี้จะแตกต่างไปจากเดิมอย่างสิ้นเชิง แต่เราจะหารือเกี่ยวกับบริการเหล่านี้จากมุมมองของบริการสตรีมมิ่งทั้งสองเท่านั้น ความแตกต่างพื้นฐานระหว่างทั้งสองคือ Apache Edgent ดำเนินการบนอุปกรณ์ ในขณะที่ AWS Lambda ดำเนินการบนคลาวด์ สิ่งนี้ทำให้เกิดข้อดีและข้อเสียมากมาย: จากฝั่ง Lambda เรามีบริการที่ยืดหยุ่นและใช้งานง่ายพร้อมการผสานรวมกับ Kinesis ที่ราบรื่น แต่จำเป็นต้องอัปโหลดข้อมูลไปยังคลาวด์แล้ว ส่งผลให้ประสิทธิภาพลดลงและจ่าย Kinesis ด้วย สำหรับข้อมูลที่จะทิ้งไปในที่สุด จากฝั่ง Edgent แทน เรามีการคำนวณส่วนใหญ่เสร็จแล้ว ที่ขอบของเครือข่าย (เช่น นั้นบนอุปกรณ์) ก่อนที่จะอัปโหลดข้อมูลที่ไร้ประโยชน์บนคลาวด์ ข้อเสียเปรียบหลักคือ Edgent เป็นเฟรมเวิร์กขนาดใหญ่ ซึ่งอาจต้องใช้เวลาในการตั้งค่าและอาจซับซ้อนในการบำรุงรักษา ความแตกต่างอีกประการหนึ่งที่อาจเกี่ยวข้องในการเลือกแพลตฟอร์มคือ Edgent เป็นโอเพ่นซอร์สอย่างสมบูรณ์ Lambda ไม่ใช่ สิ่งนี้สามารถเห็นได้ทั้งในฐานะมือโปร เนื่องจากการเข้าถึงรหัสที่คุณหรือลูกค้าของคุณจะดำเนินการนั้นเป็นสิ่งที่ดีเสมอ ทั้งเป็นการเสีย เพราะอาจมีสถานการณ์ที่คุณต้องการความช่วยเหลือเร่งด่วนที่ไม่สามารถจัดหาให้ได้ สภาพแวดล้อมโอเพ่นซอร์สทั้งหมด

คุณสมบัติอื่นๆ ที่เราสามารถพูดถึงได้คือความสามารถในการปรับขนาดอัตโนมัติของ Kinesis สำหรับทรัพยากรที่จัดสรร อันที่จริง ฮาร์ดแวร์ที่นำเสนอนั้นประกอบด้วย Kinesis Processing Units (KPU) จำนวนมากที่ทำงานพร้อมกัน โดยที่ KPU หนึ่งตัวมี 1 vCore และ RAM 4GB จำนวนของพวกเขาขึ้นอยู่กับความต้องการของแอปพลิเคชันและมีการจัดสรรแบบไดนามิกและโดยอัตโนมัติ (สิ่งที่คุณจ่ายคือเวลาของ cpu คูณกับจำนวน KPU) เพียงจำไว้ว่ามันเป็นนโยบายของ Kinesis ที่จะเรียกเก็บเงินจาก KPU อีกหนึ่งตัวหากคุณใช้ Java แอปพลิเคชัน. IBM Streams ไม่ได้ให้ความยืดหยุ่นประเภทนี้ ให้คุณมีคอนเทนเนอร์ที่มีฮาร์ดแวร์แบบตายตัว รายละเอียดเพิ่มเติมเมื่อเราพูดถึงราคา ในทางกลับกัน IBM Streams นั้นเปิดกว้างมากกว่า Kinesis เนื่องจากจะเชื่อมต่อกับ WAN ผ่านโปรโตคอลที่ใช้กันทั่วไป เช่น HTTP, MQTT และอื่นๆ ในขณะที่ Kinesis จะปิดในระบบนิเวศของ AWS

ในการเปรียบเทียบขั้นสุดท้าย เรามาพูดถึงเรื่องราคากัน และผมขอบอกว่า IBM ไม่ได้ผลดีในประเด็นนี้ เราได้กำหนดค่าโซลูชันที่แตกต่างกันสำหรับสามหมวดหมู่ที่แตกต่างกัน (พื้นฐาน ระดับไฮเอนด์ ระดับไฮเอนด์พิเศษ) สำหรับทั้ง IBM และ AWS และเราจะเปรียบเทียบราคาของพวกเขา ในการกำหนดค่าพื้นฐาน เรามี AWS KPU หนึ่งรายการที่กล่าวถึงก่อนหน้านี้ เทียบกับโซลูชันของ IBM ที่มีฮาร์ดแวร์เดียวกัน สำหรับระดับไฮเอนด์ เรามี KPU 8 ตัวที่รันขนานกันสำหรับ Kinesis และ 2 คอนเทนเนอร์ขนานกันเสมอสำหรับ IBM โดยแต่ละตัวมี 4 vCores และ RAM ขนาด 12GB IBM เสนอคอนเทนเนอร์เดี่ยวระดับไฮเอนด์ที่มี 16 vCores และ RAM ขนาด 128GB เสมอ ในขณะที่เราละเว้นโซลูชันที่เทียบเท่าสำหรับ AWS เนื่องจากหากแอปพลิเคชันบางตัวต้องการ RAM จำนวนมากนี้ จะไม่สามารถเรียกใช้บน KPU ที่ต่างกันได้. ราคาที่เรารายงานแสดงเป็น $/เดือน โดยพิจารณาจากการใช้งานตลอด 24 ชั่วโมงทุกวันไม่เว้นวันหยุด สำหรับการกำหนดค่าพื้นฐานที่เรามีสำหรับ IBM และ AWS เท่ากับ 164$ และ 490$ ตามลำดับ สำหรับ 1320$ และ 3500$ ระดับไฮเอนด์ สำหรับ AWS ระดับไฮเอนด์จะไม่ถูกพิจารณา และมีเพียง IBM ที่มี 6300$ เท่านั้น จากผลลัพธ์เหล่านี้ เราจะเห็นได้ว่า Kinesis ทำงานได้ดีขึ้นสำหรับผู้ใช้ทุกวันจนถึงระดับองค์กร ในขณะที่ไม่มีตัวเลือกในการจัดการกับการวิเคราะห์ข้อมูลโดยตรง ซึ่งต้องใช้พลังประมวลผลจำนวนมหาศาล Kinesis มอบอัตราส่วนประสิทธิภาพ/$ ที่ดีกว่า IBM Streams ซึ่งได้รับความช่วยเหลือจากการจัดสรรแบบไดนามิกของบล็อกทรัพยากรขนาดเล็กเมื่อจำเป็นเท่านั้น ในขณะที่ IBM เสนอคอนเทนเนอร์แบบคงที่ให้คุณ ด้วยวิธีนี้ หากเวิร์กโหลดของคุณถูกกำหนดโดยพีค กับ IBM คุณจะถูกบังคับให้ประเมินความต้องการแอปพลิเคชันของคุณสูงเกินไป และกำหนดค่าโซลูชันในสถานการณ์กรณีที่เลวร้ายที่สุด IBM เสนอค่าธรรมเนียมชั่วโมงแทนการชำระเต็มเดือน แต่ไม่ได้ดำเนินการอัตโนมัติเหมือน Kinesis

ขั้นตอนที่ 4: สถาปัตยกรรม IoT

การกำหนดค่าสำหรับอุปกรณ์สำหรับ aws iot นั้นค่อนข้างง่ายเมื่อเทียบกับ ibm watson iot เนื่องจากใน ibm watson iot การพิสูจน์ตัวตนเป็นต่ออุปกรณ์ที่มีโทเค็น และเมื่อแสดงโทเค็นแล้ว ระบบจะไม่แสดงอีกเลย มาถึงส่วนการกำหนดราคาอีกครั้ง ibm watson iot ค่อนข้างแพงเมื่อเทียบกับ aws iot ดังนั้น ราคาในค่าบริการ ibm watson iot จะขึ้นอยู่กับอุปกรณ์ การจัดเก็บข้อมูล การรับส่งข้อมูล แต่ใน aws iot เราสามารถจ่ายเงินครั้งเดียวและเราสามารถเพิ่มอุปกรณ์และข้อมูลที่เผยแพร่จากอุปกรณ์และส่งไปยังอุปกรณ์ได้มากขึ้น

เริ่มต้นด้วยอุปกรณ์ของคุณ ไม่ว่าจะเป็นเซ็นเซอร์ เกตเวย์ หรืออย่างอื่น และให้เราช่วยคุณเชื่อมต่อกับคลาวด์

ข้อมูลอุปกรณ์ของคุณจะปลอดภัยเสมอเมื่อคุณเชื่อมต่อกับระบบคลาวด์โดยใช้โปรโตคอลการส่งข้อความ MGTT แบบเปิดและน้ำหนักเบาหรือ HTTP ด้วยความช่วยเหลือของโปรโตคอลและโหนดสีแดง เราสามารถเชื่อมต่ออุปกรณ์ของเรากับแพลตฟอร์ม iot และสามารถเข้าถึงข้อมูลสดและข้อมูลย้อนหลังได้

ใช้ API ที่ปลอดภัยของเราเพื่อเชื่อมต่อแอปของคุณกับข้อมูลจากอุปกรณ์ของคุณ

สร้างแอปพลิเคชันภายในบริการคลาวด์ของเราเพื่อตีความข้อมูล