[koziolek666]

FaaS, czyli funkcje jako serwisy. Czy będziemy światkami tego rodzaju rewolucji?

http://koziolekweb.pl/2016/04/29/faas-czyli-jak-nisko-mozemy-zejsc-z-delegacja-kodu/

#koziolekweb #programowanie

[tell_me_more]

@koziolek666: serializacja/deserializacja parametrów zeżre cały zysk z równoległości. Do tego takie coś wykorzystywałoby pamięć w bardzo nieefektywny sposób (ładuje coś na chwilę, raz używa, wywala). GC by działało non-stop.

Lepsze jest IMHO podejście erlangowe - miliony pseudowątków na każdym fizycznym komputerze, i tam w 99% czyste funkcje, ale przekazywanie danych jest po prostu przekazaniem wskaźnika.

Albo podejście np clojure - czyli współdzielenie pamięci przez używanie trwałych (persistant) struktur danych - czyli

[koziolek666]

serializacja/deserializacja parametrów zeżre cały zysk z równoległości.

@tell_me_more: tego bym się nie obawiał, bo całość pracuje na danych, które już są przygotowane do obróbki. Co więcej w przypadku AWS Lmabda można to integrować ze storagem w ich chmurze.

[tell_me_more]

@koziolek666: chmura to nie magia, też trzeba te dane przesyłać przez sieć i deserializować.

Różnica pomiędzy pobraniem informacji z RAM (już nawet nie mówiąc o cache), a pobraniem liczby z innego serwera jest kilka rzędów wielkości. Jeśli pomiędzy każdym wywołaniem funkcji będziesz miał przejście przez sieć - to całość będzie kilka rzędów wielkości wolniejsza (bo zwykle sam dostęp do pamięci jest wąskim gardłem, a tutaj go jeszcze np 100 razy spowalniasz).

[koziolek666]

@tell_me_more: źle na to patrzysz. Jeżeli masz duży system to dane i tak pobierasz z innej maszyny np. z bazy danych. Zatem nie masz ich w RAMie. Takie rozwiązania są dobre w przypadkach gdy

1. Masz "piki" obliczeniowe i utrzymanie własnej infrastruktury zdolnej je wytrzymać nie ma sensu.
2. Analizujesz i obramiasz duże ilości danych, których i tak nie utrzymasz w RAMie pojedynczej maszyny.

Co więcej możesz mieć przecież dane upchnięte