Cloud Functions

0

Krótkie pytanie, ponieważ nie mam absolutnie doświadczenia w serverless chciałbym poznać mniej więcej powody, które sprawiają, że ten kierunek ma sens. Mogą to być powody biznesowe, powody technologiczne, lub inne o ile rzeczywiście wyjaśniają trend tworzenia takich rozwiązań. Chcę zrozumieć tylko powody jakie idą za tą idea. Nie chcę analizować jaka rzecz jest najlepsza z najlepszych.

Obecnie myślę, że tu bardziej chodzi o uzupełnienie rozwiązań zorientowanych na IO np. elixir, node. W tych jezykach najsłabszym punktem jest mielenie danych na większą skalę i to może być powód, dla którego potrzebna jest furtka do łatwego integrowania rzeczy wymagających nacisku na CPU.

Mimo to zastanawiam jaką różnicę robią te Functions.

Przecież nikt nikomu nie zabrania, można napisać własny serwis np. w go / C++ / Rust, który również wystawia API po http lub przez kolejkę i po prostu mieli nadchodzące zadania.

Pod jakim kątem te Functions są lepsze? Są bardziej skalowalne w stylu, że 1 wywołanie funkcji == 1 proces, i chodzi o to, że tych procesów może byc multum (pod warunkiem, że jest na to hajs).

Czy może chodzi o to, że pisanie serwisów w C++ / go / Rust - jest żmudne, niewygodne i że z Functions to nie trzeba się tym przejmować, bo tego typu rzeczy to Firebase weźmie na siebie. Ty jako programista myślisz wtedy tylko o kodzie do obliczeń.

Czy moze chodzi po prostu o to, ze w Firebase rozwiązanie łatwiej przekształcić na skalę globalną i że część workerów może być w jednym regionie, a część w drugim?

A może chodzi o to, by redukować koszt samej maszyny. Tzn raz na 3 godziny leci jakieś zadanie masz 15 min, to wtedy koszt tego to 15 min, a nie 3h, przez co w długofalowej perspektywie nie trzeba przywiązywać się do lepszych maszyn?

2

Chodzi ci o coś jak AWS Lambda? Ma to sens np. jeśli coś dzieje się tylko raz na jakiś czas. Po co chcesz płacić za instancje aplikacji która 99% czasu nic nie robi? :)

0

Tak koledze chodzi o FaaS czyli zarówno AWS lambda i Firebase Functions.
Z zalet to skalowalność, nie masz dostępu do serwera - nie musisz go utrzymywać. Co do regionów to możesz mieć instancje na całym świecie pytanie co z bazą danych czy też jest rozproszona.

2

Z zalet to skalowalność, nie masz dostępu do serwera - nie musisz go utrzymywać. Co do regionów to możesz mieć instancje na całym świecie pytanie co z bazą danych czy też jest rozproszona.

? Ale to są zalety dowolnego clouda/PaaS i nie potrzeba do tego serverless żadnego. Postawić instancje na AWSie w różnych regionach to nie problem, utrzymywać serwerów też nie musisz ;)

0
Shalom napisał(a):

Z zalet to skalowalność, nie masz dostępu do serwera - nie musisz go utrzymywać. Co do regionów to możesz mieć instancje na całym świecie pytanie co z bazą danych czy też jest rozproszona.

? Ale to są zalety dowolnego clouda/PaaS i nie potrzeba do tego serverless żadnego. Postawić instancje na AWSie w różnych regionach to nie problem, utrzymywać serwerów też nie musisz ;)

Nie do końca, musisz utrzymywać serwer node czy cokolwiek podobnego, robić security patche itd. Tak samo skalowalność, nawet jak masz autoscaling, zanim nowa maszyna (wirtualna) wystartuje mogą minąć minuty. W serverless jest całkowity brak utrzymania, okienek serwisowych itp. Zakres skalowania jest dużo większy i praktycznie natychmiastowy.

1

W zamian masz zdecydowanie większy poziom skomplikowania architektury, trudniejsze debugowanie, oraz wyższe koszty. I z tym "całkowitym brakiem utrzymania" to bym nie galopował za bardzo, bo dalej masz, ale przesunięty w inne miejsce.

0

Utrzymanie przesunięte w które miejsce?

2

Firebase cloud functions per se nie wychodzą taniej niż inne skalowalne zarządzane usługi w GCP bazujące na deploymencie samego kodu.
Cloud functions mają niski darmowy limit godzin CPU i memory. Struktura tych cloud functions nie pozwala na tak łatwe zarządzanie kodem jak np. w przypadku aplikacji Djangowej / Springowej / itp - po prostu to jest plik ze zbiorem funkcji.

Jak już potrzebujesz serverless w GCP to masz AppEngine (skalowanie do 0 maszyn) - tutaj tylko musisz owrapować swój kod w jakiś framework HTTP i dopisać yamla.

Cloud Run - serwis do wrzucenia obrazów dockerowych i też będzie skalować do 0.

Po co się je stosuje? Bo mają niższy narzut wejścia i czasem nie potrzebujesz pisać całego serwisu, czy używać frameworka a czasem potrzebujesz zrobić jedną małą rzecz, czyli wywołać funkcję.

Np. wrzucasz zdjęcia do storage'u w GCP i chciałbyś dla każdego nowego zdjęcia uruchomić wykrywanie czy zdjęcie nie zawiera treści 18+. Masz notyfikacje w GCP, ale ktoś musi je obsłużyć - po co stawiać serwer i pisać tam jakikolwiek rest, get, post itp, jak tylko potrzebujesz strzelić tymi wrzuconymi zdjęciami do API wykrywania 18+ i jak jest be, to usunąć zdjęcie a jak jest OK to nic nie robić - taki glue code, który potrzebuje paru linijek i 1 funkcji i nic więcej - do czegoś takiego nadaje się cloud functions.

Kolejny powód to jak musisz wyrzeźbić na szybko jakiś prototyp.

Też łatwiej jest wytłumaczyć pewnym osobom kwestię napisania tych funkcji zamiast całego kodu serwerowego.

Cokolwiek co będzie przypominało zbiór API / aplikację automatycznie u siebie w firmie wyrzucamy z cloud functions do normalnego frameworka i piszę normalną aplikację - głównie z powodu utrzymaniowego kodu i przeglądania kodu oraz wygody programisty.

Już nie wspominając, że cloud functions mają przeważnie gorsze wsparcie z IDE niż popularne frameworki.

3
ralf napisał(a):

Utrzymanie przesunięte w które miejsce?

Architekturę oraz monitorowanie. Początkowo łatwo jest pisać sobie te funkcje, ale jeśli się przesadzi, to może się okazać, że otrzymamy nieutrzymywaną kulę błota, gdzie nikt nie wie co się tak naprawdę dzieje i każdy się boi usunąć coś z kodu, bo nie wiadomo jakie będą konsekwencje. Podobnie jest jak się przesadzi z mikroserwisami.

1

W naszym projekcie mamy część flow napisaną w Lambdach AWSowych, część jako apki Javowe. Powód? Mamy na przykład dość zmienny ruch na wejściu (klienci nie zawsze będą ostrzegać przed dużą kampanią reklamową) i nie chcemy tracić wiadomości, które taka lambda wystawiona przez API zbiera do kolejki (SQS, do tego dodajemy jakieś metadane do wiadomości), a dalej mogą być obsłużone z niewielkim opóźnieniem. No i jak wspomniałem: najważniejsze dla nas to nie stracić wiadomości, a to czy będą obsłużone w 100ms czy 5-10s nie robi aż takiej dużej różnicy w naszym przypadku (bo to zazwyczaj kilkunastominutowy peak). Problem skalowania API mieliśmy z głowy już na samym początku projektu, klient oszczędził sporo hajsu kiedy nie mieli nawet jeszcze żadnego ruchu. Koszty są na klientach naszego klienta (płacą za każdą wiadomośc)
Poza tym jest to też przydatne w trakcie przenoszenia się z kilku instancji stojących na sztywno na k8s (które u nas niesamowicie długo się ciągnie).
Monitorowanie - cloudwatch (logi), xray (śledzenie którędy wiadomości przelatują przez inne lambdy/javy)

1 użytkowników online, w tym zalogowanych: 0, gości: 1