Trzecia odsłony serii o serverless. Jak ostatnio wspomniałem mam kłopot z BaaS na tyle, że dla mnie to nie serverless, a po prostu jakiś PaaS lub SaaS. Więc o nim już nie będzie. Teraz skoncentruję się nad tym co ogólnie i powszechnie uważane jest za Serverless – czyli Function as a Service (FaaS). Dziś przejdziemy pobieżnie przez dostępne rozwiązania w chmurach publicznych a za tydzień przez rozwiązania prywatne – jeżeli będzie to miało ręce i nogi. Jak nie to zaczniemy wchodzić w szczegółach określonych chmur i tego co nam oferują oraz jak nam to oferują.

Temat serveless Cię interesuje? Zapraszam na Kurs SERVERLESS - zapisz się być na bieżąco, otrzymać szczegóły kursu i dostać najlepszą ofertę!.

TL;DR

Mamy dużo możliwości, jeżeli chodzi o chmurę publiczną, każda oferuje funkcjonalność która połączona z ich produktami, tworzy ładną i jednolitą całość. Nie wszystkie jednak rozwiązania mają dobrze rozwinięty zestaw narzędzi i nie każde jest proste do zrozumienia. Czasami koszt wejścia (zrozumienia, konfiguracji) w daną chmurę może być kompletnie nie opłacalny od tego co chcemy osiągnąć. Albo może istnieć inny dostawca, który to zrobi BANALNIE prosto (patrz Azure, serio!).

Aktualnie na rynku możemy wyróżnić trzech dużych graczy i na pewno jednego małego. Zacznę więc od tego kto był pierwszy i od kogo reszta ściągała? Nie, źle powiedziane. Ale na pewno reszta nie chciała zostać w tyle. Czyli zaczynamy od Amazona. O AWS wyszło dużo więcej ale to dlatego, że AWS było pierwsze i kilka rozwiązań lub sposobu pracy z funkcjami powstało właśnie tam. Więc zamiast kopiować opisy czy też wystawiać przed nawias, zaznaczę które elementy tycza się wszystkich implementacji.

Uwaga do podsumowań

To są poglądowe wartości, nie wchodzą one w szczegóły każdego planu i dokładnych kalkulacji. W podsumowaniu linkuje do kalkulatora cen za wykorzystanie serverless który może się przydać przy liczeniu dokładniejszym. Czyli jeżeli piszę, że limit 1mln zapytań to taki limit jest, ale pewnie też jest limit na przesył danych, długości trwania funkcji itp. Do testów jednak to nie powinno mieć znaczenia.

Jeszcze notatka do: brak limitów. ZAWSZE są jakieś limity. Nie ograniczony internet też ma limit. Warto o tym wiedzieć.

Do tego czasami dochodzą różne plany – w jednym są takie ograniczenia w drugim takie. Ja założyłem przy tym wszystkim plan najbardziej opłacalny dla mnie i moich testów – czyli per wykorzystanie. TO NIE JEST podsumowanie które pozwoli wam podjąć biznesową decyzję o inwestowaniu 1 mln USD w chmurę! Jak masz 1mln USD to napisz do mnie, zrobimy z tym coś niesamowitego w tym i pomogę wybrać Ci chmurę.

AWS Lambda

AWS Lambda jest pierwszym rozwiązaniem dostępnym na rynku, jak się nie mylę to już od 2014 roku możemy tworzyć rozwiązania FaaS w oparciu o AWS. To co nas programistów .NET interesuje to wprowadzenie .NET Core i C# jako możliwego środowiska i języka tworzenia funkcji. Stało się to 2016 roku i jest to jedno z dwóch dostępnych rozwiązań na rynku gdzie możemy pisać w C#.

Jako, że lamda była pierwsza, zgarnęła rynek. Nie wiem czy mogę tak napisać, ale także przez to, że była pierwsza ustaliła sposób w jaki funkcje działają. Na jakiej zasadzie i kiedy funkcja jest wykonywana oraz jak jest liczony czas jej pracy. Ogólnie rozwiązanie hostowania mikro/nano aplikacji mija się z celem, jeżeli musimy za każdym razem pisać różnego rodzaje integrację z narzędziem/aplikacją – na przykład taka prosta rzecz jak wywołanie funkcji. Jeżeli jest ona wykorzystywana przez kilka rozwiązań, to w każdym musimy oprogramować połączenie do funkcji, wykonanie jej i zwrot danych. Co trochę mija się z celem. A jeżeli my musimy tworzyć zaawansowaną, ciężką aplikację, która będzie wywoływała wiele funkcji, to raczej mijamy się z celem serverless :)

Stąd też wprowadzenie triggerów czyli czegoś co wyzwoli naszą funkcję jak coś się stanie. Może to być CRUD na bazie, zapisanie pliku, logowanie do sytemu, odwołanie się do odpowiedniego HTTP Endpoint, pojawienie się nowego elementu w RSS. Tych wyzwalaczy jest masa. Zależy wszystko od tego co chcemy osiągnąć. Ale dzięki takiemu podejściu możemy projektować rozwiązania które nawet nie mają żadnego backendu a są aplikacjami SPA w pełni obsługiwanymi przez FaaS i wyzwalacze. Co dokładnie i jak jest to wyzwalane opowiem, kiedy indziej.

Dziś starczy wiedzieć, że AWS Lambda była pierwsza, jest dalej najbardziej popularna, można znaleźć masę informacji na jej temat w sieci.

Małe podsumowania AWS Lambda:

  • Wspierane języki: C# (dotent core), Java, JavaScript, Python – inne, przez możliwość wykonywania skompilowanych natywnych aplikacji na linuxa
  • Edytor w przeglądarce
  • Zależności załączane wraz z deploymentem
  • Maksymalny czas wykonania funkcji to 5 min
  • Automatyczna skalowalność
  • Nieograniczona liczba funkcji
  • 100 funkcji na raz wykonywanych per konto, per region (support może zwiększyć liczbę)
  • Funkcje są wersjonowane i zawsze można wrócić do poprzedniej wersji
  • Funkcje można łączyć za pomocą AWS Step Functions
  • Za pierwszy 1 milion zapytań nie płacimy, każdy kolejny milion to $0,20
  • Działa z .NET Core
  • Posiada tooling do deployment z poziomu .NET Core
  • Deployment za pomocą paczek zip
  • Deployment z poziomu przeglądarki

Google Function

Jak AWS zaczął mieć lambda to google nie mógł tego tak zostawić, więc zaczął pracować nad swoim rozwiązaniem. Mimo, że wypuszczone jako drugie wciąż jest w fazie beta.

Szczerze, na razie mogę tylko tyle powiedzieć, mimo, że google wie o mnie wszystko to jakoś mojej karty kredytowej jeszcze nigdy na oczy nie widział. Ale pewnie dla czystej ciekawości założę konto by dowiedzieć się więcej na temat platformy.

Na pewno fajne jest to, że dokumentacja jest moim zdaniem dobra, czytając wiadomo co można  czego nie można i jak to zadziała jak się poda kartę kredytową :) Szkoda jedynie, że rozwiązanie jest wciąż w wersji beta.

Małe podsumowania Google Functions:

  • Wspierane języki: JavaScript
  • Edytor w przeglądarce (tylko kodu dostępnego przez Cloud Source)
  • Zależności w postaci npm
  • Maksymalny czas wykonania funkcji to 9 min
  • Automatyczna skalowalność
  • 1000 funkcji per project
  • Brak limitów na wykonywanie funkcji równolegle
  • Wersjonowanie po repozytoriach i tagach
  • Brak możliwości łączenia funkcji
  • Za pierwszy 2 miliony zapytań nie płacimy, każdy kolejny milion to $0,40
  • Deployment z poziomy commend line
  • Deployment z poziomu przeglądarki

IBM OpenWhisk

Sprawa z OpenWhisk jest ciekawa ze względu na to, że to są dwie rzeczy i pewnie jak ktoś wam powie OpenWhisk to gruby ludzi zajmujących się chmura to każdy może to trochę inaczej zrozumieć.

Pierwsza rzecz, to taka, że OpenWhisk to platforma open sourcowa dostępna umożliwiająca tworzenie rozwiązań FaaS które będą reagowały na zdarzenia. Dosłownie, każdy może ją sobie pobrać i zainstalować lokalnie lub na dowolnej chmurze. IBM z tego co rozumiem oddał projekt OpenWhisk pod ikubator Apache i od tej pory wersja OS nazywa się Apache OpenWhisk (proszę poprawcie mnie).

Druga rzecz to hostwanie OpenWhisk w chmurze IBM Blumix. Jedno różni się od drugiego tym, że Blumix zawiera już po prostu zainstalowany i skonfigurowany produkt umożliwiający nam płacenie jedynie za czas wykonywania funkcji it. Przy czym opcja OSS wymaga postawienia tego na jakimś IaaS i płacenia dużo więcej za całość hostowania rozwiązania. Blumix zaś daje nam to za odpowiednio mniejszą cenę.

Małe podsumowania IBM OpenWhisk:

  • Wspierane języki: JavaScript, Python, Swift – inne, za pomocą docker
  • Edytor w przeglądarce
  • Zależności w postaci npm, nuget
  • Automatyczna skalowalność
  • Maksymalny czas wykonania funkcji to 5 min
  • Nieograniczona liczba funkcji
  • 1000 funkcji na raz wykonywanych per namespace
  • Brak wersjonowania funkcji
  • Funkcje można łączyć poprzez edytor kodu w przeglądarce
  • Z tego co rozumiem 500 zapytań za darmo, później się płaci
  • Deployment z poziomy command line + narzędzia np.: VS Code
  • Deployment z poziomu przeglądarki

Azure Functions

Microsoft dołączył dopiero w 2016 roku do grona dostawców dających FaaS. Jednak to co MS zrobił a innym się moim zdaniem nie udało, to prostota w jaki sposób można zacząć zabawę z funkcjami. Samo to, że aby stworzyć funkcję i się nią pobawić przez godzinę kompletnie, ale to kompletnie NIC nie potrzebujecie – zakładając, że macie konto w MS, google lub fb. Po prostu logujecie się i przez godzinę się bawicie jak chcecie. Żadnej rejestracji, żadnego podawania karty kredytowej. TO JEST SUPER.

Do opcji Try, dochodzą darmowe wyzwania, które możemy wykonać by lepiej poznać funkcje na Azure. Jak dla mnie dużo na plus. Zresztą, powinna być metryka: od pomysłu do dostarczenia. Żaden inny dostawca tutaj się z MS nie równa :)

Poza tym, funkcje są dość nowym nabytkiem Azure, ale są coraz silniej rozwijane i bardzo duży nacisk jest na nie kładziony, no i w najbliższych miesiącach będzie dużo zmian i dodatków. Warto więc TEGO gracza znać :)

To co mi się nie podoba, to wsparcie dla C# jako scriptcs. Zobaczymy jak się pojawi tooling. Osobiście próbowałem się nie raz do scriptcs przekonać i ani razu mi się nie udało. Choć może właśnie dlatego, że brakowało mi czegoś takiego jak functions? zobaczymy!

Podobno można normalny kod C# deployować (komentarz pod postem). Będę to weryfikował za tydzień/dwa. Na razie wszystko co widzę jak i opisy toolingu mówią o scriptcs.

Małe podsumowania Azure Functions:

  • Wspierane języki: C# (scriptcs + pure), F#, JavaScript, Batch, Bash, PHP, PowerShell
  • Edytor w przeglądarce
  • Zależności w postaci npm, nuget
  • Automatyczna skalowalność
  • Maksymalny czas wykonania funkcji to 5 min
  • Nieograniczona liczba funkcji
  • Brak limitów na wykonywanie funkcji równolegle
  • Wersjonowania funkcji po branchach/tagach w repozytorium
  • Funkcje można łączyć za pomocą Azure Logic Apps
  • Za pierwszy 1 milion zapytań nie płacimy a później to kombinacja wykorzystanych zasobówów i liczby zapytań
  • Aktualnie brak toolingu dla najnowszej wersji SDK
  • Deployment z poziomu przeglądarki

Webtasks

Dodałem Webtask bo jest to ciekawe rozwiązanie dostarczone przez Auth0. Jest to ciekawe z kilku powodów. Jednym z nich jest to, że jest on dostępny jako dodatek do Auth0 i rozwijany przez Polaka Tomka Janczuka – twrócę Edge.js umożliwiającego wykonywanie kodu C# z poziomu JavaScipt. A to znaczy, że i tutaj mamy możliwość pisania w C# jak potrzebujemy.

Projekt bardzo ciekawy i sam jestem zainteresowany dalszym jego rozwojem. No i marketing działa :) w sensie, wiedziałem o google, amazon i ms. IBM się domyśliłem. Ale o Webtask wiedziałem od samego początku jak tylko było to już public. Może to przez twittera a może przez to, że akurat zajmowałem się sprawami w okół Auth0 więc siłą rzezy o tym wiedziałem. Tak czy siak, wiedziałem na tyle by zamieścić to tutaj :)

Dużo jest niewiadomych w funkcjach, choć to wina w jaki sposób aktualnie dawana jest opcja Webtask – jako część czegoś większego. Jeżeli jednak macie jakieś informacje na temat tej chmury to dajcie znać, z chęcią zaktualizuje poniższe dane.

  • Wspierane języki: JavaScript, C#, T-SQL (tak wiem… no ale może być)
  • Edytor w przeglądarce
  • Brak informacji o skalowaniu
  • Brak informacji o czasie wykonania
  • Brak informacji o liczbie funkcji
  • Brak informacji o limitach wykonywania funkcji równolegle
  • Brak informacji o wersjonowaniu
  • Funkcje można łączyć za pomocą edytora w przeglądarce
  • Brak informacji o cenie – albo ja tego nie potrafiłem znaleźć. Cena jest powiązana z usługą Auth0 i WebTask są dawane jago bonus do na przykład darmowego planu.
  • Deployment z poziomu command line
  • Deployment z poziomu przeglądarki

Podsumowanie

Co do tych cen, na trochę googlałem sprawdzałem, ale jakoś nie potrafię tego chyba zbytnio pojąć. Dlatego też może się wam przydać kalkulator cenowy jaki znalazłem. Na przykład mi w tym kalkulatorze wychodzi, że OpenWhisk byłby za darmo do ponad 3 mln zapytań.

Czy to są wszyscy dostawcy? Nie, na przykład jest coś takiego jak IronFunctions, Funktion czy Fission. I to pewnie też nie wszystkie dostępne na rynku. Jednak te najbardziej popularne lub te które najczęściej spotykam to te które starałem się pokrótce podsumować.

To tyle jeżeli chodzi o pobieżne przejście przez dostępnych dostawców za tydzień zacznę pisać już bardziej konkretniej. Do przeczytania, jutro jak i za tydzień :)

8 KOMENTARZE

  1. Bardzo fajne podsumowanie. Zdecydowanie potrzebne, bo zainteresowanie FaaSem jest obecnie bardzo duże.
    W związku z tym, że bawię się trochę Azure Functions, nasuwa mi się kilka uwag do Twojego podsumowania:
    Wspierane języki: C# (scriptcs)… – Nie tylko csx. Grupa produktowa rekomenduje, by do zastosowań na produkcji używać “precompiled functions”.
    Maksymalny czas wykonania funkcji to 5 min – Ten limit ma zastosowanie tylko w Consumption plan.
    Brak limitów na wykonywanie funkcji równolegle – Istnieją load testy opisane na blogach, które wykazują pewne ograniczenia przy większych obciążeniach
    Brak wersjonowania funkcji – wersjonowanie w repo i CI/CD danego builda, nie wyobrażam sobie robić to inaczej.
    Za pierwszy 1 milion zapytań nie płacimy a później to kombinacja wykorzystanych zasobów i liczby zapytań – Kombinacja ilość wywołań + MB/sekundy ma zastosowanie również w bezpłatnym przydziale.
    Aktualnie brak toolingu – jest ale bardzo słaby pod VS2015, jest również pod NodeJs. Tooling pod vs2017 zbliża się wielkimi krokami
    Deployment z poziomu przeglądarki – Klasyczny WebDeploy też daje radę (są też inne opcje np. KUDU).

    • dzieki, o C# pure nie slyszalem, dobrze wiedziec! Kilka info

      Co do limitow- to tak, w zależności od planu, ale tam dużo zależny od planów. zakładam (czego nie napisałem) plan per wykorzystanie a nie sub.

      Co tyczy “brak limitów” to jak ze wszystkim. Brak jest do jakiegoś pułapu, to ja rozumiem samo przez się :)

      Z wersjonowaniem nie dodałem, że repo? to już dodam.

      Tak, kombinacje mają zastosowanie przy darmowych. Ale tak jest dla każdego z dostawców. więc chyba lepiej przyjąć prostą metrykę a wrazie co szczegóły to już można doczytać. Chciałbym mieć apkę co nawala co przekroczy chociaż jeden z tych limitów miesięcznie :) Ale masz rację warto wspomnieć (aktualizacje), że tam są jeszcze dodatkowe parametry.

      Toolingu brak dla najnowszej wersji SDK niezależnie od VS. Nie patrzę w dane historyczne.

      O webdeploy nie wiedziałem, dzięki. do innych opcji nie odwołuje bo bym wszędzie musiał pisać o wszystkich możliwych kombinacjach.

  2. Muszę się zgodzić, że kiedy mówimy o FaaS intuicyjnie upraszczamy, że chodzi o plany za wykonania, a nie z zadeklarowaną infrastrukturą. To drugie burzy w pewnym sensie koncepcję :)

    Co do wersjonowania, to są dwa aspekty:
    – Możemy zakodować nową wersję, wrzucić do repo, CI/CD, webdeploy i mamy nową wersję “na produkcji”. Zawsze możemy wrócić do poprzedniej – jak w klasycznym podejściu do API/Web.
    – Możemy również wersjonować nasze API mając kilka funkcji np v1/v2/latest online. Możemy do tego użyć Azure Function Proxy i przepisywać requesty do wersji w zależności od ścieżki,parametrów query string, nagłówków itp. Wkrótce też będzie integracja z API Management, a to otwiera wiele nowych możliwości.

  3. Usiłuję wpasować firmowe oprogramowanie oparte o microserwisy w serverless, ale ni jak mi to nie wychodzi.
    Serwerless uzależniasz się od konkretnego dostawcy usługi, cholera wie co się dzieje z kodem który deployujes (czy ktoś to dekompiluje itp.) Gdzie w tym wszytkim bezpieczeństwo?
    Przechowywanie danych o klientach – nie ma szans, nie wiadomo gdzie to idzie i co się z tym dzieje.

    • chyba masz ogolą awersję do chmury. Jednak tutaj się mylisz dane w chmurze są bardziej bezpieczne niż te u Ciebie. Do tego Azure (nie wiem jak AWS) ma certyfikaty pozwalające trzymać dane różnych państw jak i banków -> https://azure.microsoft.com/en-us/overview/trusted-cloud/

      To się tyczy zarówno danych jak i tego kto niby dekompiluje Twój kod. Zresztą przy node js nawet nie ma dekompilacji.

      implementacja jest uzależniona od chmury – przynajmniej podstawowe api. przy node js niczym się za bardzo więcej nie przejmujesz. Przy C# jest gorzej. Jednak deployment można wyciągnąć przed nawias chociażby frameworkami serverless.

      Prędzej z hackują serwer lokalny i wykradną dane niż chmurę. Zresztą, przy GDPR ja nawet bym nie próbował trzymać danych personalnych u siebie… o nie :)

Comments are closed.