AWS i IBM: porównanie usług IoT: 4 kroki

2024 Autor: John Day | [email protected]. Ostatnio zmodyfikowany: 2024-01-30 11:30

Dziś porównujemy dwa stosy, które umożliwiają tworzenie aplikacji IoT pod kątem różnych ofert usług.

Krok 1: działa jako usługa

FaaS to kategoria usług w chmurze służących do budowania architektury „bezserwerowej”. FaaS pozwala klientom rozwijać, uruchamiać i zarządzać funkcjonalnościami aplikacji bez budowania i utrzymywania infrastruktury.

Amazon oferuje AWS Lambda, IBM oferuje IBM Cloud Functions. Usługi te są dość podobne, jednak Lambda była pierwszą tego typu. Korzystając z FaaS możesz uruchamiać fragmenty kodu w chmurze, a każda usługa obsługuje różne języki programowania.

IBM Cloud Functions: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# itp.), Dowolne przez Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Dowolne przez Runtime API

IBM obsługuje więcej języków, a dzięki platformie Docker można łatwo używać skryptów napisanych w innych językach. Można to zrobić również z Lambdą, ale nie jest to natychmiastowe. Przykład możesz przeczytać tutaj:

Obie usługi mają limity użytkowania, raportujemy je w tabeli i wyróżniamy najlepsze.

Cena oparta jest na gigabajtach na sekundę (RAM) z dodatkiem liczby żądań dla AWS Lambda. Każda usługa ma darmowy plan i są one prawie równoważne. Jak widać, Lambda jest nieco tańsza za GB/s, ale ma koszt związany z żądaniami, których nie ma Cloud Functions, więc koszt jest prawie taki sam. Oczywiście, jeśli potrzebujesz uruchomić zadania, które pochłaniają pamięć i używają kilku żądań, powinieneś użyć Lambdy. Główną zaletą IBM Cloud Function, naszym zdaniem, jest to, że jej stos jest open source. Jest całkowicie oparty na Apache OpenWhisk i może być również wdrażany w prywatnej infrastrukturze.

Krok 2: Uczenie maszynowe

Dziedziną, w której stosy IBM i AWS oferują podobne usługi, jest uczenie maszynowe: Amazon z SageMakerem i IBM z Watson Machine Learning. Te dwie usługi są pod wieloma względami bardzo podobne: obie prezentują się jako narzędzia pomagające analitykom danych i programistom budować, szkolić, a następnie wdrażać w środowiskach produkcyjnych modele uczenia maszynowego, ale filozofie, które przyjmują obie firmy, różnią się znacznie. Obie usługi pozwalają wybierać między różnymi stopniami kontroli używanych modeli. W Watson ML masz kilka wbudowanych modeli, które są już przeszkolone do wykonywania bardzo konkretnych zadań: na przykład, jeśli chcesz rozpoznać, jakie obiekty są obecne na obrazie, po prostu importujesz model VisualRecognitionV3 i przekazujesz mu obraz, który chcesz analizować. Możesz także zbudować „model niestandardowy”, ale w Watson ML oznacza to głównie wzięcie już zbudowanego modelu i przeprowadzenie na nim naszego szkolenia, więc dostosowanie jest dość ograniczone. Należy jednak zauważyć, że ani SageMaker, ani Watson ML nie są jedynymi sposobami uczenia maszynowego na stosach ich programistów, są to tylko usługi mające na celu ułatwienie życia programistom. Platforma Watson ML obsługuje również wiele najpopularniejszych bibliotek uczenia maszynowego, dzięki czemu możesz nawet zbudować model od podstaw za pomocą bibliotek PyTorch, Tensorflow lub podobnych. Albo używasz tych bibliotek bezpośrednio, albo korzystasz z gotowych modeli, nie ma pośredniej płaszczyzny. Ponadto Watson ML nie obsługuje wybranej przez Amazon biblioteki Apache MXNet, która zamiast tego ma wsparcie pierwszej klasy w programie SageMaker.

Podejście Amazon SageMaker, nawet przy korzystaniu z wbudowanych opcji, jest nieco niższy: zamiast wybierać spośród gotowych modeli, pozwala wybierać spośród mnóstwa już zaimplementowanych algorytmów szkoleniowych, które można wykorzystać podczas budowania własnych model w bardziej tradycyjny sposób. Jeśli to nie wystarczy, możesz również skorzystać z własnego algorytmu. Ten sposób robienia rzeczy z pewnością wymaga większej wiedzy na temat uczenia maszynowego w porównaniu do korzystania z wytrenowanego modelu w Watson ML.

Na pierwszy rzut oka może się wydawać, że Watson ML jest „prostym i szybkim” sposobem, a Amazon SageMaker jest bardziej skomplikowany do skonfigurowania. Może to nie być do końca prawdą z niektórych punktów widzenia, ponieważ SageMaker jest skonstruowany tak, aby wszystko działało na notatniku Jupyter, podczas gdy dla tych samych funkcji w Watson ML musisz skonfigurować wiele różnych usług podrzędnych z interfejsu internetowego. Wstępne przetwarzanie danych obejmuje również dedykowane miejsca w usłudze IBM, podczas gdy SageMaker polega na tym, że robisz to wszystko z kodu w swoim notebooku. To plus fakt, że notebooki Jupyter nie są najlepszym wyborem z punktu widzenia inżynierii oprogramowania, może uniemożliwić SageMakerowi bardzo dobre skalowanie w produkcji. Obie usługi mają całkiem dobre i proste mechanizmy do wdrażania modelu i udostępniania dla niego interfejsów API w świecie zewnętrznym.

Podsumowując, Watson ML sprawdza się lepiej w dużych projektach, w których notebooki Jupyter zaczynają pokazywać swoje ograniczenia i gdzie nie trzeba wiele dostosowywać do tego, co robi sam model. SageMaker jest o wiele lepszy, gdy potrzebujesz większej elastyczności w definiowaniu algorytmów, ale używając go, musisz wziąć pod uwagę fakt, że musisz polegać na Jupyter Notebooks, które mogą nie skalować się dobrze w produkcji. Rozwiązaniem może być maksymalne oddzielenie reszty kodu od modelu, tak aby kod w rzeczywistych notebookach nie był zbyt duży i abyśmy mogli lepiej zorganizować nasze oprogramowanie w innych modułach, które po prostu korzystają z API naszego modelu.

Krok 3: Strumieniowanie danych i analiza

Usługi strumieniowania danych mają kluczowe znaczenie w obsłudze i analizowaniu w czasie rzeczywistym dużych przepływów danych. Ten przepływ może odbywać się z chmury do urządzenia użytkownika, jak strumieniowanie wideo, lub od użytkowników do chmury, jak telemetria IoT i odczyty czujników. Zwłaszcza w drugim przypadku możemy mieć do czynienia z sytuacją, w której pojedyncze źródła przesyłają niewielkie ilości danych, ale biorąc pod uwagę ogólną przepustowość, pochodzącą ze wszystkich urządzeń, zużywa ona znaczną przepustowość, dlatego warto skorzystać z usługi wyspecjalizowanej do obsługi takich przepływy danych. Bez bezpośredniej obsługi tego ciągłego przepływu musielibyśmy buforować przychodzące informacje w tymczasowym magazynie i po raz drugi przetwarzać je za pomocą jakiegoś silnika obliczeniowego. Problem w tym ostatnim podejściu polega na tym, że musielibyśmy koordynować więcej różnych usług, aby osiągnąć to, co pojedyncza usługa strumienia danych robi już sama, zwiększając złożoność konserwacji i konfiguracji aplikacji. Ponadto buforowanie może w zasadzie sprawić, że nasza aplikacja nie będzie już w czasie rzeczywistym, ponieważ do przetworzenia elementu konieczne jest, aby wszystkie inne elementy przed nim również zostały przetworzone, a dodanie zasad pierwszeństwa do bufora może ponownie, drastycznie zwiększyć złożoność. Podsumowując, usługi przesyłania strumieniowego danych oferują obsługę przepływu danych w czasie rzeczywistym, z łatwą konfiguracją i mogą dostarczać analizy napływających danych. Tutaj porównujemy dwie główne usługi przesyłania strumieniowego stosu IBM i AWS, a mianowicie IBM Streams i AWS Kinesis.

Zaczynamy od zwrócenia uwagi, że wszystkie podstawowe funkcje, których możemy potrzebować od usługi przesyłania strumieniowego, są oferowane zarówno przez IBM, jak i AWS. Funkcje te obejmują praktycznie nieskończoną szybkość przetwarzania, niskie opóźnienia i analizę danych w czasie rzeczywistym. Ponieważ mówimy o usługach profesjonalnych, obaj oferują narzędzia klasy produkcyjnej do wdrażania i automatyzacji.

Mówiąc o analityce danych, obie usługi oferują ją jako opcjonalną, dzięki czemu płacisz tylko, czy tego potrzebujesz, czy nie. W przypadku Kinesis, gdy nie potrzebujesz analityki, a tylko obsługi przepływu danych, ceny naliczane są za przetworzony GB, a nie czas przetwarzania, jak w przypadku IBM. Cena za GB będzie generalnie tańsza niż cena za czas, ponieważ płacisz tylko za ruch przychodzący. W dalszej części tego postu rozważymy zarówno strumienie IBM Streams, jak i AWS Kinesis z włączoną funkcją analizy danych.

Strumienie i Kinesis zapewniają integrację z różnymi usługami w celu wstępnego przetwarzania i filtrowania danych przychodzących przed przekazaniem ich do analizy danych, odpowiednio z Apache Edgent i AWS Lambda. Chociaż usługi te radykalnie różnią się od siebie, omówimy je tylko z punktu widzenia dwóch usług przesyłania strumieniowego. Podstawowa różnica między nimi polega na tym, że Apache Edgent działa na urządzeniu, podczas gdy AWS Lambda działa w chmurze. To niesie ze sobą wiele zalet i wad: od strony Lambdy mamy elastyczną i łatwą w obsłudze usługę z bezproblemową integracją z Kinesis, ale wymaga to już załadowania danych do chmury, co traci na wydajności i płaci także Kinesis dla danych, które ostatecznie zostaną odrzucone. Od strony Edgent mamy, że większość obliczeń jest wykonywana, no cóż, na brzegu sieci (a więc na urządzeniach) przed przesłaniem bezużytecznych danych do chmury. Główną wadą jest to, że Edgent jest dużym frameworkiem, którego konfiguracja może wymagać czasu i może być skomplikowana w utrzymaniu. Kolejną różnicą, która może mieć znaczenie przy wyborze platformy, jest to, że Edgent jest w pełni open source, a Lambda nie. Można to postrzegać zarówno jako profesjonalistę, ponieważ posiadanie dostępu do kodu, który ty lub twój klient będzie wykonywał, jest zawsze pozytywną rzeczą, zarówno jako wada, ponieważ mogą zaistnieć sytuacje, w których potrzebujesz pilnego wsparcia, którego nie można zapewnić w wszystkie środowiska open source.

Inne funkcje, o których możemy wspomnieć, to automatyczne skalowanie przydzielonych zasobów przez Kinesis. Rzeczywiście, sprzęt, który oferuje, składa się z wielu tak zwanych jednostek przetwarzania Kinesis (KPU) działających równolegle, przy czym jeden KPU oferuje 1 rdzeń wirtualny i 4 GB pamięci RAM. Ich liczba zależy od potrzeb aplikacji i jest przydzielana dynamicznie i automatycznie (to, co płacisz, to rzeczywiście czas procesora razy liczba KPU), pamiętaj tylko, że polityka Kinesis jest naliczana o jeden KPU więcej, jeśli używasz Javy podanie. Zamiast tego IBM Streams nie zapewnia takiej elastyczności, oferując kontener ze stałym sprzętem, więcej szczegółów, gdy mówimy o cenach. Z drugiej strony, IBM Streams jest bardziej otwarty niż Kinesis, ponieważ łączy się z siecią WAN za pośrednictwem powszechnie używanych protokołów, takich jak HTTP, MQTT itd., podczas gdy Kinesis jest zamknięty na ekosystem AWS.

Jako końcowe porównanie porozmawiajmy o cenach i powiem, że IBM nie działa dobrze w tym punkcie. Skonfigurowaliśmy różne rozwiązania dla trzech różnych kategorii (podstawowa, high-end, ultra high-end) zarówno dla IBM, jak i AWS, i porównamy ich cenę. W podstawowej konfiguracji mamy jeden KPU AWS, wspomniany wcześniej, na tle rozwiązania IBM z tym samym sprzętem. W przypadku high-endu mamy 8 jednostek KPU działających równolegle dla Kinesis i 2 kontenery zawsze równolegle dla IBM, każdy z 4 rdzeniami wirtualnymi i 12 GB pamięci RAM. Zawsze IBM oferuje w ultra-wysokiej klasie pojedynczy kontener z 16 rdzeniami wirtualnymi i 128 GB pamięci RAM, podczas gdy pominęliśmy równoważne rozwiązanie dla AWS, ponieważ jeśli jakaś aplikacja wymaga tak dużej ilości pamięci RAM, nie byłoby możliwe jej uruchomienie na różnych KPU. Ceny, które raportujemy, są wyrażone w $/miesiąc, biorąc pod uwagę użytkowanie 24/7. Dla podstawowej konfiguracji mamy dla IBM i AWS odpowiednio 164$ i 490$, dla high-endu 1320$ i 3500$, dla ultra high-endowego AWS nie jest brany pod uwagę i jest tylko IBM z 6300$. Z tych wyników widać, że Kinesis działa lepiej dla codziennego użytkownika aż do poziomu przedsiębiorstwa, podczas gdy brakuje mu opcji bezpośredniej obsługi analizy danych, która wymaga ogromnej mocy obliczeniowej. Kinesis zapewnia lepszy stosunek wydajności do $ niż IBM Streams, do czego przyczynia się również dynamiczna alokacja małych bloków zasobów tylko wtedy, gdy jest to potrzebne, podczas gdy IBM oferuje stały kontener. W ten sposób, jeśli Twoje obciążenie charakteryzuje się szczytami, w przypadku IBM jesteś zmuszony do przeszacowania potrzeb aplikacji i skonfigurowania rozwiązania w najgorszym przypadku. IBM oferuje opłaty za godziny zamiast płacenia za cały miesiąc, ale nie jest to zautomatyzowane, jak Kinesis.

Krok 4: Architektura IoT

Konfiguracja urządzeń dla aws iot jest dość prosta w porównaniu z ibm watson iot. Ponieważ w ibm watson iot uwierzytelnianie odbywa się na urządzenie z tokenem, a po wyświetleniu tokenu nigdy więcej nie zostanie wyświetlony. Ponowne przejście do części dotyczącej wyceny ibm watson iot jest dość kosztowne w porównaniu z aws iot. Tak więc cena w opłatach ibm watson iot zależy od urządzenia, miejsca przechowywania danych i ruchu danych. Ale w aws iot możemy zapłacić kwotę raz i możemy dodać więcej urządzeń i danych publikowanych z urządzeń i dostarczanych na urządzenia.

Zacznij od swojego urządzenia - niezależnie od tego, czy jest to czujnik, brama czy coś innego - i pozwól nam pomóc Ci połączyć się z chmurą.

Dane Twojego urządzenia są zawsze bezpieczne, gdy łączysz się z chmurą za pomocą otwartego, lekkiego protokołu przesyłania wiadomości MGTT lub HTTP. Za pomocą protokołów i node-red możemy połączyć nasze urządzenie z platformą iot i uzyskać dostęp do danych bieżących i historycznych.

Skorzystaj z naszych bezpiecznych interfejsów API, aby połączyć swoje aplikacje z danymi ze swoich urządzeń.

Twórz aplikacje w ramach naszej usługi w chmurze, aby interpretować dane.