Po wpisach o App Serwice Planie oraz Web Appach, dzisiaj zajmiemy się Azure Functions. Funkcje jak to funkcje umożliwiają operację na danych wejściowych i opracowanie danych wyjściowych. Z wykorzystaniem Azure functions możemy tworzyć całe systemy. Jeśli mamy proste api do wykonania lub inny processing danych warto rozważyć wykorzystanie funkcji.
Funkcje są skalowane automatycznie, przez co, przy rozliczeniach zgodnie z wykorzystaniem jesteśmy w stanie oszczędzać. Nie płacimy za zasoby, kiedy funkcje nie są wykorzystywane oraz poprzez skalowanie możemy obsłużyć szczyt wykonań (nie płacąc za nadmiarowe zasoby).
Hostowanie i rozliczenia
Funkcje niby są serverless, czyli bez wykorzystania serwera 🙂 ale czy tak musi być ? Otóż nie do końca. W przypadku funkcji do wyboru mamy 3 sposoby hostowania i rozliczania naszych funkcji. Każda funkcja musi posiadać dostęp do Storage Accounta (czym to jest opowiem w innym wpisie) jednak jego kosztów nie będę brał tutaj pod uwagę.
Na podstawie zużycia (consumption plan)
To chyba podstawowa forma hostowania i rozliczania funkcji. Opłaty naliczane są za tak zwane GB-s (gigabajto sekund) oraz ilości obsłużonych wykonań. W tym przypadku mamy pewną pulę przydziału. Możemy wykorzystać w miesiącu 400k GB-s oraz 1mln wykonań. Ale czym są te tajemnicze GB-s? O tuż jest to suma czasu wszystkich wykonań i wykorzystanej do wykonania pamięci.
Jeżeli założymy, że mamy mały system i miesięcznie wykonujemy 300 operacji przy czym każda z nich zajmuje 10s i zajmuje 0.5GB pamięci, to wykorzystujemy 300*10*0.5 = 1500 GB-s i dalej mieścimy się w bezpłatnym przydziale. Jeśli zamiast 300 operacji będziemy mieli 3mln operacji to zapłacimy za wszystkie GB-s powyżej przydziału oraz za wszystkie wykonania powyżej przydziału.
Tak hostowana funkcja jest idealna dla małych lekkich zadań, które są szybkie i nie wymagają dużej ilości zasobów a także czasu wykonania. Nie chodzi mi tu o koszty a o ograniczenia czasu pojedynczego wykonania ustalonego na maksymalnie 10 minut. Przy planie tym musimy także pamiętać, iż nie mamy dostępu do wirtualnej sieci prywatnej oraz, że funkcja po czasie nie aktywności może zostać wyładowana i następne wykonanie będzie się wiązało z Cold Startem.
Premium plan
Jeśli wymagamy czegoś więcej to jest to plan dla nas. Przez coś więcej mam na myśli:
- dłuższego wykonywania (w tym planie nie ma maksymalnego czasu wykonania)
- większych zasobów
- dostępu do wirtualnej sieci prywatnej
- nie możemy sobie pozwolić na cold start
W tym wypadku mamy zawsze dostępną jedną jednostkę hostingową (wirtualny procesor i przydzieloną pamięcią) i za takie jednostki hostingowe płacimy. Niestety z racji na to, iż zawsze musimy mieć jedną jednostkę aktywną płacimy za naszą funkcję cały czas. Opcja ta może być tańsza, jeżeli wykorzystujemy bardzo dużo szybkich wykonań, gdyż przy tym planie nie są one liczone.
Plan Dedykowany, ASE oraz Kubernetes
Połączyłem te 3 sposoby hostowania funkcji w jeden punkt, gdyż dla mnie odnoszą się one do jednego. Hostujemy funkcje w dobrze nam znanym środowisku. Czy to app service plan, gdzie funkcja jest kolejną aplikacją działającą na planie, czy też kolejną aplikacją na klastrze kubernetesa. Te typy hostowania dają nam największą kontrole nad zasobami ale też są jednymi z droższych. Jednak możemy spróbować dodać ją do już istniejących instancji, co pozwoli nam być może zaoszczędzić.
Wykonania triggery i bindingi
Trigger zapoczątkowuje wywołanie funkcji i to od niego zależy kiedy i dlaczego zostanie ona wywołana. Bindingi określają do jakich zasobów bezpośrednio funkcja przy wykonaniu ma dostęp. Azure Finctions są dobrze zintegrowane z innymi zasobami w chmurze Azure, przez co zasoby te mogą być łatwo wykorzystywane jako triggery, wejścia lub wyjścia danych. Wszystkie dostępne triggery znajdziesz w dokumentacji dostępnej tutaj, ja z tej listy wybrałem dla mnie najważniejsze i najczęściej wykorzystywane.
Http trigger
Chyba nie trzeba tego tłumaczyć, normalny endpoint dla http umożliwiający odpowiedź na requesty http. Może działać jako normalny endpoint dla Api czy jakiegoś prostego serwisu (np. logowanie zdarzeń)
Blob Storage trigger
Trigger uruchamiany dodaniem zmianą na blob storagu (dodanie lub update plików). Wykorzystane może być jako logowanie, kiedy został zmieniony/dodany plik lub też do przetwarzania nowych plików. Do systemu możemy dostarczyć pliki do jednego Blob Storaga po czym nowe pliki przetworzyć i zapisać w nowym storagu dzięki zastosowaniu bindingów. Dzięki takiej konstrukcji możemy zrobić wieloetapowe przetwarzanie danych z plików wejściowych (validacja -> import -> import2).
Queue Storage,Service Bus oraz Kafka
Dla mnie to podobna funkcjonalność tylko dla różnych zasobów. W obu przypadkach triggerem jest jakiś rodzaj kolejki. Dla mnie wykorzystanie przy systemach, gdzie różni producenci zewnętrzni komunikatów wrzucają nam dane do kolejki i my musimy na nie reagować.
Timer
To chyba najczęściej wykorzystywane przynajmniej przeze mnie rodzaj triggera. Czas w formacie podobnym do Crona (z dodatkowym parametrem na sekundy) możemy określić, kiedy nasze zadanie ma zostać wykonane (tutaj mały przypis określamy czas, kiedy zadanie powinno zostać wykonane ale nie mamy na to 100% gwarancji, czas w którym zadziała nasz trigger, może on być nieco opóźniony).
Wykorzystanie chyba we wszystkich systemach raportowych, które do tej pory robiłem. Zadania triggerowane o konkretnej porze każdego dnia lub raz w tygodniu generujące raporty dla biznesu.
Czytaj więcej
To tylko drobny wycinek, jeśli chodzi o Azure functions. Takie najważniejsze elementy, które warto znać. Do samych funkcji na pewno jeszcze wrócę z dosyć obszernym tematem Durable Functions ale o tym na pewno nie teraz. Jeśli masz ochotę zgłębić temat bardziej :