Logic Apps, integracja z prędkością światła

Dzisiaj mam ciężki dzień, dwie wizyty w ZUS potrafią wyczerpać każdego normalnego człowieka, więc siły starczyło mi tylko na przejrzenie ostatnich video dorzuconych do kanału YouTube Microsoft Azure.

Jako, że jestem nieskrywanym fanem PaaS najbardziej zainteresował mnie wideo podcast Tuesdays with Corey: The Goodness of Azure Logic Apps, w Head of Product Logic Apps zaprezentował ich możliwości. Mind blown over and over. Gość centralnie w 10 minut stworzył aplikację, która reaguje na alert z maszyny wirtualnej wysyłając e-mail z opcjami do wyboru, wiadomość SMS oraz postuje na kanał slackowy. 10 minut włączając utworzenie i deployment Logic Appa, wyklikanie ww. opcji oraz demonstrację logów i efektów ich działania.

Nie mam więcej pytań. Wiedziałem, że ta usługa ma potencjał, ale to mnie utwierdziło w przekonaniu, że rzucam wszystko i jadę w Bie… i zabieram się za wykorzystanie Logic Apps. Tyle funkcjonalności, które można dodać tak szybko. Jaram się.

 

Service Fabric, dzień 7 – Load Balancer

Wiele maszyn uruchomionych w klastrze, wiele serwisów i replik uruchamianych pod różnymi adresami i słuchającymi na różnych portach stanowi pewne wyzwanie z punktu widzenia klienta wykorzystującego jednolitą aplikację, w której ww. powinny być zupełnie przezroczyste.

Rozwiązać ten problem można na różne sposoby, np. gateway z automatycznym wykrywaniem instancji serwisów. W przypadku Service Fabric najprostszym rozwiązaniem jest jednak Load Balancer, który otrzymujemy out-of-box. Kieruje on ruch jedynie do poprawnie funkcjonujących instancji serwisów (ma wiedzę o ich stanie), co zapewnia wspomnianą już przezroczystość dla klienta – ta funkcjonalność jest jego domyślną i standardową. Posiadając wiedzę o instancjach reaguje oczywiście także na zmianę ich liczby, czyli zapewnia skalowanie aplikacji. Dodatkowo umożliwia też skonfigurowanie takiego mechanizmu jak partycjonowanie ruchu pozwalając na “ręczne” kierowanie określonych żądań do określonych węzłów.

Azure Functions 0.5

Widzę, że mam poważne braki w moich subskrypcjach RSS. Niby obserwuję Azure Blog, ale jak się okazuje wielu interesujących mnie rzeczy tam nie ma. Na nową wersję Azure Functions nadziałem się przypadkiem, kiedy po prostu chciałem coś poprawić w ustawieniach. A nowości są super! Działający monitoring, live streaming eventów (Azure Functions Pulse), można wiązać parametry do body/query w triggerze HTTP.

Takie to ładne teraz, o:

Azure Functions 0.5

Zaraz zabieram się za poprawianie kodu, poużywam sobie nowości, a co. Kroi się też przerzucenie kolejnych funkcjonalności w to miejsce, skoro tak ładnie się rozwija i tak elegancko można teraz ogarniać wyjmowanie danych z requesta 🙂

Tak czy siak, App Service Team Blog ląduje na liście regularnie odwiedzanych miesc (jak mogłem nie robić tego wcześniej?!).

Service Fabric, dzień 6 – Przegląd podsystemów, cz.1

W poprzednim wpisie była mowa o usługach domyślnych w manifeście. Jakie usługi oferuje nam out of the box Service Fabric? Trochę tego jest, dodatkowo serwisy systemowe są pogrupowane w podsystemy, odpowiedzialne za różne aspekty działania klastra.

Jednym z ciekawszych podsystemów z punktu widzenia użytkownika jest z pewnością Reliability subsystem, który odpowiada za utrzymanie wysokiej dostępności aplikacji uruchomionych w Service Fabric i składa się z trzech usług systemowych:

Failover manager – reaguje na dodawanie i znikanie węzłów, wyrównuje obciążenia w przypadku dodania węzła i rekonfiguruje repliki w przypadku jego utraty,

Resource Balancer – odpowiada za zbieranie danych o obciążeniu i przekazywanie ustalonych na ich podstawie rekomendacji do Failover managera,

Replicator – pilnuje prawidłowej replikacji serwisów, zajmuje się także zachowaniem spójności stanów pomiędzy replikami serwisów stateful.

 

Service Fabric, dzień 5 – Model aplikacji

Wiemy już, że aplikacja Service Fabric składa się z serwisów. Jak to jest jednak wszystko opisane? Za opis całości aplikacji odpowiada jej manifest, którego zadaniem jest zebrać informacje o wszystkich serwisach w aplikacji oraz o ich rozłożeniu w klastrze Service Fabric. Oprócz serwisów, o których głównie myślimy tworząc aplikację (czyli naszych) manifest zawiera też sekcję dla serwisów domyślnych, które Service Fabric uruchamia automatycznie.

A co z serwisem? Ten składa się z trzech elementów – kodu, konfiguracji, danych. Kod to rzecz jasna pliki wykonywalne serwisu. Konfiguracja może być zmieniana w run time. Dane są to informacje statyczne wykorzystywane przez usługę. Każdy z trzech elementów zebrany jest w niezależną od pozostałych paczkę.
Całość każdego serwisu także opisana jest manifestem, do którego odniesienie znajduje się w manifeście aplikacji.

Wszystkie manifesty, zarówno serwisów jak i aplikacji, mają postać plików XML (podobnie jak konfiguracja serwisu) i są niezależnie wersjonowane.

Fundamentals of Azure, 2nd Edition

Właśnie (wczoraj) pojawił się nowa edycja bezpłatnego e-booka od Microsoft – Microsoft Azure Essentials – Fundamentals of Azure, 2nd Edition.

Lektury to nie zastąpi, ale tym co czytali lub chociaż przeglądali pierwszą edycję parę słów o pierwszych zauważonych istotnych różnicach:

Azure App Service and Web Apps – zastąpiło dawne Websites oraz Cloud Services, to dość spora zmiana.

Additional Azure Resources – dodatkowy rozdział, w którym po pół strony ogólnych informacji o kilkunastu różnych usługach w Azure, wielkiego pożytku poza ogólnym oglądem z tego nie ma, niemniej dla tych co ich nie używają jest to podstawowa pigułka wystarczająca by się orientować w temacie.

But the winner is…
Azure Resource Manager – jego opis pojawia się już w pierwszym rozdziale i w kolejnych konsekwentnie dodane są elementy wykorzystania tego podejścia w deployowaniu usług. Zmiana jest o tyle naturalna, że wcześniej po prostu go nie było, ale dobrze, że zaktualizowano tego e-booka pod tym kątem bo to jednak inna koncepcja.

To tyle po bardzo pobieżnym przescrollowaniu. Zauważyłem jeszcze też sporo małych aktualizacji (np. VS 2013 na VS2015), pewnie jest tego jeszcze dużo więcej. Wyjdzie w trakcie dokładniejszego przeglądania.

Doskonała pozycja dla rozpoczynających zabawę z Azure, polecam.

Patterns & practices

Jest taki dział w bibliotece MSDN, który polecam najmocniej jak się da, nazywa się patterns & practices. Jest to wg mnie jedno z najlepszych miejsc w MSDN, dzięki któremu można porządnie ogarnąć system jako całość i spojrzeć na wiele metod podejścia do rozwiązywania problemów.

Wewnątrz tego działu jest mniejszy fragment, który dotyczy mojej codziennej pracy – Cloud Design Patterns. Genialna sprawa, świetne, przejrzyste opisy różnych wzorców projektowych podzielonych pod kątem klasy rozwiązywanych zagadnień oraz zorientowania na konkretne wyzwania stawiane przed systemem lub jego częścią. Pozwala, nawet nie znając szczegółów (co czasami jest zbawienne na początkowym etapie ;)), dowiedzieć się co potrafią usługi w Azure, jak można połączyć je z innymi i jakich efektów można się dzięki temu spodziewać. Dodatkowo, dzięki kategoryzacji typów problemów do rozwiązania daje dobrą podkładkę pod rozmowy nad projektem i checklistę do odhaczenia z czym można się w konkretnym przypadku zderzyć. Jeśli tylko dam radę to z pewnością powybieram co ciekawsze, albo sprawdzone przeze mnie, wzorce i jeszcze o nich napiszę.

Service Fabric, dzień 4 – Service/Actor API

Service Fabric udostępnia dwa frameworki do tworzenia mikroserwisów w swoim obrębie:

  • Reliable Service API – pozwala na bezpośredni dostęp do elementów Service Fabric jak połączenia czy stosy komunikacyjne,
  • Reliable Actor API – jednowątkowy, asynchroniczny model programowania z wykorzystaniem, a jakże, aktorów. Pozwala implementować aktora jak jednowątkowy singleton.

Różnią się przede wszystkim tym, że Actor API jest frameworkiem wyższego poziomu, operującym na wyższym poziomie abstrakcji.

Takie dwupoziomowe podejście to ciekawa opcja. Można wykorzystać bardziej przystępny, intuicyjny model do tworzenia nawet skomplikowanych projektów czy do sprawnego wykonania proof of concept albo użyć niższego poziomu jeśli chce się wycisnąć z usługi jej maksimum i przede wszystkim mieć pełną kontrolę nad wszystkim.

Nowinki, nowinki…

Dwa istotne newsy z tego tygodnia, dwie funkcjonalności na różnych etapach życia:

Wsparcie dla formatu JSON w Azure SQL kończy Preview i wchodzi w fazę General Availability. Yay! W dobie kiedy serwisy często wymieniają między sobą dane za pomocą tego lekkiego formatu możliwość wyciągnięcia informacji z bazy lub zapisu do niej wprost z JSONa jest słodziutka. Będę korzystał tak bardzo…

Wchodzi też kolejna nowość – otóż do każdego service planu, a wręcz do każdego deployment slotu w Web Appie możemy utworzyć sobie bazę MySQL stojącą razem z www. Co prawda nie nadaje się to (przynajmniej na razie) do tworzenia elastycznych systemów bo nie obsługuje skalowania, ale nadal jest to wielki krok naprzód. Jak mi się nie chciało za bardzo kombinować tak teraz będę się poważnie zastanawiał nad przerzuceniem tego bloga do Azure. A co 🙂

Service Fabric, dzień 3 – Podstawowa terminologia

Krótko o podstawowych, najważniejszych terminach używanych w trakcie zajmowania się Service Fabric:

  • Node – węzeł – proces runtime usługi Service Fabric, w praktyce – pojedyncza maszyna (w przypadku Azure – wirualna),
  • Cluster – klaster – zestaw węzłów (o wysokiej dostępności, niezawodności itd…),
  • Application – aplikacja – zbiór usług, mikroserwisów,
  • Service – usługa, mikroserwis – jednostka dostarczająca jakieś konkretne funkcjonalności
  • Partition – partycja – usługa może posiadać wiele partycji, tzn. być uruchomiona w wielu instancjach w klastrze, ten mechanizm służy do zarządzania obciążeniem – load balancing pomiędzy wieloma instancjami tej samej usługi,
  • Replica – replika – redundancja w ramach instancji (partycji) usługi, mechanizm służy do zapewnienia ciągłości działania – płynne przełączanie pomiędzy Primary i Secondary zarówno w trakcie wyłożenia się procesu usługi jak i w przypadku deployowania updatu.

Tyle na razie. Do tych jeszcze wrócimy, nadejdzie też parę nowych.