Chaos Monkey - zasymulujmy awarię pod kontrolą

Od kilku lat temat Chaos Monkey jest ciekawą zabawką dla wielu inżynierów oprogramowania i SRE (Site Reliability Engineering). Postaram się naświetlić koncept i działania mające na celu poprawę jakości produktów w architekturze SOA (mikroserwisów).

Wstęp

 Zacznę od początku, bo na początku projektu jest (mikro)usługa, która komunikuje się z inną/innymi poprzez API. Obecnie modne w web developmencie jest REST API, jak każdy wie działające w oparciu o protokół HTTP (a ten na TCP/IP). W związku z tak niewielką zmianą sposób wymiany danych od kilkunastu lat, błędy jakie mogą się przytrafić podczas działania w takiej typowej architekturze również są powtarzalne. 

Mam na myśli fakt, że architekci/programiści/testerzy popełniają te same błędy i stale jest dyskusja dlaczego. Otóż dlatego, że liczy się "metodyka zwinna" wdrażania małymi krokami, a w takich krokach kompleksowe testy wydajnościowe/wysokiej dostępności niekiedy nie mają szansy zostać zrealizowane. Często zespoły mając już na produkcji zmianę mają testy na żywym organizmie. Łatwo dojść może do kolejnego poważnego incydentu, który nie zawsze opatrzony zostanie stosownym komentarzem i wiedza o przyczynie nie zostanie przedstawiona na większym forum. Tzn. inne zespoły nie dowiedzą się wcześniej niżeli przed identycznym incydentem na swoich usługach.

Jeśli nie wiecie, to takie testy prowadzą od dawna w NASA, w wojsku i w systemach medycznych oraz automatyce przemysłowej. Tzn. po wdrożeniu systemu często generuje się tzw. chaos i obserwuje, czy odpowiednie kontrolki w monitoringu zapalają się, informując operatorów o konkretnych problemach. Mogą oni podjąć racjonalne decyzje w kwestii np: przeżycia innych członków zespołu, czyli ocalić czyjeś życie. Bo jak wiemy w wielu profesjach jesteśmy skazani na błędy maszyn i ich oprogramowania. Tak, już od wielu lat oprogramowanie stanowi element naszego życia i warto dbać o jego jakość, bo istotne jest też to, że mniej niepotrzebnych nerwów - np: z powodu wad w sofcie - u człowieka wydłuża jego życie :-) To nie jest mój wymysł, ale obserwacja zachowań kolegów po ok. 20 latach pracy w IT. Jak to niektórzy mawiają, "nie każdy jest na tyle cierpliwy, aby przeżyć awarię i odnosi to dość osobiście". Po części z tym się zgodzę, bo widziałem odejścia z pracy ludzi, którzy nie zgadzali się z bylejakością i zwyczajnie z powodów zdrowotnych rezygnowali z miejsca pracy, bo dusiło ich to, że np: nie mają wpływu na podniesienie jakości.

W obecnych czasach w IT każdy człowiek w zespole, jak również zarząd mają wpływ na jakość produktów, które tworzą lub zlecają do wytworzenia. Idąc tym tropem, pojawia się "chaos", tzn. naturalna kolej rzeczy na produkcji, jeśli nie założymy, że przetestujemy system pod kątem chaotycznego/nietypowego działania. Ba niektóre firmy doszły do takiej wprawy, że testy chaosu potrafią robić na produkcji - tak, nie jest to literówka - i poziom wysokiej dostępności, jaki osiągnęli umożliwia takie działania.

Nieco historii - pewnego pięknego dnia - ok. 10 lat temu - pojawił się arttykuł "5 Lessons We’ve Learned Using AWS" na blogu Netflix, który oświecił cały świat IT w tematyce Chaos engineering.

Od tego momentu wiele firm budujących ze świadomością swoją infrastrukturę zarówno wewnętrzną, jak i hybrydową z użyciem publicznych chmur obliczeniowych, zaczyna inaczej postrzegać jakość i wysoką dostępność. To było epokowe odkrcie, bo świat chaotycznych testów jest dość fascyjnujący :-)

Co ludziom z IT dają testy chaosu

Chaos Monkey wprowadza tutaj w pracy zespołów celowe zamieszanie, które zapewnia w sposób kontrolowany poznanie wad sprzętu / oprogramowania / protokołów a także całego stosu technicznego. Wspomaga zespoły w ich pracy, o ile nie robią same takich testów w ramach kontroli jakości.

Zasada jest prosta: spróbujmy coś wyłączyć, zmienić przepustowość, zmienić jakiś timeout, rozłączać wymagane połączenia pomiędzy serwerami / usługami i mamy "niemalże" gwarantowane problemy, na którejś z warstw naszych usług. A jednak - okazało się, że jest jeszcze jakaś praca do wykonania, aby nazwać nasz system "wysoko dostępnym".

Tak, mam tutaj na myśli automatyczne generowanie "wywrotek" różnych części systemów, aby nauczyć się w praktyce, co jeszcze należy poprawić, aby nasze produkty były odporne na różnego typu błędy. Bo w sumie klienci są zadowoleni z tego, że coś co im oferujemy działa z ich punktu widzenia a naszą rolą jako inżynierów oprogramowania jest zapewnienie im tego komfortu. Tak, pomimo, że wiemy o tym, że połowa usług w jednej serwerowni padła i nie ma szansy na działanie. Ale o tym wiemy my a nie klienci i do tego zmierzają takie testy - wychwycić braki w jakości/ciągłości działania systemów możliwe wcześnie przed awarią postrzeganą przez klientów jako niedogodność. Liczy się uśmiech każdego klienta :-)

Z technicznego punktu widzenia zapewniamy testując chaosem wiedzę o tym jak działa system w kilku ważnych wymiarach:

- dostępności (ang. Availability)

- wydajności (ang. Performance)

- zestaw powiązań (ang. Feature Set)

- integralności komponentów (ang. Components Integrity)

- integralności danych (ang. Data Integrity)

Jakiego rodzaju scenariusze testowe są najczęściej wykorzystywane?

 

- przełączanie bazy danych (ang. Database Colocation) - kiedy dwie różne bazy działające w trybie np: master-slave lub active-active doznają symulowanej awarii lub niestabailności

- problem z niewydajnymi zrzutami/indeksami/archiwizacją bazy danych (ang. Snapshot Impact) - kiedy wzrasta ilość zrzutów / logów / procesów archiwizacji ew. indeksacji na bazie danych

- aktualizacja klastra / supervisora / urządzenia sieciowego (ang. Rolling Upgrade) - kiedy mamy do czynienia z automatyczną aktualizacją klastra, wirrualnej maszyny, firmware na urządzeniach sieciowych

- wiele, wiele innych "niesamowirtych" zjawisk w IT ...

Jak rozpocząć chaotyczne testy w naszym systemie

Na pewno od razu, po przeczytaniu tego posta ;-)

Jeśli chodzi o testy chaosu, to zakłada się zazwyczaj jakiś plan, który uwzględnia:

- poinformowanie innych zespołów, biznesu, programistów i działu jakości + monitoringu, w jakim przedziale czasu będą odbywały się takie testy i na jakim środowisku. Szanujemy nerwy innych.

- zasymulowanie obciążenia o charakterystyce zbliżonej do PRODukcji i zaplanowanie scenariuszy, które będziemy przeprowadzali. Nie wszystko na raz, bo nie łatwo będzie nam wnioskować.

- przygotujmy sobie dedykowane metryki, KPI i wskaźniki, po których poznamy, że zaszły jakikolwiek anomalie. Tak, w pierwszej fazie nauczymy się działania naszego systemu w warunkach normalnych, aby pod testami chaosu zaobserwować i nazwać anomalie.

- umówmy się w kilka osób.zespołów, że chcemy razem to zrobić, aby innym też dać szansę na odkrycie być może swoich błędów w ich ulubionej/dziedzinowej warstwie.

- przygotować się na starcie na PRODukcji o ile na innych środowiskach jest wszystko w porządku i jak najbardziej w godzinach pracy zaplanować takie testy

- koniecznie jest utworzenie formalnego raportu z testów i podzielić się nim z całą firmą, aby wiedza rozpropagowała się po znakomitej większości ludzi odpowiedzialnych. Świadomość jest cenniejsza, kiedy mamy dla ludzi lekkostrawne dane, które łatwo odczytają/odnajdą. Nie chodzi mi tylko o geeków, ale też o biznes, który może być nieświadomy np: długu technicznego.

- stałe dyskusje, szkolenia. rozwój wiedzy technicznej zespołów i uświadamianie o typach awarii ludzi od biznesu - to jest stały element branży IT

Tak dla pełnej jasności, ten artykuł ma na celu zwrócenie Waszej uwagi na metodologię testów chaosu i wprowadzenie do tematu. Nie zachęcam nikogo do wystartowania takich testów bez porozumienia z liderami technicznymi i bieznesem. Wszelkie działania, jakich dokonacie po przeczytaniu tego artykułu wykonujcie z pełną odpowiedzialnością i świadomością konsekwencji (tzn. prawdopodobnej awarii lub niedostępności biznesu).

Jakie narzędzia mamy do dyspozycji

Temat jest na tyle wartościowy, że celowo nie będę tutaj przeklejał linków a podam dwa źródła, jakie rozwinął Waszą wiedzę z tego obszaru. Oto otwiera się przed wami nieskończony ocean chaosu :-)

Github - awesome chaos engineering

Chaos engineering and testing: 34 tools and tutorials

Jeśli macie jakiekolwiek doświadczenie z testami chaosu i pozwalacie na takie praktyki piszcie, jak postrzegacie ten art.,  co odkryliście ciekawego dzięki tej metodzie testowania. 

Otwieram dyskusję na ten temat w komentarzach.

Cloud Builders' Day Poznań 2018 - darmowe warsztaty z chmury AWS

Jak zwyczajnie bywa ciekawy temat mnie wzywa :-) i tak trafiłem na wydarzenie "Cloud Builders' Day Poznań 2018". Chciałbym podzielić się z Wami kilkoma faktami i przybliżyć czym jest taki dzień.

W czasach hybrydowych podejść do budowania infrastruktury rozproszonych aplikacji i mikroserwisów warto poznawać chmury publiczne. Wiedziałem po kilku fajnych dniach spędzonych w konsoli AWS oraz w Berlinie na AWS Summit Berlin, jak sprytnie i szybko można stworzyć produkcyjną usługę z kilkoma linijkami kodu. Jednak kiedy chcemy wrócić do tematu, gdy nie używamy wielu uslug z chmur publicznych na co dzień i zgłębić dziedzinę, z pomocą przychodzi  wydarzenie Cloud Builders' Day. Rekomenduję każdemu, kto się zastanawia nad wzięciem udziału.
Głównie dlatego, aby w niektórych przypadkach przed rozpoczęciem napisania własnej implementacji wykonać tzw. MVP (minimalna wersja produktu), PoC (udowodnienie konceptu) na klockach przygotowanych dla nas w chmurze. To na prawdę wspaniałe narzędzie do szybkiego prototypowania a w wielu powtarzalnych przypadkach do wdrożeń produkcyjnych. Decyzję pozostawiam Wam, bo ilość zmiennych w decyzjach architektonicznych jest zależna od postawionego problemu.

Chmury publiczne bardzo dostosowują się do potrzeb developerów i czasów, dlatego pomijanie ich w branży IT jest niejako ignorancją dobrobytu jaki niesie za sobą wszechobecna technologia.

Oto slajd z rozpoczęcia warsztatów.

Moje pozytywne wrażenia zawarte są w doświadczeniu praktycznym podczas tego warsztatu, kiedy poznawaliśmy tajniki konfiguracji i budowania aplikacji oraz infastruktur dla:

• serwerów aplikacyjnych automatycznie skalujących się zależnie od metryk obciążenia/ruchu
• małego klastra Hadoop do analityki Big Data
• usługi tłumaczącej pismo na mowę i wysyłającej SMSa dzięki 'funkcji lambda'
• składowania danych w magazynie obiektów (AWS S3 object storage)
• budowania klastrów ECR i EMR
• narzędzi wspomagających pracę developerską
• ambitnych zadań z Machine Learning (ML)
• ... i kilku innych praktycznych przykładów

A wszystko w 8 godzin i dla zdobycia odznak chmurowych :-) + dobrej zabawy w programowanie pod okiem ekspertów wprost z Amazona. Dzięki prowadzącemu Tomaszowi Stachlewskiemu warsztaty odbieram jako zabieg wyrafinowany, skrojony na miarę współczesnych potrzeb oraz dopracowany w każdej minucie :-)   

Internet of Things - protocols review - gościnnie na Net::IP Meetup #8

Po wystąpineniu z prezentacją Internet of Things - protocols review w Poznaniu na meetupie
Network&WirelessMeetup (NWM): IoT - bezpieczeństwo i protokoły zostałem zaproszony gościnnie na wystąpienie z prezentacją we Wrocławiu na meetupie Net::IP #8.

Chciałbym się podzielić wrażeniami z wystąpienia oraz polecić Net::IP jako wartościową inicjatywę dla społeczności lokalnych DevOpsów we Wrocławiu i nie tylko :-)

Z pozytywnym nastawieniem jak zwykle mogłem podzielić się swoimi doświadczeniami oraz researchem z używania protokołów internetu rzeczy MQTT, HTTP oraz DDS.
Liczebność na meetupie dopisała, bo było coś ponad 60 osób, miejsce dość przyjemne i oczywiście rarytasik to pizza wypiekana na miejscu z pieca.


Pokrótce każdy z prelegentów (Ja i Piotr) pokazał coś, co jest wyciągniętym tzw. mięsiwem technicznym i bardzo ucieszyły nas liczne pytania, które pojawiały się wokół tematyki spotkania.

W kwestii swojej prezentacji mam wrażenia, że dotrzymałem kontraktu i wystąpienie cieszyło się zainteresowaniem. Określam to na podstawie pytań w trakcie i po wydarzeniu.
Zadziwiają mnie zawsze pytania o podstawy typu "jak zacząć z IoT, którą płytkę wybrać, jak programować" i oczywiście zakładamy, że na meetup przyjść może każdy i takie pytania są jak najbardziej ok. To co mnie zadziwia, to fakt jak długo dociera do ludzi informacja o powszechności np: takiego środowiska i hardwaru jakim jest Arduino oraz mistycznego Raspberry Pi

Z tego miejsca zachęcam wszystkich do ryzykowania i wydawania czasami tzw. stówki w celu edukacyjnym, bo w dobie dzisiajszych możliwości, jeśli kupicie nawet nieodpowiedni sprzęt lub soft. to zawsze zyskacie wiedzę i kolejne zakupy będą bardziej trafione :-)

Przypomina mi się również mój wpis o obecnie rekordowej oglądalności, kiedy ok. 10 lat temu znając już od wielu lat architekturę AVR zacząłem składać coś, co nazywało się Arduino i posiadało jeszcze wówczas zamiast USB port szeregowy SERIAL. Udało się bez problemu a cały zestaw instrukcji jak zainstalować i uruchomić na Linuxie Arduino zapisałem na moim blogu.
Wpis p.t. Arduino, Freeduino, Pyduino - szybki start z mikrokontrolerami AVR


W kwestii wystąpienia kolegi z Akamai, to jestem pełen podziwu dla mistrzostwa i wykorzystania protokołu BGP do sporej optymalizacji i pięknego przeskalowywania architektury. Znam ludzi, którzy wspominali mi o tym, że taki eksperyment chcą przeprowadzić i posiłkując się materiałem przedstawionym na meetupie bardzo w to uwierzyli. Czekamy na realizację i poprawę kolejnej zacnej infrastruktury ;-)

Dziękuję z tego miejsca wszystkim uczestnikom i prelegentom meetupu Net::IP i oby więcej takich wspaniałych edukacyjnych dni w naszym codziennym technicznym życiu się pojawiało.

Everything as Code - kodem opisujemy programy i systemy IT

"Everything as Code" to koncept, który przywołuje bazę programowania, czyli kod. Oczywiście większości z nas kod kojarzy się z pisaniem programów. Jednakże każdy system jesteśmy opisać również dedykowanym kodem i w ten sposób mamy zapewnionie analogicznie jak w przypadku programów sprawniejsze rozwijanie i utrzymanie systemów informatycznych.

Zgodnie z trendami w IT doszło do takiej sytuacji, że frazes "as code" został wykorzystany do wielu produktów, które pokrótcec w tym wpisie chciałbym przedstawić. Oto najpopularniejsze pojęcia, które bardzo silnie wpływają na propagowanie omawianej filozofi "... as code" w IT.

Configuration as Code

Configuration as Code ( CaC ) - Konfiguracja jako kod jest praktyką traktowania wszystkich części systemu jako kodu. Oznacza to przechowywanie konfiguracji wraz z kodem źródłowym w repozytorium, takim jak git lub svn. Przechowywanie konfiguracji kompilacji, właściwości aplikacji i konfiguracji wdrażania jako kodu oznacza, że ​​są one śledzone i można je odtworzyć jednym kliknięciem. Oczywiście w sytuacji ingerencji osoby z zewnątrz do systemu łatwo przywrócić stan konfiguracji automatycznie.

Centralne zarządzanie nawet bardzo rozproszoną konfiguracją to klucz do bezpiecznego i stabilnego systemu, w którym wiemy dlaczego coś działa zgodnie z ustawieniami.

Infrastructure as code

Infrastructure as code - ( IaC ) - Infrastruktura jako kod obejmuje projekt systemu, również zapisany jako kod. W starym świecie IT infrastruktura wymagała specjalistycznych umiejętności oraz fizycznego sprzętu i kabli do zainstalowania. Systemy były cenne lub nie były często dotykane / aktualizowane, ponieważ ludzie, którzy je stworzyli, nie działają już dla firmy. Początek przetwarzania w chmurze i aplikacji natywnych w chmurze sprawił, że jest to tania i łatwa w rozlokowaniu infrastruktura wirtualna. Przechowując konfigurację środowisk wirtualnych jako kodu, można je cyklicznie przetwarzać i odtwarzać w razie potrzeby.

Automatyzacja wdrożeń to klucz do bezpiecznego i stabilnego systemu, w którym poszczególne bloki / usługi / mikroserwisy mają swoją znaną z góry rolę.

Dlaczego infrastruktura jako kod?

Wirtualizacja, chmura, kontenery, automatyzacja serwerów i sieci zdefiniowane przez oprogramowanie powinny uprościć pracę działu IT. Zapewnienie, skonfigurowanie, zaktualizowanie i utrzymanie usług wymaga mniej czasu i wysiłku. Problemy powinny być szybko wykrywane i rozwiązywane, a systemy powinny być konsekwentnie konfigurowane i aktualne.
Pracownicy IT powinni spędzać mniej czasu na rutynowych pracach, mając czas na szybkie wprowadzanie zmian i ulepszeń, aby pomóc ich organizacjom w zaspokajaniu ciągle zmieniających się potrzeb współczesnego świata. Ale nawet z najnowszymi i najlepszymi nowymi narzędziami i platformami zespoły ds. Obsługi IT wciąż uważają, że nie nadążają za codziennym obciążeniem pracą. Nie mają czasu na rozwiązywanie długotrwałych problemów z ich systemami, a tym bardziej ich modernizację, aby jak najlepiej wykorzystać nowe narzędzia.
W rzeczywistości chmura i automatyzacja często pogarszają sytuację. Łatwość dostarczania nowej infrastruktury prowadzi do ciągle rosnącego portfolio systemów i potrzeba coraz więcej czasu, aby wszystko się nie zawaliło. Przyjęcie narzędzi chmurowych i automatyzacyjnych natychmiast obniża bariery dla wprowadzania zmian w infrastrukturze. Jednak zarządzanie zmianami w sposób poprawiający spójność i niezawodność nie wychodzi z pudełka z oprogramowaniem. Potrzeba ludzi, aby zastanowili się, w jaki sposób wykorzystają narzędzia i wprowadzą systemy, procesy i nawyki, aby skutecznie z nich korzystać.

Wartościowy cytat z wartościowej książki o IaC odpowiadający na postawione pytanie. Przy okazji polecam tą książkę jako lekturę podstawową w tym temacie. Oto jak prezentuje się okładka:

Potężne narzędzia operacyjne DevOps we współczesnych systemach IT

Od wielu lat poskramiamy rozwiązania w chmurach prywatnych, publicznych i hybrydowych. Zdecydowanie więcej Dev niżeli Ops jest obecnie w codziennej pracy w nowowczesnym dziale IT.

Koncept DevOps to stałe poszukiwanie możliwości automatyzacji powtarzalnych admińskich działań poprzez rozwój warsztatu developerskiego. Automatyzacja infrastruktury poprzez kod uwypukla ten koncept.

Najczęściej kod opisujący infrastrukturę to specjalny język domenowy DSL (ang. Domain Specific Language), czyli rozwiązujący problemy określonej dziedziny. W tym przypadku problem to opis konfiguracji i kolejności instalacji poporzez skrypty automatyczne naszych maszyn, systemów i  oprogramowania na nich.
Najczęściej plików definicji nie piszemy od zera, gdyż analogicznie do języków programowania istnieją biblioteki, które ułatwiają nam wiele typowych czynności t.j. ustawienie strefy czasowej, automatyzacja aktualizacji, czyszczenie starych kerneli z listy, postawienie serwera www, itp.



Przedstawiam poniżej kilka gotowych do użycia ideii oraz narzędzi automatyzacji i wsparcia operacyjnego dla świeta DevOps (pod linkiem mój odrębny artykuł p.t. "Fenomen DEVOPS na ratunek dla skostniałych i niezbyt wydajnych zespołów w IT (programista i administrator w jednym)").


Puppet - bazując na dialekcie języka Ruby powstał pakiet pierwotnie pod banderą 'Puppet Labs' do zarządzania farmą maszyn. Obecnie Puppet doczekał się wersji 5 co potwierdza jego popularność wśród środowsk produkcyjnych. Działa dość sprawnie i zasadniczo tworzymy plik z rozszerzeniem *.pp a wnim zawieramy recepturę. Oczywiście dotyczyła będzie w praktyce całej farmy/klasy maszyn a nie jednej maszynki. Taka receptura trafia do repozytorium, z którego puppet-agent - zainstalowany na maszynce tuż po postawieniu z kanonicznego obrazu systemu - pobiera sobie przebieg działań i skutecznie je wykonuje.   


Ansible - to narzędzie do provisioningu, któro pozwala na podłączenie się do node/maszyny, wgranie tam modułów. Moduły to zasoby wykorzystywane w opisie deklaratywnym stan systemu. Moduły są następnie wykonywane. Po wykonaniu moduły są kasowane. Słowo klucz tutaj to deklaratywny stan systemu. Czyli coś co nam opisuje jaki jest pożądany końcowy stan – jeżeli coś odbiega od założeń my mamy prawo odpowiednio zareagować, jak? zależy od nas.
Ansible najlepiej nadaje się do środowisk już istniejących, np. kiedy przejmujemy "legacy system" i musimy wesprzeć się automatyzacją, to możemy dodawać nowe zmiany już w sposób kontrolowany, przy pomocy receptur pisanych w Ansible.
Plusem Ansible jest prosta konfiguracja zmiennych i zadań do wykonania na środowisku oraz brak konieczności instalowania na klientach (w puppet musimy zainstalować puppet-agent na mszynkach).

Oczywiście mamy jeszcze do dyspozycji Chef, Salt i wiele innych możliwości.

Oto porównenie kilku narzędzi automatyzacji opisu systemu jako kodu.


Kolejnymi ważnymi pojęciami, które warto kojarzyć w kontekście konfiguracji jako kodu jest:

Platform as a service - PaaS - opis całej platformy w kodzie, który pozwala na postawienie np: całego naszego systemu w innej chmurze publicznej w celu wykonania testów lub sprawnej migracji do modelu hybrydowego.

Function as a service - FaaS - funkcje w chmurze (koncepcja serverless computing), dzięki którym nie musimy budować wielu mikroserwisów. Są to funkcje zazwyczaj dostępne publicznie po protokole HTTP i oferujące ~kilka minut przetwarzania naszych danych wejściowych. W wielu chmurach publicznych umożliwiają łączenie z wieloma usługami wewnętrznymi a nawet zewnętrznumi spotkałem się z takim ciekawym przypakiem w Azure, że można np: wpisywać do Google Docs rezultaty przetwarzania danych z FaaS.


Oto ciekawe porównanie, IaaS, PaaS i FaaS:

Pamiętaj, kiedy potrzebujesz potężnych narzędzi operacyjnych. Musisz napisać kod.

Internet of Things - protocols review (MeetUp Wireless & Networks, Poznań 21.02.2018)

Dziękuję wszystkim słuchaczom, którzy pojawili się na drugim MeetUpie p.t. "Network & Wireless Meetup (NWM): IoT - bezpieczeństwo i protokoły"
Posileni tak sporą dawką wiedzy wracamy do projektowania i programowania bezpieczniejszych i wydajniejszych "lodówek" :-)

W związku z obietnicą po dzisiejszym wystąpieniu n.t. protokołów internetu rzeczy udostępniam swoją prezentację :-)
Zachęcam do zadawania pytań i dyskusji związanej z tym szeroko rozumianym tematem. Wszelkie uwagi/sugestie/wrażenia mile widziane - piszcie proszę w komentarzach.

Internet of Things - protocols review (MeetUp Wireless & Networks, Poznań 21.02.2018) from Marcin Bielak


Dla osób zainteresowanych wersją wideo załączam nagranie prezentacji: