Serverless – Maszyny stanu w Azure Functions (Azure Functions Część 5)

W ostatnim poście o Azure Functions wspomniałem, że Logic Apps przypomina trochę to AWS Step Functions. To było trochę naciągane. To znaczy mogliśmy tam sobie poukładać tak jakbyśmy niby mieli stan ale… nie mieliśmy go. Wykonywaliśmy po prostu funkcję za funkcją. W AWS step functions też jakoś nie przechowują stanu, logują stan po każdym kroku tak byśmy my mogli dowiedzieć się co poszło nie tak, ale nie ma miejsca centralnego zarządzania tym. Jest za to opis i wizualny edytor. To nam umożliwia określenie przepływu pracy i nie martwienie się o nic innego, reszta jest załatwiana przez AWS. Do tej pory nie było zbliżonego prawie do 1-1 odpowiednika w Azure aż do teraz. Azure Durable Functions (rozszerzenie do Azure) umożliwia nam tworzyć maszyny stanu z wykorzystaniem funkcji.

Durable Functions to jest rozszerzenie Durable Task i daje nam pewne ciekawe możliwości określania przepływu pracy jak i rozwiązuje kilka problemów które nie byłyby łatwe normalnie do rozwiązania. To co wyróżnia Azure Durable Functions to sposób ich deklarowania, iż zarządzania. To nie jest schemat JSON czy wizualny edytor, a zwykły prosty i zrozumiały kod. Jak przeczytacie poniższy kod to z miejsca będziecie wiedzieć jaki problem tutaj jest rozwiązany:

public static async Task<object> Run(DurableOrchestrationContext ctx)
{
    try
    {
        var x = await ctx.CallFunctionAsync<object>("F1");
        rerun = await ctx.CallFunctionAsync<object>("F2", x);
    }
    catch (Exception ex)
    {
        // error handling
    }
}

To co daje nam Durable Functions to rozwiązanie kilku problemów na które mogliśmy natrafić lub zastanawiać się jak to można rozwiązać z wykorzystaniem serverless:

• Wykonywanie seryjne funkcji z przekazaniem informacji o wyniku poprzedniej funkcji – po dodaniu elementu do bazy danych, wrzuć informację do logu, jak wyląduje w logu, przepchnij ją do kolejki i obrób pozbywając się danych osobowych i zwróć użytkownikowi końcowemu;
• Wykonywanie równoległe funkcji i przekazanie ich wyników do kolejnej funkcji – na przykład obliczamy stan magazynowy pojedynczego elementu w kilku magazynach, wynik jest następnie sumowany i przekazywany do kolejne funkcji;
• Możliwość implementacji Actor Model z wykorzystaniem Azure Functions. O Actor Model nie pisałem ale wspominałem przy elixir przy opisie BREAM (tak mniej więcej może wyglądać implementacja Actor Model);
• Typowy przepływ pracy w pracy. Próba akceptacji urlopu przez osobę która jest na urlopie. Każdy chyba coś takiego pisał lub przez coś podobnego przechodził. Durable Functions umożliwiają w prosty sposób określenie co i kiedy ma być wykonane, kiedy na nasz szef nie może nam zaakceptować urlopu w danym przedziale czasu;
• Długo wykonywane funkcje mają ten problem, że ciężko się dowiedzieć czy ich wykonywanie się zakończyło – na przykład przetwarzanie jakiegoś raportu, którego wygenerowanie może zając 5 min. W takcie generacji użytkownik może prosić o informację na temat statusu operacji. Tutaj Durable Function bardzo sprytnie i krótko to załatwia.

Oczywiście wraz z takimi fajnymi możliwościami natykamy się na kilka zastrzeżeń, ograniczeń ale głównie one tyczą funkcji zarządzającej całym procesem a nie funkcji które są przez ten proces wywoływane. Ale ograniczenia są dość… zrozumiałe: brak możliwości while(true), lepiej nie robić Thread.Sleep, nie powinno polegać na danych generowanych jak nowe guidy czy daty (jest na daty specjalna prop) itp.. Chyba zrozumiałe ? :)

Jest to na razie beta albo może i alpha. Ale wygląda już ciekawie i już teraz można się z nią pobawić.  Więc jeżeli jedynym powodem dla których nie wchodziliście w Azure Functions były problemy które powyżej opisałem to już nie ma wytłumaczenia! :) Do dzieła :)

PS.: Kilka fajnych i działających przykładów znajdziecie na stronie dokumentacji dla projektu tutaj.