AWS và IBM: So sánh các dịch vụ IoT: 4 bước

2024 Tác giả: John Day | [email protected]. Sửa đổi lần cuối: 2024-01-30 13:33

Hôm nay chúng tôi đang so sánh hai ngăn xếp giúp có thể phát triển các ứng dụng IoT dưới quan điểm của các cung cấp dịch vụ khác nhau.

Bước 1: Chức năng như một dịch vụ

FaaS là một loại dịch vụ đám mây được sử dụng để xây dựng kiến trúc “serverless”. FaaS cho phép khách hàng phát triển, chạy và quản lý các chức năng của ứng dụng mà không cần xây dựng và duy trì cơ sở hạ tầng.

Amazon cung cấp AWS Lambda, IBM cung cấp Chức năng đám mây của IBM. Những dịch vụ đó khá giống nhau, tuy nhiên Lambda là dịch vụ đầu tiên thuộc loại này. Sử dụng FaaS, bạn có thể chạy các đoạn mã trên đám mây và mọi dịch vụ đều hỗ trợ các ngôn ngữ lập trình khác nhau.

Chức năng đám mây của IBM: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C # F #, v.v.), Bất kỳ thông qua Docker AWS Lambda: JavaScript, Java, C #, F #, Go, Python, Ruby, PowerShell, Bất kỳ thông qua Runtime API

IBM Hỗ trợ nhiều ngôn ngữ hơn và với docker, bạn có thể dễ dàng sử dụng các tập lệnh được viết bằng các ngôn ngữ khác. Điều này cũng có thể được thực hiện với Lambda nhưng nó không phải là ngay lập tức. Bạn có thể đọc một ví dụ ở đây:

Cả hai dịch vụ đều có giới hạn sử dụng, chúng tôi báo cáo chúng trong một bảng và nêu bật những dịch vụ tốt nhất.

Giá dựa trên GigaByte trên giây (RAM) với việc bổ sung số lượng yêu cầu cho AWS Lambda. Mỗi dịch vụ đều có gói miễn phí và chúng gần như tương đương nhau. Như bạn có thể thấy Lambda rẻ hơn một chút đối với GB / s nhưng nó có chi phí liên quan đến các yêu cầu mà Chức năng đám mây không có nên nhìn chung chi phí gần như giống nhau. Tất nhiên, nếu bạn cần chạy các tác vụ ngốn bộ nhớ và sử dụng ít yêu cầu, bạn nên sử dụng Lambda. Theo chúng tôi, ưu điểm chính của Chức năng đám mây của IBM là ngăn xếp của nó là mã nguồn mở. Nó hoàn toàn dựa trên Apache OpenWhisk và cũng có thể được triển khai trên cơ sở hạ tầng riêng.

Bước 2: Học máy

Một lĩnh vực mà ngăn xếp IBM và AWS cung cấp các dịch vụ tương tự là lĩnh vực máy học: Amazon với SageMaker và IBM với Watson Machine Learning. Hai dịch vụ này rất giống nhau về nhiều khía cạnh: cả hai đều thể hiện mình là công cụ giúp các nhà khoa học và nhà phát triển dữ liệu xây dựng, đào tạo và sau đó triển khai vào môi trường sẵn sàng sản xuất mô hình học máy của họ, nhưng triết lý mà hai công ty áp dụng khác nhau khá nhiều. Cả hai dịch vụ đều cho phép bạn lựa chọn giữa các mức độ kiểm soát khác nhau trên các kiểu máy bạn sử dụng. Trong Watson ML, bạn có một số mô hình tích hợp sẵn đã được đào tạo để thực hiện một số tác vụ rất cụ thể: ví dụ: nếu bạn muốn nhận ra những đối tượng nào hiện diện trong một bức ảnh, bạn chỉ cần nhập mô hình VisualRecognitionV3 và chuyển cho nó bức ảnh bạn. muốn phân tích. Bạn cũng có thể xây dựng một “mô hình tùy chỉnh”, nhưng trong Watson ML, điều này chủ yếu có nghĩa là lấy một mô hình đã được tạo sẵn và thực hiện đào tạo của chúng tôi về nó, vì vậy việc tùy chỉnh khá hạn chế. Điều quan trọng cần lưu ý là mặc dù cả SageMaker và Watson ML đều không phải là cách duy nhất để thực hiện học máy trên ngăn xếp của các nhà phát triển, chúng chỉ là các dịch vụ nhằm mục đích làm cho cuộc sống của các nhà phát triển trở nên dễ dàng hơn. Nền tảng Watson ML cũng hỗ trợ nhiều thư viện máy học phổ biến nhất, vì vậy bạn thậm chí có thể xây dựng mô hình từ đầu với PyTorch, Tensorflow hoặc các thư viện tương tự. Bạn có thể sử dụng trực tiếp các thư viện đó hoặc sử dụng các mô hình được tạo sẵn, không có điểm trung gian. Ngoài ra, Watson ML không hỗ trợ thư viện lựa chọn của Amazon, Apache MXNet, thay vào đó có hỗ trợ hạng nhất trong SageMaker.

Cách tiếp cận của Amazon SageMaker, ngay cả khi sử dụng các tùy chọn tích hợp, ở mức thấp hơn một chút: thay vì bắt bạn chọn từ các mô hình được tạo sẵn, nó cho phép bạn chọn từ rất nhiều thuật toán đào tạo đã được triển khai, bạn có thể sử dụng khi xây dựng mô hình theo cách truyền thống hơn. Nếu những điều này vẫn chưa đủ, bạn cũng có thể sử dụng thuật toán của riêng mình. Cách thực hiện này chắc chắn đòi hỏi nhiều kiến thức hơn về cách máy học được thực hiện so với việc chỉ sử dụng một mô hình được đào tạo trong Watson ML.

Thoạt nhìn, có vẻ như Watson ML là cách "dễ dàng và nhanh chóng", trong khi Amazon SageMaker là cách phức tạp hơn để thiết lập. Điều này có thể không hoàn toàn đúng theo một số quan điểm, vì SageMaker được cấu trúc để làm cho mọi thứ chạy trên Máy tính xách tay Jupyter, trong khi đối với các tính năng tương tự trong Watson ML, bạn phải thiết lập nhiều dịch vụ con khác nhau từ giao diện người dùng web. Việc xử lý trước dữ liệu cũng có không gian dành riêng trên dịch vụ IBM trong khi SageMaker dựa vào việc bạn thực hiện tất cả từ mã trong sổ ghi chép của mình. Điều này cộng với việc máy tính xách tay Jupyter không chính xác là lựa chọn tốt nhất theo quan điểm kỹ thuật phần mềm, có thể ngăn cản SageMaker mở rộng quy mô sản xuất rất tốt. Cả hai dịch vụ đều có các cơ chế khá tốt và đơn giản để triển khai mô hình của bạn và cung cấp các API cho mô hình đó ở thế giới bên ngoài.

Tóm lại, Watson ML hoạt động tốt hơn trong các dự án lớn, nơi các máy tính xách tay Jupyter bắt đầu hiển thị các giới hạn của chúng và nơi bạn không cần tùy chỉnh nhiều trong những gì chính mô hình làm. SageMaker tốt hơn rất nhiều khi bạn cần linh hoạt hơn trong việc xác định các thuật toán, nhưng khi sử dụng nó, bạn cần tính đến thực tế là bạn phải dựa vào Máy tính xách tay Jupyter, điều này có thể không mở rộng tốt trong quá trình sản xuất. Một giải pháp có thể là tách phần còn lại của mã khỏi mô hình càng nhiều càng tốt, để mã trong sổ ghi chép thực tế không quá lớn và chúng tôi có thể tổ chức phần mềm của mình tốt hơn trong các mô-đun khác chỉ sử dụng API của mô hình của chúng tôi..

Bước 3: Phân tích và phát trực tuyến dữ liệu

Các dịch vụ truyền dữ liệu rất quan trọng trong việc xử lý và phân tích các luồng dữ liệu lớn theo thời gian thực. Luồng này có thể từ đám mây đến thiết bị của người dùng, như phát trực tuyến video hoặc từ người dùng tới đám mây, như đo từ xa IoT và các bài đọc cảm biến. Đặc biệt trong trường hợp thứ hai, chúng tôi có thể gặp phải tình huống trong đó các nguồn tải lên một lượng nhỏ dữ liệu nhưng khi chúng tôi xem xét thông lượng tổng thể, đến từ tất cả các thiết bị, nó tiêu tốn băng thông đáng kể, do đó, rất hợp lý khi sử dụng một dịch vụ chuyên biệt để xử lý các luồng dữ liệu. Nếu không xử lý trực tiếp luồng liên tục này, chúng tôi sẽ phải đệm thông tin đến vào một bộ lưu trữ tạm thời và trong lần thứ hai xử lý nó bằng một số công cụ tính toán. Vấn đề của cách tiếp cận cuối cùng này là chúng tôi sẽ phải phối hợp nhiều dịch vụ khác nhau hơn để đạt được những gì mà một dịch vụ luồng dữ liệu đơn lẻ đã làm, làm tăng độ phức tạp của việc bảo trì và cấu hình ứng dụng. Ngoài ra, bộ đệm về nguyên tắc có thể làm cho ứng dụng của chúng ta không còn ở trong thời gian thực nữa, vì đối với một mục được xử lý, tất cả các mục khác trước khi nó được xử lý cũng cần được xử lý và việc thêm các chính sách ưu tiên vào bộ đệm có thể, một lần nữa, tăng độ phức tạp lên mạnh mẽ. Tóm lại, các dịch vụ truyền dữ liệu cung cấp khả năng xử lý luồng dữ liệu trong thời gian thực, với cấu hình dễ dàng và có thể cung cấp phân tích về dữ liệu đến. Ở đây chúng tôi so sánh hai dịch vụ phát trực tuyến chính của ngăn xếp IBM và AWS, đó là IBM Streams và AWS Kinesis.

Chúng tôi bắt đầu bằng cách lưu ý rằng tất cả các tính năng cơ bản mà chúng tôi có thể muốn từ dịch vụ phát trực tuyến đều được cung cấp bởi cả IBM và AWS. Các tính năng này bao gồm tốc độ xử lý gần như vô hạn, độ trễ thấp và phân tích dữ liệu thời gian thực. Vì chúng ta đang nói về các dịch vụ chuyên nghiệp, cả hai đều cung cấp các công cụ cấp sản xuất để triển khai và tự động hóa.

Nói về phân tích dữ liệu, cả hai dịch vụ đều cung cấp nó như một tùy chọn, khiến bạn chỉ phải trả tiền cho dù bạn có cần hay không. Trong trường hợp Kinesis, khi bạn không cần phân tích mà chỉ cần xử lý luồng dữ liệu, giá được tính cho mỗi GB được xử lý thay vì thời gian xử lý, như trong trường hợp của IBM. Định giá trên mỗi GB nói chung sẽ ít đắt hơn so với định giá theo thời gian, vì bạn chỉ trả tiền cho lưu lượng truy cập đến. Đối với phần còn lại của bài đăng này, chúng tôi sẽ xem xét cả IBM Streams và AWS Kinesis với tính năng phân tích dữ liệu được bật.

Streams và Kinesis cung cấp tích hợp với các dịch vụ khác nhau để xử lý trước và lọc dữ liệu đến trước khi chuyển chúng sang phân tích dữ liệu, tương ứng với Apache Edgent và AWS Lambda. Mặc dù các dịch vụ này hoàn toàn khác nhau, nhưng chúng ta sẽ chỉ thảo luận về chúng theo quan điểm của hai dịch vụ phát trực tuyến. Sự khác biệt cơ bản giữa cả hai là Apache Edgent thực thi trên thiết bị, trong khi AWS Lambda thực thi trên đám mây. Điều này mang lại rất nhiều ưu và nhược điểm: từ phía Lambda, chúng tôi có một dịch vụ linh hoạt và dễ sử dụng với sự tích hợp liền mạch với Kinesis, nhưng nó yêu cầu dữ liệu phải được tải lên đám mây, do đó mất hiệu quả và cũng phải trả tiền cho Kinesis cho dữ liệu cuối cùng sẽ bị loại bỏ. Thay vào đó, từ phía Edgent, chúng tôi cho rằng hầu hết việc tính toán được thực hiện ở rìa mạng (do đó trên các thiết bị) trước khi tải lên dữ liệu vô ích trên đám mây. Hạn chế chính là Edgent là một khuôn khổ lớn, có thể cần thời gian để thiết lập và có thể phức tạp để bảo trì. Một sự khác biệt khác có thể liên quan đến việc lựa chọn nền tảng là Edgent là nguồn mở hoàn toàn, Lambda thì không. Điều này có thể được coi là một người chuyên nghiệp, vì có quyền truy cập vào mã mà bạn hoặc khách hàng của bạn sẽ thực thi luôn là một điều tích cực, cả hai đều là một kẻ lừa đảo, vì có thể có những tình huống bạn cần hỗ trợ khẩn cấp mà không thể được cung cấp trong tất cả các môi trường mã nguồn mở.

Các tính năng khác mà chúng ta có thể đề cập là khả năng tự động mở rộng của Kinesis đối với các tài nguyên được phân bổ. Thật vậy, phần cứng mà nó cung cấp bao gồm một số được gọi là Đơn vị xử lý Kinesis (KPU) chạy song song, trong đó một KPU cung cấp 1 vCore và 4GB RAM. Số lượng của chúng phụ thuộc vào nhu cầu của ứng dụng và được phân bổ động và tự động (số tiền bạn trả thực sự là thời gian cpu nhân với số KPU), chỉ cần nhớ rằng chính sách Kinesis tính phí bạn thêm một KPU nếu bạn sử dụng Java ứng dụng. Thay vào đó, IBM Streams không cung cấp loại linh hoạt này, cung cấp cho bạn một vùng chứa với phần cứng cố định, hãy biết thêm chi tiết khi chúng ta nói về giá cả. Mặt khác, IBM Streams cởi mở hơn Kinesis, vì nó giao tiếp với mạng WAN thông qua các giao thức được sử dụng phổ biến, như HTTP, MQTT, v.v., trong khi Kinesis đóng cửa với hệ sinh thái AWS.

Như so sánh cuối cùng, hãy nói về giá cả và để tôi nói rằng IBM không hoạt động tốt về điểm này. Chúng tôi đã định cấu hình các giải pháp khác nhau cho ba loại khác nhau (cơ bản, cao cấp, siêu cao cấp) cho cả IBM và AWS, và chúng tôi sẽ so sánh giá của chúng. Trong cấu hình cơ bản, chúng tôi có một AWS KPU, được đề cập trước đó, chống lại một giải pháp của IBM với cùng một phần cứng. Đối với dòng cao cấp, chúng tôi có 8 KPU chạy song song cho Kinesis và 2 thùng chứa luôn song song cho IBM, mỗi thùng có 4 vCores và 12GB RAM. IBM luôn cung cấp trong bộ chứa siêu cao cấp một bộ chứa duy nhất với 16 vCores và 128GB RAM, trong khi chúng tôi đã bỏ qua một giải pháp tương đương cho AWS, vì nếu một số ứng dụng yêu cầu số lượng RAM lớn này thì không thể chạy nó trên các KPU khác nhau. Giá chúng tôi báo cáo được biểu thị bằng $ / tháng khi sử dụng 24/7. Đối với cấu hình cơ bản, chúng tôi có cho IBM và AWS lần lượt là 164 $ và 490 $, cao cấp là 1320 $ và 3500 $, AWS siêu cao cấp không được xem xét và chỉ có IBM với 6300 $. Từ những kết quả này, chúng ta có thể thấy rằng Kinesis hoạt động tốt hơn cho người dùng hàng ngày cho đến cấp doanh nghiệp, trong khi nó thiếu các tùy chọn để xử lý trực tiếp các phân tích dữ liệu đòi hỏi sức mạnh tính toán khổng lồ. Kinesis mang lại hiệu suất / tỷ lệ $ tốt hơn IBM Streams, cũng được hỗ trợ bởi việc phân bổ động các khối tài nguyên nhỏ chỉ khi cần thiết, trong khi IBM cung cấp cho bạn một vùng chứa cố định. Theo cách này, nếu khối lượng công việc của bạn có đặc điểm là cao điểm, với IBM, bạn buộc phải đánh giá quá cao nhu cầu ứng dụng của mình và định cấu hình giải pháp trong trường hợp xấu nhất. IBM cung cấp phí theo giờ thay vì trả cả tháng, nhưng nó không được tự động hóa như Kinesis.

Bước 4: Kiến trúc IoT

Cấu hình cho thiết bị aws iot khá dễ dàng so với ibm watson iot. Bởi vì trong ibm watson, xác thực là trên mỗi thiết bị có mã thông báo và một khi nó hiển thị mã thông báo thì nó sẽ không bao giờ hiển thị nữa. Đến phần định giá nữa ibm watson iot khá đắt so với aws iot. Vì vậy, giá tính theo iot ibm watson dựa trên mỗi thiết bị, bộ nhớ dữ liệu, lưu lượng dữ liệu. Nhưng trong thời gian chờ đợi, chúng tôi có thể thanh toán số tiền một lần và chúng tôi có thể thêm nhiều thiết bị và dữ liệu được xuất bản từ các thiết bị và được phân phối đến các thiết bị.

Bắt đầu với thiết bị của bạn - cho dù đó là cảm biến, cổng hay thứ gì khác - và để chúng tôi giúp bạn kết nối với đám mây.

Dữ liệu thiết bị của bạn luôn được bảo mật khi bạn kết nối với đám mây bằng cách sử dụng giao thức nhắn tin MGTT nhẹ, mở hoặc HTTP. Với sự trợ giúp của các giao thức và nút đỏ, chúng tôi có thể kết nối thiết bị của mình với nền tảng iot và có thể truy cập dữ liệu lịch sử và trực tiếp.

Sử dụng API bảo mật của chúng tôi để kết nối ứng dụng của bạn với dữ liệu từ thiết bị của bạn.

Tạo các ứng dụng trong dịch vụ đám mây nhất định của chúng tôi để diễn giải dữ liệu.