Cloud Functions

Odpowiedz Nowy wątek
ret
2020-06-29 13:48
ret

Rejestracja: 3 tygodnie temu

Ostatnio: 13 godzin temu

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?

Pozostało 580 znaków

2020-06-29 15:04
Moderator

Rejestracja: 16 lat temu

Ostatnio: 52 minuty temu

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? :)


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
tak, dzięki za odpowiedź - ret 2020-06-29 16:30

Pozostało 580 znaków

2020-06-29 16:38

Rejestracja: 2 lata temu

Ostatnio: 16 godzin temu

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.

Pozostało 580 znaków

2020-06-29 16:46
Moderator

Rejestracja: 16 lat temu

Ostatnio: 52 minuty temu

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 ;)


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
edytowany 1x, ostatnio: Shalom, 2020-06-29 16:46

Pozostało 580 znaków

2020-06-29 16:53

Rejestracja: 2 lata temu

Ostatnio: 16 godzin temu

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.

Pozostało 580 znaków

2020-06-29 17:30
Moderator

Rejestracja: 12 lat temu

Ostatnio: 16 godzin temu

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.


Pozostało 580 znaków

2020-06-29 17:33

Rejestracja: 2 lata temu

Ostatnio: 16 godzin temu

0

Utrzymanie przesunięte w które miejsce?

Pozostało 580 znaków

2020-06-29 21:54

Rejestracja: 3 lata temu

Ostatnio: 4 godziny temu

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.

edytowany 1x, ostatnio: MuadibAtrides, 2020-06-29 21:58

Pozostało 580 znaków

2020-06-30 10:38
Moderator

Rejestracja: 12 lat temu

Ostatnio: 16 godzin temu

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.


Architektura to nie jest utrzymanie, nie wiem co to za nowe teorie. Monitorujesz działanie kodu a nie serwerów i o to chodziło w braku utrzymania przy serverless - ralf 2020-06-30 11:12
@ralf: utrzymanie aplikacji to całość. Serwery też monitorujesz, a nawet przy monitorowaniu samej aplikacji jest trudniej, bo trzeba zaplanować rozproszony tracing, który wcale nie jest łatwy. - hauleth 2020-06-30 11:29
serverless = brak serwerów = brak utrzymania serwerów (maszyn) i serwerów aplikacji (np node). Tyle i aż tyle, kod utrzymujesz to chyba oczywiste, różnice w architekturze, dostępu do logów oczywiście są. Nigdzie nie pisałem że nie trzeba utrzymywać kodu. - ralf 2020-06-30 12:57
serverless != brak serwerów, serverless == serwery nad którymi nie masz kontroli. A zgodnie z prawem cieknących abstrakcji prędzej czy później będzie problem, który będzie trzeba rozwiązać, a który będzie związany z tym, że "gdzieś pod spodem" jednak jest serwer. - hauleth 2020-06-30 13:59
@hauleth Miałeś problem z tego typu usługą czy tylko teoretyzujesz? - ralf 2020-06-30 14:06
Ja miałem problemy z ograniczeniami, sandboxem serwerów, czy choćby tym, że i tak musisz zdefiniować CPU i RAM więc czasem trzeba podkręcić te maszyny - MuadibAtrides 2020-06-30 15:27

Pozostało 580 znaków

2020-06-30 15:06

Rejestracja: 12 lat temu

Ostatnio: 44 minuty temu

0

Polecam ten odcinek Patoarchitektów: https://open.spotify.com/epis[...]qoG?si=Wg5CGvUDTASA-VUPWFoMcQ


IT menedżer

Pozostało 580 znaków

2020-07-02 20:02

Rejestracja: 5 lat temu

Ostatnio: 19 minut temu

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)

edytowany 6x, ostatnio: OtoKamil, 2020-07-02 20:07

Pozostało 580 znaków

Odpowiedz

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