Bár a szerver nélküli technológiák az elmúlt években gyorsan népszerűvé váltak, még mindig sok tévhit és félelem kapcsolódik hozzájuk. A szállítói függőség, a szerszámok, a költségkezelés, a hidegindítás, a figyelés és a fejlesztési életciklus mind-mind forró témák a szerver nélküli technológiák terén. Ebben a cikkben megvizsgálunk néhány említett témakört, valamint tippeket és linkeket osztunk meg hasznos információforrásokhoz, amelyek segítségével a kezdők hatékony, rugalmas és költséghatékony kiszolgáló nélküli alkalmazásokat hozhatnak létre.
Tévhitek a szerver nélküli technológiákról
Sokan úgy gondolják, hogy a szerver nélküli és szerver nélküli feldolgozás (, FaaS) szinte ugyanaz. Ez azt jelenti, hogy nem túl nagy a különbség, és érdemes egy újdonságot bevezetni. Bár az AWS Lambda a szerver nélküli virágkor egyik sztárja és a szerver nélküli architektúra egyik legnépszerűbb eleme volt, ez az architektúra azonban sokkal több, mint a FaaS.
A szerver nélküli technológiák mögött meghúzódó alapelv az, hogy nem kell aggódnia az infrastruktúra kezelésével és méretezésével, csak azért kell fizetnie, amit használ. Számos szolgáltatás megfelel ezeknek a feltételeknek – AWS DynamoDB, S3, SNS vagy SQS, Graphcool, Auth0, Now, Netlify, Firebase és még sokan mások. Általánosságban elmondható, hogy a szerver nélküli kifejezés a felhőalapú számítástechnika teljes erejének kihasználását jelenti anélkül, hogy az infrastruktúrát kellene kezelni és optimalizálni a méretezéshez. Ez azt is jelenti, hogy az infrastruktúra szintű biztonság már nem az Ön gondja, ami óriási előny, tekintettel a biztonsági előírások teljesítésének nehézségeire és összetettségére. Végül, nem kell megvásárolnia az Ön számára biztosított infrastruktúrát.
A szerver nélküli „lelki állapotnak” tekinthető: bizonyos mentalitás a megoldások tervezése során. Kerülje el azokat a megközelítéseket, amelyek bármilyen infrastruktúra karbantartását igénylik. Szerver nélküli megközelítéssel olyan feladatok megoldásával töltjük az időt, amelyek közvetlenül érintik a projektet, és hasznot hoznak felhasználóinknak: fenntartható üzleti logikát alakítunk ki, felhasználói felületeket fejlesztünk, adaptív és megbízható API-kat fejlesztünk.
Például, ha el lehet kerülni egy szabad szöveges keresőplatform kezelését és karbantartását, akkor ezt tesszük. Az alkalmazások építésének ez a megközelítése nagymértékben felgyorsíthatja a piacra kerülést, mivel többé nem kell bonyolult infrastruktúra kezelésében gondolkodnia. Szüntesse meg az infrastruktúra kezelésével járó felelősségeket és költségeket, és összpontosítson az ügyfelek által igényelt alkalmazások és szolgáltatások kiépítésére. Patrick Debois ezt a megközelítést nevezte el , a kifejezést a szerver nélküli közösségben alkalmazzák. A funkciókat úgy kell felfogni, mint egy hivatkozást a szolgáltatásokhoz, mint telepíthető modulokhoz (ahelyett, hogy egy teljes könyvtárat vagy webalkalmazást telepítenének). Ez hihetetlen részletességet biztosít a telepítések és az alkalmazás módosításainak kezeléséhez. Ha nem tudja ilyen módon telepíteni a függvényeket, akkor ez azt jelezheti, hogy a függvények túl sok feladatot hajtanak végre, és újra kell alakítani őket.
Egyeseket összezavar a szállítótól való függés a felhőalkalmazások fejlesztésekor. Ugyanez igaz a szerver nélküli technológiákra is, és ez aligha tévhit. Tapasztalataink szerint a kiszolgáló nélküli alkalmazások AWS-en való építése, valamint az AWS Lambda azon képessége, hogy más AWS-szolgáltatásokat egybeköt, a kiszolgáló nélküli architektúrák erősségének része. Ez egy jó példa a szinergiára, amikor a kombináció eredménye több, mint a kifejezések összege. Ha megpróbálja elkerülni a szállítói függőséget, még több problémába ütközhet. Ha konténerekkel dolgozik, könnyebben kezelheti saját absztrakciós rétegét a felhőszolgáltatók között. De ami a szerver nélküli megoldásokat illeti, az erőfeszítés nem lesz kifizetődő, különösen, ha a költséghatékonyságot már az elején figyelembe vesszük. Feltétlenül tájékozódjon arról, hogyan nyújtanak szolgáltatásokat az eladók. Egyes speciális szolgáltatások más szállítókkal való integrációs pontokra támaszkodnak, és már a dobozból is biztosíthatják a plug-and-play csatlakozást. Könnyebb Lambda-hívást biztosítani egy átjáró API-végpontról, mint proxyzni a kérést valamilyen tárolóhoz vagy EC2-példányhoz. A Graphcool egyszerű konfigurálást tesz lehetővé az Auth0 segítségével, ami egyszerűbb, mint a harmadik féltől származó hitelesítési eszközök használata.
A megfelelő szállító kiválasztása kiszolgáló nélküli alkalmazásához építészeti döntés. Amikor létrehoz egy alkalmazást, nem várható, hogy egy napon visszatérjen a kiszolgálók kezeléséhez. A felhőszolgáltató kiválasztása nem különbözik a konténerek vagy adatbázisok, vagy akár egy programozási nyelv használatától.
Fontolgat:
- Milyen szolgáltatásokra van szüksége és miért.
- Milyen szolgáltatásokat nyújtanak a felhőszolgáltatók, és hogyan kombinálhatja ezeket a választott FaaS-megoldással.
- Milyen programozási nyelvek támogatottak (dinamikus vagy statikus gépeléssel, lefordítva vagy értelmezve, mik a benchmarkok, mi a teljesítmény hidegindításkor, mi a nyílt forráskódú ökoszisztéma stb.).
- Mik a biztonsági követelményei (SLA, 2FA, OAuth, HTTPS, SSL stb.).
- A CI/CD és a szoftverfejlesztési ciklusok kezelése.
- Milyen infrastruktúra-as-code megoldásokat használhat.
Ha kibővít egy meglévő alkalmazást, és fokozatosan hozzáadja a kiszolgáló nélküli funkciókat, ez némileg korlátozhatja az elérhető képességeket. Azonban szinte minden kiszolgáló nélküli technológia biztosít valamilyen API-t (REST-en vagy üzenetsorokon keresztül), amely lehetővé teszi az alkalmazásmagtól független és egyszerű integrációval rendelkező bővítmények létrehozását. Keressen világos API-kkal, jó dokumentációval és erős közösséggel rendelkező szolgáltatásokat, és nem tévedhet. Az integráció egyszerűsége gyakran kulcsfontosságú mérőszám lehet, és valószínűleg ez az egyik fő oka annak, hogy az AWS olyan sikeres volt a Lambda 2015-ös megjelenése óta.
Amikor a szerver nélküli jó
A szerver nélküli technológiák szinte mindenhol alkalmazhatók. Előnyeik azonban nem korlátozódnak egyetlen alkalmazási módra. A kiszolgáló nélküli technológiáknak köszönhetően ma olyan alacsony a felhőalapú számítástechnika piacra lépésének akadálya. Ha a fejlesztőknek van ötlete, de nem tudják, hogyan kezeljék a felhő infrastruktúrát és optimalizálják a költségeket, akkor nem kell ehhez valamilyen mérnököt keresniük. Ha egy startup platformot szeretne építeni, de attól tart, hogy a költségek kikerülhetnek az irányítás alól, könnyen kiszolgáló nélküli megoldásokhoz fordulhatnak.
A költségmegtakarítás és a könnyű skálázhatóság miatt a kiszolgáló nélküli megoldások egyformán alkalmazhatók belső és külső rendszerekre, akár egy több milliós közönséggel rendelkező webalkalmazásig. A számlákat nem euróban, hanem centben mérik. Az AWS EC2 legegyszerűbb példányának (t1.micro) bérlése egy hónapra 15 euróba kerül, még akkor is, ha nem csinálsz vele semmit (ki soha nem felejtette el kikapcsolni?!). Összehasonlításképpen, ahhoz, hogy ugyanazon idő alatt elérje ezt a költési szintet, egy 512 MB-os Lambdát körülbelül 1 millió alkalommal kell 3 másodpercig futtatnia. És ha nem használja ezt a funkciót, akkor nem fizet semmit.
Mivel a kiszolgáló nélküli rendszer elsősorban eseményvezérelt, meglehetősen könnyű kiszolgáló nélküli infrastruktúrát hozzáadni a régebbi rendszerekhez. Például az AWS S3, a Lambda és a Kinesis használatával analitikai szolgáltatást hozhat létre egy régi kiskereskedelmi rendszerhez, amely képes adatokat fogadni API-n keresztül.
A legtöbb kiszolgáló nélküli platform több nyelvet is támogat. Leggyakrabban Python, JavaScript, C#, Java és Go. Általában nincs korlátozás a könyvtárak használatára minden nyelven, így használhatja kedvenc nyílt forráskódú könyvtárait. Javasoljuk azonban, hogy ne éljen vissza a függőségekkel, hogy funkciói optimálisan működjenek, és ne veszítsék el a kiszolgáló nélküli alkalmazások hatalmas méretezhetőségének előnyeit. Minél több csomagot kell a konténerbe betölteni, annál tovább tart a hidegindítás.
A hidegindítás az, amikor először inicializálni kell a tárolót, a futási környezetet és a hibakezelőt használat előtt. Emiatt a funkciók végrehajtásának késése akár 3 másodperc is lehet, és ez nem a legjobb megoldás a türelmetlen felhasználók számára. A hidegindítás azonban az első híváskor történik néhány percnyi üresjárat után. Sokan ezt egy kisebb bosszúságnak tartják, amelyet úgy lehet kiküszöbölni, ha rendszeresen pingeljük a funkciót, hogy az alapjáraton maradjon. Vagy teljesen figyelmen kívül hagyják ezt a szempontot.
Bár megjelent az AWSAz SQL-adatbázisok azonban nem ideálisak ehhez az alkalmazáshoz, mivel a kapcsolatoktól függenek a tranzakciók végrehajtása során, amelyek gyorsan szűk keresztmetszetekké válhatnak az AWS Lambda nagy forgalmával. Igen, a fejlesztők folyamatosan fejlesztik a Serverless Aurorát, és érdemes kísérletezni vele, de ma már olyan NoSQL megoldások, mint pl.. Kétségtelen azonban, hogy ez a helyzet hamarosan megváltozik.
Az eszköztár sok korlátozást is támaszt, különösen a helyi tesztelés területén. Bár vannak olyan megoldások, mint a Docker-Lambda, a DynamoDB Local és a LocalStack, ezek kemény munkát és jelentős mennyiségű konfigurációt igényelnek. Mindezeket a projekteket azonban aktívan fejlesztik, így csak idő kérdése, hogy az eszköztár elérje azt a szintet, amelyre szükségünk van.
A szerver nélküli technológiák hatása a fejlesztési ciklusra
Mivel az infrastruktúra csak egy konfiguráció, kódot definiálhat és telepíthet parancsfájlok, például shell-parancsfájlok segítségével. Vagy folyamodhat konfigurációs kódként osztályú megoldásokhoz, mint pl . Bár ez a szolgáltatás nem biztosít minden terület konfigurációját, lehetővé teszi, hogy meghatározott erőforrásokat határozzon meg Lambda-függvényként. Vagyis ahol a CloudFormation kudarcot vall, megírhatja saját erőforrását (Lambda függvény), amely bezárja ezt a rést. Így bármit megtehet, még az AWS-környezeten kívüli függőségeket is konfigurálhat.
Mivel mindez csak konfiguráció, testreszabhatja telepítési szkriptjeit adott környezetekhez, régiókhoz és felhasználókhoz, különösen akkor, ha olyan infrastruktúra-kód-megoldásokat használ, mint a CloudFormation. Például telepítheti az infrastruktúra egy példányát a lerakat minden ágához, így teljesen elszigetelten tesztelheti őket a fejlesztés során. Ez drasztikusan felgyorsítja a visszacsatolást a fejlesztők számára, amikor meg akarják érteni, hogy kódjuk megfelelően működik-e élő környezetben. A menedzsereknek nem kell aggódniuk a több környezet telepítésének költségei miatt, mivel csak a tényleges használatért fizetnek.
A DevOps-nak kevésbé kell aggódnia, mivel csak arról kell gondoskodnia, hogy a fejlesztők a megfelelő konfigurációval rendelkezzenek. Többé nem kell példányokat, kiegyenlítőket vagy biztonsági csoportokat kezelnie. Ezért a NoOps kifejezést egyre gyakrabban használják, bár továbbra is fontos az infrastruktúra konfigurálása, különösen, ha IAM-konfigurációról és felhő-erőforrás-optimalizálásról van szó.
Vannak nagyon hatékony megfigyelési és vizualizációs eszközök, mint az Epsagon, a Thundra, a Dashbird és az IOPipe. Lehetővé teszik a kiszolgáló nélküli alkalmazások aktuális állapotának nyomon követését, naplózást és nyomkövetést, teljesítménymutatók és architektúra szűk keresztmetszetek rögzítését, költségelemzést és előrejelzést stb. Nemcsak átfogó képet adnak a DevOps mérnökeinek, fejlesztőinek és építészeinek az alkalmazások teljesítményéről, hanem lehetővé teszik a menedzserek számára a helyzet valós időben történő nyomon követését is, másodpercenkénti erőforrásköltségekkel és költség-előrejelzéssel. Menedzselt infrastruktúrával ezt sokkal nehezebb megszervezni.
Szerver nélküli alkalmazások tervezése sokkal egyszerűbb, mert nem kell webszervereket telepítenie, virtuális gépeket vagy konténereket, javítószervereket, operációs rendszereket, internetes átjárókat stb. kell kezelnie. Mindezen felelősségek elvonásával a szerver nélküli architektúra a magra összpontosíthat – a megoldást.az üzleti és az ügyfelek igényeit.
Noha az eszköztár lehetne jobb (minden nap jobb lesz), a fejlesztők az üzleti logika megvalósítására összpontosíthatnak, és az alkalmazás komplexitásának legjobb elosztását az architektúrán belüli különböző szolgáltatások között. A kiszolgáló nélküli alkalmazáskezelés eseményalapú és a felhőszolgáltató által absztrahált (pl. SQS, S3 események vagy DynamoDB folyamok). Ezért a fejlesztőknek csak üzleti logikát kell írniuk, hogy reagáljanak bizonyos eseményekre, és nem kell azon törődniük, hogyan lehet a legjobban megvalósítani az adatbázisokat és az üzenetsorokat, vagy hogyan lehet megszervezni az optimális munkavégzést az egyes hardvertárolókban lévő adatokkal.
A kód helyileg futtatható és hibakereshető, mint bármely fejlesztési folyamat esetében. Az egységteszt ugyanaz marad. A teljes alkalmazás-infrastruktúra egyéni veremkonfigurációval történő üzembe helyezésének képessége lehetővé teszi a fejlesztők számára, hogy gyorsan kapjanak fontos visszajelzéseket anélkül, hogy a tesztelés költségeire vagy a drága felügyelt környezetekre gyakorolt hatásra gondolnának.
Szerver nélküli alkalmazások építésének eszközei és technikái
Nincs konkrét módszer a szerver nélküli alkalmazások létrehozására. Valamint egy szolgáltatáskészlet ehhez a feladathoz. Az AWS manapság vezető szerepet tölt be a hatékony szerver nélküli megoldások között, de nézze meg , и . Ha AWS-t használ, az alkalmazások gyűjtésének javasolt módja (SAM), különösen C# használatakor, mert a Visual Studio remek szerszámokkal rendelkezik. A SAM parancssori felület mindenre képes, amit a Visual Studio, így nem veszít semmit, ha másik IDE-re vagy szövegszerkesztőre vált. Természetesen a SAM más nyelvekkel is működik.
Ha más nyelveken ír, a Serverless Framework egy kiváló nyílt forráskódú eszköz, amellyel bármit beállíthat nagyon hatékony YAML konfigurációs fájlokkal. A Serverless Framework különféle felhőszolgáltatásokat is támogat, így azoknak ajánljuk, akik többfelhős megoldást keresnek. Hatalmas közössége van, amely egy csomó beépülő modult hozott létre bármilyen igényre.
A helyi teszteléshez a Docker-Lambda, a Serverless Local, a DynamoDB Local és a LocalStack nyílt forráskódú eszközök jól használhatók. A szerver nélküli technológiák még a fejlesztés korai szakaszában járnak, csakúgy, mint a hozzájuk tartozó eszközök, így az összetett tesztforgatókönyvek beállításakor keményen kell dolgoznia. Azonban a verem egyszerű üzembe helyezése és tesztelése egy környezetben hihetetlenül olcsó. És nem kell pontos helyi másolatot készítenie a felhőkörnyezetekről.
Az AWS Lambda Layers használatával csökkentheti a telepített csomagok méretét és felgyorsíthatja a letöltéseket.
Használja a megfelelő programozási nyelveket bizonyos feladatokhoz. A különböző nyelveknek megvannak a maga előnyei és hátrányai. Számos benchmark létezik, de a JavaScript, a Python és a C# (.NET Core 2.1+) az élen jár az AWS Lambda teljesítményét tekintve. Az AWS Lambda nemrég bemutatta a Runtime API-t, amely lehetővé teszi a kívánt nyelv és futási környezet megadását, ezért kísérletezzen.
A telepítéshez tartsa kicsi a csomagméretet. Minél kisebbek, annál gyorsabban töltődnek be. Kerülje a nagy könyvtárak használatát, különösen, ha néhány funkciót használ belőlük. Ha JavaScriptben programoz, használjon olyan összeállítási eszközt, mint a Webpack, hogy optimalizálja összeállítását, és csak azt tartalmazza, amire valóban szüksége van. A .NET Core 3.0 rendelkezik QuickJit-tel és többszintű összeállítással, amely javítja a teljesítményt és sokat segít a hidegindításoknál.
A szerver nélküli funkciók eseményektől való függése megnehezítheti az üzleti logika összehangolását. Ebben a tekintetben az üzenetsorok és az állapotgépek hihetetlenül hasznosak lehetnek. A lambda-függvények hívhatják egymást, de csak akkor tegye ezt, ha nem vár választ ("gyújts és felejts el") – nem akarsz számlát kapni azért, mert vársz egy másik funkció befejezésére. Az üzenetsorok hasznosak az üzleti logika egyes részeinek elkülönítésére, az alkalmazások szűk keresztmetszete kezelésére és a tranzakciók feldolgozására (FIFO-sorok használatával). Az AWS Lambda funkciói beragadt üzenetsorokként rendelhetők az SQS-sorokhoz, amelyek nyomon követik a sikertelen üzeneteket későbbi elemzés céljából. Az AWS Step Functions (állapotgépek) nagyon hasznosak a függvények láncolását igénylő összetett folyamatok kezelésére. Ahelyett, hogy egy lambda függvény hívna egy másik függvényt, a lépésfüggvények koordinálhatják az állapotátmeneteket, adatokat adhatnak át a függvények között, és kezelhetik a függvények globális állapotát. Ez lehetővé teszi az újrapróbálkozási feltételek meghatározását, vagy azt, hogy mi a teendő egy adott hiba esetén – ez egy nagyon hatékony eszköz bizonyos körülmények között.
Következtetés
Az elmúlt években a szerver nélküli technológiák példátlan ütemben fejlődtek. Ehhez a paradigmaváltáshoz bizonyos tévhitek kapcsolódnak. Az infrastruktúra absztrahálása és a méretezési felügyelet révén a kiszolgáló nélküli megoldások jelentős előnyöket kínálnak az egyszerűsített fejlesztéstől és a DevOps folyamatoktól a működési költségek jelentős csökkentéséig.
Bár a kiszolgáló nélküli megközelítés nem mentes a hátrányoktól, vannak robusztus tervezési minták, amelyek segítségével robusztus kiszolgáló nélküli alkalmazások építhetők fel, vagy kiszolgáló nélküli elemek integrálhatók a meglévő architektúrákba.
Forrás: will.com