Bár a szerver nélküli technológiák az utóbbi években gyorsan népszerűvé váltak, még mindig sok félreértés és aggály övezi őket. A beszállítói függőség, az eszközkészlet, a költségek kezelése, a hidegindítás, a monitoring és a fejlesztési életciklus – ezek a témák aktívan napirenden vannak, amikor a szerver nélküli technológiákról van szó. Ebben a cikkben megvizsgálunk néhány említett témát, és megosztunk tippeket és hasznos források linkjeit, amelyek segítségével a kezdők erőteljes, rugalmas és költséghatékony szerver nélküli alkalmazásokat hozhatnak létre.
Félreértések a szerver nélküli technológiákról
Sokan azt hiszik, hogy a szerver nélküli működés és az adatfeldolgozás (, FaaS) szinte ugyanaz. Ezért a különbség nem túl nagy, és érdemes bevezetni az újdonságot. Bár az AWS Lambda volt az egyik „csillag” a szerver nélküli technológiák virágkorában, és az egyik legnépszerűbb eleme a szerver nélküli architektúrának, ez az architektúra még sokkal többet jelent, mint a FaaS.
A szerver nélküli technológiák alapelve az, hogy nem kell aggódnia az infrastruktúra kezeléséről és méretezéséről, csak azért fizet, amit használ. Számos szolgáltatás megfelel ezeknek a kritériumoknak – AWS DynamoDB, S3, SNS vagy SQS, Graphcool, Auth0, Now, Netlify, Firebase és még sok más. Összességében a szerver nélküli működés az összes felhőalapú számítási lehetőség kihasználásáról szól anélkül, hogy az infrastruktúra kezelésével és optimalizálásával kellene foglalkozni a méretezés miatt. Ez azt is jelenti, hogy az infrastruktúra biztonsága már nem az Ön problémája, ami óriási előny, figyelembe véve a biztonsági standardok betartásának nehézségét és komplexitását. Végül, nem kell megvásárolnia a rendelkezésére bocsátott infrastruktúrát.
A szerver nélküli működést „mentális állapotnak” tekinthetjük: egy bizonyos mentalitás a megoldások tervezésében. Kerülje azokat a megközelítéseket, amelyek bármilyen infrastruktúra karbantartását igénylik. A szerver nélküli megközelítés esetén az időnket olyan feladatok megoldására fordítjuk, amelyek közvetlen hatással vannak a projektre, és előnyöket nyújtanak felhasználóink számára: fenntartható üzleti logikát alakítunk ki, fejlesztjük a felhasználói felületeket és adaptív, megbízható API-kat készítünk.
Például, ha elkerülhetjük a szabad szövegkeresési platform kezelését és támogatását, akkor éppen így is járunk el. Ez a megközelítés képes jelentősen felgyorsítani a termék piacra jutását, mivel többé nem kell bonyolult infrastruktúrák kezelésével foglalkoznia. Szabaduljon meg az infrastruktúra kezelésével járó kötelezettségektől és kiadásoktól, és összpontosítson az olyan alkalmazások és szolgáltatások létrehozására, amelyekre az ügyfeleinek szüksége van. Patrick Debois ezt a megközelítést , ezt a kifejezést a serverless közösségben használták. A funkciókat összekötő elemként kell kezelni a szolgáltatásokhoz, formálisan telepíthető modulokként (ahelyett, hogy egy egész könyvtárat vagy webalkalmazást telepítenénk). Ez elképesztő fokú granularitást biztosít a telepítési és változtatási folyamatok kezelésében az alkalmazásban. Ha nem tudja így telepíteni a funkciókat, akkor ez arra utalhat, hogy a funkciók túl sok feladatot látnak el, és refaktorálásra szorulnak.
Néhányan aggódnak a beszállítótól való függőség miatt felhős alkalmazások fejlesztésekor. Ugyanez igaz a szerver nélküli technológiákra is, és valószínűleg nem csupán félreértés következménye. Tapasztalataink szerint a szerver nélküli alkalmazások AWS-en való létrehozása, az AWS Lambda képessége, hogy más AWS szolgáltatásokat hasznosítson — mindez részben hozzájárul a szerver nélküli architektúrák előnyeinek kialakulásához. Ez egy jó példa a szinergiára, amikor az összegzés eredménye nagyobb, mint a részek egyszerű összege. Ha megpróbálja elkerülni a beszállítói függőséget, nagyobb problémákkal is szembesülhet. Az konténerek kezelése során könnyebb irányítani az absztrakciós szintet a felhős szolgáltatók között. De amikor a szerver nélküli megoldásokról van szó, az erőfeszítések nem térülnek meg, különösen, ha a gazdaságosságot már kezdetben figyelembe vesszük. Feltétlenül derítse ki, hogyan biztosítják a szolgáltatások nyújtását a beszállítók. Néhány speciális szolgáltatás más beszállítókkal való integrációs pontokon alapul, és dobozból kipróbálható csatlakozási lehetőségeket kínálhat. Könnyebb Lambda-t hívni egy API gateway végpontból, mint egy konténer vagy EC2 példány számára proxyzálni a kérést. A Graphcool egyszerű konfigurálást biztosít az Auth0-val, ami könnyebb, mint harmadik fél hitelesítési eszközeit használni.
A megfelelő beszállító kiválasztása a szerver nélküli alkalmazásához architekturális szintű döntés. Amikor alkalmazást épít, nem számít arra, hogy egyszer visszatér a szerverek kezeléséhez. Az felhőszolgáltató kiválasztása nem különbözik a konténerek, adatbázisok vagy akár programozási nyelvek használatának megválasztásától.
Fontolja meg:
- Milyen szolgáltatásokra van szüksége és miért?
- Milyen szolgáltatásokat kínálnak a felhőszolgáltatók, és hogyan integrálhatja ezeket a választott FaaS megoldásával?
- Milyen programozási nyelvek vannak támogatva (dinamikus vagy statikus típusozású, hordozható vagy értelmezett, milyen benchmarkok vannak, milyen teljesítményt nyújt a hideg indításkor, milyen az open source ökoszisztéma és így tovább).
- Mik a biztonsági követelményei (SLA, 2FA, OAuth, HTTPS, SSL stb.).
- Hogyan kezelheti a CI/CD-t és a szoftverfejlesztési ciklusokat.
- Milyen infrastructure-as-code megoldások előnyeit tudja kihasználni.
Ha meglévő alkalmazást bővít és fokozatosan hozzáadja a serverless funkciókat, ez korlátozhatja a rendelkezésre álló lehetőségeket. Azonban szinte minden serverless technológia biztosít valamilyen API-t (REST vagy üzenetsorokon keresztül), amely lehetővé teszi a bővítmények létrehozását az alkalmazás alapjától függetlenül és egyszerű integrációval. Olyan szolgáltatásokat keressen, amelyek érthető API-val, jó dokumentációval és erős közösséggel rendelkeznek, és nem tévedhet. Az integráció egyszerűsége gyakran kulcsmérőszám lehet, és valószínűleg ez az AWS sikerének egyik fő oka, mióta 2015-ben megjelent a Lambda.
Mikor hasznos a serverless megoldás
A serverless technológiák szinte mindenhol alkalmazhatók. Azonban az előnyeik nem csupán a felhasználási módokra korlátozódnak. A felhőalapú számítások belépési küszöbe ma annyira alacsony éppen a serverless technológiáknak köszönhetően. Ha a fejlesztőknek van egy ötletük, de nem tudják, hogyan kezeljék a felhőinfrastruktúrát és optimalizálják a költségeket, akkor nem szükséges mérnököt keresniük. Ha egy startup platformot szeretne létrehozni, de attól tart, hogy a költségek ellenőrizhetetlenné válhatnak, akkor könnyen fordulhat serverless megoldásokhoz.
A költségmegtakarítás és a skálázhatóság egyszerűsége miatt a serverless megoldások egyaránt alkalmazhatók belső rendszerekre és külsőkre, egészen a többmilliós közönséggel rendelkező webalkalmazásokig. A számlák inkább centekben mérhetők, mint eurókban. A legbasicabb AWS EC2 példány (t1.micro) havi bérlése 15 €-ba kerül, még akkor is, ha semmit sem csinál vele (kinek nem volt már olyan, hogy elfelejtette kikapcsolni?!). Összehasonlításképpen, hogy ugyanazt a költségszintet elérje ugyanebben az időszakban, körülbelül 3 millió alkalommal kell működtetnie egy 512 MB-os Lamdát 1 másodpercre. Ha pedig nem használja ezt a funkciót, akkor nem fizet semmit.
Mivel a serverless technológia főként az eseményektől függ, viszonylag könnyen hozzáadható serverless infrastruktúra a régi rendszerekhez. Például az AWS S3, Lambda és Kinesis segítségével létrehozhat egy elemző szolgáltatást egy régi kiskereskedelmi rendszerhez, amely adatokat kaphat API-n keresztül.
A legtöbb szerver nélküli platform támogatja a különböző programozási nyelveket. Leggyakrabban a Python, JavaScript, C#, Java és Go. Általában nincs korlátozás a könyvtárak használatára minden nyelvben, így használhatod a kedvenc nyílt forráskódú könyvtáraidat. Azonban nem tanácsos túlságosan sok függőséget használni, hogy a funkcióid optimálisan működjenek és ne semmizzék ki a hatalmas skálázhatóság előnyeit a szerver nélküli alkalmazásaid számára. Minél több csomagot kell betölteni a konténerbe, annál hosszabb lesz a hideg indítás végrehajtása.
A hideg indítás az, amikor először inicializálni kell a konténert, a futtatási környezetet és a hibakezelőt, mielőtt használni lehetne őket. Emiatt a funkciók végrehajtási késlelte akár 3 másodpercet is elérhet, ami nem a legjobb megoldás a türelmetlen felhasználók számára. Azonban a hideg indítások előfordulnak az első eléréskor, miután a funkció néhány percig inaktív volt. Így sokan ezt apró kellemetlenségnek tartják, amelyet rendszeres pingeléssel elkerülhetnek, hogy a funkciót folyamatosan működésben tartsák. Vagy teljesen figyelmen kívül hagyják ezt a szempontot.
Bár az AWS kiadta, az SQL-adatbázisok nem ideálisak az ilyen alkalmazásokhoz, mivel a tranzakciók végrehajtása a kapcsolatoktól függ, amelyek nagy forgalom esetén gyorsan szűk keresztmetszetté válhatnak az AWS Lambda-n. Igen, a fejlesztők folyamatosan javítják a Serverless Aurora-t, és érdemes kísérletezni vele, de ma a szerver nélküli rendszerekhez sokkal jobban illenek a NoSQL megoldások, mint például. Mindazonáltal kétségtelen, hogy ez a helyzet nagyon gyorsan megváltozik.
Az eszközök is számos korlátozást imposztálnak, különösen a helyi tesztelés terén. Bár léteznek megoldások, mint a Docker-Lambda, a DynamoDB Local és a LocalStack, ezek azonban alapos munkát és jelentős konfigurálást igényelnek. Mindazonáltal ezek a projektek aktívan fejlődnek, így csak idő kérdése, hogy az eszköváz elérje a szükséges szintet.
A szerver nélküli technológiák hatása a fejlesztési ciklusra
Mivel az infrastruktúrád csupán egy konfiguráció, a kódot egyszerűen megadhatod és telepítheted szkriptek segítségével, például shell-szkriptek segítségével. Vagy használhatsz konfigurációként kód komplex megoldásokat, mint például Bár ez a szolgáltatás nem kínál konfigurációt minden területre, lehetővé teszi a konkrét erőforrások meghatározását Lambda-funkciók használatára. Tehát ahol a CloudFormation megcsalna, írhat egy saját erőforrást (Lambda-funkciót), amely betömi ezt a rés. Így bármit megtehet, akár a függőségek konfigurálását is az AWS környezetén kívül.
Mivel mindez csupán konfiguráció, a telepítési szkripteket paraméterezheti a konkrét környezetek, régiók és felhasználók számára, különösen, ha infrastruktúra-kód típusú megoldásokat, mint például a CloudFormation-t alkalmazza. Például létrehozhat egy infrastruktúrakópát minden ágra a tárolóban, hogy teljesen elszigetelten tesztelje azokat a fejlesztés során. Ez radikálisan felgyorsítja a fejlesztők visszajelzéshez jutását, amikor meg akarják érteni, hogyan működik a kódjuk az élő környezetben. A vezetőknek nem kell aggódniuk a számos környezet telepítési költsége miatt, mivel csak a tényleges használatot kell fizetni.
A DevOps szakembereknek kevesebb gondjuk van, mivel csak arról kell megbizonyosodniuk, hogy a fejlesztők helyes konfigurációt használnak. Már nincs szükség az instance-ok, terheléselosztók vagy biztonsági csoportok kezelésére. Ezért egyre gyakrabban használják a NoOps kifejezést, bár továbbra is fontos a infrastruktúra konfigurálásának ismerete, különösen az IAM konfiguráció és a felhőerőforrások optimalizálása terén.
Nagyon erőteljes eszközök állnak rendelkezésre, mint például az Epsagon, Thundra, Dashbird és IOPipe, amelyek lehetővé teszik a serverless alkalmazások aktuális állapotának nyomon követését, naplókat és nyomkövetést biztosítanak, teljesítménymérő metrikákat és architekturális szűk keresztmetszeteket regisztrálnak, valamint költségelemzést és előrejelzést végeznek, és még sok más. Ezek nemcsak átfogó képet adnak a DevOps mérnökök, fejlesztők és architectek számára az alkalmazások működéséről, hanem lehetővé teszik a vezetők számára, hogy valós időben követhessék a helyzetet, másodpercre pontosan a forrásköltségekkel és költségelőrejelzéssel. Ilyen környezetekben a felügyelt infrastruktúra szervezése sokkal nehezebb.
Szerver nélküli alkalmazások tervezése jelentősen egyszerűbb, mivel nem kell webkiszolgálókat telepíteni, virtuális gépeket vagy konténereket kezelni, szervereket, operációs rendszereket, internetkapukat javítani stb. Az összes ilyen kötelezettség alól való feloldás lehetővé teszi a szerver nélküli architektúra számára, hogy a fő feladatára összpontosítson — az üzleti és ügyféligények kielégítésére.
Bár az eszközkészlet lehetne jobb (napról napra fejlődik), a fejlesztők a vállalati logika megvalósítására és az alkalmazás összetettségének legjobb elosztására összpontosíthatnak a különböző szolgáltatások között az architektúrában. A szerver nélküli alkalmazások kezelése eseményalapú, és a felhőszolgáltató (például SQS, S3-események vagy DynamoDB-áramok) által van absztrahálva. Ezért a fejlesztőknek csak annyit kell tenniük, hogy meghatározzák a vállalati logikát a konkrét eseményekre való reagáláshoz, és nem kell aggódniuk a legjobb adatbázis- és üzenetküldési megoldások, valamint az adott hardver tárolók optimális adatkezelése tekintetében.
A kódot helyben is futtathatjuk és hibakereshetjük, mint bármely fejlesztési folyamat során. A moduláris tesztelés változatlan marad. Az alkalmazás teljes infrastruktúrájának telepítési lehetősége egy testreszabható stack konfiguráción keresztül lehetővé teszi a fejlesztők számára, hogy gyorsan fontos visszajelzést kapjanak anélkül, hogy a tesztelés költségeivel vagy a drága kezelhető környezetekre gyakorolt hatással kellene foglalkozniuk.
Szerver nélküli alkalmazások építési eszközei és módszerei
Nincs konkrét módszer a szerver nélküli alkalmazások felépítésére. Ugyanez igaz a feladatra szánt szolgáltatásokra is. Az AWS ma a legnépszerűbb erőteljes szerver nélküli megoldás, de érdemes figyelembe venni a , és . Ha az AWS-t használja, a javasolt megközelítés az alkalmazások építésére a (SAM), különösen a C# esetében, mivel a Visual Studio nagyszerű eszközkészlettel rendelkezik. A SAM CLI mindent meg tud csinálni, amit a Visual Studio, így semmit sem veszít, ha más IDE-re vagy szövegszerkesztőre vált. Természetesen a SAM más nyelvekkel is működik.
Ha más nyelveken írsz, a Serverless Framework egy nagyszerű nyílt forráskódú eszköz, amely lehetővé teszi, hogy bármit konfigurálj nagyon erőteljes YAML konfigurációs fájlok segítségével. A Serverless Framework különböző felhőszolgáltatásokat is támogat, ezért ajánljuk azoknak, akik többfelhős megoldást keresnek. Óriási közösség áll mögötte, amely rengeteg plugint készített a különböző igényekhez.
Helyi teszteléshez jól alkalmazható nyílt forráskódú eszközök a Docker-Lambda, Serverless Local, DynamoDB Local és LocalStack. A serverless technológiák még mindig fejlődőben vannak, csakúgy, mint az azokhoz szükséges eszközök, így a bonyolult tesztelési forgatókönyvek beállításakor igénybe kell venni a munkát. A stack környezetben történő telepítése és tesztelése azonban hihetetlenül olcsón megvalósítható. Nincs szükséged pontos helyi másolatokra a felhői környezetekből.
A telepített csomagok méretének csökkentéséhez és a betöltési idő felgyorsításához használj AWS Lambda Layers-t.
Használj a konkrét feladatokhoz megfelelő programozási nyelveket. A különböző nyelveknek saját erősségeik és gyengeségeik vannak. Számos benchmark létezik, de a JavaScript, a Python és a C# (.NET Core 2.1+) a teljesítmény tekintetében vezetők az AWS Lambda esetében. Nemrégiben megjelent az AWS Lambda-ban a Runtime API, amely lehetővé teszi a kívánt nyelv és futtatási környezet megadását, így kísérletezz.
Tartsd kicsi a telepítési csomagok méretét. Minél kisebbek, annál gyorsabban töltődnek be. Kerüld a nagy könyvtárak használatát, különösen, ha csak néhány funkciót használsz belőlük. Ha JavaScriptben programozol, használj olyan csomagoló eszközöket, mint a Webpack, hogy optimalizáld a buildet és csak azt a részt tartalmazd, amire valóban szükséged van. A .NET Core 3.0-ban létezik a QuickJit és a Tiered Compilation, amelyek javítják a teljesítményt és nagyban segítenek a hideg indítások során.
A szerver nélküli funkciók eseményektől való függősége kezdetben megnehezítheti az üzleti logika koordinálását. Ezért rendkívül hasznosak lehetnek az üzenetsorok és az állapotautomaták. A Lambda-funkciók képesek egymást hívni, de ezt csak akkor tegye, ha nem vár választ («lőj és felejtsd el») — hiszen nem szeretne várakozási díjat fizetni egy másik funkció befejezésére. Az üzenetsorok hasznosak az üzleti logika részeinek szétválasztására, az alkalmazások szűk keresztmetszeteinek kezelésére és a tranzakciók feldolgozására (FIFO sorok használatával). Az AWS Lambda funkciók SQS sorokhoz rendelhetők „holt” üzenetek soraként, amelyek a hibás üzeneteket nyomon követik a későbbi elemzéshez. Az AWS Step Functions (állapotautomaták) nagyon hasznosak bonyolult folyamatok kezelésében, amelyek funkcióláncok létrehozását igénylik. Ahelyett, hogy egy Lambda-funkció hívna meg egy másik funkciót, a Step Functions koordinálhatják az állapotátmeneteket, adatokat adhattak át funkciók között, és kezelhetik a funkciók globális állapotát. Ez lehetővé teszi a próbálkozások feltételeinek meghatározását, vagy hogy mit kell tenni egy adott hiba esetén — meghatározott körülmények között rendkívül hatékony eszköz.
Zárás
Az utóbbi években a szerver nélküli technológiák páratlan ütemben fejlődnek. Ezzel a paradigmaváltással kapcsolatban azonban bizonyos tévhitek is felmerültek. Az infrastruktúra és a skálázás irányításának absztrakciójának köszönhetően a szerver nélküli megoldások jelentős előnyöket kínálnak: a fejlesztés és a DevOps folyamatok egyszerűsítésétől kezdve a működési költségek drámai csökkentéséig.
Habár a szerver nélküli megközelítésnek megvannak a hátrányai, léteznek megbízható módszerek és tervezési minták, amelyek segítségével robusztus szerver nélküli alkalmazásokat lehet létrehozni, vagy integrálni a szerver nélküli elemeket a meglévő architektúrákba.
Forrás: habr.com
