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.

Na ASAPy – Azure Functions

Co tu zrobić jak przychodzi szef i mówi:

– Dostaniesz zaraz kawałek gotowego kodu. Kod działa, do tej pory był wywoływany ręcznie, teraz chcę żeby to pracowało w tle i uruchamiało się samo pod koniec tygodnia roboczego. A, i chciałbym mieć możliwość szybkiego zrobienia sobie samodzielnie zmian, żebym z każdą poprawką nie musiał do Ciebie biegać. Na kiedy to może być gotowe?

Optymalnie byłoby:

– Wychodzisz, czy chcesz popatrzeć?

Funkcja uruchomiona w planie Dynamic, więc głębsze zastanawianie się nad wydajnością chwilowo można było odsunąć na przyszłość. Wybrany Time Trigger. Kopiuj, wklej, lekko popraw – najwięcej czasu zajęło dołożenie usingów i ogarnięcie potrzebnych paczek nugetowych, bo kod do użycia to faktycznie był wycinek ze środka większej klasy. Dodać application settings, connection strings. Ustawić czas. Go!

Jak mnie się ta usługa podoba!

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.

Azure User Group live z Krakowa

Kiedy wczoraj pisałem o community zupełnie zapomniałem, że dziś jestem w Krakowie na spotkaniu Azure User Group!

Dzisiaj bardzo interesujące tematy: IoT, Service Fabric i Functions. Nie pamiętam kiedy agenda była tak w punkt z moimi zainteresowaniami.

Here we go!

[19:00] Grubo, fajne przykłady rozwiązań architekturalnych dla IoT oraz wstęp do Service Fabric uzupełniony demkiem. Muszę koniecznie zrobić taki eksperyment u siebie. A na deser Functions…

AUGPL KRK 3

[20:00] Functions też było super, parę ciekawych wykorzystań i obejść dla mechanizmów, które teoretycznie dostępne są tylko w wyższych planach cenowych.

Pisałem już, że warto wybierać się na spotkania community? Pisałem, wczoraj. No, to warto 😉

I jeszcze jedno – tacy Panowie mówili na takie tematy: agenda spotkania.

6 tygodni do AzureDay North Poland

Już za półtora miesiąca odbędzie się w Gdyni konferencja pretendująca (i w moich oczach będąca głównym faworytem) do najlepszego azurowego wydarzenia w tym roku w Polsce. Prelegenci krajowi i zagraniczni, lokalni liderzy, pracownicy Microsoft, wiele ścieżek tematycznych. Zapowiada się smakowicie.

Ja się wybieram, już od jakiegoś czasu mam wszystko połapane i jestem gotów. No, przynajmniej organizacyjnie, jeszcze mentalnie muszę popracować nad otworzeniem głowy i psychicznym przygotowaniem się na spotkanie z lokalnymi tuzami technologii, która wiedzie prym w mojej codziennej pracy.

Czekam w sumie dość niecierpliwie na ten dzień. Od kiedy po raz pierwszy wybrałem się spotkanie community – tegoroczny Global Azure Bootcamp w Warszawie – bardzo cenię sobie takie spotkania. A tu dwa dni technicznego mięsa i ciekawych rozmów. Będzie się działo!

AzureDay North Poland, Gdynia 3-4 października 2016

Open source PowerShell

Dziś po prostu nie wypada o tym nie napisać. Co prawda PowerShell nie jest pierwszą opcją międzyplatformowego zarządzania chmurą Azure (jest wszakże xplat cli), a mnie akurat na codzień to w nim najbardziej interesuje to trudno nie docenić takiego kroku. Raz, że PowerShell jest nie tylko od Azura, dwa, że jest znacznie bardziej popularny od ww. konsoli.

Kolejny krok ku otwarciu, przytuleniu do siebie użytkowników niewindowsowych, poszerzeniu możliwości integracji oraz, jak to przy projektach open source, dodatkowy firepower w stronę rozwoju. Nic tak nie napędza community jak możliwość samodzielnego dołożenia funkcjonalności do narzędzia.

Więcej do poczytania u źródła.

Service Fabric, dzień 2 – Stateful & Stateless

Widywałem już, wynikające zapewne z tłumaczenia tych pojedynczych słów – stateful, stateless – podsumowania, że te dwa rodzaje usług różnią się posiadaniem lub nie posiadaniem stanu przechowywanego między poszczególnymi wywołaniami. Uproszczenie niby małe, ale jednak wprowadzające w konkretny błąd. Należy do niego dodać jeszcze słówko „lokalnie”. To znaczy usługę stateful można przerobić na usługę stateless nie rezygnując z żadnych stanów, a jedynie zmieniając miejsce ich zapisu poprzez umieszczenie go poza samą usługą. Dzięki temu np. po wywrotce węzła jego redundantna lub nowo uruchomiona kopia odczytuje aktualny stan usługi z zewnętrznej lokalizacji i wszystko działa bez zakłóceń.

Most services have states. However, this doesn’t mean they are stateful. The only difference between stateful services and stateless services is where states are stored.

– Programming Microsoft Azure Service Fabric (Haishi Bai)

Swoją drogą nie dziwią mnie te niedopowiedzenia – to nazewnictwo nie jest specjalnie intuicyjne. Co poradzić, opisowe pewnie byłoby niewygodne.

Service Fabric, dzień 1 – Microservices

Mikroserwisy, kto nie słyszał o mikroserwisach? Owiane nutką tajemnicy i nowoczesności, modne, intrygujące. Z jednej strony „róbcie mikroserwisy, są eleganckie, skalowalne, niezawodne”, z drugiej „nie róbcie mikroserwisów, chyba, że naprawdę musicie i dobrze wiecie co robicie”. Bądź tu człowieku mądry. Ale tak to już zdaje się jest, praktycznie nie ma rozwiązań, które załatwiałyby w elegancki sposób skomplikowane problemy i nie wymagały jednocześnie ostrożności w projektowaniu i konstruowaniu.

Service Fabric to mikroserwisy, pod nie przynajmniej jest ta usługa zaprojektowana i one są preferowaną metodą wykorzystania Service Fabric.

To a great extent, the art of a software architect is to strike a balance between the number of components and the number of communication paths.

– Programming Microsoft Azure Service Fabric (Haishi Bai)

Nie pozostaje zatem nic innego jak uczyć się, zdobywać doświadczenie, pytać lepszych i zostawać art-engineer 😉

Service Fabric, prolog

Zacząłem czytać o Service Fabric i zaraz na początku urzekło mnie to:

Programming Microsoft Azure Service Fabric (Haishi Bai)

Powinno się wprowadzić jakiś obowiązek, że każda techniczna książka, szczególnie posiadająca znamiona dokumentacji, powinna zawierać na początku taki przewodnik. Co prawda tę i tak prawdopodobnie przeczytam całą, ale idea jest szczytna i należy ją wspierać.

Dodatkowo, tak na marginesie, dziś zauważyłem, że nie dość że weszła w PREVIEW zmiana, o której napisałem tutaj, to jeszcze przebudowano menu portalowe scalając Settings i Tools (no nie wszędzie, ale tam gdzie mi pasuje jest OK) i pogrupowano to wszystko razem sensownie po funkcjonalnościach. Na przykład nareszcie ustawienia logów są tuż obok Log Stream i nie trzeba się przełączać jak potłuczony. Tyle dobra na raz, wzruszyłem się 😉