• Alicja Filipowicz
• May 19,2023

Cała Prawda o Rozwiązaniach IoT w AWS i Azure

IoT (Internet of Things), bo o tym mowa jest jedną z usług, jednym z zestawów funkcjonalności, który spopularyzuje chmurę publiczną i przyspieszyć tworzenie rozwiązań działających poza korporacyjnymi data centrami.

W szczególności skupmy się nad kilkoma różnicami pomiędzy dwoma dostawcami (wydawać by się mogło, na tą chwilę wiodącymi) wspomnianej usługi.

Termin IoT jest sukcesorem określenia Telemetria, ponieważ gdybyśmy pokusili się o poszukanie w internecie definicji obydwu zwrotów to zapewne uzyskamy bardzo podobne informacje. W związku z tym, iż IoT jest terminem młodszym to niejako doprecyzowuje on pewne kwestie na ogół związane z technikaliami po stronie urządzenia przekazującego informacje uzyskane w procesie pomiaru.

Po jednej stronie Microsoft Azure , po drugiej Amazon Web Services .

Który z tych dwóch potentatów na rynku chmurowym włożył więcej pracy lub raczej uzyskał lepszy efekt w osiągnięciu celu? Nie uzyskamy odpowiedzi na to pytanie, a nawet nie to jest celem tego artykułu, natomiast możemy się przyjrzeć i porównać obydwa rozwiązania.

Aby ułatwić porównanie, postanowiłem zdefiniować swego rodzaju obszary techniczne, które muszą w stopniu większym lub mniejszym zaistnieć w rozwiązaniu telemetrycznym.

Po pierwsze protokoły komunikacyjne, czyli mechanizmy umożliwiające nawiązanie połączenia i dialektu, czyli rozmowy pomiędzy urządzeniem pomiarowym a chmurą.

Po drugie możliwości analityczne, jakie istnieją zaraz po dostarczeniu informacji od urządzenia.

Po trzecie wsparcie ze strony dostawcy usług IoT dla prototypowania urządzeń (SDK, itp.).

Po czwarte bezpieczeństwo (uwierzytelnienie i autoryzacja).

Po piąte koszt, zatem coś co przy porównywalnej funkcjonalności obydwu rozwiązań może zaważyć na wyborze.

Poniższe obrazki przedstawiają architekturę rozwiązań zaczerpniętą z oficjalnych materiałów dostarczanych przez Microsoft i Amazon.

Azure:

AWS:

1.Protokoły Komunikacyjne

W obydwu rozwiązaniach możemy zauważyć istnienie czegoś, co działa na wzór bramy (gateway), która jest punktem styku pomiędzy fizycznym urządzeniem (względnie aplikacją) a resztą funkcjonalności chmury.

W przypadku AWS jest to Device Gateway , w przypadku Azure jest to IoT Hub .

W obydwu przypadkach transportem komunikacyjnym są dobrze znane protokoły HTTP oraz MQTT. Microsoft pokusił się o jeszcze jedną metodę, otóż użył protokołu AMQP (Advanced Message Queueing Protocol). AMQP to protokół warstwy aplikacji w modelu ISO/OSI zaprojektowany z myślą o wsparciu aplikacji komunikacyjnych. Przy czym to, że Microsoft zdecydował się na implementację jednego protokołu więcej niż AWS, nie czyni go w żaden sposób lepszym, po prostu jest to jedna z różnic, które należy odnotować w obszarze dwukierunkowej komunikacji pomiędzy urządzeniem a chmurą.

2.Możliwości Analityczne

W tej części są w zasadzie same różnice. Gwoli wyjaśnienia nie chodzi o analizę dużej ilości danych z gatunku BI, lecz o analizę wiadomości na jej wczesnym etapie istnienia, czyli zaraz po odebraniu przez gateway. Zatem przebiegniemy się po procesie wczesnej obróbki danych w obydwu przypadkach.

AWS:

Pierwszym elementem przyjmującym informacje jest Message Broker, który robi to przy pomocy wcześniej wspomnianych protokołów. Następnie przychodzi czas na Rules Engine gdzie przy pomocy SQL podobnych kwerend, na różne sposoby możemy dokonywać selekcji interesujących nas informacji, dostarczonych przez urządzenia (things).

Następnie będąc na tym samym poziomie decydujemy dalej, co z wyselekcjonowaną informacją zrobić. Możemy zapisać ją do logu w usłudze AWS S3 , w przypadku przekroczenia jakiegoś poziomu możemy przekierować ją do usługi CloudWatch w celu podniesienia alarmu, możemy zapisać ją do nierelacyjnej bazy danych DynamoDB w celu dalszej pracy na zestawie danych zebranych w jakimś czasie, albo możemy „odpalić” kawałek kodu w usłudze AWS Lambda w celu wykonania bardziej złożonych i w zasadzie nieograniczonych zadań, lub możemy zrobić wiele, wiele innych rzeczy:

Wraz z pojawieniem się wiadomości, w międzyczasie dzieje się kilka nazwijmy to technicznych zdarzeń, istotnych z punktu widzenia ewidencji i zarządzania kontrolerem.

Wykorzystywane są elementy Thing Shadow oraz Thing Registry . Pierwszy jest swego rodzaju reprezentacją fizycznego urządzenia w formacie JSON i używany jest do przechowywania informacji takich jak aktualny a także pożądany status.

Z tego miejsca na pewno będą korzystały aplikacje/mechanizmy wchodzące w interakcję z urządzeniem. Drugi to miejsce, w którym możemy przypisać atrybuty naszemu kontrolerowi a także powiązać go z certyfikatem oraz identyfikatorem klienta MQTT. Do atrybutów mogą należeć takie informacje jak nazwa producenta sprzętu, model kontrolera lub wersja firmware’u, zatem informacje dostarczane na etapie provisioningu czyli konfigurowania bytu w usłudze.

Azure:

W przypadku tej technologii elementem przyjmującym dane jest Event Hub .

Każdy Event Hub jest podzielony na partycje, które są swego rodzaju kanałami komunikacyjnymi.

W dalszej kolejności dostarczone dane możemy poddać wstępnej i natychmiastowej obróbce przy pomocy usługi Azure Stream Analytics , następnie przesłać je do jakiegoś storage’u, którym może być baza danych (np. Azure SQL Database ) lub zwizualizować na spreparowanym wcześniej dashboardzie PowerBI .

Tak samo jak w przypadku AWS, możemy wyróżnić pewne elementy techniczne istotne z punktu widzenia ewidencji i zarządzania kontrolerem. Jeszcze przed komunikacją urządzenia z usługą, w Azure musi zaistnieć coś takiego jak Thing Registry. Jest to rejestr zawierający informacje na temat urządzenia. Oprócz właściwości ewidencyjnych, Thing Registry pozwala na zarządzanie kontrolerem i w szczególności przy jego użyciu możemy wyłączyć z nim komunikację.

3. Wsparcie dla programistów

Zarówno Amazon jak i Microsoft dostarczają pakiety SDK z bibliotekami i przykładami użycia kodu w C dla urządzeń bez systemu operacyjnego (ANSI C99) jak i w node.js.

Do różnic można zaliczyć to, że Microsoft z oczywistych przyczyn dostarcza wsparcie dla kontrolerów, na których można „posadzić” system operacyjny Windows w wersji 10 (np. Raspberry Pi ), Amazon za to udzielił wsparcia otwartej technologii sprzętowej Arduino w wersji Yun, czyli z interfejsem WiFi.

W tym temacie pojawia się szerokie pole do działania dla firm trzecich. Ciekawym zjawiskiem jest na przykład projekt Mangusta ( Mongoose OS ), które dostarcza swego rodzaju firmware dla kontrolerów ESP8266. Kontroler z chipem firmy Espressif charakteryzuje się sporymi możliwościami w zamian za bardzo niską cenę. Projekt dostarcza kilka przykładów komunikacji z AWS IoT pokazujących prostotę i łatwość uruchomienia.

Oczywiście wszystkie opisane powyżej rzeczy są dostępne na platformie Github co należy uznać dzisiaj za standard.

4. Bezpieczeństwo

Obydwaj dostawcy zdecydowali się na szyfrowanie kanału komunikacyjnego pomiędzy urządzeniem a chmurą przy pomocy protokołu TLS (Transport Layer Security, następca SSL), który zapewnia poufność i integralność transmisji danych, a więc uwierzytelnienie odbywa się przy pomocy certyfikatu X.509 podczas TLS handshaking.

IoT Hub od Microsoft przydziela dostęp urządzeniom do środowiska poprzez weryfikacje tokena zdefiniowanego w politykach współdzielonego dostępu.

Amazon do określenia dostępu do zasobów wykorzystuje jedną ze swoich usług, konkretnie chodzi o IAM service gdzie określamy użytkowników, grupy i role.

5. Koszt

AWS:

W dużym uproszczeniu, cena to 5 dolarów za jeden milion wiadomości, z wyłączeniem lokalizacji Azjatyckich gdzie jest troszkę drożej. Przy czym miłe jest to, że nie ma żadnych dodatkowych opłat podczas interakcji z takimi usługami jak S3, DynamoDB, Lambda, Kinesis, SNS, SQS.

Należy pamiętać, że dla Amazona wiadomość to 512-bajtowy blok danych, zatem jeśli będziemy generować dane mające zaistnieć w systemie jako dane typu string (w szczególności długie ciągi znaków) to będzie miała miejsce multiplikacja ceny. Zatem wiadomość o wielkości 1024 bajtów to już dwie wiadomości do zapłacenia. Warto się wczytać w cennik , w szczególności przy dużych infrastrukturach urządzeń IoT.

Azure:

Usługa jest sprzedawana w czterech pakietach, pierwszy bezpłatny pozwala na zapoznanie się z możliwościami i bezpłatne dostarczanie 8 tysięcy komunikatów o objętości 512 bajtów każdy per dzień.

Ponadto są jeszcze trzy typowo komercyjne plany taryfowe, w których można przesłać odpowiednio 400 000, 6 000 000, 300 000 000 czterokilobajtowych wiadomości (a więc uwaga, w tym przypadku wiadomość to już 4096 Kb) za 50, 500 i 5000 dolarów per dzień. Tu także warto wczytać się w cennik , aby niechcący nie stracić pracy o czym mówił Mirek Burnejko w swym artykule „ Najłatwiejszy sposób, aby stracić pracę przez cloud computing ”.

Podsumowanie

Obydwie firmy osiągnęły cel, jakim było stworzenie środowiska do akwizycji danych telemetrycznych, tylko w różny sposób. O wyborze dostawcy może zadecydować to, do której chmury mamy już dostęp, cena lub nawet usługi na pierwszy rzut oka niezwiązane z IoT.

Gdybyśmy chcieli na przykład ruszyć z biznesem podobnym do takich jak Exosite , Ubidots , itp. to musimy w jakiś sposób wystawić interfejs użytkownika dla klientów, chcących konfigurować zbieranie danych, generować raporty, oglądać dostarczane pomiary, itp. Zatem dochodzą nam usługi związane z utrzymaniem aplikacji WWW, najlepiej bez potrzeby utrzymywania systemów operacyjnych i maszyn wirtualnych, bo właśnie to według mnie zadecyduje o popularności cloud computingu.

Dzięki powyższym rozwiązaniom Telemetria, która kiedyś była zarezerwowana dla bardzo wyspecjalizowanych obszarów, teraz dzięki chmurze publicznej ma szansę trafić pod strzechy lub raczej rozwinąć biznesy, których wdrożenie jakiś czas temu wobec złożoności architektury i kosztów utrzymania byłoby niemożliwe.

WAŻNE: Rozpoczynamy prace nad najbardziej praktycznym warsztatem budowy rozwiązań IoT End-To-End w AWS i Azure. Jeżeli chcesz dowiedzieć się jako pierwszy o tym warsztacie, podaj swojego maila. Ilość miejsc na warsztacie ograniczona.

Jak Porównać Microsoft Azure i Amazon Web Services

Moją rolą, jako konsultanta, jest pomóc przedsiębiorcom i działom IT. Pomóc w wybraniu dobrej technologii i zaimplementowaniu jej. Gdy przy całym procesie mój klient nie ma wielu blizn i został doceniony przez swoich przełożonych, to wykonałem dobrą robotę.

W ostatnich miesiącach temat porównania usług dwóch największych graczy cloud pojawiał się wyjątkowo często. Mowa tu o Amazon Web Services i Microsoft Azure.

Pomyślałem, że nie może to być takie trudne. Pracując przez kilka lat z rozwiązaniami sieciowymi, łatwo mi było porównać router Cisco do routera Juniper.

Amazon Web Services znam też dość dobrze. Jeden z pierwszych biznesów, który przyniósł mi dużo dochodu, uruchomiliśmy z kolegą właśnie w AWS.

Zacząłem więc szukać… Zadanie okazał się trudne.

Co w Azure odpowiada instancjom EC2? Co w Azure odpowiada CloudFormation?

Rozumiesz idee.

To co mnie zdziwiło, to brak materiałów oraz jakość materiałów dostępnych. Niektóre porównania w sieci miały tylko kilka serwisów. Inne były błędne.

Postawiłem sobie cel. Opracuję porównanie Amazon Web Services i Microsoft Azure.

Jako pierwszy krok postanowiłem zrobić to co widzisz poniżej. Spotkałem się na piwie… na kilku piwach z ekspertem Microsoft Azure. Usiedliśmy i rozmawialiśmy o serwisach. On o Azure. Ja o AWS.

Zadanie okazało się ekstremalnie trudne, bo z pozoru podobne serwisy są bardzo od siebie różne.

Nie poddaliśmy się. Porównywaliśmy.

Przed Tobą pierwszy krok porównania. Aby określić które jabłko jest lepsze, trzeba najpierw odnaleźć podobne jabłka.

WAŻNE

Tu była statyczna tabelka.

W tej chwili jest to “żywy” dokument.

Dostępny pod tym adresem Serwisy Microsoft Azure, Amazon Web Services i Google Cloud Platform. Możesz go pobrać, edytować i dzielić się bez pytania.

IoT a Big Data i Cloud Computing - co łączy te technologie i jak można je wykorzystać?

Zdajemy sobie sprawę, że tematyka tego artykułu może rodzić wiele pytań, dlatego poniżej postaramy się odpowiedzieć na te najbardziej popularne. Jeśli jednak pojawi się kwestia, o której nie wspomnieliśmy — napisz do nas. Chętnie odpowiemy na wszystkie pytania, które budzą Twoje wątpliwości w tym temacie.

1. Jakie są korzyści modelu chmurowego IoT?

Rozwiązania IoT oparte na technologiach cloud computing są przede wszystkim elastyczne. Środowiska skalują się (zarówno w górę, jak i w dół) w zależności od liczby urządzeń lub ruchu, jaki generują. Co więcej, system do przetwarzania danych IoT można łatwo rozszerzyć o inne komponenty, np. analitykę czy wizualizację danych. Dodatkowo warto pamiętać, że usługi chmurowe do IoT zapewniają również najwyższe bezpieczeństwo zarówno przesyłania, jak i przechowywania danych.

2. Czym jest IoT Proof of Concept (PoC)?

PoC to mini projekt, który odpowie na pytanie, czy dana technologia nadaje się / spełnia wymagania niezbędne do budowy docelowego rozwiązania produkcyjnego. Nasz zespół wraz z Tobą wypracowuje końcowy efekt produktu, czyli powstaje główna architektura rozwiązania, doprecyzowywane są wymagania biznesowe, techniczne, testowe. Tworzymy plan projektu wraz z poszczególnymi kamieniami milowymi oraz dokumenty wsadowe dla poszczególnych obszarów wraz z metrykami, które będą śledzone w ramach projektu. Potwierdzenie wyjściowych założeń na początku współpracy daje Ci gwarancję, że otrzymasz taki produkt, jakiego oczekujesz.

3. Czym jest “on premise”?

On premise oznacza, że dany zasób (w tym przypadku system komputerowy) znajduje się w posiadaniu danej firmy — na produkcji, w biurze lub serwerowni.

4. Jak duże ilości danych mogę przesyłać do chmury? Czy są jakieś ograniczenia? Jeśli tak, to jakie?

Praktycznie nie ma takich ograniczeń. Big Data w chmurze obliczeniowej to poziom petabajtów. Tak naprawdę jest to tylko kwestia kosztów, jakie poniesiemy za zasoby, których będziemy używać.

5. Czy dane w chmurze mogą ulec awarii?

Zawsze istnieje ryzyko awarii i utraty danych, jednakże w rozwiązaniach chmurowych chmurach poziom tego ryzyka jest znikomy. Dostępność usług chmurowych często jest określona na poziomie 99,99%. Ciekawostką jest np. niezawodność (durability) dla Google Cloud Storage wynosi 99.999999999%.

6. Jaki jest najlepszy protokół umożliwiający przesyłanie danych z IoT do chmury?

Najczęściej wybierane protokoły do obsługi IoT to MQTT (Message Queuing Telemetry Transport) i HTTP (Hypertext Transfer Protocol). Dodatkowo można jeszcze spotkać protokołu AMQP (Advanced Message Queuing Protocol), COAP (Constrained Application Protocol) oraz DDS (Data Distribution Service). Rosnąca popularność protokołu MQTT jest wynikiem jego szybkości i małego zapotrzebowania na zasoby, a także generowaniem mniejszego ruchu sieciowego w porównaniu do protokołu http. W tabeli prezentujemy wspierane protokoły przez najbardziej popularne platformy:

L.P. Platforma Protokoły 1 Microsoft Azure MQTT, AMQP, HTTPS, MQTT poprzez websockets, AMQP poprzez websockets 2 AWS MQTT, HTTPS, Websockets, LoRaWAN 3 IBM Bluemix MQTT, HTTP, HTTPS 4 Thingworx MQTT, HTTPS, HTTP, COAP 5 Google MQTT, HTTP

7. Czy dane do chmury muszą być wysłane w sposób ciągły?

Dane mogą trafiać do chmury nieregularnym strumieniem, ponieważ zdarza się, że urządzenia IoT nie mają stałego połączenia z siecią. Usługi chmurowe są (niemal) zawsze gotowe do działania.

8. Czy mogę przesyłać dane, takie jak aktualizacje i informacje kontrolne z chmury do IoT?

Zdecydowanie tak. Połączenie do usług chmurowych może być dwukierunkowe.

9. Jaki jest średni miesięczny koszt chmury dla przeciętnego urządzenia IoT?

To zależy od dostawcy, na którego się zdecydujemy, a także modelu rozliczenia, który oferuje. Całkowity koszt zależy od wielu czynników, takich jak ilość przetworzonych danych czy też wykorzystania innych usług w systemie.