Igazából semmiben, ez a Google konkurens megoldása. Annyiban még korlátozottabb is, hogy csak JS-ben írhatod a függvényeket. Amiért viszont annyi mobil fejlesztő örül neki, hogy integrálják a Firebase-el, amit nagyon nyom most a Google, és nagyon jó az androidos támogatottsága. Mondhatni a Firebase a hivatalos (ajánlott) android backend megoldás. Eddig én is Lambda-ra gondoltam portolni a szerver oldalunk bizonyos részeit, de így már érdemes újragondolni a dolgokat.
Csaba Sári A lambda egy általánosabb valami. Mondjuk ezt a wrappelt Go-t még nem olvastam. Viszont megvan a Google JS only megoldásának is az az előnye, hogy valszeg nagyon ki van hegyezve az architektúra a V8-ra, meg gondolom a V8-ból is valami saját variáns fut, ami erre van kihegyezve. Horváth Gyula Most nagy divat lett ez a serverless architektúra, megfelelő tervezéssel szerintem bármilyen szerver oldali funkcionalitás kiváltható vele. Nálunk pl. már régóta úgy néznek ki a weboldalak, hogy mindent kliens oldalon generálunk JS-el, így a szerverrel csak adatkommunikáció megy úgy, mint egy mobil vagy egy desktop alkalmazás esetén. Így van egy viszonylag szűk, csak program logikát tartalmazó rész a szerveren, amit egy REST API-n lehet elérni. Ezek a cloud function megoldások (Google Cloud Functions, AWS Lambda, Azure-nak is van valamije) arra mennek rá, hogy ha betartasz pár szabályt, akkor leveszik a válladról a teljes szerver menedzsment terhét. A pár szabály igazából annyi, hogy szedd szét a szervered funkcionalitását önálló modulokra a funkció mentén, és a modulok legyenek állapotmentesek. Ezek a külön kis modulok a szerver oldali funkciók, amit tudsz futtatni. Ezeket feltöltöd szépen, és utána mindent intéz a felhő. Mindig annyi erőforrást allokál alá, amennyit kell. Nálunk olyan funkciók vannak, hogy telefon regisztrálása, ha küldesz valakinek egy üzenetet, és az megkapja, visszaszól a telója a szerverre, aminek vissza kell szólni a küldőnek, hogy megjött az üzi, ha lement egy interaktív üzenet, a user válaszait be le kell tárolni, stb. De ide elképzelhetsz bármilyen funkcionalitást. Jelenelg van 2 szerverünk clusterben, egyfelől a terhelés elosztás miatt, másfelől a biztonság miatt, hogy ha az egyik kidől, ott a másik. Fizetünk rájuk mondjuk 20 ezer Ft-ot (nemtom pontosan mennyit) havonta, és az idejük 99%-ban nem csinálnak semmit. Totál felesleges, de szerver kell, és legalább 2 a redundancia miatt. Ráadásul ha valami isteni csoda folytán bejönne valami terhelés cunami, akkor hiába a 2 szerver, ledöntené a lábáról a rendszert. Ha áttérünk Lambda-ra (vagy Google Cloud Functions-ra), akkor a funkció futások után fizetünk. Ha egy hónapig nem történik semmi, akkor nem fizetünk semmit, ha meg hirtelen beindul valami, és egyszerre 100 000-en akadnak rá a szerverre, akkor sincs baj, az Amazon (v Google) felhúz alá hirtelen 10 szervert, kiszolgálja a kéréseket, aztán lelövi őket. De a dolog teljesen transzparens. Te csak a futások után fizetsz, nem kell vele foglalkoznod, hogy mi történik alatta. Baromi kényelmes dolog.
Egy korábbi cégnél pl. SVG rasterizert futtatunk Lambdán Javaban. De pl. arra is használom, hogy ha API gateway + lambda + sqs mögött, akkor nem kell a szervernek 100%-os uptime, elég ha időnként letölti a queue-ból az üzeneteket és reagál rá. (pl. hírlevél feliratkozás)
Nem igazán világos nekem, miben különbözik az AWS Lambda-tól...
VálaszTörlésIgazából semmiben, ez a Google konkurens megoldása. Annyiban még korlátozottabb is, hogy csak JS-ben írhatod a függvényeket. Amiért viszont annyi mobil fejlesztő örül neki, hogy integrálják a Firebase-el, amit nagyon nyom most a Google, és nagyon jó az androidos támogatottsága. Mondhatni a Firebase a hivatalos (ajánlott) android backend megoldás. Eddig én is Lambda-ra gondoltam portolni a szerver oldalunk bizonyos részeit, de így már érdemes újragondolni a dolgokat.
VálaszTörlésAz megvan, hogy már Go-t is lehet wrappelve futtatni Lambdán?
VálaszTörlésMegkérdezhetem, hogy milyen funkciókat futtatok a szerverem? Mire használjátok?
VálaszTörlés#follow
VálaszTörlésCsaba Sári A lambda egy általánosabb valami. Mondjuk ezt a wrappelt Go-t még nem olvastam. Viszont megvan a Google JS only megoldásának is az az előnye, hogy valszeg nagyon ki van hegyezve az architektúra a V8-ra, meg gondolom a V8-ból is valami saját variáns fut, ami erre van kihegyezve.
VálaszTörlésHorváth Gyula Most nagy divat lett ez a serverless architektúra, megfelelő tervezéssel szerintem bármilyen szerver oldali funkcionalitás kiváltható vele. Nálunk pl. már régóta úgy néznek ki a weboldalak, hogy mindent kliens oldalon generálunk JS-el, így a szerverrel csak adatkommunikáció megy úgy, mint egy mobil vagy egy desktop alkalmazás esetén. Így van egy viszonylag szűk, csak program logikát tartalmazó rész a szerveren, amit egy REST API-n lehet elérni. Ezek a cloud function megoldások (Google Cloud Functions, AWS Lambda, Azure-nak is van valamije) arra mennek rá, hogy ha betartasz pár szabályt, akkor leveszik a válladról a teljes szerver menedzsment terhét. A pár szabály igazából annyi, hogy szedd szét a szervered funkcionalitását önálló modulokra a funkció mentén, és a modulok legyenek állapotmentesek. Ezek a külön kis modulok a szerver oldali funkciók, amit tudsz futtatni. Ezeket feltöltöd szépen, és utána mindent intéz a felhő. Mindig annyi erőforrást allokál alá, amennyit kell. Nálunk olyan funkciók vannak, hogy telefon regisztrálása, ha küldesz valakinek egy üzenetet, és az megkapja, visszaszól a telója a szerverre, aminek vissza kell szólni a küldőnek, hogy megjött az üzi, ha lement egy interaktív üzenet, a user válaszait be le kell tárolni, stb. De ide elképzelhetsz bármilyen funkcionalitást. Jelenelg van 2 szerverünk clusterben, egyfelől a terhelés elosztás miatt, másfelől a biztonság miatt, hogy ha az egyik kidől, ott a másik. Fizetünk rájuk mondjuk 20 ezer Ft-ot (nemtom pontosan mennyit) havonta, és az idejük 99%-ban nem csinálnak semmit. Totál felesleges, de szerver kell, és legalább 2 a redundancia miatt. Ráadásul ha valami isteni csoda folytán bejönne valami terhelés cunami, akkor hiába a 2 szerver, ledöntené a lábáról a rendszert. Ha áttérünk Lambda-ra (vagy Google Cloud Functions-ra), akkor a funkció futások után fizetünk. Ha egy hónapig nem történik semmi, akkor nem fizetünk semmit, ha meg hirtelen beindul valami, és egyszerre 100 000-en akadnak rá a szerverre, akkor sincs baj, az Amazon (v Google) felhúz alá hirtelen 10 szervert, kiszolgálja a kéréseket, aztán lelövi őket. De a dolog teljesen transzparens. Te csak a futások után fizetsz, nem kell vele foglalkoznod, hogy mi történik alatta. Baromi kényelmes dolog.
Egy korábbi cégnél pl. SVG rasterizert futtatunk Lambdán Javaban. De pl. arra is használom, hogy ha API gateway + lambda + sqs mögött, akkor nem kell a szervernek 100%-os uptime, elég ha időnként letölti a queue-ból az üzeneteket és reagál rá. (pl. hírlevél feliratkozás)
VálaszTörlésEz utóbbi kifejezetten hasznos így, hogy amúgy óránként fizetsz a szerverért.
VálaszTörlés