Czym jest usługa Service Bus i dlaczego Microsoft stawia na komunikaty w chmurze?

Azure Service Bus pozwala oddzielić producentów komunikatów od ich konsumentów. Dzięki temu aplikacje nie muszą znać się nawzajem ani działać w tym samym czasie. Komunikaty mogą być bezpiecznie przechowywane, ponawiane i przetwarzane asynchronicznie, co znacząco poprawia stabilność całego systemu.

Z perspektywy architekta jest to jedno z kluczowych narzędzi do budowy systemów odpornych na przeciążenia i chwilowe awarie.

Azure Service Bus to zarządzana usługa message brokera, oferująca:

• kolejki (Queues),
• tematy i subskrypcje (Topics & Subscriptions),
• transakcje,
• obsługę kolejki utraconych wiadomości (dead-letter queue),

Nowoczesne systemy IT konsekwentnie promują komunikację asynchroniczną za pomocą kolejek z kilku powodów:

• zwiększa skalowalność,
• upraszcza rozwój mikroserwisów,
• pozwala niezależnie wdrażać i rozwijać komponenty niezależnie od użytych technologii do ich wytworzenia,
• pozwala lepiej wykorzystać zasoby chmurowe dostępne np. w środowisku Microsoft Azure.

Kolejki, Topics i subskrypcje oraz sesje – jak działa usługa Azure Service Bus?

Service Bus Queue – kolejki usługi service bus

Kolejki w Azure Service Bus realizują model point-to-point, w którym każdy komunikat trafia do kolejki i jest przetwarzany przez jednego konsumenta. Nadawca i odbiorca są od siebie niezależni – komunikaty mogą być wysyłane i odbierane w różnym czasie, co zwiększa odporność systemu na awarie i chwilowe przeciążenia.

Usługa wykorzystuje mechanizm Peek-Lock, który tymczasowo blokuje komunikat po jego odebraniu. Dopiero po poprawnym przetworzeniu jest on usuwany z kolejki. W przypadku wystąpienia błędu może zostać ponownie udostępniony innemu odbiorcy lub trafić do dead-letter queue, co ułatwia diagnostykę problemów. Mechanizm Peek-Lock pozwala konsumentowi tymczasowo zablokować komunikat w kolejce. W przypadku wygaśnięcia blokady (np. z powodu timeoutu), komunikat staje się dostępny dla innych konsumentów, co może prowadzić do powtórnego odbioru.

Jedna kolejka może być obsługiwana przez wiele instancji konsumentów. Azure Service Bus automatycznie rozdziela komunikaty pomiędzy nich, zapewniając naturalny load balancing bez dodatkowej logiki po stronie aplikacji.

Kolejki sprawdzają się szczególnie dobrze w scenariuszach takich jak:

• przetwarzanie zadań w tle,
• kolejkowanie żądań i ochrona systemów przed przeciążeniem,
• równoważenie obciążenia pomiędzy wieloma instancjami usług,
• asynchroniczna integracja systemów.

Topics i subskrypcje

Topics w Azure Service Bus realizują wzorzec publish/subscribe, w którym jeden komunikat może zostać dostarczony do wielu niezależnych odbiorców. Producent wysyła komunikat do tematu (Topic), nie wiedząc, kto i ile systemów będzie go konsumować. Każda subskrypcja działa jak osobna kolejka, posiadająca własny stan, retry oraz dead-letter queue.

Największą zaletą Topics są subskrypcje z filtrami, które pozwalają określić, jakie komunikaty trafią do danego odbiorcy. Filtry SQL lub reguły oparte o właściwości komunikatu umożliwiają precyzyjne routowanie zdarzeń bez dodatkowej logiki po stronie producenta.

Każda subskrypcja może być obsługiwana przez wiele instancji konsumentów, co, podobnie jak w przypadku kolejek, umożliwia równoległe przetwarzanie i load balancing. Jednocześnie różne subskrypcje mogą przetwarzać ten sam komunikat w zupełnie inny sposób lub w innym tempie.

Topics i subskrypcje sprawdzają się szczególnie dobrze w scenariuszach takich jak:

• architektura event-driven,
• propagacja zdarzeń domenowych,
• integracja wielu systemów reagujących na te same zdarzenia,
• oddzielenie logiki biznesowej od procesów pomocniczych (np. powiadomień, audytu, raportowania).

Dzięki modelowi publish/subscribe Azure Service Bus Topics umożliwiają budowę elastycznych i łatwo rozszerzalnych systemów, w których dodanie nowego odbiorcy nie wymaga zmian po stronie nadawcy.

Sesje

Sesje w Azure Service Bus to mechanizm umożliwiający grupowanie powiązanych komunikatów i przetwarzanie ich w ściśle określonej kolejności. Każdy komunikat posiada SessionId, a wszystkie komunikaty z tym samym identyfikatorem trafiają do tej samej sesji i są obsługiwane sekwencyjnie przez jednego konsumenta.

W praktyce oznacza to, że choć kolejka lub subskrypcja może być przetwarzana równolegle przez wiele instancji odbiorców, to w ramach jednej sesji nigdy nie dochodzi do przetwarzania równoległego. Azure Service Bus blokuje sesję na czas jej obsługi przez konkretnego konsumenta, co eliminuje problemy z kolejnością i współbieżnością.

Sesje są szczególnie przydatne w scenariuszach, gdzie:

• kolejność komunikatów ma znaczenie (np. workflow, procesy krok po kroku),
• komunikaty dotyczą jednego obiektu biznesowego (np. OrderId),
• wymagane jest przetwarzanie stanowe (stateful processing),
• system musi zachować spójność bez skomplikowanej synchronizacji.

Sesje mogą być używane zarówno w Queue, jak i w subskrypcjach Topiców. Dzięki nim Azure Service Bus łączy wysoką skalowalność z kontrolą kolejności, co jest trudne do osiągnięcia w klasycznych systemach kolejkowych bez dodatkowej logiki po stronie aplikacji.

Azure Service Bus Queue vs Topic – kiedy wybrać które rozwiązanie?

Wybór pomiędzy Queue a Topic w Azure Service Bus zależy przede wszystkim od tego, ile systemów ma przetwarzać dany komunikat i w jaki sposób ma on być obsłużony.

Queue najlepiej sprawdzi się w scenariuszach typu point-to-point, gdzie komunikat ma zostać przetworzony dokładnie raz przez jeden komponent. Jest to idealne rozwiązanie dla zadań w tle, kolejkowania żądań czy równoważenia obciążenia pomiędzy wieloma instancjami tej samej usługi. Queue upraszcza architekturę i minimalizuje liczbę zależności pomiędzy komponentami.

Topic warto wybrać wtedy, gdy komunikat reprezentuje zdarzenie, na które powinno zareagować wiele niezależnych systemów. Dzięki subskrypcjom i filtrom możliwe jest selektywne dostarczanie komunikatów do różnych odbiorców bez modyfikowania producenta. Topic naturalnie wspiera architekturę event-driven i ułatwia dalszą rozbudowę systemu.

W praktyce często stosuje się oba mechanizmy jednocześnie:

• Queue do obsługi zadań i procesów technicznych,
• Topic do publikowania zdarzeń domenowych.

Dobrze dobrany model komunikacji upraszcza architekturę i pozwala skalować system bez kosztownych refaktoryzacji w przyszłości.

Azure Service Bus Patterns – wzorce, które warto znać

Azure Service Bus Request-Response pattern

Request–Response Pattern w Azure Service Bus umożliwia realizację komunikacji dwukierunkowej w sposób asynchroniczny, bez konieczności bezpośredniego połączenia pomiędzy nadawcą a odbiorcą. Zamiast klasycznego wywołania synchronicznego (np. HTTP), klient wysyła komunikat z żądaniem do kolejki lub tematu, a odpowiedź otrzymuje jako osobny komunikat.

W praktyce klient wysyła żądanie do Request Queue, dołączając informacje pozwalające na korelację odpowiedzi (np. CorrelationId lub nazwę kolejki odpowiedzi). Usługa odbierająca żądanie przetwarza je w swoim tempie i publikuje wynik do Response Queue, z której klient odbiera odpowiedź.

Takie podejście zapewnia: 

• brak blokowania zasobów po stronie klienta,
• odporność na opóźnienia i chwilową niedostępność usług,
• lepszą skalowalność w porównaniu do komunikacji synchronicznej.

Request–Response Pattern sprawdza się szczególnie w scenariuszach, gdzie odpowiedź jest wymagana, ale nie musi być natychmiastowa – np. w integracjach między mikroserwisami, procesach długotrwałych czy komunikacji pomiędzy systemami o różnej wydajności. W połączeniu z mechanizmami Azure Service Bus, takimi jak retry i dead-letter queue, wzorzec ten pozwala budować niezawodne i elastyczne rozwiązania komunikacyjne.

Outbox Pattern

Outbox Pattern to wzorzec architektoniczny, który rozwiązuje problem spójności pomiędzy zapisem danych a publikacją komunikatu. W systemach opartych na komunikatach często pojawia się ryzyko, że dane zostaną zapisane w bazie, ale zdarzenie nie trafi do brokera (lub odwrotnie). Outbox Pattern eliminuje ten problem.

W praktyce, zamiast wysyłać komunikat bezpośrednio do Azure Service Bus, aplikacja zapisuje go najpierw do tabeli Outbox w tej samej transakcji co dane biznesowe. Dzięki temu zapis danych i „intencja wysłania komunikatu” stają się operacją atomową. Osobny proces (np. background worker) odczytuje wpisy z Outboxa i publikuje je do Azure Service Bus.

Takie podejście zapewnia:

• brak utraty komunikatów,
• odporność na awarie sieci i brokera,
• możliwość bezpiecznego ponowienia wysyłki.

Outbox Pattern jest szczególnie przydatny w architekturze mikroserwisów i systemach event-driven, gdzie zdarzenia domenowe muszą być publikowane w sposób pewny i powtarzalny. W połączeniu z mechanizmami Azure Service Bus, takimi jak ponowienia wysyłki czy deduplikacja, stanowi solidną podstawę do budowy niezawodnej komunikacji między systemami. Outbox Pattern szczególnie dobrze współpracuje z bazami danych wspierającymi transakcje, pozwalając na spójne zapisanie danych biznesowych i komunikatu w jednym kroku.

Inbox Pattern

Inbox Pattern to wzorzec architektoniczny, który rozwiązuje problem wielokrotnego przetwarzania tego samego komunikatu. W systemach opartych na komunikatach – takich jak Azure Service Bus – ponowne dostarczenie komunikatu jest zachowaniem poprawnym (np. po błędzie lub timeoutach), dlatego aplikacja musi być na to przygotowana.

W praktyce każdy odebrany komunikat jest najpierw rejestrowany w Inboxie – najczęściej w postaci zapisu jego unikalnego identyfikatora (MessageId) w bazie danych. Dopiero jeśli komunikat nie był wcześniej przetwarzany, trafia on do logiki biznesowej. Duplikaty są bezpiecznie ignorowane, co zapewnia idempotentność operacji.

Inbox Pattern zapewnia:

• ochronę przed skutkami retry i ponownych dostarczeń,
• spójność danych w przypadku awarii podczas przetwarzania,
• możliwość bezpiecznego skalowania konsumentów.

Monitoring i diagnostyka: Azure Service Bus Alerts i integracja z Application Insights

Skuteczne wykorzystanie Azure Service Bus w środowisku produkcyjnym wymaga odpowiedniego monitoringu i diagnostyki, które pozwalają szybko reagować na problemy z przetwarzaniem komunikatów. Platforma Azure udostępnia w tym zakresie gotowe mechanizmy oparte o Azure Monitor.

Azure Service Bus publikuje szereg metryk, takich jak liczba aktywnych komunikatów, długość dead-letter queue czy czas przetwarzania. Na ich podstawie można konfigurować Alert Rules, które automatycznie powiadomią zespół o potencjalnych problemach, np. rosnącej liczbie komunikatów w kolejce lub błędach po stronie konsumentów.

Dla głębszej diagnostyki Service Bus integruje się z Application Insights, umożliwiając śledzenie komunikatów w kontekście całego przepływu aplikacji. Dzięki korelacji telemetrycznej możliwe jest przeanalizowanie, jak komunikat przechodzi przez kolejne komponenty systemu i gdzie pojawiają się opóźnienia lub błędy.

Połączenie alertów, metryk i telemetryki aplikacyjnej pozwala nie tylko reagować na incydenty, ale także proaktywnie wykrywać problemy, zanim wpłyną one na użytkowników końcowych.

Zabezpieczenia w Azure Service Bus – RBAC, SAS i protokół AMQP

Azure Service Bus oferuje mechanizmy bezpieczeństwa klasy enterprise, które pozwalają precyzyjnie kontrolować dostęp do komunikatów i chronić komunikację pomiędzy komponentami systemu. Usługa wspiera zarówno nowoczesne uwierzytelnianie oparte o Azure Active Directory, jak i tradycyjne mechanizmy kluczy dostępowych.

RBAC (Role-Based Access Control) umożliwia zarządzanie uprawnieniami przy użyciu ról przypisanych do użytkowników, aplikacji i tożsamości zarządzanych. Pozwala to na centralne i spójne zarządzanie dostępem do kolejek, tematów i subskrypcji, bez konieczności przechowywania wrażliwych danych, takich jak hasła czy klucze dostępu, w kodzie aplikacji. W kontekście Azure Service Bus można stosować predefiniowane role – między innymi Data Owner, Data Sender i Data Receiver – które pozwalają na granularne zarządzanie dostępem do wysyłania, odbioru lub pełnego zarządzania zasobami komunikacyjnymi.

Alternatywą lub uzupełnieniem RBAC są SAS (Shared Access Signatures), czyli tokeny dostępu z określonym zakresem uprawnień i czasem ważności. SAS sprawdzają się w scenariuszach integracyjnych, gdzie wymagany jest ograniczony i kontrolowany dostęp do zasobów Service Bus.

Komunikacja z Azure Service Bus odbywa się z wykorzystaniem protokołu AMQP 1.0, który zapewnia wysoką wydajność, niezawodność oraz wsparcie dla scenariuszy enterprise. AMQP umożliwia stabilne połączenia, efektywne przesyłanie komunikatów i pełne wykorzystanie zaawansowanych funkcji usługi. Azure Service Bus obsługuje również protokół HTTP jako alternatywę dla AMQP w przypadku aplikacji, które nie wspierają AMQP. Zaleca się jednak korzystanie z AMQP w przypadku systemów wymagających niskiej latencji i trwałych połączeń.

Połączenie RBAC, SAS i AMQP pozwala budować bezpieczne, skalowalne i zgodne z najlepszymi praktykami rozwiązania komunikacyjne w chmurze Azure.

Podsumowanie – co warto zapamiętać?

Azure Service Bus to kluczowe narzędzie komunikacyjne w chmurze Microsoft Azure, pozwalające na tworzenie nowoczesnych aplikacji opartych na architekturze asynchronicznej. Dzięki bogatemu zestawowi funkcji – takich jak kolejki, tematy i subskrypcje, sesje, oraz wsparcie dla wzorców projektowych (Request-Response,
Outbox, Inbox) – usługa umożliwia skalowalność, niezawodność i elastyczność systemów.

Zintegrowane mechanizmy bezpieczeństwa (RBAC, SAS, AMQP) oraz zaawansowane monitorowanie (Application Insights, Azure Monitor) gwarantują pełną kontrolę i stabilność rozwiązania, czyniąc je niezbędnym elementem w ekosystemie
nowoczesnych aplikacji chmurowych.

Jeżeli temat cię zaciekawił i chcesz korzystać z usługi w swoim projekcie, zajrzyj do Microsoft Learn na Azure Portal, by uzyskać więcej informacji.

Często zadawane pytania:

Automatyzacja i testowanie

Zmiany nie będą dotyczyły tylko kodu samej aplikacji, ale też testów (tworzenie testów jednostkowych nowej funkcjonalności). Jednym z kluczowych atrybutów ciągłej integracji jest wysoki stopień wykorzystania zautomatyzowanych testów. Po zakończeniu wprowadzania zmian na lokalnym komputerze wykonywany jest zautomatyzowany proces kompilacji (build). W procesie tym pobierany jest kod źródłowy z lokalnego repozytorium, który jest następnie kompilowany, łączony z plikiem wykonywalnym, a na końcu przeprowadzane są testy automatyczne. Build uznaje się za prawidłowy, gdy kompilacja oraz testy zakończą się poprawnie, bez błędów.  

Integracja i aktualizacja

Następnym krokiem jest zatwierdzenie zmian w repozytorium. Na tym etapie należy uwzględnić zmiany wprowadzone przez innych członków w zespole, ponieważ w międzyczasie zmiany innego programisty mogły zostać już zintegrowane z głównym repozytorium tworzonego oprogramowania. Należy więc najpierw zaktualizować lokalną gałąź z kodem z głównej gałęzi (master) i ponownie uruchomić zautomatyzowaną kompilację (build). Jeżeli w trakcie tego procesu pojawią się konflikty (zmiany w kodzie kolidujące ze zmianami wprowadzonymi przez innych programistów), należy je rozwiązać i ponownie uruchomić kompilację. Gdy zakończy się ona powodzeniem, zmiany można zatwierdzić i zintegrować z głównym repozytorium. 

W tym momencie wykonywana jest ponowna kompilacja, lecz tym razem jest ona przeprowadzana na serwerze integracyjnym. Zdarza się, że podczas kompilacji na lokalnej stacji roboczej coś może zostać przeoczone, przez co główne repozytorium zostanie zaktualizowane w nieodpowiedni sposób. Dopiero gdy zmiany w głównym repozytorium zbudują się poprawnie na serwerze CI, można je będzie uznać za zakończone sukcesem. 

Jeśli dojdzie do konfliktów w plikach zmienionych przez innych programistów, zwykle będą one wychwycone, gdy programista zatwierdzający zmiany utworzy zaktualizowaną kopię roboczą, a sama kompilacja zakończy się niepowodzeniem. Błąd jest szybko wyłapany, a zadaniem programistów jest zlokalizowanie źródła błędów i naprawienie ich. W środowisku CI należy unikać sytuacji, w których przez dłuższy czas kompilacje integracyjne kończą się błędem – trzeba je naprawić najszybciej, jak to możliwe. 

Po pomyślnej kompilacji na serwerze ciągłej integracji nowe zmiany można wprowadzić na przykład na środowiska testowe, gdzie testerzy będą mogli przeprowadzać testy na aktualnej wersji oprogramowania zawierającej najnowsze zmiany. 

Zarządzanie błędami i powiadomienia

Na każdym etapie procesu ciągłej integracji po stronie serwera, w razie niepowodzenia w budowaniu projektu, można zaimplementować narzędzia raportujące błędy. W ten sposób, w przypadku wystąpienia błędu w którymś kroku kompilacji – odpowiedni użytkownicy mogą zostać powiadomieni, na przykład za pomocą wiadomości e-mail lub powiadomienia na firmowym czacie. 

Przykładowy ogólny schemat procesu ciągłej integracji: 

Praktyka DevOps

Termin DevOps pochodzi z połączenia dwóch słów: development i operations (programowanie i operacje). Służy do określenia podejścia do rozwoju oprogramowania zakładającego zmniejszanie barier pomiędzy zespołami deweloperskimi i operacyjnymi firmy. Celem DevOps jest skrócenie czasu wprowadzenia produktu na rynek. Oznacza to przyjęcie i wdrożenie pewnych praktyk w celu skrócenia czasu od identyfikacji nowego wymagania do momentu jego wdrożenia dla klientów. W podejściu tym wykorzystywana jest omawiana ciągła integracja i ciągłe dostarczanie, które pomagają skrócić czas wprowadzenia produktu na rynek i stworzyć oprogramowanie lepszej jakości. 

Historia i rozwój

Celem DevOps jest skrócenie czasu wprowadzenia produktu na rynek. Filozofia DevOps narodziła się w 2008 roku podczas konferencji Agile w Toronto, kiedy  Patrick Debois wygłosił wykład pod tytułem „Infrastructure and Operations“. Wyjaśnił w nim zastosowanie podejścia Agile do budowy infrastruktury, a na koniec zaproponował lepszą metodę komunikacji oraz pomysły, dzięki którym programiści mogliby „ poszerzać swoje horyzonty”, w sensie pogłębiania wiedzy systemowej niezbędnej do zapewnienia płynniejszego procesu wydawania oprogramowania. Mijały lata, a podejście DevOps stawało się coraz bardziej popularne, a w ślad za nim pojawiła się nowa rola w świecie IT – inżynier DevOps.  

Rola inżyniera DevOps

Inżynier DevOps stanowi swego rodzaju pomost pomiędzy programistami a działem operacyjnym. W większości przypadków rola, jaką przyjmuje, jest ich mieszanką (inżynierowie ci muszą posiadać wiedzę niezbędną do doradzania i zarządzania problemem z obu dyscyplin). W niektórych przypadkach odpowiedzialność inżyniera DevOps związana jest z ciągłą integracją i dostarczaniem. Inne obowiązki obejmują zarządzanie infrastrukturą, zazwyczaj w postaci kodu (IaC) oraz pomoc we wdrażaniu optymalnych praktyk DevOps w całej firmie. Czasem inżyniera DevOps postrzega się go także jako osobę odpowiedzialną głównie za utrzymanie oprogramowania w środowisku produkcyjnym i automatyzację procesów, rozwiązywanie problemów, administrowanie systemem.  Rola inżyniera DevOps jest zróżnicowana i może zmieniać się w zależności od firmy. 

Zalety podejścia DevOps

Efektywność i współpraca 

Zespoły, które wdrażają podejście DevOps, stają się bardziej wydajne, dzięki czemu tworzone oprogramowanie wydawane jest nie tylko szybciej, ale też jest bardziej stabilne. Lepsza współpraca i zwiększona produktywność pozwalają też osiągać cele biznesowe, takie jak szybsze wprowadzenie produktu na rynek czy utrzymanie jego niezawodności i stabilności w każdych warunkach. Zastosowanie metodyki DevOps nie tylko pozwala zautomatyzować i optymalizować procesy za pomocą technologii. Jest to przede wszystkim zmiana kultury wewnątrz organizacji i ludzi zaangażowanych w ten proces.  

Wdrożenie kultury DevOps wymaga głębokich zmian w dotychczasowym sposobie pracy zespołów i przestrzegania określonych zasad, jednak te zmiany pozwalają stworzyć środowisko pracy o wysokiej wydajności.   Cechą charakterystyczną DevOps jest ścisła współpraca między zespołami. Różne zespoły, na przykład zespoły deweloperów i odpowiedzialne za operacje, muszą dzielić się swoimi procesami, priorytetami i problemami. Muszą także wspólnie planować pracę oraz cele i środki związane z ich osiągnięciem. W miarę jak zespoły dostosowują się do nowej rzeczywistości, obowiązki w poszczególnych rolach również zaczynają się poszerzać. Na przykład deweloperzy stają się odpowiedzialni nie tylko za tworzenie aplikacji w fazie programowania, ale też za wydajność i stabilność w fazie działania. Jednocześnie zespół operacji uwzględnia nadzór, zabezpieczenia i zgodność w fazach planowania i programowania.  

Elastyczność i reaktywność 

Elastyczność zespołów pozwala na wydawanie oprogramowania w krótszych cyklach. Łatwiej jest planować wdrażanie zmian i zarządzać ryzykiem – to droga do stworzenia stabilnego produktu. Krótsze cykle wydawania nowych wersji pozwalają także sprawniej reagować na zmiany zachodzące na rynku, dzięki czemu można szybciej dostosować się do zmian potrzeb klientów i nie odstawać od konkurencji. Podejście DevOps stanowi state-of-the-art nowoczesnego tworzenia oprogramowania i jest dziś pierwszym wyborem wielu firm z tego powodu, że promuje najlepsze praktyki niezbędne do poprawy jakości oprogramowania. DevOps wymaga zmiany nie tylko w sposobie myślenia o infrastrukturze, ale także w  zakresie dobrego projektowania i organizowania wewnętrznej infrastruktury firmy.   

Ciągłe testowanie 

Ciągłe testowanie (Continuous Testing, CT) to umiejętne wykorzystanie pewnych narzędzi i technik. Cytując sylabus ISTQB, ciągłe testowanie to:  

„Podejście obejmujące proces wczesnego, częstego, szerokiego, automatycznego testowania w celu otrzymania możliwie szybko informacji zwrotnej o poziomie ryzyka biznesowego związanego z aplikacją przed jej wydaniem”.  

Podejście to znacznie skraca czas potrzebny do wykonania testów manualnych. 

Głównym celem wprowadzenia podejścia CI/CD jest poprawa jakości wydawanego oprogramowania, a ciągłe testowanie i kontrola powinny być częścią tego procesu.  Celem ciągłego testowania jest zapewnienie, że wydawane oprogramowanie będzie niezawodne.  W tym celu tworzy się różnego rodzaju testy, które mogą być wykonywane automatycznie za każdym razem, gdy oprogramowanie jest budowane. 

Poziomy testów w ciągłym testowaniu 

1. Testy jednostkowe – bazę testów automatycznych stanowią testy jednostkowe. Są one wykonywane za każdym razem, gdy oprogramowanie jest kompilowane i budowane.  

2. Testy integracyjne – kolejnym poziomem testów, który należy włączyć, są testy integracyjne. Są one przeprowadzane po testach jednostkowych i wykorzystują rzeczywiste dane. Testy integracyjne są ważną fazą w ciągłym testowaniu, ponieważ odpowiadają za testowanie całego systemu, a nie tylko tworzonego kodu.  

3. Testy akceptacyjne (E2E) – ostatnią fazą są testy akceptacyjne. W tej fazie wykonywane są testy przygotowane przez zespół QA w celu przetestowania systemu z punktu widzenia użytkownika. Celem tej fazy jest weryfikacja wymagań użytkownika i ich walidacja. 

Kontrola kodu 

Oprócz różnych faz testowania, istnieje także faza kontroli kodu. Polega ona na sprawdzeniu kodu przy wykorzystaniu zestawu reguł wykorzystywanych do sporządzenia raportu na temat samego oprogramowania. Można ją podzielić na dwie fazy:  

1. Przegląd kodu wykonywany przez programistę, który nie jest  jego autorem. Przed integracją z główną gałęzią (master) kod musi zostać zatwierdzony. Członkowie zespołu sprawdzają kod i dodają komentarze, jeśli jakieś fragmenty wymagają zmian. W tym przypadku autor kodu dokonuje zmian na ich podstawie, a po skończonej pracy kod ponownie trafia do przeglądu. Jeśli nikt nie będzie miał zastrzeżeń – kod zostanie zaakceptowany i scalony z główną gałęzią. 
2. Faza statycznej analizy jest wykonywana przez odpowiednie narzędzia. Kod może zostać wtedy zweryfikowany przez pewne reguły, na przykład sprawdzające złożoność metod.  

Automatyzacja i shift-left testing 

Ciągłe testowanie wykorzystuje podejścia automatyzacji do przyspieszenia testowania poprzez przyjęcie podejścia shift-left testing, które łączy etapy wytwarzania oprogramowania i zapewniania jakości. Takie podejście może obejmować zestaw przepływów pracy testów automatycznych, które można łączyć z narzędziami raportującymi i metrykami w celu otrzymania jasnego obrazu jakości oprogramowania. 

Zapewnia to zespołom projektowym otrzymanie szybkiej informacji zwrotnej na temat jakości oprogramowania. Pozwala również testować na wcześniejszych etapach wytwarzania oprogramowania oraz zwiększyć pokrycie testami, eliminując wąskie gardła testowe, takie jak: dostęp do współdzielonych środowisk testowych czy oczekiwanie na stabilny interfejs użytkownika. 

Ciągłe testowanie niesie ze sobą szereg korzyści, takich jak: 

• Integrowanie zespołów testowych, deweloperskich i operacyjnych na każdym etapie cyklu życia oprogramowania. 
• Pozwala na wdrożenie testów automatycznych w takim zakresie, jak to tylko możliwe, aby stale testować kluczowe funkcje. 
• Szybkie i ciągłe informacje zwrotne, które są istotne również dla biznesu. 
• Usunięcie wąskich gardeł w kwestii dostępności środowisk testowych, które mogą być stale dostępne. 
• Pozwala na stałe i aktywne zarządzanie jakością w całym etapie dostarczania oprogramowania.  

Fundamenty ciągłego testowania 

Ciągłe testowanie opiera się na kombinacji określonych narzędzi i technik. Odpowiednie ich wdrożenie tworzy system, dzięki któremu znacząco można ograniczyć liczbę błędów przedostających się na środowiska rozwojowe lub produkcyjne. Większość błędów ma bardzo krótką żywotność, ponieważ są one wyłapywane przez testy. Odpowiednie zaimplementowanie tego podejścia powinno rozpoczynać się na jak najwcześniejszym etapie cyklu życia oprogramowania, aby móc je odpowiednio budować, aktualizować i (w razie potrzeby) refaktoryzować. Sama budowa i działanie zależą w głównej mierze od potrzeb projektowych – inne testy i techniki będą wykorzystywane do testowania sklepu internetowego, inne do testowania systemów w branży automotive. Lecz niezależnie od przypadku, cel pozostanie ten sam – uzyskanie jak najszybciej informacji zwrotnej w przypadku wystąpienia błędu. 

Projektowanie małych komponentów i usług 

Idea ciągłego testowania polega na maksymalnym zautomatyzowaniu procesów testowania i wdrażania oraz zapewnieniu, że każdy komponent aplikacji może zostać poddany testom, gdy tylko zostanie opracowany. Przykłady, które mogą ułatwić implementację tego podejścia to: projektowanie małych komponentów i usług oraz projektowanie danych testowych wykorzystywanych w ciągłym testowaniu. 

Projektowanie małych komponentów i usług – nowe komponenty powinny nie tylko spełniać określone funkcje w trakcie działania programu, ale również być w pełni testowalne niezależnie od innych komponentów. Celem jest zapewnienie, że każda w pełni przetestowana usługa będzie spełniała swoje zadania zgodnie z założeniami, aby w trakcie ich łączenia i przejścia do etapu testów integracyjnych komponenty bezproblemowo współpracowały ze sobą.. Należy więc już na etapie projektowania odpowiednio przygotować architekturę i ograniczyć sprzężenie komponentów tak bardzo, jak to możliwe. W efekcie zyskamy komponenty bardziej stabilne, które zmniejsza ryzyko, że jakakolwiek zmiana dokonana w komponencie „A” spowoduje nieoczekiwaną zmianę zachowania w innych komponentach. Ograniczenie połączeń między nimi upraszcza proces testowania, rozwiązywania problemów oraz konserwacji. Dodatkowo w łatwiejszy sposób można izolować ewentualne problemy – analizie zostanie poddany konkretny komponent, bez potrzeby przeszukiwania ich grup i zależności między nimi. 

Projektowanie danych testowych wykorzystywanych w ciągłym testowaniu 

Posiadanie w pełni zautomatyzowanego rozwiązania do zarządzania danymi testowymi jest niezbędne do solidnego wdrożenia ciągłego testowania. Złym podejściem byłoby na przykład kopiowanie produkcyjnej bazy danych w celu utworzenia danych testowych, nie anonimizując uprzednio wrażliwych danych. Tworzenie nowych zestawów danych testowych od zera dla każdej serii testów również nie jest dobrym pomysłem ze względu na bardzo słabą efektywność, zwłaszcza gdy nie są generowane automatycznie. 

Jak zatem stworzyć skuteczne rozwiązania do generowania i zarządzania danymi testowymi? Z pomocą przychodzą pewne charakterystyki, do których można zaliczyć na przykład: 

• Tworzenie i generowanie danych testowych 
  Daje możliwość tworzenia nowych, zbiorczych zestawów danych uwzględniających zależności, tak jakby pochodziły ze środowiska produkcyjnego. 
• Możliwość pobrania pewnego podzbioru danych produkcyjnych 
  Na podstawie określonych kryteriów, maskowania wrażliwych pól i umieszczania ich w środowisku testowym, zachowując ich integralność referencyjną. Najtrudniejsza w realizacji jest ostatnia część: wrażliwe pola muszą być zamaskowane w taki sposób, aby zachować oryginalne powiązania między danymi. Przykładowo, jeśli wartość numeru PESEL musi zostać zamaskowana i zastąpiona niepowiązaną wartością, każde odwołanie do tego numeru PESEL w bazie danych musi zostać zamaskowane tą samą wartością. 
• Możliwość maskowania i transformacji danych 
  Rozwiązanie powinno też zapewnić możliwość automatycznego porównania danych wstępnie zamaskowanych, aby upewnić się, że nie doszło do ich utraty i że proces maskowania nie spowodował błędów w ich integralności. 
• Możliwość przesyłania danych 
  Proces polegający na przesyłaniu wyodrębnionych, zamaskowanych danych na środowiska testowe, z zachowaniem integralności. Proces ten powinien obejmować funkcje dodawania, edytowania, aktualizacji i usuwania. 
• Możliwość odświeżania danych 
  Polega na okresowym przeglądzie i usuwaniu starych pakietów danych testowych oraz zamienianiu ich na nowy zestaw. 
• Ekstrakcja danych i tworzenie ich podzbiorów 
  Pozwala na tworzenie mniejszych kopii danych produkcyjnych zdefiniowanych za pomocą określonych kryteriów. 
• „Postarzanie” danych 
  Technika, w której dane są zmieniane w celu dopasowania ich do określonych, specyficznych warunków i wykorzystania ich w pewnych procesach (na przykład symulacji określonej godziny lub daty). 
• Możliwość tworzenia i wyodrębniania danych testowych 
• Zarządzanie zbiorami danych 
• Wykorzystanie narzędzi, które umożliwiają nie tylko zarządzanie wieloma zbiorami danych, ale także ich archiwizację i wersjonowanie.  

Rola testów jednostkowych w ciągłym testowaniu 

Podstawę testów w podejściu ciągłego testowania, zgodnie z piramidą testów, stanowią testy jednostkowe. Są one najszybsze w wykonaniu i sprawdzają działanie oprogramowania we wczesnej fazie jego wytwarzania. Powinno ich więc być jak najwięcej (przy zachowaniu odpowiedniego stosunku liczby do jakości – nie jest prawdą, że większa liczba testów stanowi o jakości).  

Projektowanie testów jednostkowych 

Zdarza się, że testy jednostkowe są źle zaprojektowane i zamiast jednostek testują kompletne przypadki użycia (wywołanie metod, asercje, wywołanie większej liczby metod i tworzenie większej liczby asercji). Takie testy są zwykle niestabilne, a błędy wykryte w jednej części kodu mogą maskować inne błędy i utrudniać ich wykrycie. Aby temu zapobiec, należy przeanalizować takie testy, wyodrębnić z nich poszczególne, testowane funkcjonalności i asercje i rozbić je na mniejsze testy sprawdzające każdą funkcjonalność z osobna. 

Implementacja testów na różnych poziomach 

Testowanie bardziej złożonych ścieżek, dajmy na to przypadków użycia, powinno zostać zaimplementowane na przykład w testach akceptacyjnych. W ciągłym testowaniu można wykonywać wszystkie rodzaje testów, lecz im wyższy poziom testów, tym liczba przypadków testowych powinna być mniejsza (są one mniej stabilne, czas ich wykonywania jest dłuższy, wykrywają błędy w późniejszych etapach, przez co wydłuża się czas naprawy, a koszt rośnie). 

Dotyczy to zwłaszcza testów UI (User Interface), gdy testowana jest logika biznesowa i zachowanie interfejsu użytkownika. Może tu dojść do wielu współzależnych awarii. Oddzielenie warstwy interfejsu od systemu bazowego, aby logika biznesowa mogła zostać opatrzona zaślepkami (mock) jest istotną zmianą zbliżającą nas do większej stabilności testów. 

Jednym z podejść jest uruchamianie testów jednostkowych w sposób ciągły, a testów wyższych poziomów – na żądanie (nie muszą one być uruchamiane automatycznie w trakcie budowy projektu w narzędziu ciągłej integracji – zamiast tego, istnieje możliwość uruchomienia ich w sposób manualny, gdy potrzeba). 

Rola podejścia TDD 

Praktykowanie podejścia TDD (Test-Driven Development) w wytwarzaniu oprogramowania ułatwia zrozumienie i wdrożenie ciągłego testowania. W TDD testy tworzone są przed implementacją funkcjonalności. Najpierw tworzony jest mały test, po którym następuje implementowanie powiązanego fragmentu całej funkcjonalności. Następnie dokonuje się refaktoryzacji w celu ulepszenia kodu i wyeliminowania ewentualnych powieleń. Dzięki ciągłemu testowaniu otrzymujemy natychmiastową informację zwrotną na każdym z tych kroków. Nie tylko z tego jednego testu, który jest w danym momencie pisany, lecz ze wszystkich powiązanych testów, bez dodatkowego wysiłku i zaangażowania ze strony programisty. Dzięki temu może on skupić się w pełni na projektowaniu i pisaniu kodu, zamiast rozpraszać się koniecznością uruchamiania testów. 

Cel ciągłego testowania 

Zarówno w podejściu TDD, jak i w ciągłym testowaniu, celem jest jak najszybsze uzyskanie informacji zwrotnej. Pod wieloma względami naturalnym rezultatem skutecznego stosowania TDD jest dobrej jakości zestaw testów. Różnica polega na tym, że stosując ciągłe testowanie, zyskuje się dodatkowe źródła informacji zwrotnych. Stary aksjomat podejścia TDD mówi, że testy sprawdzają poprawność kodu, z kolei kod weryfikuje poprawność testów. Testy sprawdzają również projekt kodu – źle zaprojektowany kod jest trudny do przetestowania.  

Jakie narzędzia wykorzystywane są w procesie dostarczania oprogramowania z CI/CD? 

Jenkins 

Jenkins to serwer ciągłej integracji (CI) typu open source.  Kontroluje kilka etapów procesu dostarczania oprogramowania, takie jak testowanie, kompilacja i wdrażanie. Popularność tego narzędzia wynika między innymi z jego możliwości śledzenia i monitorowania powtarzalnych działań pojawiających się w trakcie prac nad projektem. Każda zmiana w aplikacji jest kompilowana i testowana, a w razie wykrycia błędu Jenkins ostrzeże zespół o problemach. 

Wdrożenie kodu na produkcję 

Jednym z podstawowych zastosowań Jenkinsa jest możliwość wdrażania kodu na produkcję. Jeśli wszystkie testy opracowane dla danej funkcji lub releasu zakończą się powodzeniem, Jenkins może automatycznie opublikować kod na środowisku staging lub produkcyjnym (jest to właśnie przykład Continuous Deployment opisanego w poprzednim artykule). 

Automatyzacja workflow i różnych zadań 

Innym przypadkiem, w którym można użyć Jenkinsa, jest m.in. automatyzacja workflow. Na przykład, gdy programista pracuje na kilku środowiskach, w pewnym momencie zajdzie konieczność instalacji lub aktualizacji pewnych komponentów na każdym z nich. Jeśli instalacja lub aktualizacja wymaga wykonania wielu kroków, przeprowadzenie jej ręcznie może skutkować pojawieniem się błędów, a dodatkowo będzie czasochłonne. Zamiast tego wszystkie kroki potrzebne do finalizacji można odpowiednio skonfigurować w Jenkinsie. Dzięki temu cały proces będzie stabilny i szybki, bo też zawsze będzie wykonywany identycznie. 

Konfiguracja zadań 

Jenkins umożliwia tworzenie zadań (Jenkins Jobs) na różne sposoby. Konfigurację można stworzyć całkowicie przez UI, przeklikując odpowiednie opcje, lecz lepszym wyborem jest utworzenie pliku konfiguracyjnego i zdefiniowanie w nim wszystkich niezbędnych kroków. W Jenkinsie wykorzystuje się w tym celu skrypty pisane w języku Groovy. Zaletą w stosowaniu tej opcji jest dodatkowo to, że plik konfiguracyjny można przechowywać wraz z kodem dotyczącej go aplikacji. Dzięki temu mamy zapewnione wersjonowanie zmian i powstaje kopia zapasowa, przydatna w przypadku wystąpienia awarii. 

Rozszerzalność poprzez pluginy 

Możliwości Jenkinsa można rozszerzać dzięki wielu pluginom dostępnym na stronie https://plugins.jenkins.io/. Ich liczba pozwala na dowolne skonfigurowanie serwera pod konkretne potrzeby, począwszy od zmiany wyglądu elementów interfejsu użytkownika po możliwość integracji z zewnętrznymi serwisami lub aplikacjami czy modyfikujące kroki w tworzonych jobach.  

GitLab 

Innym narzędziem, o którym warto wspomnieć, jest GitLab. Serwis ten nie tylko pozwala na tworzenie i przechowywanie repozytoriów kodu, ale także udostępnia narzędzia do wersjonowania oprogramowania, zarządzania zadaniami oraz procesami CI/CD. Pozwala on wszystkim członkom zespołu współpracować na wszystkich etapach projektu, upraszczając tworzenie oprogramowania. 

Funkcjonalności GitLaba 

GitLab to internetowe repozytorium Git, które umożliwia zespołom programistów planowanie, kodowanie, testowanie, wdrażanie i monitorowanie zmian tworzonego oprogramowania w jednym miejscu. Natomiast Git to dobrze wszystkim znany system kontroli wersji. 

Jedną z istotnych możliwości jest śledzenie błędów: GitLab posiada wbudowany system umożliwiający zespołom tworzenie, przypisywanie i śledzenie błędów. Zapewnia także tablicę zarządzania projektami z konfigurowalnymi przepływami pracy (workflow) w celu wizualizacji zadań i postępów. 

Inną kluczową funkcjonalnością GitLaba są zintegrowane potoki CI/CD (pipelines). Dzięki temu można łatwo zautomatyzować procesy testowania, budowania i wdrażania, zapewniając dokładne testowanie zmian w kodzie przed połączeniem z główną bazą kodu i wdrożeniem w środowisku produkcyjnym. 

GitLab posiada także wewnętrzny system wiki, umożliwiający zespołom tworzenie i utrzymywanie dokumentacji projektowej. 

Podsumowanie 

Podejście Continuous Integration wraz z Continuous Development i Continuous Testing stanowią komplementarne praktyki. Continuous Development umożliwia obserwowanie wdrażanych zmian w czasie rzeczywistym i jednocześnie eliminuje proces ręcznego śledzenia zmian. Błędy znalezione na jak najwcześniejszym etapie są najszybsze i najtańsze w naprawie. 

Budowanie aplikacji wraz z przeprowadzeniem testów na lokalnym środowisku może zająć kilka minut, a ich przeprowadzenie daje pewność, że wprowadzone zmiany będą przygotowane do integracji z główną gałęzią repozytorium. Czasem zmiany mogą budzić szczególne wątpliwości –   na przykład, gdy modyfikacji wymagają pliki konfiguracyjne. W takim przypadku można wykonać pełną kompilację i uruchomić wszystkie testy, aby mieć pewność, że zmiana nie spowodowała błędów w innych obszarach aplikacji, a kod jest bezpieczny i może zostać dodany do głównego repozytorium. 

Ciągła integracja ma na celu identyfikowanie problemów, ale może również posłużyć jako narzędzie do zmniejszania kosztów uruchamiania testów wyższego poziomu – wykrycie błędów na etapie testów jednostkowych sprawi, że testy z pozostałych poziomów będą bardziej stabilne, co daje dodatkową pewność co do jakości. at the capabilities are within the connectivity management framework. At Inetum, we are a partner of Cumulocity IoT, which has a network of partners providing platform-compatible devices with substantial connectivity capabilities.

PRZEJDŹ DO:

1. 1. Czym jest usługa Azure Active Directory?
2. 2. Czym jest aplikacja multi-tenant?
3. 3. Rozpocznij pracę z usługą Azure AD
4. 4. Rejestrowanie aplikacji multi-tenant
5. 5. Logowanie do aplikacji jako użytkownik zewnętrzny
6. 6. Aplikacja multi-tenant wywołująca wewnętrzne API
7. 7. Zarządzanie tożsamościami – ograniczanie dostępu do aplikacji
8. 8. Usługa Azure AD od Microsoft – podsumowanie

Zarządzanie dostępami do aplikacji jest zagadnieniem poruszanym w przypadku niemal każdego systemu. Dbając o odpowiednie uwierzytelnianie, nie tylko ograniczamy możliwości pozyskania czy modyfikowania wrażliwych danych, ale mamy również większą elastyczność w przypadku tzw. User Experience, poprzez definiowanie ról czy właściwości związanych z danym użytkownikiem. 

Czym jest usługa Azure Active Directory? 

Azure Active Directory (AAD) jest serwisem chmurowym firmy Microsoft pozwalającym na zarządzanie dostępami i tożsamościami. Korzystając z tego rozwiązania, możemy również rejestrować nasze aplikacje i określać zasady dostępności. Przy czym rozważamy tutaj zarówno dostępy użytkowników, jak i innych aplikacji. Do zarejestrowanego rozwiązania w danej dzierżawie (z ang. tenant ) dostęp mogą mieć wszystkie obiekty (użytkownicy, aplikacje) ją współdzielące. AAD pozwala również na „udostępnianie” aplikacji innym najemcom, dzięki czemu nie musimy martwić się o zarządzanie użytkownikami zewnętrznymi naszej aplikacji. Tak skonfigurowane rozwiązanie nazywamy multi-tenantowym. 

Czym jest aplikacja multi-tenant? 

Aplikacja typu multi-tenant pozwala obsługiwać wielu dzierżawców poprzez jedną instancję. Przy tego typu rozwiązaniach istotne jest, aby klient nie miał dostępu do danych należących do innych najemców. Jest to najczęściej rozwiązywane poprzez logikę biznesową lub rozdzielenie baz danych tak, aby każdy klient miał własną. 

Aplikacja wielodostępowa zarejestrowana w Azure Active Directory pozwala przenieść zarządzanie użytkownikami i określanie poziomu dostępu do rozwiązania na barki administratora danego dzierżawcy. Zmniejsza to koszty związane z utrzymywaniem użytkowników po stronie dostawcy usługi.  

Należy jednak pamiętać, że kwestia dostępu do poszczególnych elementów aplikacji jest dalej rozwiązywana przez programistów poprzez definiowanie odpowiednich polityk w kodzie. 

Rozpocznij pracę z usługą Azure AD

Firma Microsoft udostępnia administratorom materiały niezbędne do zarządzania usługami w Azure Portalu.  Dokumentacja zawiera też odpowiedzi na często zadawane pytania. Wszelkie informacje są dostępne na stronie Microsoft Azure Active Directory,  gdzie można się dowiedzieć wszystkiego na temat zarządzania tożsamością i dostępami w chmurze. Jeżeli jeszcze nie korzystasz z usług Microsoft Azure, warto zacząć właśnie w tym miejscu.   

Rejestrowanie aplikacji multi-tenant 

Podczas rejestracji nowej aplikacji jesteśmy zobligowani do wybrania, jakiego rodzaju konta chcemy wspierać. Wybierając opcję zaznaczoną poniżej, dajemy możliwość dostępu innym dzierżawcom. Jeżeli mamy wątpliwości, którą opcję wybrać, pod sekcją znajduje się link z krótkim opisem, na co zezwala każda z nich. 

Zarejestrowanie obiektu aplikacji powoduje utworzenie aplikacji biznesowej, a dokładniej jednostki usługi (z ang. Service Principal). To właśnie do jednostki usługi są podpinane dostępy użytkownika do aplikacji. Dokładnie ten sam mechanizm jest wykorzystywany w przypadku zewnętrznych klientów. 

Logowanie do aplikacji jako użytkownik zewnętrzny  

Przy pierwszej próbie logowania do aplikacji jesteśmy poproszeni o udzielenie zgody dla danej aplikacji. W zależności od ustawień dzierżawcy będziemy mogli sami jej udzielić lub będzie ona wymagała zatwierdzenia przez administratora.  

Warto nadmienić, że administrator udziela zgody dla wszystkich użytkowników, przez co tylko pierwsze logowanie do aplikacji jakimkolwiek użytkownikiem będzie wywoływać prośbę o udzielenie uprawnień.  

Przy samoakceptacji (self-consent) będzie ona wywoływana indywidualnie dla każdego użytkownika przy pierwszej próbie logowania. 

Tu u niektórych z was mogą pojawić się obawy: czy zezwalając na dostęp do danych użytkownika, przydzielamy go dostawcy, u którego aplikacja została zarejestrowana? Spokojnie, nie do końca tak jest. Podobnie jak w przypadku dzierżawcy pierwotnego tworzona jest jednostka usługi jako aplikacja biznesowa, i to w zależności od ustawionych dostępów względem niej nasze rozwiązanie pozyskuje informacje o aktualnie zalogowanym użytkowniku. 

Gdy DevOps lub inżynier rejestruje aplikację i chce, aby logowano się do niej przez Microsoft, docelowa aplikacja z docelowymi dostępami używanymi przy logowaniu utworzy się automatycznie podczas rejestracji. Nie ma wówczas potrzeby, by użytkownicy wyrażali zgodę dla aplikacji w tej dzierżawie. 

Przeczytaj także: Czym jest Azure IoT? Jakie daje możliwości? Jaki jest koszt usług i gdzie zdobyć niezbędną wiedzę?

Aplikacja multi-tenant wywołująca wewnętrzne API 

Często, zwłaszcza w przypadku mikroserwisów, zdarza się, że nasza aplikacja komunikuje się z inną poprzez jej API. Kiedy dzieje się to w modelu serwis do serwisu, wystarczy, że zagwarantujemy dostęp w dzierżawie dostawcy. Sytuacja komplikuje się, kiedy chcemy aby aplikacja komunikowała się poprzez API w imieniu zalogowanego użytkownika. 

Dla rozwiązania multi-tenantowego musimy zagwarantować, że API ma swojego reprezentanta u najemcy w postaci jednostki usługi, co wymusza publiczną dostępność szablonu API. Wszystko za sprawą mechanizmu weryfikacji dostępów, który tak naprawdę ma miejsce ramach tenanta, tj. dzierżawcy użytkownika. Dlatego należy dokładnie przemyśleć model komunikacji między aplikacjami. 

Istotne jest, aby w zarejestrowanym obiekcie aplikacji API zdefiniować aplikację webową jako jedną ze zautoryzowanych – dzięki temu klient będzie mógł zezwolić na dostęp do API, a tym samym jednostka usługi zostanie zarejestrowana w jego dzierżawie. 

Zarządzanie tożsamościami – ograniczanie dostępu do aplikacji 

Jak już wspomniałem, w momencie pojawienia się aplikacji biznesowej u danego dzierżawcy każdy użytkownik ma do niej dostęp. Możemy jednak to ograniczyć.  

Jeżeli chcemy, aby tylko określeni użytkownicy czy też grupa użytkowników miała dostęp, musimy ustawić naszą jednostkę usługi w taki sposób, żeby wymagała przypisania. 

Wtedy, aby użytkownik bądź grupa miała dostęp, aplikacja musi widnieć w przypisanych do użytkownika lub grupy. 

Innym sposobem na modyfikowanie dostępów do aplikacji jest dostęp warunkowy, który pozwala wymuszać pewne zachowania bądź blokować dostęp w zależności od ustawionych scenariuszy. Opcja ta jest jednak dostępna w wersji Premium Azure Active Directory. Informacje o planach cenowych i dostępnych usługach znajdziesz na stronie Microsoft Azure. 

Usługa Azure AD od Microsoft – podsumowanie 

Aplikacja wielodostępowa pozwala zredukować koszty poprzez współdzielenie jednej instancji przez wielu klientów. Zastosowanie Azure Active Directory do zarejestrowania takiego rozwiązania ogranicza dodatkowo koszty związane z utrzymywaniem użytkowników, gdyż niejako korzystamy z tych należących do najemcy. To od administratora dzierżawcy, który chce mieć dostęp, zależy, komu i w jakim zakresie chce go przydzielić. 

Niestety ograniczamy się wtedy tylko do klientów Microsoft, przez co możemy być mniej konkurencyjni. Jeżeli chcielibyśmy mieć rozwiązanie dostępne dla klientów niezależnie od dostawcy poświadczeń którego używają, ciekawą opcją jest Azure Active Directory B2C z Single Sign-On.  

PRZEJDŹ DO:

1. 1. Czym właściwie jest DSC?
2. 2. Zalety
3. 3. Zastosowanie w praktyce
4. 4. W jakich sytuacjach DSC nie zadziała?
5. 5. Architektura
6. 6. Microsoft Azure Automation Desired State Configuration
7. 7. Podsumowanie

Czym właściwie jest DSC (Desired State Configuration)?

DSC (Desired State Configuration) jest to sformalizowany sposób, który pozwala skonfigurować środowisko tak, aby przybrało ono oczekiwany przez nas stan. Jeśli przykładowo chcemy, aby na danej maszynie znajdowała się aplikacja (np. jakiś program antywirusowy) w określonej wersji, to możemy to osiągnąć właśnie za pomocą DSC. Może to być jedna aplikacja, może być ich wiele, jesteśmy tutaj właściwie nieograniczeni. Może potrzebujemy odpowiednio skonfigurowanego serwera IIS? Nie ma problemu. A może chcemy mieć pewną strukturę katalogów na dysku z konkretnymi plikami? Z DSC wszystko jest możliwe, ale ktoś słusznie pewnie zauważy, że możemy to wszystko również osiągnąć za pomocą przygotowanego wcześniej obrazu do stworzenia maszyny wirtualnej. Co różni tę opcję od DSC? Sprawdźmy!

Desired State Configuration – zalety

1. Łatwiejsza konfiguracja

Wyobraźmy sobie, że posiadamy maszynę wirtualną – serwer. Chcemy ten serwer skonfigurować: zainstalować różne aplikacje, zabezpieczenia, wprowadzić zmiany w rejestrze. W zależności od tego, jak duża jest to konfiguracja, musimy wykonać odpowiednio dużą liczbę kroków. Moglibyśmy to rozpisać w następujący sposób:

• Zainstaluj Firefox w wersji X
• Zainstaluj Dotnet Core w wersji X
• Dodaj regułę X w MS Defenderze
• Usuń wpis X w rejestrze

Aby wykonać każdy z tych kroków manualnie, będziemy się posiłkować różnymi narzędziami. Jeśli ta konfiguracja jest złożona, mogą pojawić się problemy z kompatybilnością. Jedno narzędzie może nie działać z innym w danej wersji albo mogą sobie wzajemnie nadpisywać pracę. Tu z pomocą przychodzi właśnie DSC. Zostało stworzone w tym celu, aby wziąwszy rozwiązania kilku dostawców, można było używać ich ze sobą bezkonfliktowo. Służy do tego sformalizowanie reguł, których powinni się trzymać dostawcy komponentów, jakich chcemy używać.

2. Idempotentność

Inną zaletą takiego podejścia jest idempotentność, czyli możliwość wykonywania wielokrotnie tej samej operacji bez zmiany wyniku. Dzięki temu mamy pewność, że za każdym razem, gdy zastosujemy pewną konfigurację, stan systemu się nie zmieni i będzie taki, jakiego oczekujemy. Warto zauważyć, że stosowane jest tutaj podejście deklaratywne, co jest kolejną zaletą takiego rozwiązania. Definiujemy zatem stan, jaki chcemy zastać, zamiast zastanawiać się nad poszczególnymi etapami, które pozwolą nam do tego stanu dojść.

3. Kompatybilność

Na początku wspomniałem o tym, że DSC pomaga w zarządzaniu komponentami tak, aby były one kompatybilne ze sobą. Oznacza to, że DSC jest pewnego rodzaju ustandaryzowaną metodą tworzenia tych komponentów. Jest to szereg reguł, które, stosowane podczas tworzenia komponentu, dają nam zapewnienie, że komponenty te będą mogły być wykorzystywane przez wielu odbiorców. Nie jest to jedynie zależność komponent – odbiorca. To również gwarancja, że komponenty te mogą być ze sobą łączone i nie oddziałują na siebie wzajemnie.

Desired State Configuration – zastosowanie w praktyce

Kompatybilność komponentów i ich idempotentność to niejedyne zalety DSC. Daje nam on również pewność, że cokolwiek by się działo, nasza maszyna wróci do stanu określonego w początkowej konfiguracji. W wyjątkowej sytuacji (np. gdy nastąpiły jakieś nieodwracalne zmiany) takiego stanu nie uda się odtworzyć, ale zostaniemy o tym fakcie poinformowani i będziemy mogli odpowiednio zareagować. O możliwościach reagowania szerzej napiszę w moim kolejnym artykule, w którym skupię się na Azure AA DSC.

Tymczasem wyobraźmy sobie, że serwer został przez nas skonfigurowany i pozostawiony w pewnym stanie. Pod naszą nieobecność ktoś, kto być może nie znał trybu pracy zespołu, albo ten tryb nie był odpowiednio określony, dokonał pewnej zmiany, która wpłynęła na serwer w taki sposób, że stan przestał być poprawny. Bez DSC po powrocie do pracy moglibyśmy być zaskoczeni, że wystąpiły jakieś nieoczekiwane zmiany. DSC dba o to, aby w takiej sytuacji środowisko cały czas było przywracane do stanu, w jakim je pozostawiliśmy i opisaliśmy. Jeśli skonfigurowałem serwer do konkretnego stanu, to ten stan ma być utrzymany.

Żeby lepiej to zobrazować – załóżmy, że na serwerze trzymamy jakieś pliki konfiguracyjne w katalogu X, co zostało zdefiniowane w konfiguracji DSC. Tworzy ona odpowiedni katalog i przenosi do niego poszczególne pliki z wybranego źródła zewnętrznego. Ktoś zalogował się na nasz serwer i nieumyślnie ten katalog usunął. DSC szybko wychwyci, że tego katalogu nie ma, i na nowo go odtworzy bez zakłócania pracy serwera.

W jakich sytuacjach DSC nie zadziała?

Wyżej wspomniałem, że DSC nie zawsze pozwoli przywrócić odpowiedni stan. Podam prosty przykład. Powiedzmy, że w ramach działania DSC chcemy zainstalować aplikację. Aplikacja ta musi być najpierw pobrana, ale ktoś na serwerze w firewallu zablokował ruch wychodzący. W takiej sytuacji DSC nie poradzi sobie z tym zadaniem, bo „nie wie”, że taka blokada powstała. My otrzymamy informację, że ten krok nie został wykonany, co prawdopodobnie sprowokuje nas do przejrzenia logów i trafienia na informację, że nie udało się połączyć z danym adresem do pobrania pliku. Ostatecznie po głębszej analizie zorientujemy się, że ruch ten jest zablokowany, ale będzie to wymagało naszego zaangażowania. Jedyne, co DSC będzie próbować robić, to pobrać plik z podanego adresu.

Desired State Configuration – architektura

Powyższe przykłady w pewien sposób obrazują już, jak wygląda architektura DSC. Możemy tu wyróżnić następujące elementy:

• Usługa Desired State Configuration
• Zasoby (Powershell Gallery)
• Konfiguracja
• Nody (instancje wirtualnych maszyn – serwerów)

Wszystkie one współpracują ze sobą, tworząc spójną całość – architekturę DSC. Jeżeli chcielibyśmy szczegółowo omówić ten wątek, to należy skupić się na dwóch najważniejszych modelach, które spajają powyższe, czyli Push oraz Pull.

Model Push

Jak sama nazwa wskazuje, model Push polega na „wypychaniu” – w tym przypadku wypychamy konfiguracje na nody. Model push jest to aktywna działalność użytkownika w celu dodania konfiguracji na jednym lub wielu node’ach / serwerach. W modelu tym nasze działanie skupia się na skompilowaniu oraz wypchnięciu konfiguracji za pomocą komend PowerShell. Ten model stosowany jest, gdy zależy nam na tym, żeby wszystkie maszyny otrzymały taką samą konfigurację w możliwie jak najbardziej zbliżonym czasie. Wymaga on zatem odpowiedniego zaplanowania i wdrożenia.

Model Pull

Model Pull polega natomiast na połączeniu maszyn z zewnętrzną usługą, gdzie zostaje im przypisana konfiguracja. Serwer Pull zawiera w tym przypadku wszystkie niezbędne konfiguracje oraz zasoby, wymagane do poprawnego rozmieszczenia konfiguracji na poszczególnych node’ach. Taka konfiguracja na serwerze Pull zostaje zaciągnięta wraz ze wszystkimi niezbędnymi zależnościami, a stan node’a jest monitorowany z poziomu usługi serwera Pull. Każdy z node’ów, który jest wpięty do takiej usługi, co pewien czas odpytuje serwer zgodnie z lokalną konfiguracją.

Służy do tego LCM (local configuration manager), który dba o to, aby odpytać serwer Pull, pobrać konfigurację i ją wykonać. Dodatkowo, oprócz samego odpytywania serwera Pull w interwałach czasowych, LCM dba również o to, aby monitorować stan konfiguracji na bieżącej maszynie (compliance check). Informuje nas o tym, czy wszystkie nasze maszyny poprawnie pobrały najnowszą konfigurację i prawidłowo ją wykonały. Stosowanie tego modelu jest szczególnie przydatne, gdy część maszyn jest czasowo offline. Gdy tylko przejdą w tryb online, automatycznie pobiorą i wykonają najnowszą konfigurację.

Jakie są znane rodzaje usług obsługujących metodę Pull? Na chwilę obecną są to:

• Azure Automation Desired State Configuration
• Usługa Pull w systemie Windows Server
• DSC SMB Pull server

Microsoft Azure Automation Desired State Configuration

W czasach, gdy chmura jeszcze raczkowała, implementacja polegała na pisaniu odpowiednich skryptów i konfigurowaniu własnego serwera do zarządzania nimi. Dziś Microsoft w pełni już wspiera to rozwiązanie i zintegrował je ze swoją chmurą, co jest wygodne i przekłada się na opisane przeze mnie korzyści. Niedawno podjęta została decyzja, że usługa DSC Pull servera w systemach Windows Server przestanie być rozwijana, a wszelkie prace zostaną przekierowane na usługę na platformie Azure.

Azure Automation Desired State Configuration jest dedykowaną usługą oferowaną i zalecaną przez Microsoft w większości scenariuszy. Dzięki niej jesteśmy w stanie wdrożyć automatyzację konfiguracji i zarządzania serwerami Windows i Linux. DSC umożliwia użytkownikom definiowanie ustawień, tzw. konfiguracji, w skrypcie PowerShell lub innych językach, takich jak JSON lub MOF, które reprezentują wymagany stan zasobów w sposób deklaratywny. Po zdefiniowaniu tych konfiguracji mogą być one przypisane do node’ów.

Azure Automation DSC oferuje wiele funkcji ułatwiających zarządzanie konfiguracją, w tym:

• Zarządzanie konfiguracją
• Raportowanie stanu oraz poprawności na poszczególnych instancjach (node’ach)
• Raporty, które umożliwiają użytkownikom śledzenie konfiguracji swoich zasobów

Podsumowanie

Desired State Configuration jest potężnym narzędziem, które daje nam możliwość zarządzania konfiguracjami (Configuration Management) na serwerach. Pozwala zminimalizować złożoność zadań związanych z zarządzaniem konfiguracją, zwiększyć niezawodność i zapewnić zgodność z zasadami bezpieczeństwa wedle potrzeb.

1. 1. Multi-tenant vs single-tenant
2. 2. Czym jest rozwiązanie single-tenant?
3. 3. Czym jest rozwiązanie multi-tenant?
4. 4. Implementacja – jak działa rozwiązanie single-tenant?
5. 5. Zalety i wady modelu single-tenant
6. 6. Znaczenie modelu multi-tenant w rozwoju oprogramowania
7. 7. Multi-tenant w chmurze
8. 8. Rodzaje architektur multi-tenant
9. 9. Zalety i wady modelu multi-tenant
10. 10. Implementacja multi-tentant vs single-tenant – podsumowanie

Multi-tenant vs single-tenant

Podejścia multi-tenant i single-tenant często bywają porównane do współwynajmu mieszkania (multi-tenant) bądź wynajmowania go na wyłączność (single-tenant). Każde z tych rozwiązań ma pewne wady i zalety. Wynajmując mieszkanie z innymi, dzielimy się opłatami z pozostałymi lokatorami, ale nie mamy wpływu na to, w jaki sposób gospodarują przestrzenią, ile zużywają wody, prądu itp. Wynajmując mieszkanie na wyłączność, łatwiej kontrolujemy rachunki i mamy większą swobodę, możemy też wprowadzać więcej zmian w swoim otoczeniu, ale musimy liczyć się z większymi kosztami. A jak to wygląda w praktyce w przypadku naszej aplikacji?

Czym jest rozwiązanie single-tenant?

Rozwiązanie single-tenant to architektura, w której pojedyncza instancja aplikacji wraz z infrastrukturą służy tylko jednemu klientowi. Rozwiązania single-tenant (w dosłownym tłumaczeniu: pojedyncza dzierżawa) są powszechnie wdrażane w modelach dostarczania oprogramowania jako usługi (czyli w modelu SaaS) lub w usługach w chmurze dostarczanych do klientów docelowych (serwisy typu Netflix, Slack, Shopify itp.).

W architekturze single-tenant klient, nazywany tenantem (lub dzierżawcą, najemcą), będzie miał dedykowaną mu pojedynczą instancję aplikacji SaaS. Dostawca będzie pomagać w zarządzaniu instancją oprogramowania i dedykowaną infrastrukturą, jednocześnie zapewniając prawie pełną kontrolę temu właśnie najemcy w zakresie dostosowywania oprogramowania i infrastruktury.

Cechą charakterystyczną rozwiązań single-tenant jest to, że zwykle pozwalają użytkownikom zachować kontrolę i w wysokim stopniu zaangażować się w dostosowanie rozwiązania, a także cechuje je niezawodność, bezpieczeństwo i możliwość tworzenia kopii zapasowych. Ponieważ dzierżawcy znajdują się w oddzielnym środowisku, nie są związani w taki sam sposób, w jaki byliby, korzystając ze wspólnej infrastruktury w modelu multi-tenant (o którym poniżej).

Przeczytaj także:

• Serwer TCP na platformie Azure
• Kim jest DevOps i jak wspiera projekty IT?

Czym jest rozwiązanie multi-tenant?

Multi-tenant to architektura, w której pojedyncza instancja aplikacji obsługuje wielu klientów. Dzierżawcy mogą mieć uprawnienia do dostosowywania niektórych części aplikacji, takich jak kolor interfejsu użytkownika lub reguły biznesowe, ale nie mogą modyfikować kodu aplikacji.

W architekturze wielodostępnej wiele instancji aplikacji działa w środowisku współdzielonym. Takie rozwiązanie jest możliwe, ponieważ każdy najemca jest zintegrowany fizycznie, ale oddzielony na poziomie logiki biznesowej.

Oznacza to, że pojedyncza instancja oprogramowania będzie działać na jednym serwerze, a następnie obsługiwać wielu najemców. Aplikacje dostarczane przez dostawcę często są podobne. Mogą mieć elementy wspólne, jak na przykład widoki czy logikę do zarządzania użytkownikami. Te obszary będą współdzielić konfigurację, która będzie identyczna dla określonej liczby najemców.

Aplikacje multi-tenant mogą być używane przez tych samych użytkowników, ekrany, reguły i schematy baz danych. Użytkownicy mogą dostosowywać reguły biznesowe i schematy baz danych.

Implementacja – jak działa rozwiązanie single-tenant?

W architekturze single-tenant każdy najemca będzie miał własną bazę danych i instancję oprogramowania (aplikacji), która izoluje dane każdego z najemców. Ponadto ta architektura dopuszcza tylko jedną instancję per serwer SaaS. Każda część oprogramowania może być albo specjalnie zaimplementowana dla danego najemcy, albo najemca może dostosować interfejs użytkownika po instalacji. Po wdrożeniu oprogramowania najemcy mogą zazwyczaj dostosować oprogramowanie do potrzeb konkretnego środowiska, ale nie mają dostępu do kodu źródłowego.

Dane każdego najemcy powinny również mieć kopię zapasową, dzięki czemu w przypadku utraty danych będą oni mieć możliwość łatwego i szybkiego ich przywrócenia. Ponadto dzierżawcy mogą samodzielnie zdecydować, kiedy będą instalowane dostępne aktualizacje, zamiast czekać, aż zrobi to dostawca.

W ostatnim czasie powszechne jest chmurowe wdrażanie rozwiązań single-tenant. W większości przypadków, jeśli ktoś korzysta z usług chmury prywatnej lub oferty chmury innej firmy, najprawdopodobniej jest to właśnie system z tzw. jednym dzierżawcą. Dzieje się tak, ponieważ najemca byłby jedynym klientem posiadającym dostęp do tej instancji, z opcjami bezpieczeństwa i zarządzania, a także indywidualnymi kontrolami.

Zalety i wady modelu single-tenant

Zalety

Single-tenant niesie ze sobą pewne zauważalne zalety, które są kluczowe przy podejmowaniu decyzji o wyborze rozwiązań architektonicznych. Do korzyści można zaliczyć:

• Przenośność – instancje single-tenant można przenosić za pośrednictwem usług chmurowych lub SaaS.
• Bezpieczeństwo danych – nawet jeśli dojdzie do wycieku/naruszenia danych jednego najemcy u tego samego dostawcy usług (service providera), to inny najemca będzie bezpieczny, ponieważ jego dane są przechowywane w osobnej instancji.
• Dostosowanie aplikacji – wszystkie dane klienta są oddzielne, dzięki temu ten model daje duże możliwości w zakresie dostosowania oprogramowania.
• Niezawodność – rozwiązania single-tenant są uważane za niezawodne, ponieważ ich wydajność jest oparta tylko na jednej instancji, a więc niezależna od działania wielu innych instancji pozostałych najemców.
• Przywracanie i odzyskiwanie po awarii – odizolowane kopie zapasowe umożliwiają użytkownikom szybkie odzyskiwanie usług w przypadku awarii i utraty danych.

Wady

Biorąc pod uwagę wszystkie potencjalne zalety single-tenant, jest to nadal rzadziej używana opcja spośród konkurencyjnych architektur, co może wynikać z niektórych jej wad. Główne wady podejścia single-tenant to:

• Wysokie koszty – hosting jednej instancji SaaS per klient może nieść ze sobą znaczne koszty, ponieważ taka sama liczba zasobów potrzebna w środowisku jest opłacana przez tylko jednego najemcę.
• Złożone zarządzanie – skomplikowane procesy, które mogą pojawić się, gdy po raz pierwszy zaczniesz wdrażać i dostosowywać SaaS dla jednego najemcy.
• Niewykorzystane zasoby – w słabiej zoptymalizowanych systemach nie wszystkie zasoby mogą być wykorzystane, co spowoduje, że system będzie mniej wydajny.

Znaczenie modelu multi-tenant  w rozwoju oprogramowania

Multi-tenant on-premise to z reguły stare rozwiązania, a ich korzenie sięgają klasycznych architektur mainframe, w których wiele aplikacji i użytkowników współdzieliło jedną platformę sprzętową. Wraz z wprowadzeniem i przyjęciem nowoczesnej wirtualizacji sprzętowej pojawiły się możliwości współdzielenia sprzętu między wieloma instancjami oprogramowania, takimi jak maszyny wirtualne i zainstalowane na nich aplikacje. Rozwiązanie to zyskało popularność zwłaszcza w centrach danych. Wszystko to umożliwia wielu użytkownikom współdzielenie jednej infrastruktury sprzętowej.

Multi-tenant w chmurze

Wraz z eksplozją zainteresowania migracją do chmury podejście multi-tenant odnotowało najbardziej spektakularne zastosowanie w usługach chmurowych. Architektury multi-tenant można znaleźć zarówno w środowiskach chmury publicznej, jak i prywatnej. Umożliwiają oddzielenie danych każdego najemcy od pozostałych. Na przykład w chmurze publicznej z wieloma najemcami te same serwery będą używane w hostowanym środowisku do udostępniania zasobów wielu użytkownikom. W ramach tych serwerów każdy użytkownik otrzymuje oddzielną i zabezpieczoną przestrzeń logiczną do uruchamiania aplikacji i przechowywania danych.

Rodzaje architektury multi-tenant 

Istnieją trzy główne typy modeli wielodostępnych, wszystkie o różnym poziomie złożoności i wiążące się z różnymi kosztami. Każdy model jest tradycyjnie omawiany w kategoriach aplikacji i bazy danych.

• Pojedyncza aplikacja, jedna baza danych – pojedyncza, współużytkowana baza danych to model wielodostępny z wielodostępną bazą danych. Jest to najprostsza forma spośród trzech typów modeli i ze względu na wykorzystanie współdzielonych zasobów charakteryzuje ją stosunkowo niski koszt dla najemców. To rozwiązane używa pojedynczego wystąpienia aplikacji i bazy danych do obsługi wielu jednoczesnych najemców i przechowywania danych. Korzystanie z jednej, współdzielonej bazy danych umożliwia łatwiejsze skalowanie, jednak koszty operacyjne mogą być wyższe.

• Pojedyncza aplikacja, wiele baz danych – rozwiązanie obejmuje korzystanie z jednej bazy danych z wieloma schematami. Ten system dzierżawy używa pojedynczej instancji aplikacji z indywidualnymi bazami danych dla każdego najemcy. Ponadto ta architektura jest trudniejsza do skalowania i wiąże się z wyższymi kosztami oraz większym obciążeniem dla każdej bazy danych. Jest to warta zastosowania architektura, gdy dane pochodzące od różnych najemców są rozproszone. Wówczas każda aplikacja to mikroserwis, który posiada własną bazę danych i jest niezależny od innych.

• Wiele aplikacji, wiele baz danych – ten typ architektury multi-tenant obsługuje dane w wielu bazach danych. Model ten jest dość złożony pod względem kosztów, zarządzania i utrzymania, ale podejście jest bezpieczne. Najemców można rozdzielić według wybranego kryterium.

Zalety i wady multi-tenant 

Multi-tenant wiąże się z kilkoma korzyściami, najważniejsze z nich to:

Zalety: 

• Korzystna cena – ten model jest tańszy w porównaniu z innymi architekturami hostingu dzierżawy.
• Różne modele rozliczeniowe – oferuje modele cenowe typu Pay for what you use i Pay as you go.
• Zapewnione aktualizacje – najemcy korzystający z oprogramowania dostawcy nie muszą martwić się o aktualizacje, ponieważ są one dostarczane przez dostawcę.
• Przyjazny hosting – najemcy nie muszą martwić się o sprzęt, na którym są hostowane ich dane.
• Łatwiejsza administracja – dostawcy mają do monitorowania i administrowania tylko jeden system.
• Skalowalność – architektura multi-tenant jest łatwo skalowalna.

Wady: 

• Mniejsza elastyczność – aplikacje dostarczane przez dostawcę są zwykle mniej elastyczne niż aplikacje w innych architekturach dzierżawców (tenant architecture), takich jak single-tenant.
• Złożoność – jest to na ogół bardziej złożone niż single-tenant ze względu na dodatkową wirtualizację i zarządzanie potrzebne do odizolowania i zabezpieczenia każdego najemcy.
• Rygorystyczne zabezpieczenia – aplikacje wymagają bardziej rygorystycznego uwierzytelniania i kontroli dostępu ze względów bezpieczeństwa.
• Ryzyko niedostępności – w zależności od dostawcy, przestoje również mogą stanowić problem. Skutki uboczne, takie jak pojedynczy problem z serwerem dotykający wielu użytkowników, również mogą stanowić niepożądane ryzyko.

Implementacja multi-tentant vs single-tenant – podsumowanie: 

Architektura single-tenant jest podobna do podejścia „jeden serwer, jedna aplikacja”, które przypomina tradycyjne centra danych, jakie były dostępne przed upowszechnieniem wirtualizacji serwerów. W hostowanych architekturach z jednym najemcą będzie miał on pojedynczą instancję dedykowanej mu aplikacji SaaS, w przeciwieństwie do modelu multi-tenant, gdzie usługi są współdzielone. Ponieważ każdy najemca znajduje się w oddzielnym środowisku fizycznym lub infrastrukturze, nie są oni związani w taki sam sposób, jak użytkownicy współdzielonej infrastruktury. Oznacza to, że architektury z jednym najemcą są znacznie bardziej konfigurowalne.

Multi-tenant jest używany częściej, ponieważ większość lokalnych centrów danych, SaaS i innych usług w chmurze jest współdzielona. W porównaniu z pojedynczym dzierżawcą, multi-tenant jest tańszy, pozwala na bardziej efektywne wykorzystanie zasobów i ma niższe koszty utrzymania, a także niesie potencjał większej mocy obliczeniowej. Dzięki architekturze z wieloma dzierżawcami dostawca musi dokonywać aktualizacji tylko raz. W architekturze z jednym dzierżawcą dostawca musi z kolei zadbać o aktualizacje.

Mimo że rozwiązanie multi-tenant ma wiele zalet w porównaniu z single-tenant, możliwość wprowadzania znaczących zmian w oprogramowaniu jest utrudnione dla danego najemcy, ponieważ oprogramowanie jest współużytkowane przez innych najemców.

Przeczytaj również: Jak wygląda proces dostarczania oprogramowania oparty na CI/CD? 

Przejdź do:

1. 1. Serwer TCP na platformie Azure – ale po co?
2. 2. Komunikacja po TCP – jakie są opcje?
3. 3. Konfigurujemy Azure Container Instances
4. 4. Testy
5. 5. Problem zmiany adresu IP po przeładowaniu…
6. 6. Container Apps z TCP jako kolejny etap ewolucji
7. 7. Podsumowanie

Serwer TCP (Transmission Control Protocol) na platformie Azure – ale po co?

W naszym projekcie, pracując nad rozwiązaniem pozwalającym systemom POS (ang. point of sale) na obsługiwanie płatności, musieliśmy zintegrować je z systemem obsługującym komunikację z terminalami płatniczymi. Wiązało się to z posiadaniem fizycznego urządzenia, w tym przypadku terminala, do celów testowych. Pracując w trybie zdalnym, z zespołem rozproszonym po kilku miastach w Polsce, niemożliwe było współdzielenie jednego takiego urządzenia. Zdecydowaliśmy, że do testów i na etapie pracy nad kodem będziemy używać stuba (czyt. staba) – aplikacji, która będzie zwracała predefiniowane odpowiedzi).

Lista wymagań wobec naszego zamiennika była bardzo krótka:

• Komunikacja musi odbywać się po TCP
• Żądanie musi zwracać oczekiwaną odpowiedź
• Serwer musi być w stanie obsłużyć równoległe żądania

Gotowe rozwiązanie w .NET było przygotowane tak, aby można je było uruchomić lokalnie na Dockerze.

Po upewnieniu się, że stub spełnia nasze oczekiwania i bez ryzyka może zastąpić rzeczywistą integrację, postanowiliśmy użyć go do testów E2E (ang. end to end), które są elementem pipeline’u DevOps. W tym celu trzeba było aplikację umieścić gdzieś na platformie Azure, z której korzystaliśmy.

Azure Serverless workflow orchestration

Automatyzacja procesów biznesowych jest naturalną transformacją. Poznaj rozwiązanie oparte na Azure Durable Function, które pozwoli ci przejść gładko przez ten proces.

Przeczytaj artykuł

Komunikacja po TCP – jakie są opcje?

Największą trudnością w znalezieniu odpowiedniego zasobu okazał się wymagany rodzaj protokołu, niewspierany przez serwisy bazujące głównie na komunikacji po HTTP. Jakie mieliśmy opcje?

1. Maszyna wirtualna – można postawić maszynę wirtualną i na niej uruchomić aplikację, ale wymagałoby to dodatkowej konfiguracji dostępu do maszyny oraz utrudniało monitorowanie samej aplikacji.
2. Azure Kubernetes Services – kolejną opcją jest AKS, który daje sporą elastyczność w kwestii automatyzacji zarządzania infrastrukturą, jednak na potrzeby prostego stuba jest to nadmiarowe rozwiązanie (wymagałoby odpowiedniej konfiguracji, a i tak nie wykorzystalibyśmy wielu opcji, jakie oferuje).
3. Azure Container Instances – przeglądając portfolio usług Azure, natrafiłem na informację, że protokół TCP jest dostępny dla Azure Container Instances. Wyglądało to na idealne rozwiązanie, które można byłoby w prosty sposób uruchomić. Dodatkowym atutem była łatwość monitorowania i fakt, że lokalnie stub działał na kontenerze dockerowym.

Obejrzyj także wideo z serii BiteIT:

Konfigurujemy Azure Container Instances

Na potrzeby tego artykułu przygotowałem uproszczoną wersję docelowego rozwiązania. Działa ono jak echo, zwracając otrzymane żądanie do nadawcy, i to właśnie tę aplikację będę starał się udostępnić poprzez Azure Container Instances.

Poniżej fragment kodu serwera odpowiedzialny za obsługę żądań.

private void Echo(IAsyncResult result) 

{ 

var listener = (TcpListener)result.AsynState!; 
	 

if (!_active) 

     { 

          return 

 
     } 
 
     var client = listener.EndAcceptTcpClient(result); 

     _logger.LogInformation(“Client connected from: {ip}”, 
     client.Client.RemoteEndPoint); 
     _allDone.Set(); 

     Task.Run(async () => 

     { 

          using (var stream = client.GetStream()) 

          var buffer = _array.Pool.Rent(256); 

         Array.Pool.Return(await stream.Echo(buffer), clearArray: true); 
     } 

     client. Close(); 

     }); 

 
} 

Jako osoby zajmujące się wytwarzaniem oprogramowania powinniśmy dążyć do automatyzowania powtarzalnych czynności, dlatego całą konfigurację zasobów umieściłem w plikach Bicep. Takie rozwiązanie pozwala używać raz zdefiniowanej konfiguracji wielokrotnie podczas wdrażania jej na platformie Azure.

Podstawowa konfiguracja Azure Container Instances wymaga zdefiniowania:

1. Zasobów, z jakich może korzystać skonteneryzowana aplikacja.

resources: { 

     requests: {  

          cpu: 1  

          memoryInGB: 1  
     } 
} 

2. Lokalizacji obrazu, na podstawie którego będzie budowany kontener, wraz ze zdefiniowanymi portami zewnętrznymi.

image: '${containerRegistryName}/tcp-server:latest’ 

ports: [  

{ 

port: port 

protocol 'TCP' 

} 

] 

3. Dostępu do rejestru, na którym znajduje się obraz.

imageRegistryCredentials: [ 

{ 

server: containerRegistryName 

username: registryUserName 

password: registryPassword 

} 

] 

4. Konfiguracji adresu IP.

IpAddress: { 

type: ‘Public’ 

ports: [  

    {  

port: port 

protocol: ‘TCP’  

    } 

          ] 

} 

Najważniejsza rzecz, o której trzeba pamiętać, to aby wewnętrzny port odpowiadał portowi zewnętrznemu, inaczej komunikacja po TCP nie będzie działać.

Poniżej cały plik Bicep dla konfiguracji Azure Container Instances:

Czas na testy

Po wdrożeniu na środowisko Azure mogliśmy upewnić się, że aplikacja działa i nasłuchuje na żądania.

Do celów testowych napisałem prostego klienta TCP jako test w xUnit. 

[Fact]  

public void MakeSingleCall() 

{ 

var buffer = _arrayPool.Rent(256); 

try 

{ 

using var client = GetClient(); 

using var stream = client.GetStream(); 

stream.Write(Encoding.UTF8.GetBytes(TestMessage)); 

 

          while (!stream.DataAvailable) 

          { 

               Thread.Sleep(1000); 

          } 

 

          StringBuilder sb = new(); 

          while (Stream.DataAvailable) 

         { 

         var readBytes = stream. Read(buffer); 

         Sb.Append(Encoding.UTF8.GetString(buffer[...readBytes])); 

         } 

         Assert.Equal(TestMessage, sb.ToString()); 

    } 

    finally   

    { 

           _arrayPoolReturn(buffer); 

    } 


} 

Do nawiązywania połączenia służy prywatna metoda GetClient.

private static TcpClient GetClient() 

{  

var socketException = new SocketException(); 

ushort attempts = 0; 

while (attempts < RetryAttempt) 

{ 

try  

{ 

TcpClient client = new (HostName, Port); 

return client; 

          } 

          catch (socketException  ex  

          { 

          socketException = ex; 

                attempts++; 

                Thread.Sleap(TimeSpan.FromSeconds(Math.Pow(2,  attempts))); 

                continue;   

 

          } 

     } 

     throw SocketException; 

} 

Jak widać, test zakończył się sukcesem, a w logach kontenera mamy informację o nawiązaniu połączenia.

Problem zmiany adresu IP po przeładowaniu…

Mógłbym w tym momencie przejść do podsumowania, jako że mamy działającą aplikację w Azure pozwalającą na komunikację po TCP. Niestety w dokumentacji Azure Container Instances jest informacja, że adres IP może się zmienić w przypadku przeładowania zasobu, co z kolei jest wymagane, aby pobrać najnowszą wersję obrazu aplikacji. Ryzyko zmiany adresu stuba sprawiało, że testy E2E nie mogły być częścią pipeline’u, ponieważ istniała możliwość, że będą fałszywie negatywne.

…i rozwiązanie tego problemu

Żeby nie wymuszać na kliencie serwera TCP pilnowania i zmieniania adresu IP po przeładowaniu zasobu, należy ten problem „schować” i obsłużyć wewnętrznie poprzez infrastrukturę. Na szczęście Azure zapewnia rozwiązania pozwalające to zrobić.

Docelowa architektura prezentuje się następująco:

I składa się z:

• Publicznego IP
• Load balancera
• Sieci wirtualnej (VNet)
• Container registry
• Container instances

Konfigurację w plikach Bicep podzieliłem na moduły per typ zasobu oraz jeden plik główny jako punkt startowy do postawienia wszystkich niezbędnych elementów.

Aby zmniejszyć liczbę adresów IP, jakie mogą zostać przydzielone do kontenera, zdefiniowana podsieć ma tylko 8 adresów, z czego 5 jest na wewnętrzne potrzeby Azure, co zostawia nas z 3 dostępnymi adresami.

resource virtualNetwork ‘Microsoft.Network/virtualNetworks@2022-05-01'  existing = { 

name:shared-vnet' 

} 

 

resource subnet ‘Microsoft.Network/virtualNetworks/subnets@2022-05-01' = { 

   name’tcp-server-sub' 

   parent: virtualNetwork 

   properties: { 

 	   	addressPrefix: ‘10.1.2.0/29 

delegations: [ 

   { 

name: ACIDelegationService’  

properties: {  

   serviceName: ‘Microsoft.ContainerInstance/containerGroups’  

type: ‘Microsoft.Network/virtualNetworks/subnets/delegations’ 

   } 

] 

privateEndpointNetworkPolicies: ‘Disabled’ 

privateLinkServiceNetworkPolicies: ‘Enabled’  

   } 

   	} 

 
output subnetId string = subnet.id 

Konfigurując load balancer, należy ustawić pulę dla dostępu do wewnętrznego zasobu.

backendAddressPools: [  

     {  

     name: ‘tcp-server-be' 

     properties: {  

     loadBalancerBackendAddresses: [  

     { 

     name: ‘tcp-server’ 

         properties: { 

         ipAddress: backendPrivateIPAddress 

  	     virtualNetwork: { 

         id:virtualNetworkId 

         } 

         } 

      } 

   ] 

 } 

 } 

] 

Gdzie „ipAddress” jest adresem dla Container Instances wewnątrz podsieci.

Dodatkowo zdefiniowałem sprawdzanie żywotności kontenera poprzez próbkowanie.

probes: [ 

{ 

name: ‘tcp-server-hc' 

properties: {  

   protocol: ‘Tcp’  

   port: tcpPort 

   intervalInSeconds: 5  

   numberOfProbes: 1  

          } 

     } 

]  

Wszystkie te ustawienia są niezbędne do ustalenia reguł przekierowywania ruchu z publicznego adresu IP na wewnętrzne.

loadBalancingRules: [ 

   { 

name:  ‘tcp-server-lb-rule' 

   properties: { 

frontendPort: tcpPort 

   protocol: ‘Tcp’ 

   backendPort: tcpPort 

   disableOutboundSnat: true 

   frontendIPConfiguration: { 

id: resourceId( ‘Microsoft.Network/loadBalancers/frontendIPConfigurations’, ‘tcp-server-lb', ‘tcp-server-fe' ) 

} 

backendAddressPool: { 

id: resourceId( ‘Microsoft.Network/loadBalancers/backendAddressPools’, ‘tcp-server-lb', ‘tcp-server-be' ) 

} 

probe: { 

   	id: resourceId(‘ Microsoft.Network/loadBalancers/probes’, ‘tcp-server-lb', ‘tcp-server-hc' ) 

     } 

    } 

 } 

] 

Jedyna zmiana w konfiguracji Container Instances dotyczy ustawień adresu IP, który teraz jest prywatny i przydzielony z podsieci.

ipAddress: {  

type: ‘Private’  

ports: [ 

   { 

port: port  

protocol : ‘TCP’ 

        } 

     ] 

} 

subnetIds:[ 

          {  

id: subnetId 

} 

]     

Taka konfiguracja dalej wymaga pilnowania adresu IP po restarcie kontenera i upewniania się, że jest taki sam jak ustawiony na load balancerze, ale staje się to problemem wewnętrznym.

Container Apps z TCP jako kolejny etap ewolucji

Pod koniec 2022 roku Azure dał możliwość skonfigurowania Container Apps dla komunikacji po TCP w wersji zapoznawczej.

Ponieważ Azure Container Apps ułatwia skalowanie oraz pozwala zautomatyzować podnoszenie wersji aplikacji po pojawieniu się nowego obrazu w rejestrze, postanowiłem się temu przyjrzeć.

Zgodnie z dokumentacją należy umieścić środowisko zarządzane wewnątrz podsieci. Istotne jest skonfigurowanie poprawnego zakresu CIDR – minimum /23.

resource virtualNetwork ‘Microsoft.Network/virtualNetworks@2055-05-01' existing = { 

name: ‘shared-vnet’ 

     } 

     resource subnet ‘Microsoft.Network/virtualNetworks/subnets@2022-05-01 = { 

         name: ‘tcp-server-ca-sub' 

         parent: virtualNetwork 

         properties: {  

          addressPrefix: ‘10.1.0.0/23’ 

           } 

      } 

output subnetId string = subnet.id  

Container Apps wymagają zdefiniowanego środowiska zarządzanego. Jak już wspomniałem, należy je umieścić wewnątrz podsieci, pamiętając o ustawieniu właściwości „internal” na false, aby aplikacja była dostępna z zewnątrz.

vnetConfiguration: { 

infrastructureSubnetId: subnetId 

internal: false 

} 

Sama konfiguracja Container Apps wymaga zdefiniowania:

1. Szablonu dla rewizji, którą chcemy uruchomić.

template: {  

containers: [  

{ 

          env: [ 

          { 

          name: ‘TcpServer_Port’ 

value: ‘${port}’ 

      } 

    ] 

    image: ‘${containerRegistryName}/tcp-server:latest’ 

    name: ‘tcp-server’ 

    probes: [ 

     { 

     periodseconds: 10 

     successThreshold: 1  

          tcpSocket: { 

         port: port 

     } 

     type: ‘Liveness’ 

    } 

] 

resources: { 

cpu: json(‘0.25’) 

memory: ‘0.5Gi’ 

} 
} 

] 

revisionSuffix: guid(‘tcp-server') 

}   

Dodałem, oczywiście, próbkowanie żywotności kontenera.

2. Punktu wejścia dla komunikacji zewnętrznej.

ingress: { 

allowInsecure: false 

     exposedPort: port 

     external: true 

     targetPort: port 

     transport: ‘tcp’ 

} 

3. Dostępu do Azure Container Registry, na którym znajduje się obraz aplikacji.

registries: [  

   {  

server: ascoding.azurecr.io’ 

username: registryUsername 

passwordSecretRef:  registryPasswordSecretId 

   } 

] 

secrets: [  

   { 

name: registryPasswordSecretId 

value: registryPassword 

  } 

]  

Przydatnym dodatkiem jest możliwość przechowywania informacji wrażliwych wewnątrz zasobu, bez konieczności podłączania zewnętrznego Key Vaulta.

Po zakończonym wdrożeniu okazało się, że rozwiązanie Azure jest bardzo podobne do mojego.

I również działa.

Podsumowanie

Azure Container Instances pozwala na szybkie uruchamianie skonteneryzowanych aplikacji, które umożliwia zewnętrzną komunikację po TCP. Niestety, nie jest to rozwiązanie pozbawione wad (przypomnijmy: zmieniające się IP, brak skalowania), które utrudniają skonfigurowanie środowiska i w przypadku prostych aplikacji mogą być powodem do jego odrzucenia. 

Na szczęście Azure wyszedł naprzeciw potrzebom użytkowników z nową usługą, jaką jest Container Apps, która jest relatywnie prosta do skonfigurowania i pozbawiona problemów, na jakie trafimy korzystając z Container Instances. Warto mieć to rozwiązanie na uwadze i śledzić nowe możliwości, jakie zespół developerów chmury Microsoft Azure będzie do niego dodawał.  

Przeczytaj także: Big Data w chmurze Azure

Spis treści

1. 1. Czym jest Azure IoT?
2. 2. Dlaczego warto zainteresować się tematem Azure IoT?
3. 3. Azure IoT Hub
4. 4. IoT Edge
5. 5. IoT – protokoły komunikacyjne
6. 6. Rozwiązania bezpieczeństwa Azure IoT
7. 7. Bezpieczenstwo IoT
8. 8. Najczęściej zadawane pytania (FAQ)

Czym jest Azure IoT?

Skrót IoT (ang. Internet of Things) odnosi się do fizycznych urządzeń lub całej ich grupy, które za pomocą różnego rodzaju czujników i sensorów zbierają informacje z otaczającego je świata oraz komunikują się z innymi urządzeniami i systemami, wysyłając im dane za pomocą sieci Internet.

Azure IoT jest kolekcją serwisów udostępnianych w modelu PaaS (Platform as a Service) lub SaaS (Software as a Service) zarządzanych przez firmę Microsoft. Zasoby te mogą służyć do zbierania danych oraz monitorowania i komunikacji pomiędzy milionami różnych fizycznych urządzeń. W najprostszej konfiguracji system IoT oparty o chmurę można zbudować już z jednego urządzenia peryferyjnego, które komunikuje się z wybranym zasobem dostępnym w portfolio Azure IoT.

Poniższa grafika przedstawia dostępne technologie, serwisy oraz rozwiązania z zakresu urządzeń Internet of Things oferowane przez firmę Microsoft. W tym artykule postaram się przybliżyć kluczowe usługi.

Dlaczego warto zainteresować się tematem Azure IoT?

W obecnych czasach urządzenia IoT obecne są w każdym obszarze naszego życia. Wykorzystujemy je w domach, samochodach, miejscach pracy czy w sektorze przemysłu. Postęp technologii i minimalizacja kosztów produkcji chipów w połączeniu z wszechobecną siecią Internet sprawia, że liczba dostępnych urządzeń wykorzystujących Internet Rzeczy rośnie w zawrotnym tempie. Prognozy przewidują, że będzie ono jeszcze szybsze – w 2023 roku według analityków zaobserwujemy 22-procentowy wzrost, a w 2025 liczba dostępnych urządzeń IoT wyniesie 27 mld.

Rosnąca liczba dostępnych urządzeń IoT sprawia, że zarządzanie nimi, monitorowanie ich czy zbieranie danych z czujników staje się coraz bardziej problematyczne. Tutaj naprzeciw obecnie stawianym wymaganiom rynku wychodzi platforma Azure, oferując w swojej gamie wiele rozwiązań ułatwiających komunikację z milionami urządzeń peryferyjnych działających w czasie rzeczywistym. Firma Microsoft stara się optymalizować proces wdrażania swoich rozwiązań u klientów tak, aby następował on szybko i sprawnie, jednocześnie zmniejszając koszt jego wprowadzenia. Ułatwiają to między innymi udostępniane zestawy narzędzi dla programistów – tzn. SDK (ang. software development kit). Dostępne paczki pozwalają na łatwą obsługę:

• urządzeń IoT w językach oprogramowania .NET, Python, Node.js, Java oraz C.
• wbudowanych urządzeń z ograniczonymi zasobami pamięciowymi oraz obliczeniowymi.
• serwisami do zarządzania komunikacją z urządzeniami IoT.

Szczegółowe informacje o dostępnych pakietach SDK można znaleźć bezpośrednio na stronie producenta.

Poza samymi zasobami umożliwiającymi komunikację z aparaturą Internetu Rzeczy Azure oferuje narzędzia, które pozwalają w prosty sposób analizować, przetwarzać, przechowywać i wizualizować odbierane dane.

Przeczytaj atykuł: Kim jest DevOps i jak wspiera projekty IT?

Microsoft, dzięki wachlarzowi swoich usług, pozwala developerom na stworzenie rozwiązania dostosowanego do indywidualnych wymagań stawianych przez klientów. Oferując przy tym prostotę w konfiguracji gotowego do działania środowiska. Poniższy diagram przedstawia, jakie możliwości w składaniu kompozycji zasobów oferuje platforma Azure:

Warto dodać, że rozwiązania oparte o zasoby z zakresu Azure IoT pozwalają zapewnić bezpieczne połączenie dla milionów urządzeń.

Azure IoT Hub

IoT Hub jest głównym zasobem składającym się na rozwiązania z obszaru Azure IoT. Jest to usługa udostępniana w modelu PaaS pozwalająca na dwukierunkową komunikację pomiędzy urządzeniami IoT a chmurą. Za pomocą bezpiecznego połączenia umożliwia obsługę transferu ogromnej liczby danych oraz ciągły monitoring praktycznie dowolnych urządzeń.

IoT Hub wspiera kilka kanałów komunikacyjnych. Są to między innymi:

Dane telemetryczne oraz alerty 

Są to wiadomości wysyłane z urządzenia do chmury (ang. device-to-cloud). Po wysłaniu przez aparat tego typu wiadomości trafia ona do wewnętrznej kolejki IoT Hub, gdzie może być przechowywana do 7 dni. Następnie zewnętrzny serwis, np. aplikacja kliencka, za pomocą wbudowanego w IoT Hub punktu końcowego jest w stanie odebrać oczekujące wiadomości. Kanał ten przeznaczony jest szczególnie do obsługi wiadomości wysyłanych z dużą częstotliwością o maksymalnym rozmiarze do 256 KB. Najprostszym sposobem na przesyłanie tego typu wiadomości jest użycie na docelowym urządzeniu wspomnianej wcześniej paczki SDK w preferowanym języku programowania, która udostępnia prosty i czytelny interfejs komunikacyjny.

Wiadomości sterujące urządzeniami

Jest to komunikacja, która w przeciwieństwie do wyżej opisanej służy do przekazywania wiadomości z chmury, np. aplikacji klienckiej, do urządzenia (ang. cloud-to-device). W tym przypadku zasób IoT Hub również jest pośrednikiem komunikacji i wysyłane wiadomości trafiają w pierwszej kolejności do wspomnianej kolejki. W zależności od konfiguracji mogą oczekiwać na odebranie przez urządzenie do kilku dni. Jest to szczególnie przydatne w przypadku urządzeń, które nie mają zapewnionego ciągłego dostępu do sieci.

Przesyłanie plików z urządzeń

Kanał ten służy do przekazywania różnego rodzaju plików. Mogą to być np. nagrania wideo czy też – w celu ograniczenia zużywanego transferu – skompresowane paczki zawierające dane telemetryczne. Przekazywane z urządzenia pliki trafiają bezpośrednio do skonfigurowanego w IoT Hub kontenera na zasobie Azure Blob Storage.

Monitoring konfiguracji oraz stanów urządzeń

Kanał ten został przez inżynierów Azure nazwany Device Twins. Służy przede wszystkim do przechowywania metadanych urządzenia w chmurze, monitorowania aktualnego stanu połączenia z urządzeniem i upewniania się, czy np. odbywa się ono przez sieć komórkową, czy Wi-Fi, oraz synchronizowania długotrwałych przepływów, takich jak stan etapów wgrywania nowej wersji dla urządzenia sprzętowego (firmware).

IoT Edge

Azure IoT Edge jest usługą używaną do wstępnej analizy danych przed ich wysłaniem do powyżej opisanego zasobu IoT Hub. Usługi te przeznaczone są dla klientów, którzy chcą przeprowadzić część agregacji danych bezpośrednio na urządzeniu, zamiast dokonywać ich w chmurze. Poprzez przeniesienie części obliczeń na graniczne urządzenia (IoT Edge Devices) można zminimalizować liczbę przesyłanych poprzez sieć danych, co może nieść ze sobą spore oszczędności w przypadku miejsc z trudno dostępną siecią. Dodatkową zaletą takiego rozwiązania może być między innymi możliwość wcześniejszej reakcji na zmianę statusu bądź wykrycie ustawionego limitu na danym parametrze.

Opisywana usługa składa się ze środowiska uruchomieniowego wraz z modułami brzegowymi, które są używane bezpośrednio na urządzeniu. Po stronie chmury znajduje się interfejs służący do zdalnego monitorowania urządzeń i zarządzania nimi przez usługę IoT Edge. 

Dodatkowym atutem jest fakt, że środowisko uruchomieniowe usługi IoT Edge jest całkowicie bezpłatne i oferowane jako rozwiązanie typu open-source.

Przeczytaj także: Azure DevOps – jak zacząć karierę?

IoT – protokoły komunikacyjne

Urządzenia IoT służą przeważnie do zbierania danych z czujników i wysyłają je do backendowych serwisów, które następnie zajmują się ich przetwarzaniem. Opisywany typ urządzeń często posiada cechy takie jak:

• fizyczna lokalizacja w miejscu trudno dostępnym dla człowieka.
• ograniczenia w dostępie do sieci Internet.
• brak możliwości obsługi przez człowieka (często są to urządzenia wbudowane).
• brak graficznego interfejsu użytkownika.
• wymaganie specyficznych dla danego przemysłu protokołów.

Chcąc na nie odpowiedzieć, firma Microsoft zaleca używanie dedykowanych pakietów SDK ułatwiających rozpoczęcie pracy z aparaturą IoT. Zarówno paczki SDK, jak i sam zasób IoT Hub wspierają popularne protokoły komunikacyjne takie jak:

• MQTT (Message Queue Telemetry Transport).
• MQTT przez WebSocket.
• AMQP (Advanced Message Queuing Protocol).
• AMQP przez WebSocket.
• HTTPS.

Rozwiązania bezpieczeństwa Azure IoT

Internet Rzeczy, prócz nieograniczonych wręcz możliwości, stwarza też wiele zagrożeń. Firmy stają przed nowymi wyzwaniami w zakresie bezpieczeństwa – do tej pory skupiało się ono na oprogramowaniu, a przy IoT dochodzi dodatkowa składowa, jaką jest połączony z oprogramowaniem świat rzeczywisty.

Aby odpowiednio zdefiniować zagrożenia, konieczne jest ich modelowanie, m.in. za pomocą Azure Digital Twins. Procedura ta składa się z kilku kroków – modelowania aplikacji, zdefiniowania zagrożeń, ich ograniczenia i sprawdzenia wprowadzonych środków zaradczych. Celem jest zrozumienie, w jaki sposób atakujący mogą naruszyć system, i upewnienie się, że wdrożono konieczne zabezpieczenia.

Pozaj również powiązane produkty z portfolio Azure, które pomogą zadbać o bezpieczeństwo, takie jak Azure Defender dla IoT, Azure Sentinel czy Azure IoT Central.

Bezpieczeństwo IoT

O ile urządzenia IoT mogą wydawać się zbyt małe czy wyspecjalizowane, by stanowić zagrożenie, prawdziwym niebezpieczeństwem jest ich powiązanie z siecią i możliwość ataku. Może on doprowadzić do kradzieży danych czy zakłócenia świadczenia usług, ale też wyrządzić szkody fizyczne w obiektach, a nawet stanowić zagrożenie dla obsługujących je lub zależnych od nich ludzi.

Podejmowane ataki można podzielić na 5 głównych obszarów:

1. Spoofing – podszywanie się, gdzie haker może anonimowo manipulować urządzeniem, przejąć je lub częściowo przechwycić przesył i obserwować dane z urządzenia.
2. Tampering – manipulowanie urządzeniami, podczas którego atakujący może wymienić oprogramowanie na urządzeniu.
3. Disclosure – ujawnianie informacji; gdzie atak polega na podsłuchiwaniu transmisji, przechwytywaniu informacji bez autoryzacji lub zagłuszaniu sygnału i odmowie uzyskania informacji. 
4. Denial of service – odmowa usługi, np. przez zakłócanie częstotliwości radiowych lub odcięcie przewodów; skutkiem może być niezdolność urządzenia do działania lub komunikacji.
5. Elevation of privilege – przechwycenie uprawnień, np. gdy urządzenie wyspecjalizowane do określonych czynności zostaje zmuszone do robienia czegoś innego.

Ochrona struktur IoT zakłada kompleksowe podejście z wykorzystaniem odpowiednich technologii i protokołów.

Zaleca się trzystopniowe podejście do ochrony danych, urządzeń i połączeń: 

1. Bezpieczne udostępnianie urządzeń. 
2. Bezpieczne połączenie między urządzeniami i chmurą.
3. Zabezpieczenie danych w chmurze podczas przetwarzania i przechowywania.

Najczęściej zadawane pytania (FAQ)

Spis treści

1. 1. Od programisty do DevOpsa
2. 2. Błądzenie w chmurze – czyli od czego zacząć?
3. 3. Narzędzia DevOps
4. 4. Zasoby – platforma Microsoft Learn
5. 5. A jak poznać proces DevOps?
6. 6. CI/CD (Continuous Integration / Continuous Delivery)
7. 7. IaaC (Infrastructure-as-a-Code)
8. 8. Podsumowanie

Od programisty do DevOpsa

W przypadku programowania wybierasz język, który wydaje się najbardziej interesujący i dostosowany do tego, co chcesz robić, albo… prosty w nauce. Kiedy poznasz podstawy składni, jedyne, co cię ogranicza, to twoja własna wyobraźnia. Na początku zastanawiasz się: „Co by tu napisać?”. Może kalkulator, może kółko i krzyżyk albo coś bardziej zaawansowanego z obsługą bazy danych lub zewnętrznych bibliotek?

Im więcej zrealizowanych projektów, tym więcej napotkanych wyzwań, a twoje umiejętności rosną z każdą kolejną linią kodu. Czujesz się biegle w składni, korzystasz już z zewnętrznych bibliotek, a na rozmowach o pracę możesz pochwalić się owocem swojej dotychczasowej nauki w postaci działających programów. Na kolejnym etapie zaczynasz obracać się w bardziej zaawansowanych projektach, które wymagają zastosowania i znajomości różnych podejść. Pojawiają się procesy, większy nacisk kładziony jest na jakość kodu, jego elastyczność, a z tym wiąże się nauka wzorców.

Błądzenie w chmurze – czyli od czego zacząć?

A jak to wygląda w przypadku chmury? Zarówno przy programowaniu, jak i tutaj możemy wyróżnić dwa główne etapy nauki. Pierwszym z nich jest nauka narzędzia (Azure), a drugim – wzorców i procesów. Jest to oczywiście uproszczenie, bo zarówno narzędzia, jak i wzorce można jeszcze precyzyjniej skategoryzować, ale wszystko to zależy od poszczególnych projektów i ich wymagań.

Usługa Azure DevOps – narzędzia

Zaczęliśmy od narzędzi i tutaj wybór może paść na dowolną chmurę: Microsoft Azure, AWS, GCP – to najwięksi obecnie dostawcy na rynku. To, którą chmurę wybierzesz, nie ma wielkiego znaczenia, gdyż oferują one podobne usługi i w większości przypadków rozwiązanie jednej firmy ma swój odpowiednik w rozwiązaniu oferowanym przez inną.

Od czego rozpocząć? Czyli „pakiet startowy” Azure DevOps

To, od czego możesz zacząć i co pozwoli ci rozwinąć skrzydła, to poznanie samej chmury i tego, co oferuje. Przykładami takich zasobów, które warto poznać w ramach Azure, mogą być np.:

Nie bez powodu podałem akurat te. Chciałem w ten sposób pokazać, że zasoby, poza realizowanymi przez nie odpowiedzialnościami, są również w pewien sposób od siebie zależne i ze sobą powiązane.

Na powyższym przykładzie możemy to zobrazować tak, że Virtual Machine należy do podsieci zdefiniowanej w Virtual Network, a dostęp do niej zdefiniowany jest poprzez skonfigurowany Network Security Group.

Zasoby Azure DevOps – usługa Microsoft Learn 

Kiedy poznasz poszczególne zasoby oferowane przez chmurę, będziesz już mieć świadomość tego, w jakich przypadkach możesz je wykorzystać i jak się ze sobą komunikują. A z pomocą w nauce przyjdzie ci platforma Microsoft Learn. Ma ona trzy ważne zalety, o których chciałbym wspomnieć.

1. Wybór ścieżki 

Po pierwsze, pozwala na wybór ścieżki, w której chcesz się kształcić. Może to być jedna z wielu, np.:

W zależności od tego, którą ścieżkę obierzesz, będziesz mieć dostęp do modułów, które zapoznają cię z poszczególnymi zagadnieniami potrzebnymi w pracy na danym stanowisku. Zaletą takiego rozwiązania jest to, że nie musisz się zastanawiać, na czym spośród wielu możliwości się skupić, i możesz od razu zająć się zagadnieniami, które są ze sobą powiązane. Poznasz w ten sposób również charakter pracy w danej roli, dowiesz, czy jest to praca bardziej administracyjna, koncepcyjna lub developerska.

2. Certyfikacja 

Po drugie – certyfikacja. Microsoft w zakresie wszystkich swoich rozwiązań oferuje ścieżkę certyfikacji. Nie jest ona darmowa, nie jest też prosta, a w wielu przypadkach wręcz można na niej pobłądzić. Jest to jednak najbardziej rozpoznawalne i uznawane potwierdzenie umiejętności na rynku pracy w zakresie technologii oferowanych przez Microsoft.

Jeżeli zależy ci na udokumentowaniu swojej wiedzy i umiejętności, możesz skorzystać z modułów, które przygotują cię do wybranego przez siebie certyfikatu, co na pewno ułatwi szukanie pracodawcy. Warto jest się dobrze zapoznać z dostępnymi ścieżkami certyfikacji i dowiedzieć, jaka wiedza jest sprawdzana na poszczególnych egzaminach. Na każdą ze ścieżek składa się kilka egzaminów o różnym zakresie i podziale tematycznym. W przypadku typowego DevOpsa w chmurze Azure (DevOps Engineer) polecam skupić się na AZ-900 Microsoft Azure Fundamentals. Certyfikat ten zapozna cię z koncepcją chmury oraz dostępnymi zasobami w Azure na podstawowym poziomie. Dalej możesz już obrać jedną z bardziej zaawansowanych ścieżek w zależności od tego, co cię interesuje. Wszystkie certyfikaty wraz z opisami dostępne są na oficjalnej stronie Microsoftu.

3. Ćwiczenie umiejętności  

Trzecią zaletą tej platformy jest jej funkcjonalność. Wszystkie moduły są pogrupowane w poszczególne kategorie ze względu na technologię lub certyfikację, którą wybierzesz. Dodatkowo twoja aktywność jest na bieżąco śledzona i zapisywana, dzięki czemu wiesz, które materiały już przerobiłeś. Bardzo często na końcu każdego modułu lub ważnego zagadnienia umieszczane są linki do dodatkowych zasobów, które pozwolą ci pogłębić wiedzę odnośnie opisywanych zagadnień. Nie są one wymagane, ale na pewno pozwalają zdobyć bardziej szczegółowe pojęcie o zasobach i poznać możliwości, jakie oferują.

Oprócz lekcji w formie tekstowej pojawiają się również laboratoria. Są one zintegrowane ze stroną i można w prosty sposób poćwiczyć tworzenie i konfigurowanie zasobów tak, jak byśmy to robili w codziennej pracy.

A jak poznać proces DevOps?

Chmurę, na przykładzie Azure, można zatem poznać w dość przystępnej formie, którą opisałem powyżej. Inaczej sytuacja wygląda natomiast z samym procesem DevOps. Niestety w tym przypadku, chyba w każdej firmie trafimy na odstępstwa od modelowych procesów i trudno szukać miejsca, gdzie wszystko byłoby idealne. Warto jest zatem mieć ogólne pojęcie o tym, jak powinny przebiegać poszczególne procesy, jakie dają nam realne korzyści oraz kiedy powinniśmy je stosować.

Reszta zależy już od wielu składowych, takich jak: specyfika projektu, oczekiwania klienta, budżet, zaangażowanie i wiedza zespołów ze sobą współpracujących, a nawet narzędzia, których używają.

Jak wdrażać projekty? Pomocne wzorce

Z pomocą przyjdą nam wzorce, czyli podobnie jak w programowaniu, szablony, które stosujemy i które w czysty, zorganizowany sposób pozwalają nam budować strukturę projektu, który będzie elastyczny i reużywalny. O jakich zatem wzorcach / praktykach mowa?

1. CI/CD
2. IaaC

Wymieniłem właśnie te, ponieważ uważam je za najważniejsze i podstawowe – bez nich żadna infrastruktura nie powinna funkcjonować. Jest ich oczywiście znacznie więcej, np.: SecOps, monitoring, konteneryzacja, orkiestracja, ale moim zdaniem są to bardziej złożone procesy wynikające z przyjętej technologii oraz specyfiki projektu. Przyjrzyjmy się zatem nieco bliżej dwóm wybranym przeze mnie wzorcom.]

CI/CD (Continuous Integration / Continuous Delivery)

CI/CD (Continuous Integration / Continuous Delivery) – to szablon przepływu procesów w projekcie od momentu zaplanowania, przez wdrożenie, ciągłe utrzymywanie i monitorowanie. CI/CD to esencja kultury DevOps i warto go poznać, aby zrozumieć, jakie niesie ze sobą korzyści. Do jego składowych należą procesy:

• Plan
• Code
• Build
• Test
• Release
• Deploy
• Operate
• Monitor

Na każdy z nich można poświęcić jeden artykuł, dlatego zachęcam do skupienia się na tym wzorcu, który niewątpliwie stanowić będzie solidny fundament w rozwoju jako DevOps.

IaaC (Infrastructure-as-a-Code)

IaaC (Infrastructure-as-a-Code) – czyli infrastruktura jako kod, jest to wzorzec, dzięki któremu jesteśmy w stanie budować skalowalną infrastrukturę w sposób zautomatyzowany. Istnieje wiele podejść do tego tematu. Dostawcy zasobów chmurowych oferują swoje rozwiązania, ale istnieją również na rynku narzędzia firm zewnętrznych. Możemy wyróżnić tutaj podejście deklaratywne, jak i imperatywne – oba są mniej lub bardziej świadomie stosowane. Warto zatem zapoznać się z różnicami między nimi (poruszę ten temat w kolejnym artykule) oraz z dostępnymi na rynku narzędziami do tworzenia IaaC, takimi jak:

• Bicep
• Terraform
• Ansible
• Pulumi
• Chef

W przypadku platformy Azure, Bicep jest dedykowanym językiem do pisania deklaratywnego kodu infrastruktury. Nie zastosujemy go w przypadku innych chmur (np. AWS czy GCP). Jeżeli zależy ci zatem na narzędziu opisującym infrastrukturę deklaratywnie i ze wsparciem dla pozostałych rozwiązań chmurowych, to polecam Terraform.

Metodyki DevOps – podsumowanie

W dobie zwinnego rozwoju oprogramowania i coraz szybszej transformacji cyfrowej już nikt nie kwestionuje potrzeby posiadania w zespole specjalisty, który może nie tylko budować aplikacje w chmurze, ale też je wdrażać. Warto zainteresować się kulturą DevOps – dla wielu programistów jest to naturalna droga rozwoju.

Mam nadzieję, że po lekturze tego artykułu łatwiej będzie ci zrobić pierwszy krok w stronę rozwoju jako Azure DevOps. Jak widać powyżej, rola ta jest złożona i wymaga cierpliwości, ale jak to w życiu bywa, na wszystko potrzeba czasu. Powodzenia!

Big Data w chmurze dla każdego?  

Termin „Big Data” oryginalnie został stworzony ponad 30 lat temu, ale jak wszystko w IT, w ciągu 3 dekad ewoluował i rozwijał się, towarzysząc ekspansji Internetu i źródeł informacji. Do niedawna był to termin opisujący systemy, na które mogły sobie pozwolić jedynie wielkie korporacje i wiodące startupy z dużym finansowaniem – wymagało to wszak wielkich nakładów kapitałowych na rozproszone klastry utrzymujące infrastrukturę Big Data. Nic dziwnego, że na wyłuskiwaniu informacji w wielkiej skali zbudowały swoją potęgę takie korporacje jak Google czy Facebook. Liderzy obserwujący, co się dzieje na rynku, nie mogli zaprzeczyć, że zbieranie i analiza dużych zbiorów danych może dać wymierne korzyści biznesowe.  

Chęć zbudowania nowej wartości w oparciu o wielkoskalową analizę danych rosła, ale brak było odpowiednich narzędzi, aby sprawdzić potencjał drzemiący w danych, jednocześnie zachowując rozsądne koszty (np. w modelu try-before-buy). Na tę potrzebę odpowiedzieli dostawcy platform chmurowych, oferując w ostatnich latach ogromną ilość usług zorientowanych na przetwarzanie danych – niektóre wprost w modelu PaaS (Platform-as-Service). W wyniku tego możemy zaobserwować eksplozję popularności systemów chmurowych Big Data. Po prostu dzisiaj już każdego stać na to, żeby spróbować wycisnąć ze swoich wielkich zbiorów danych maksimum informacji i… wartości.  

Przeczytaj także: Kim jest DevOps?

Ekosystem Azure’a a architektura Big Data 

Na przestrzeni kilkunastu lat ugruntowały się dwa podstawowe modele wysokopoziomowej architektury Big Data – Lambda i Kappa. Model Lambda może uchodzić za fundamentalny. W jego skład wchodzą: 

• Magazyny danych (ang. Stores). 
• Systemy przetwarzania wsadowego (ang. Batch Layer). 
• Systemy przetwarzania strumieniowego – w czasie zbliżonym do rzeczywistego (ang. Speed Layer, Near-Realitme – Stream Processing Systems). 
• Magazyny udostępniające dane i wyniki analiz (ang. Serving Layer). 
  
  

W modelu Lambda oba systemy przetwarzania danych są niezależne i równoległe. W międzyczasie powstała koncepcja architektury Kappa, w której model przetwarzania strumieniowego jest podstawowym elementem, a model przetwarzania wsadowego jest niejako procesem potomnym. Jest to model prostszy, ale bardziej wyspecjalizowany – odpowiedni w przypadku, gdy głównymi źródłami danych są dane napływające w czasie rzeczywistym (np. logi, tweety / wiadomości, komunikaty z urządzeń IoT).  

Usługi składowania danych (bez limitu) 

Centralnym elementem każdego systemu Big Data są magazyny danych. W nich przechowujemy ogromne ilości surowych (nieprzetworzonych) danych, które zebraliśmy ze źródeł, ale także zbiory „potomne” powstałe w procesie transformacji, korelacji i analizy danych źródłowych. Azure umożliwia przechowywanie danych w dwóch typach magazynów: Azure Storage (AS) i Azure Data Lake Storage (ADLS). W przypadku obu usług rozliczani jesteśmy za rozmiar składowanych danych i operacje na nich wykonane (podstawowe: zapis i odczyt oraz inne). Magazyn Azure Storage oprócz możliwości składowania dużych plików (Blob) ma też „wbudowane” dodatkowe usługi:  

• Files – serwer plików udostępniający pliki z wykorzystaniem protokołu SMB.  
• Tables – Baza NoSQL działająca na zasadzie Klucz / Wartość (Key / Value).  
• Queues – prosty system kolejkowy wymiany danych.  

Ponieważ każda z tych „dodatkowych” usług może łatwo zostać zastąpiona przez dedykowaną usługę Azure, to ciągle podstawową funkcją AS i ADLS jest składowanie dużych zbiorów danych.  

Przyjrzyjmy się im bardziej szczegółowo: 

Azure Blob Storage (ABS)  

ABS pojawił się na Azure kilka lat temu. Jego podstawowe cechy to: 

• Składowanie danych bez limitu (standardowy limit – który jednak można usunąć – to ponad 5 PB).  
• Limit dla pojedynczego pliku danych (blob) to 4,7 TB.  
• Występuje w dwóch podstawowych rodzajach (ang. Tiers) Standard i Premium (Premium jest lepiej przystosowany do obsługi plików o mniejszych rozmiarach). 
• Umożliwia składowanie w kilku warstwach (ang. Access Tiers) – Premium, Hot, Cool, Archive różniących się ceną, wydajnością i kosztem operacji – im „zimniejsza” warstwa, tym tańsze składowanie (przestrzeń), ale wolniejsze i droższe są operacje dostępu do danych. 

Azure Data Lake Storage (ADLS) 

Usługa ADLS została zbudowana jako rozszerzenie ABS, umożliwiając składowanie danych w hierarchicznym systemie plików (ang. Hierarchical Namespace) – ABS składuje bowiem bloby w prostym systemie plików, opartym na słowniku Klucz / Wartość (ang. Flat Namespace). Użycie hierarchicznego systemu plików to niewątpliwie udogodnienie, co można zaobserwować przy atomowych operacjach dotyczących dużej liczby blobów, jak np. przeniesienie w inne miejsce. ADLS z takim systemem plików jest też bardziej wydajny, ale są dwa punkty, w których przegrywa ze starszą usługą: 

1. Jest trochę droższy w zakresie koszów operacji na danych.  
2. Ma nieznacznie ograniczone możliwości, jeżeli chodzi o zabezpieczenie przed wszelkiego rodzaju katastrofami – magazyn ADLS może mieć redundantną kopię w innym rejonie świata, ale przełączenie na kopię może być uruchomione jedynie przez Microsoft, gdy zorientuje się, że coś nie działa. W przypadku starszej usługi ASB kopię może przełączyć sam użytkownik z poziomu portalu Azure’a. Niby to drobnostka, ale w przypadku systemów krytycznych dla biznesu może mieć znaczenie. 

Azure Stream Analytics (AStA) – przetwarzanie strumieniowe PaaS 

Jedną z ciekawszych usług przetwarzania danych udostępnionych przez Microsoft na platformie Azure jest Azure Stream Analytics (na potrzeby tego artykułu będę posługiwał się skrótem AStA, dla odróżnienia od ASA – Azure Storage Account i Azure Sunapse Analytics). Jako że jest to usługa strumieniowego przetwarzania danych udostępniona w modelu PaaS, nie dotkniemy tu „serwerów” ani nie wybierzemy rozmiaru pamięci naszego silnika przetwarzania danych. Prawie wszystkie parametry skali przetwarzania sprowadzają się do przypisania do zadania magicznego czynnika Streaming Units (SU). Większe ilości SU przyznają więcej mocy procesora, pamięci do zadania, a także przy większych ilościach SU – większą liczbę instancji przetwarzających strumień danych równolegle. Zadania AStA mogą być wykonywane na wirtualnych klastrach współdzielonych z innymi klientami Microsoftu (multi-tenant), jak również na izolowanym i dedykowanym klastrze (usługa Azure Stream Analytics Cluster) z zastrzeżeniem, że dedykowany klaster nie może alokować mniej jednostek niż 36 SU (oznacza to większy koszt startowy). 

AStA oferuje ciekawy sposób oprogramowania zadań przetwarzania strumieniowego. Zadania tworzy się tu w formie kwerendy (lub zestawu kwerend) z użyciem konkretnego rozszerzenia, języka T-SQL. Innymi słowy – kod zadania ASA wygląda jak SQL, z zastrzeżeniem, że niektóre „wirtualne tabele” z których ASA czyta i do których pisze, to w rzeczywistości źródła danych strumieniowych (zwykle kolejki) i zbiory wyjściowe (tu mamy pełną gamę możliwości zapisywania wyników do kolejek wyjściowych, zbiorów na Azure Storage, baz SQL i NoSQL, hurtowni czy systemu BI). Trudno się oprzeć wrażeniu, że jest to rozwiązanie odzwierciedlające możliwości platformy open-source zaproponowanej przez Confluent.io i opartej na systemie Kafka i języku KSQL. 

Jako że podstawą analizy strumieniowej jest analiza kontekstowa wymiarze czasu, to język T-SQL usługi ASA został wyposażony w specjalne funkcje pozwalające agregować wyniki kwerendy po kluczach i w odpowiednich interwałach czasowych (agregaty per okno czasowe). Mamy tutaj takie możliwości jak: 

• Tumbling Window – stała agregacja jedynie po czasie – podsumowanie i generowanie wyników następuje zawsze po określonej liczbie sekund (periodycznie). 
• Hoping Window – stała agregacja po czasie z przesunięciem – okna czasowe, w których obliczane są wyniki, mogą na siebie zachodzić, okno następne może się zacząć przed zakończeniem poprzedniego. 
• Sliding Window – dynamiczna agregacja po czasie z oknami czasowymi stałej długości – ale granice okien czasowych są wyznaczane przez kolejne rekordy pojawiające się na wejściu – okna czasowe zatem zaczynają się i kończą w nieustalonych z góry momentach. 
• Session Window – dynamiczna agregacja po czasie z oknami czasowymi różnej długości – okno czasowe jest wydłużane (sesja), jeżeli wybrane rekordy pojawiają się odpowiednio często. 

Innymi ciekawymi rozszerzeniami T-SQL na użytek ASA są funkcje geolokacyjne (ang. Geospatial Functions) oraz natywne możliwości czytania rekordów wejściowych, które są zakodowane w postaci obiektów najczęściej transportowanych wielkoskalowymi kolejkami AVRO i JSON. Jeżeli ktokolwiek chce szybko zbudować w Azure system strumieniowy, to z pewnością użycie AStA jest jednym z pomysłów, które warto rozważyć.  

Azure Synapse Analitics i Azure Databricks – pojedynek gigantów 

W ostatnim czasie podstawowym frameworkiem do analizy zbiorów Big Data stał się Spark. Jego niezaprzeczalne walory oparte na rozproszonym przetwarzaniu z użyciem samej tylko pamięci zostały docenione przez całą rzeszę użytkowników na świecie. Konsekwencją tej popularności jest pojawienie się Databricks – komercyjnej platformy początkowo zorientowanej na to redukowanie niedogodności związanych z zarządzaniem klastrami Sparka (Managed-Spark). W odpowiedzi na popularność Databricks Microsoft przygotował swoją wersję platformy analitycznej Big Data. Oba rozwiązania konkurują ze sobą, starając się sprostać wymaganiom nowoczesnych systemów Big Data – każdy w trochę innym modelu.  

Azure Synapse Analytics – hurtownia Big Data 

Azure Synapse Analytics wspiera bodaj najpopularniejszy model organizacji danych w nowoczesnych systemach danych. Wszystko zostało pomyślane w taki sposób, aby wspierać architekturę danych nazywaną kiedyś Two-Tier Data – zakładająca współistnienie dwóch równoległych głównych magazynów danych: 

• DataLake – jako magazynu przechowującego dane nieustrukturyzowane oraz wstępnie przetworzone  
• Hurtowni danych – jako źródła dla systemów BI. 

Ten dwutorowy model powstał, gdy zorientowano się, że nie istnieje jedno rozwiązanie odpowiadające potrzebom wszystkich popularnych przypadków użycia danych. Hurtownie są znacznie wygodniejsze jako źródła danych dla systemów opartych na SQL (w tym BI), ale dużo mniej wygodne, jeżeli chodzi o eksplorację danych (Data Science) oraz źródło danych do trenowania modeli sztucznej inteligencji (Machine Learning). Stąd pomysł, aby w systemie obydwa te byty istniały równolegle. 

Azure Synapse Analytics w pełni implementuje ten model. Centralnym elementem platformy jest tandem – wysoce skalowalna chmurowa hurtownia danych Azure Synapse DWH (Built-in pool) oraz środowisko zarządzalnych klastrów Spark do analiz danych w Data Lake. To jednak jeszcze nie wszystko. Pod jednym dachem Microsoft umieścił dodatkowe usługi przetwarzania danych.  

Znajdziemy tu zintegrowane: 

• Data Factory – usługa integracji danych. 
• Serverless SQL Pools – system serwerów SQL on-demand – gdzie użytkownik płaci jedynie za czas i zasoby zużyte do wykonania zapytania, bez ponoszenia kosztów serwera czy maszyny wirtualnej. 
• Data Explorer – usługa analizy danych. 

Każdą z tych usług można oprogramować w ich natywnym języku (SQL, KustoQL, Python, Scala, a nawet C#). 

Do dyspozycji mamy więc o wiele więcej niż prosty system hurtownia + Data Lake. Zyskujemy scentralizowaną platformę udostępniającą wszystko, co najlepsze pod dachem Microsoftu do analizy danych. Brawo za pomysł! 

Azure Databricks – architektura Lakehouse 

Azure Databricks jako bezpośrednia konkurencja Azure Synapse Analytics realizuje trochę inny model. Ta strategia wynika z faktu, że Databricks powstał jako środowisko do łatwego zastosowania Sparka i koncepcja silnika Big Data jako centralnego elementu pozostała tu silnie zakorzeniona. W ciągu dwóch ostatnich lat Databricks zorientował się jednak, że sam Spark nie wystarczy. Wraz ze swoimi partnerami rozbudował platformę o dodatkowe funkcjonalności prowadzące do powstania kompletnie nowego modelu platformy danych – Lakehouse Architecture.  

Koncepcja Lakehouse w skrócie bazuje na tym, że platforma ciągle polega na danych umieszczonych w Data Lake, ale udostępnia większość funkcjonalności dostępnych dotychczas tylko w hurtowniach: 

1. Transakcyjność – model ACID dla (niektórych) zbiorów Big Data.
2. Wsparcie wysoce wydajnego silnika zapytań SQL.
3. Mechanizmy kontroli dostępu do danych w Data Lake (Data Governance).
4. Wsparcie importu danych i orkiestracje ETL.

Model Lakehouse to naprawdę mała rewolucja. Zapewne nie będzie on aż tak wydajny jak model typu StarSchema w dobrej hurtowni danych, ale koncepcja Lakehouse opiera się na paradygmacie taniego składowania dużych zbiorów danych. Stąd Databricks zakłada, że skoro składowanie danych jest tanie, mogą być one przechowywane i organizowane w redundantnych kopiach (tabelach) skierowanych pod konkretne zastosowania – przy jednoczesnym założeniu, że dane są klasyfikowane w ich zaawansowaniu (koncepcja klas tabel Bronze-Silver-Gold).  

Patrząc z boku, Databricks zbliża się do koncepcji reprezentowanych przez innych konkurentów, np. do platformy Vertica z podobnym redundantnym i specjalizowanym modelem tabel. 

DeltaLake – transakcyjność Big Data 

Idea Lakehouse nie byłaby kompletna bez wspierania koncepcji transakcyjności. Oczywiście transakcyjności nie da się łatwo zaimplementować dla surowych i nieustrukturyzowanych danych, ale dla danych przetworzonych można się już o to pokusić. Do realizacji tego celu Databricks i partnerzy (Delta.io) zaproponowali nowy format zapisu tabel „zarządzanych” o nazwie „Delta”. Delta to rozszerzenie koncepcji tabel opartych na formacie Parquet, czyli kolumnowym formacie plikowym.

Delta zakłada, że obraz „tabeli” reprezentowanej przez zestaw plików w magazynie nie opiera się na prostej sumie wszystkich rekordów ze wszystkich plików danych. Obok plików z danymi Delta utrzymuje tzw. Delta-Log, czyli zestaw plików opisujący transakcje na zbiorze. Innymi słowy, przy zmianie zawartości tabeli w magazynie pojawiają się nowe wersje starych plików ze zmienionymi danymi, a informacja o zakończonej transakcji (o tym, że nowy plik jest ważniejszy niż stary) jest zapisywana w Delta-Logu. Ponieważ w tym samym momencie w zbiorach plików występują pliki z danymi z różnych okresów, w Delta-Logu przechowywane jest ich wersjonowanie. Dzięki tej prostej koncepcji tabele Delta mają cechy ACID, a przy tym… możliwa jest podróż w czasie, tzn. można poprosić o obraz tabeli z pewnego momentu w przeszłości. Oczywiście w dowolnym momencie możemy wyczyścić tabelę z plików / rekordów historycznych, co spowoduje zmniejszenie jej wielkości w magazynie danych. 

SQL Warehouse – SQL w służbie Big Data 

Natywnym językiem wielu rozwiązań klasy BI pozostaje SQL. Z tego powodu koncepcja Lakehouse musi uwzględniać jak najszersze wsparcie dla tego języka. Oczywiście podstawowa wersja silnika Sparka zawiera wbudowany „Spark SQL”, ale jego użyteczność była trochę ograniczona. W celu poprawienia tej sytuacji Databricks zaproponował nowy rodzaj silnika zapytań o nazwie Photon oraz nowy typ klastrów dla zapytań SQL – SQL Warehouses (albo SQL endpoints). Ze względu na to, że nowy silnik zapytań wykorzystuje mocno cache klastry SQL Warehouse trzeba opierać się na trochę mocniejszych maszynach (w Azure to Standard_E8ds_v4, czyli 8 vCore’ów i 64 GB pamięci). Zwiększony koszt pozostaje jednak pod kontrolą, ponieważ działają na nich wszystkie dotychczasowe mechanizmy autoskalowania w górę i w dół, aż do osiągnięcia limitów określonych przez administratora.  

Z moich obserwacji wynika, że zastosowanie nowego silnika i nowych klastrów znacząco przyspieszyło wykonywanie zapytań SQL na zbiorach Big Data. Oczywiście ponieważ ciągle pod spodem mamy zbiory plikowe, warto pokusić się o stworzenie właściwej organizacji danych, nie wahając się przed tworzeniem redundantnych i dedykowanych zbiorów pod najbardziej krytyczne zapytania – po to, żeby umożliwić silnikowi skorzystanie z optymalizatorów wykorzystujących partycjonowanie oraz dane indeksów i metadane dostępne w niektórych typach plików (np. Delta). 

Unity Catalog – właściwy Data Governance w Data Lake 

Nie można by nazwać rozwiązania przygotowanego przez Databricks hurtownią danych bez rozbudowanego mechanizmu umożliwiającego zarządzanie danymi. W tym celu Databricks zaimplementował nowy, lepszy mechanizm „katalogu danych”, czyli metabazy przetrzymującej informacje o zbiorach danych i ich schematach widzianych jako tabele. W tradycyjnych środowiskach Big Data (również opartych na Sparku) ten element bazował na najpopularniejszym katalogu Hive Metastore albo katalogu Impala. Databricks zaproponował swoją własną wersję katalogu danych nazwaną Unity Catalog. Unity Catalog pozwala na rozbudowaną kontrolę nad zbiorami Big Data: 

• System zarządzania oparty na instrukcjach ANSI SQL.
• Szczegółowy audyt i analizę logów dostępu do danych.
• Przypisywanie uprawnień do zbiorów danych na poziomie konta użytkownika.
• Wsparcie dla implementacji uprawnień na poziome rekordów (Row-Level Security) oraz kolumn (Column-Masking Policy).
• Scentralizowane i bezpieczne przeszukiwanie metadanych – pozwalające zrozumieć, które zbiory / tabele Big Data zawierają jakie dane.
• Wizualizacje powiązań między zbiorami – grafy przedstawiające zależności między zbiorami z uwzględnieniem uprawnień użytkownika korzystającego z tej funkcjonalności.
• Lepsza efektywność kwerend zbiorów zarejestrowanych w Unity Catalog – wynikająca z określonego przeorganizowania katalogu i przetrzymywania jego zapisów w pamięci w skompresowanej formie.

Jak widać powyżej, korzyści, które wnosi nowy metastore Databricks, są rewolucyjne. Migracja zwykłego Hive Metastore do Unity Catalog jest prosta i na pewno warto to zrobić, żeby wynieść poziom zarządzania danymi na niespotykany dotąd poziom. 

Delta Sharing – udostępnianie danych na zewnątrz 

Najnowsza wersja platfrom Databricks wprowadza jeszcze jedną użyteczną funkcjonalność – w pełni kontrolowane udostępnianie danych na zewnątrz. Proces ten jest realizowany z użyciem rozwiązania Delta Sharing, które zostało wbud

Takie rozwiązanie jest bardzo wygodne w przypadku gdy system Big Data został oparty na danych od wielu klientów (np. serwisów typu multi-tenant). Właściciel systemu Big Data ma dostęp do wszystkich udzielonych mu danych, mając jednocześnie możliwość udostępnienia określonych informacji/wyników na zewnątrz w taki sposób, aby jego indywidualni partnerzy mieli dostęp jedynie do swoich podzbiorów. 

Cloud przyszłością Big Data 

Mój artykuł jedynie pobieżnie poruszył temat kilku ważnych usług z portfolio Azure. Żeby opisać je dokładnie, potrzebny byłby cały cykl. Mam nadzieję jednak, że treść zainteresowała was na tyle, aby spróbować swoich sił z tematem projektowania i implementacji systemów Big Data z użyciem Azure. Rewolucja oparta na danych trwa nadal. Warto się stać jej częścią. Jeżeli macie jakieś wątpliwości lub pytania służymy pomocą!  

Jak wiele rozwiązań technologicznych, także systemy wbudowane trafiły do powszechnego użycia z projektów dla przemysłu kosmicznego. Żeby poznać ich historię, trzeba cofnąć się do lat 60., gdy na potrzeby misji Apollo powstał w 1961 r. zintegrowany obwód sterujący. Stworzone przez Charlesa Starka Drapera rozwiązanie pozwoliło nie tylko zmniejszyć wagę promu kosmicznego, ale też umożliwiło załodze zbieranie danych w czasie rzeczywistym.

Przeczytaj: Co przyniosą połączone siły IIoT i 5G?

Dziś każdy z nas ma, dosłownie, na wyciągnięcie ręki podobne rozwiązania – wszelkie urządzenia przenośne czy wykorzystywane w obszarze Smart Home. Według danych MarketsandMarkets do 2025 roku rynek rozwiązań wbudowanych osiągnie wartość 116 bln dol., a już teraz rynek ten rośnie o 50% szybciej niż systemów obliczeniowych ogólnego przeznaczenia. To jednak niejedyny powód, by się nimi zainteresować!

Embedded systems (systemy wbudowane). Co to w ogóle jest? 

Najczęściej spotkamy się z określeniem, że system wbudowany to połączenie software’u i hardware’u.

Taki system za pomocą sterownika odpowiada za jakąś część bardziej złożonego procesu (np. określone zadanie lub funkcjonalność). Systemy wbudowane mogą być oparte zarówno na mikroprocesorach, jak i mikrokontrolerach, a w niemal wszystkich tego rodzaju układach wykorzystuje się system operacyjny LINUX (można też zastosować Windows IoT lub Embedded Java). W przypadku systemów wbudowanych „im prościej, tym lepiej” – a ze względu na wysoki poziom wyspecjalizowania, im mniej skomplikowany system, tym większa niezawodność.

Czym charakteryzują się systemy wbudowane?  

Najważniejsze zalety systemów wbudowanych to kompaktowość, nisko kosztowość możliwa dzięki masowej produkcji oraz ich szerokie zastosowanie w wielu różnych sektorach.

Jednocześnie inżynierowie systemów wbudowanych dążą do tego, aby tworzone przez nich rozwiązania były niezawodne, szybkie, efektywne i bardziej energooszczędne. To prawdziwe wyzwanie, zwłaszcza jeśli weźmiemy pod uwagę to, że nieraz muszą obsługiwać krytyczne procesy, procesować wrażliwe dane i reagować w czasie rzeczywistym.  

Zastosowanie  

• Automotive – we współczesnych samochodach znajdziemy nieraz nawet około 100 wbudowanych komputerów czy systemów, które wspierają różne obszary, jak np. systemy nawigacyjne czy sterowanie audio. Branża automotive wykorzystuje systemy wbudowane w rozwiązaniach typu ADAS (Advanced Driver Assistance System). Taki zaawansowany system wspierający jest wykorzystywany w systemach wspomagania parkowania, prowadzenia pojazdu, zwiększania bezpieczeństwa – jak np. sterowanie poduszkami powietrznymi itp. Po przestoju spowodowanym pandemią, dynamika przemysłu motoryzacyjnego nabiera znów tempa, a systemy wbudowane znajdują szerokie zastosowanie w różnego rodzaju pojazdach. 
• Urządzenia smart – telefony komórkowe wykorzystują wiele systemów wbudowanych do sterowania kamerami, mikrofonami, USB. Posiadają je także zegarki cyfrowe (do procesowania danych w czasie rzeczywistym) oraz wszelkiego rodzaju urządzenia przenośne czy te, które pomagają budować Smart City (sygnalizatory świetlne, inteligentne oświetlenie, czujniki ruchu, kamery). Potencjał IoT, a zatem systemów wbudowanych wykorzystuje szeroko rozumiana elektronika użytkowa (urządzenia rolnicze, urządzenia domowe typu Smart Home) 
• Maszyny przemysłowe – wykorzystanie systemów wbudowanych otworzyło drzwi dla rewolucji przemysłowej. Urządzenia IIoT (Industrial Internet of Things w procesie produkcji umożliwiają sterowanie produkcją, monitorowanie i optymalizację procesów – wszystko to w czasie rzeczywistym. Sensory, zautomatyzowane systemy produkcyjne i monitorujące czynią proces bardziej efektywnym, ekonomicznym i przyjaznym środowisku      
• Sprzęt medyczny – urządzenia wykorzystywane w medycynie (respiratory, urządzenia MRI) muszą spełniać najbardziej restrykcyjne wymagania, gdyż często od ich poprawnego funkcjonowania zależy zdrowie lub życie ludzkie. Wbudowane systemy obsługują w nich graficzny interfejs użytkownika, który powinien być możliwie jak najbardziej przyjazny i intuicyjny w obsłudze. Podobnie jak w maszynach użytkowych, wykorzystuje się tu również kontrolery i sensory   
• Przemysł lotniczy – w przemyśle lotniczym systemy wbudowane mierzą się z ekstremalnymi warunkami (jak niskie czy wysokie temperatury). Mają krytyczne znaczenie dla bezpieczeństwa, muszą więc spełniać wyśrubowane normy. Takie systemy mogą odpowiadać za kontrolę prędkości i temperatury, rejestrować parametry lotu, sterować silnikami, ale też… dostarczać rozrywki pasażerom poprzez wbudowane w kabinie ekrany, którymi sterują. Jako zastosowanie rozwiązań Embedded warto też wymienić coraz chętniej wykorzystywane drony z systemami nawigacyjnymi i sterowania   

Podsumowanie  

Coraz większe możliwości technologii takich jak chmura, sieć 5G czy sztuczna inteligencja, wykorzystywanych przez IoT, z pewnością będzie sprzyjał wykorzystaniu systemów wbudowanych. Szerokie zastosowanie w wielu branżach i zapotrzebowanie na sprzęty elektroniki użytkowej sprawiają, że producenci mogą z optymizmem patrzeć w przyszłość. Muszą jednak liczyć się z zagrożeniami i potrzebami, jakie wiążą się z zastosowaniem rozwiązań typu Embedded Systems w urządzeniach użytkowych. Zatrudniając odpowiednio wykwalifikowanych inżynierów i przeprowadzając testy bezpieczeństwa systemów wbudowanych, można odpowiednio zminimalizować to ryzyko.