Data Engineering vs. Software Engineer - co możemy zyskać z praktyk BigData w roli Software Engineer?

Kiedy myślimy o programowaniu, wówczas rola inżyniera oprogramowania (ang. Software Engineer) jest jednym z pierwszych zawodów, które przychodzą nam na myśl. Tak wiele lat mówiło się o tzw. deweloperach, czy też full-stack developers, że mamy na codzień mieszankę różnych ról, która jeśli podsumujmemy sobie dzień pracy, robią identyczne rzeczy tzn. tworzą oprogramowanie.

Świat IT oferuje również wiele specjalizacji, które dotykają poddziedzin i szczególnych tematów wokół różnych aspektów, jakie na codzień robi rola inżyniera oprogramowania. W tym wpisie przyjżymy się porównaniu ról Software Engineer i Data Engineering (Inżynieria Danych). Zastanowimy się, dlaczego warto zainteresować się tą dziedziną skupioną głównie wokół przepływów, gromadzenia i transformacji danych? Jakie korzyści może przynieść Software Engineerowi rozwinięcie pojęć, które są codziennością dla roli Data Engineer?

Software Engineer vs Data Engineer (BigData Engineer)

Software Engineer tworzy oprogramowanie, dba o jego jakość, testuje i wdraża. Głównym celem tej roli jest dostarczenie funkcjonalnego, wydajnego i skalowalnego kodu.

Data Engineer (BigData Engineer) skupia się na projektowaniu, budowie, integracji i zarządzaniu dużymi zbiorami danych. Osoba w tej roli pracuje nad optymalizacją architektury danych, przepływem informacji oraz przetwarzaniem danych w czasie rzeczywistym.

Porównanie narzędzi

Obie role korzystają z narzędzi, które ułatwiają pracę nad kodem i danymi (bardzo ogólna lista - celowo zaweżona, aby wyrobić sobie pogląd): 

• repozytoria kodu typu: GitHub, GitLab
• obie role korzystają z systemów kontroli wersji do zarządzania kodem.
• bazy danych: MySQL, PostgreSQL - podczas gdy Software Engineers skupiają się na integracji, Data Engineers pracują nad optymalizacją i bazy danych SQL oraz noSQL stanowią codzienność.
• automatyzacja: Jenkins, Travis CI - obie role korzystają z narzędzi CI/CD do automatyzacji procesów.
• testowanie: JUnit, PyTest - testowanie jest kluczem dla obu ról, ale w kontekście różnych zastosowań.
• Big Data: Hadoop, Spark - głównie narzędzia Data Engineers, ale Software Engineers powinni je znać i często bywają częścią projektów, w których korzystają z Data Warehouses (magazynów danych) oraz object-storage (systemów przechowywania obiektów np: AWS S3, Google Storage, Azure Blob Storage, itp)

Wysoka jakość kodu i CI/CD

W obu rolach kluczowe jest dbanie o jakość kodu. Narzędzia takie jak linters, code reviews i testy jednostkowe, testy integracyjne, testy rozmyte, testy end to end są niezbędne do codziennej pracy nad jakością rozwiązań. 

Procesy CI/CD są stosowane zarówno przez Software Engineers, jak i Data Engineers, ale w przypadku tych drugich skupiają się one bardziej na przetwarzaniu danych i analizie w czasie rzeczywistym.

Spotkałem się wielokrotnie z przykładami, kiedy inżynier danych nie miał podstaw inżynierii oprogramowania, ale dzięki znajoności metod analitycznych efeky jego pracy były jak najbardziej na oczekiwanym poziomie. Dla roli Data Engineer liczą się gotowe narzędzia i usługi SaaS. Dla roli Data Engineer lub DataOps bardziej liczy się tworzenie dedykowanych narzędzi, czy platform przetwarzania danych.

Nie zawsze Data Engineer musi rozwiązywać swoje zadania poprzez kodowanie w wielu językach programowania. Spotyka się stanowiska DE, gdzie liczy się zaawansowana znajomość dialektu SQL i wiele zadań dotyczących batchingu danych oraz streamingu udaje się dowozić z oczekiwaną skutecznością. Ba, często nie oczekuje się od roli DE, że wytworzy narzędzie, czy framework - firmy są bardziej skłonne kupić gotowe narzędzie lub wdrożyć platformę do przetwarzania danych. Wiadomo, zależy od skali i sytuacji. 

Większość dużych firm posida BigData, co wiąże się z tym, że SaaS i inne gotowe rozwiązania komerycyjne nie dają rady, lub ich koszt utrzymania to 9 zer! Spotkałem się wówczas z pozytywną praktyką reużywania narzędzi z świata Open Source i robieniu własnych zmian, czasami dzieląc się ze społecznością. To jest ciekawsza opcja dla roli DE moim zdaniem i doceniam organizacje za takie ambicje, aby dokładać swoją cegiełkę dla społeczności Open Source.

TOP10 narzędzi dla ról Software Engineer oraz Data Engineer

Poniżej przedstawiam bardzo wąski wycinek narzędzi, aby zwrócić uwagę i nakierować, jakie współczesne narzędzia mogą być pomocne w wymienionych rolach. Warto brać poprawkę na fakt, że z miesiąca na miesiąc zestaw narzędzi zmenia się dość silnie i warto podążać za trendami. 

Dobre praktyki często mówią nam, że jeśli narzędzie jest stare i sprawdzone, to warto go używać. Dzisiaj ilość rozwiązań SaaS oraz ML burzy wyżej wymienioną koncepcję - zachęcam do eksperymentowania z najnowszymi narzędziami, gdyż mogą być oparte o rozwiązania uczenia maszynowego (ang. Machine Learning), przez co wspierają pracę inżynierów IT, wyszukując np. najczęstsze pomysłi i serwując auto-korektę. To wpływa pozytywnie na jakość rozwiązań oraz czas dostarczania.

Tak prezentują się zestawy narzędzi dla ról:

Software Engineer:

1. GitHub
2. Docker
3. Kubernetes
4. IntelliJ IDEA / Visual Studio Code
5. Jenkins / Github Actions / GoCD
6. JIRA - Scrum / Kanban baord
7. Slack / Discord
8. Sonarcube / Sonar - code quality checker 
9. AWS / Google Cloud / Azure
10. Terraform / Pulumi / CDK

Zasadniczo w roli SF liczą się dość silnie rozwiązania serverless, czyli takie, gdzie inżynier nie musi niczego wiedzieć o sieci, serwowaniu API a zwyczajnie buduje funkcje i wdraża do clouda rozwiązania, które mają od razu podpięty monitoring. Tak, tutaj pewnie zastanawiacie się, o jakim inżynieże myślę - wyjaśniam, takim regularze, który potrafi dowozić rozwiązania na czas i orientuje się, że sprawność nie zawsze oznacza debugowanie własnego serwera www :-)

Oczywiście rola SF jest znacznie szersza i często jest bazą do wszelkich innych ról w IT np: może być wymagana dla Data Engineer w większych firmach. Jest to związane z tym, że niektóre organizacje tworzą i utrzymują swoje frameworki lub/i platformy developerskie. Brak wiedzy o koncepcjach i wzorcach SF zdecydowanie utrudni współpracę.  

Jest wiele miejsca pracy, gdzie od roli SF wymaga się zaawansowaj znajomości konkretnych technologii oraz doświadczenie np: ze specyficznym sprzętem (ang. hardware). Mnogość kombinacji powoduje, że możemy w tej roli odnaleźć wiele ciekawych miejsc pracy oraz wyzwań zawodowych.

Data Engineer:

1. S3 / Google Storage / Azure Blob storage - object-storage
2. Spark
3. Hadoop
4. Kafka
5. Airflow
6. Hive / Presto
7. Elasticsearch / SOLR / vector databases
8. Terraform / Pulumi / CDK
9. Snowflake / Google BigQuery / AWS Redshift
10. Data governance & data security solutions

Większość narzędzi Open Source, które są używane przez rolę Data Enginner (oraz Machine Learning Engineer) znajdziesz tutaj (ang. LF AI & Data Foundation Interactive Landscape) - to jest lista + interaktywna macierz narzędzi rekomendowych przez Linux Foundation. Są w niej opisy oraz linki do projektów. Jeśli ktoś w roli DE opanuje skutecznie ok. 20% tych narzędzi, to może śmiało nazywać się Seniorem :-) Liczba narzędzi jest zacna i każde narzędzie to dość spory projekt Open Source ze swoją historią, repozytorium i społecznością!

W roli Data Engineer liczy się często rozumienie architektury przepływu danych w całej organizacji, nie tylko w jednym zespole. Taka umiejętność daje moce optymalizacji zarówno zasobów (CPU/RAM/storage) w przetwarzaniu danych (np: przy pomocy tzw. pipelines) jak i pozwala szerzej spojrzeć na potrzeby analityczne. Nie zawsze rola DE ma 

Wymagane kompetencje i cechy dla omawianych ról

Software Engineer:

• Zrozumienie architektury systemów (obecnie głównie opartych o publiczne cloudy: AWS, GCP, Azure, Oracle, itp)
• Umiejętność debugowania (wyszukiwania nietrywialnych powodów, dlaczego oprogramowanie, czy system opearacyjny reaguje na nasz kod w specyficzny sposób - szukanie błędów w kodzie i integracjach z innymi usłygami)
• Znajomość różnych języków programowania
• Umiejętność pracy w zespole (szczególnie w zwinnych metodach pracy t.j. Scrum, Kanban, XP, itp)
• Zgłębienie protokołów: HTTP, GraphQL, gRPC, ptotobufitp.
• Znajomość koncepcji telemetrii i obserwacji pracy usług i aplikacji; koncepcja Service Mesh
• Orientacja w OWASP TOP 10 i bezpieczeństwie wokół web/mobile oraz integracji API

Data Engineer:

• Rozumienie przepływu danych
• Rozumienie koncepcji t.h. batching, streaming, 7V, data lake, delta lake, lakehouse, warehouse, distributed computing, object storage, Data Mesh, Data Quality, Data Governance, ...
• Umiejętność pracy z dużymi zbiorami danych (np: 100 TB+)
• Znajomość specjalistycznych narzędzi Big Data (Hadoop, Spark, Snowflake, S3 API, IoT analytics tools)
• Znajomość matematyki i statystyki (podstawy analityki lub/i Data Science)
• Znajomość wzorców integracyjnych (np: EIP - Enterprise Integration Patterns)
• Znajomość koncepcji telemetrii i obserwacji pracy usług BigData. Szczególnie skupienie na kosztach przetwarzania danych oraz monitoringu zdarzeń w procesach przetwarzania danych, alertowanie sytuacji krytycznych do właścieli obszarów danych.
• Pogłębiona wiedza o wydajnych formatach danych t.j. HDFS, AVRO, parquet, protobuf, IceBerg itp.
• Umiejętność odnajdywania w katalogach danych relacji pomiędzy tabelami/polami oraz wartości, które mogą potencjalnie zwiększyć wartość - od strony jakości danych - dla wdrażanych rozwiąń 

Podsumowanie

Dla roli Software Engineer, ścieżka Data Engineer jest więcej niż tylko nowym zestawem narzędzi. To rozszerzenie horyzontów, nowe wyzwania i możliwość pracy z przy interesujących zbiorach danych.

Zdecydowanie spojrzenie w stronę chmur publicznych i komponentów z kategorii data, AI, ML i BigData, których są dziaiaj dziesiątki a niebawem pewnie będą setki.

Jeśli jesteś Software Engineerem i myślisz o rozwoju, pomyśl o BigData. Twoje umiejętności programistyczne w połączeniu z wiedzą o danych otworzą przed Tobą drzwi do fascynującego świata Big Data. Nowe narzędzia do integracji i transformacji danych, to ciekawy kawałem inżynierii oprogramowania, który za pewne poszerzy Twoje horyzony i zestaw umiejętności zawodowych.

Jeśli jesteś praktykującym Software Engineerem czy Data Engineerem, podziel się swoimi przemyśleniami i doświadczeniami w komentarzach.

AWS re:Invent 2020 i redefinicja wysokiej dostępności dla data center

Kiedy zastanawiamy się nad pojęciem wysokiej dostępności (ang. high availability) w systemach informatycznych - o ile w ogóle niektórzy zastanawiają się - to warto nadmienić tutaj o ważnej nowości, którą podzielił się w ostatnich dniach Amazon w ramach konferencji AWS re:Invent 2020. Ten wpis to rozważania nad wysoką dostępnością w skrócie HA, jak możemy ją zdefiniować, jakie miary ją definiują i jakie techniczne zagadki nas czekają, kiedy mówimy, że "chcemy wdrożyć HA".

Wprowadzenie do HA

Wysoką dostępnością określamy stan systemu, kiedy jego funkcjonalności biznesowe, czyli te z punktu widzenia użytkownika końcowego w całości są dostępne do użycia. W języku polskim określa się to nawet skrótem SWN (system wysokiej niezawodności), z którym spotkałem się rzadziej niżeli przyjętym skrótem HA. Zasadniczo nie wszyscy rozumieją, że nie chodzi tutaj o dostępność wszystkich komponentów systemu, bo nie zawsze klikanie np: ikonki Like jest kluczowe dla biznesu. Dla jednego (patrz: Facebook) to core biznes, dla innego np: wirtualnej galerii sztuki to po prostu dodatek. Z tego też banalnego punktu widzenia, posiadanie wysokiej dostępności to sprawa zależna od core biznesu. 

Na pewno nie można dyskutować o płynności HA, w niektórych bardzo specyficznych dziedzinach t.j. medycyna, lotnictwo, obronność, przemysł kosmiczny, sterowanie ruchem, autonomiczne pojazdy, roboty przemysłowe i wiele innych. Jak widać, są zastosowania, gdzie warto nieco przedefiniować podejście do wysokiej dostępności. A może po prostu zastosować HA zgodnie z obowiązującymi normami :-)

Wydaje się niektórym młodszym przedstawicielom IT, że HA to ostatni nabytek branży IT i to tutaj tak dba się o wysoką dostępność. Otóż, założenie to jest obarczone błędem, bo HA również towarzyszyło pierwszym konstruktorom z różnych dziedzin np: w motoryzacji - silników, w przemyśle kosmicznym - napędów rakiet, od którego zależy powodzenie misji załogowej. Widać po tych przykładach, że HA, to nie jest kilka zasad i koniec. Na prawdziwe HA składa się wiele detali -  szkoły inżynierskie, praktyka starszych inżynierów i szkolenie młodych adeptów sztuki, monitoring, audyty, testy chaosu, fuzzing, dzielenie się wiedzą, bezpieczeństwo z podejściami blue/red i stałą eksploracją branży, budowanie standardów i norm, zasady i higiena w miejscu pracy, dyskutowanie o wyzwaniach i dzielenie się wiedzą, posiadanie patentów, poddawanie testom obciążeniowym tego co wytwarzamy i wiele więcej różnych tematów. Tak, na HA składa się dość sporo doświadczenia ludzi z różnych działów, aby w końcu je jakoś zapisać. Warto zapisać, bo do momentu posiadania "wirtualnego SLA", nie wiemy z czym się technicznie mierzymy.

Tak przy okazji, kiedy lecicie samolotem tam też są komputery, których HA jest wyliczone i jest taka mini serwerownia, która zapewnia redundancję, kiedy zawiedzie sekacja A. Nasze życie ratuje wówczas sekcja B oraz dalsze reakcje zgodnie z procedurami pilotów. Jak zaufać autopilotowi w takiej sytuacji ? Otóż, SLA takiego zachowania zostało określone w normach i testy, awarie, incydenty, wypadki wykazały, że pewne rozwiązania działają sprawniej od innych. Tym samym, są znane kroki, które podwyższają HA działania samolotów. Ba, są instytucje, które piszą standardy, abyśmy w powietrzu czuli się zdecydowanie lepiej niżeli w powietrznym PKSie ;-) Nie jest to uwaga do tanich linii lotniczych - polubiłem je kiedyś i nawet dają dreszczyk emocji czasami, gratis.

Jak przedstawić HA w postaci mierzalnej metryki

Zapisanie formalnie jaki jest poziom wysokiej dostępności (ang. HA) w naszym systemem dobrze jeśli będzie odbywał się w sposób pół-automatyczny i bazował na wskaźniku umownym Service Level Agreement (ang. SLA, - pol. umowa o gwarantowanym poziomie świadczenia usług). Tutaj słowo wyjaśnienia, bo SLA dla nas samych może wydawać się żartem, ale nim nie jest. Jest za to prawdziwym przedsięwzięciem, postawieniem na nogi wielu działów w firmie, dzięki czemu każdy w swoim zespole zastanawia się przy okazji: co mógłby zrobić jutro lepiej? na co nie było być może czasu wczoraj. A może był czas, ale zarządzanie nim nie było efektywne? A może klient nie zapłacił za SLA na poziomie wyższym niżeli mamy obecnie? 

Takie i inne ważne pytania warto zadać sobie w zespole, aby powiedzieć np: mamy SLA na poziomie zmierzonym od miesiąca wynoszącym 99,999 % !!! No na pewno nie będzie nikomu wstyd, jeśli takie SLA posiada, bo podana wartość to zmierzona niedostępność systemu 5 minut na rok :-)

Czemu warto walczyć o więcej 9-tek w swoim SLA?

Tak, są firmy, które walczą o więcej dziewiątek w swoim umownym zapisie o dostępności SLA i uwierzcie tysiące ludzi dbają o to, aby po roku rozliczyć się sumiennie z tego. Tak, bo inżynieria a nie amatorka polega na tym, że jeśli zgadzamy się w zespole na SLA i umawiamy, że będzie to grało na poziomie X, to robimy jako inżynierowie wszystko, aby do tego doszło. 

Nie zawsze w zespole są inżynierowie z tytułami, lecz dobrze jeśli znajdzie się taki dla uzupełnienia ekipy ;-). Warto wiedzieć, że obecnie w branży IT są obecni ludzie po technikach, po filozofii i innych szkołach i branża bardzo szanuje każdego, bo brakuje zwyczajnie chętnych osób o otwartych umysłach do stałej nauki nowości IT. Zapewniam Was, że niekiedy nieinżynierowie mają więcej odwagi/energii/zamozaparcia do zrobienia HA na solidnym poziomie, niżeli tzw. "inżynierowie z petrobudowy" jak śpiewał kiedyś Kazik. Ta dygresja wynika z doświadczenia, a nie jest to obraza dla szeroko rozumianej inżynierii. Mam tutaj na myśli fakt, że nie jeden inżynier w karierze zawodowej spotkał młodzika, który robił coś i szybko uczył się, po czym jego poziom realizacji zadań przewyższył poziom oferowany przez inżyniera. To w tych czasach IT może być zgubne, jak szybko ludzie spoza branży są w stanie, przy odpowiedniej motywacji stać się ekspertami. Zapewne jest to kwestia urodzenia obok tabletu :-) albo z wrośniętym 9-tym bitem, hahaa. 

Tutaj znajdziecie kalkulacje dostępności dla SLA. Istnieją w sieci też kalkulatory online dla SLA, gdzie wpisując 9-tki zobaczymy jak bardzo dostępny powinien być system IT wg. określonego SLA. 

Wracając do tematu kolejnych 9-tek w SLA, warto powiedzieć, że niektórym firmom HA zwyczajnie się to opłaca. Np: weźmy pod uwagę Allegro.pl, czyli taki najbardziej namacalny przykład polecanego e-commerce w naszym kraju :-) Doceniam inżynierię, jaką tam mogłem poznać i współtworzyć. To jak Allegro.pl podchodzi o SLA to właśnie przykład powagi i odpowiedzialności, dojrzałości zespołowej, gdzie na końcu Pan Kowalski kupując żyrafkę w pacyfki wnuczce w prezencie, po prostu klika "Kup teraz" i np: mając podpiętą kartę kredytową, nie musi się martwić tym, czy towar dotrze na miejsce. Tak, towar dotrze, bo większa grupa dojrzałych inżynierów jest świadoma tego, jakie ma SLA i to motywuje ich do dostarczania radości klientom :-)

Szukając przykładów bardziej globalnych, które też mają w swoich celach dostarczanie radości klientom, skupię się na SLA firmy Amazon, bo ciekawostka jakiej się dowiedziałem może Was zmotywować do pracy nad własnym HA.

Jak bardzo AWS zwiększył wysoką dostępność na poziomie centrum danych?

Centrum danych (ang. data center) tzn. serwerownia to zestaw wielu serwerów, na których działają obliczenia oraz przez które przemieszczają się różne dane klientów ew. towarów. Budowanie DC jest to dość nowa dziedzina, która zapewnia zbudowanie centrum obliczeniowego na wymaganym poziomie. Okazuje się, że wymagania z roku na rok rosną. Nie jest prawdą, że serwerownie mają jedno łącze do internetu i radośnie sobie wszystko działa, bo admin Janek czuwa nad stabilnością. Nie te czasy minęły ok. 15 lat temu. Obecnie serwerownie to miejsca ze specjalnymi klimatyzatorami, szynami wielu kanałów zasilających, awaryjnych UPSów, agregatów awaryjnych, które napędzane silnikami diesla pozwalają przetrwać serwerom braki i niestabilności zasilania. Prawdą jest, że kupując miejsce w DC mamy zazwyczaj jasno określone zasady HA np: przez podanie SLA i zasad wspierania HA, albo na różne inne sposoby, które są często tajemnicą wewnętrzną danego centa danych. 

W tym roku Amazon w ramach konferencji podzielił się pewną architekturą, jaką chciałbym przedstawić tutaj i pokazał, jak fajnie przeskalować i uzyskać kolejną 9-tkę wysokiej dostępności, fizyczną architekturą wspierającą ten cel. 

Otóż, kiedy popatrzymy na typowy obraz DC i zapewnienia podtrzymania zasilania, mamy taki ogólny diagram:

Wszystko jest tutaj dość łatwo rozpoznawalne dla wprawnych oczu z infrastruktury :-) Dla pewności omówię: mamy zewnętrznego dostawcę prądu i awaryjny agregat prądotwórczy, do tego logikę przełączników, baterię akumulatorów. Kiedy dostawca prądu powie nie mam fazy, wówczas na chwilę przełączania na agregat działamy z banków energii, jakimi są akumulatory. Tak, agregat rozgrzewa się jak stary zbawiciel diesel :-) Wiadomo, dolewamy paliwa do diesla, to agregat działa, jeśli nie dolewamy, to ma to często kilka do kilkunastu godzin działać, aż naprawią trakcję elektryczną.

Wygląda dość racjonalnie i teraz zobaczcie, co zrobił Amazon:

Jak widać na pierwszy rzut oka 99.99997 % SLA - tak, to nie błąd po przecinku są cztery 9-tki i jedna 7-ka. Co daje niedostępność ich infrastruktury serwerowej na poziomie .....  9 sekund rocznie !!!!

Sprawdźcie sami na kalkulatorze SLA online. 

Brawo, dla ich zapału, innowacji i inżynierii - to jest mega dobry wskaźnik jakości.

Dodali drugi tor z agregatem prądotwórczym i silą z elektrowni :-) 

To ciekawe, a zapewne drogie rozwiązanie, ale to nie jest koniec. Amazon przede wszystkim uznał, że wszystkie podsystemy po drodze tzn. UPS, logika w sterownikach, agregaty oparte są też o software i jak wiadomo, software ma błędy :-) Idąc dalej tym tropem, uznali, że sami stworzą sobie oprogramowanie a docelowo hardware dla swoich serwerowni. I tutaj pewnie uznacie, że to koniec zabawy, bo zrobienie własnego racka (szafki na serwery) jest bardzo spoko, ale własny UPS, to ambitny produkt. 

Oto, jak prawdopodobnie mogło się to rozegrać w praktyce: inżynierowie teoretyczni spotkali praktyków, mieli wspólne rozmowy, zapewne poleciało kilka nieudanych prób i nagle, po wykonaniu jednego komponentu kompleksowo okazało się, że działa tak jak chcemy i mamy do niego testy. 

Jeśli nasi testerzy wiedzą jak to działa i gwarantują nasze standardy jakości, to zaczyna się nieźle. 

Suma podwyższonych standardów jakości działów w Amazon, spowodowała, że te mniejsze SLA na poziomie poszczególnych zespołów wytworzyły wartość globalną jaką jest podwyższenie HA w produkcie AWS. Tak, przerabiali też hardware, ale jak widać, inaczej się nie da - tzn. nikt nie podzielił się taką wiedzą, jak to realnie zrobić inaczej. 

Coś, co widać i warto wspomnieć: Amazon uzyskał redundancję w DC, rozdzielając podsystem podtrzymania zasilania dla dwóch torów zasilania, które są w ich szafach z serwerami. Bo wiedzą, że przełączanie zasilania to też ryzyko i tym samym wypadki na tej linii mają z głowy. Okazuje się, że to dość wrażliwa sprawa :-) i wiem też z praktyki, że bardzo newralgiczna dla ludzi z utrzymania infrastruktury z wysokim HA.

Uznaję tą prezentację "Infrastructure Keynote" za lekcję, że jeśli zespół otrzymuje ambitne i czasami niemożliwe wyzwanie, wówczas odpowiednia ilość PoC, burzy mózgów, wiedzy, radości jako pozytywny miks, dają wartość biznesową innym. Tak, znam to uczucie - fajnie jest uczestniczyć w takim procesie twórczym ;-)

Wprowadzenie HA często niweluje tzw. jeden punkt awarii (ang. Single Point of Failure), pozwala zapewnić większą redundancję (ang. redundancy), czyli odporność na wymieniony SPoF. Z tym wiąże się często obserwacja i monitorowanie (ang. abservability and monitoring). Tak się składa, że świetnie się to wpisuje w filozofię DevOps, którą opisuję tutaj. Stosuję ją na co dzień w pracy i widzę, że bywa przekonująca dla wielu inżynierów :-) Bardzo pożądaną konsekwencją podwyższonego SLA jest też spadek zgłoszeń technicznych do działu kontaktu z klientami. Same plusy - tak, ale wiemy, że to inwestycja, która przenosi poziom organizacji na wyższy status. Nie wszystkich stać, ale Ci, którzy wdrożyli liczą pozytywne efekty dość szybko.

Jeśli macie jakieś przemyślenia związane z budowaniem większej dostępności w IT, napiszcie w komentarzach. Chętnie poznam Wasze punkty widzenia.

 

Teachable Machine - Machine Learning to takie proste !

 Teachable Machine to projekt tworzony m.in. przez Google, który ułatwia wejście w podstawy uczenia maszynowego (ang. Machine Learning) poprzez praktykę. Tak wiele kroków należy uczynić, aby zrozumieć w praktyce Machine Learning, podstawy matematyczne, typowe algorytmy, algorytmy pozwalające na uzyskanie wysokiej skuteczności per różne dziedziny, frameowrki i programowanie, trenowanie modeli, dopieszczanie modeli, zapewnienie wlaściwych zbiorów danych do trenowania, itd. Jak widać z potoku pojęć, jest kilka tematów, które warto poznać, aby zrozumieć ML :-) 

Jednak poznanie Machine Learning nie musi być wcale takie trudne, kiedy mamy odpowiednie oparte o interfejs wizualny narzędzia. Oto docieramy do projektu Teachable Machine, dzięki któremu wytrenujemy rozpoznawanie różnych stanów/przedmiotów/obiektów w kilka minut. Sprawdźcie sami, bo tak banalny interfejs pokazuje, że problemy klasyfikacji nie są wcale trudne do zrozumienia w podstawach ML. 

To co zobaczmy - po kliknięciu w link - to przyjazny interfejs, który pozwala na podłączenie się z przeglądarki do kamerki lub upload obrazków dla poszczególnych klas służących do klasyfikacji.

 

Dzięki takiej sprytnej koncepcji możemy zrobić modele, wytrenować w locie nasz model i oglądać rezultaty w czasie rzeczywistym np: z podłączonej do laptopa kamerki.

Projekt nie ogranicza nas za bardzo, jeśli chcemy użyć wyobraźni to jest jak zawsze dozwolone ;-) W związku z tym wyjściem może być mowa lub dźwięk zależnie od ścieżki klasyfikacji.

Zachęcam do pokazania tego narzędzia dzieciom, bo jest to jak mi się wydaje najbardziej praktyczny sposób na odpowiedź dziecku na podstawowe pytanie: "co to jest machine learning?". Zapewniam Was, że nie zawsze odpowiedź na to pytanie udaje się znaleźć łatwo, stąd dzielę się tym znaleziskiem, być może wzmocnicie pojęcie ML u przyszłych pokoleń wynalazców ;-).

Więcej przykładów i sugestii do nauki Machine Learning z Teachable Machine przez zabawę możecie też wyszukać na YT, np:  

Jeśli udało Wam się ułożyć jakąś ciekawą klasyfikację, dajcie znać w komentarzach.