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.