Hoewol serverless technologyen yn 'e lêste jierren rap populêr hawwe wûn, binne d'r noch in protte misferstannen en soargen ferbûn mei har. Ofhinklikens fan ferkeapers, ark, kostenbehear, kâlde start, tafersjoch en libbenssyklus fan ûntwikkeling binne allegear heul besprutsen ûnderwerpen as it giet om serverless technologyen. Yn dit artikel sille wy guon fan 'e neamde ûnderwerpen ûndersykje, en ek tips en keppelings diele nei nuttige boarnen om begjinners te helpen krêftige, fleksibele en kosten-effektive serverless-applikaasjes te bouwen.
Misbegryp oer serverless technologyen
In protte minsken leauwe dat serverless en serverless gegevensferwurking (, FaaS) binne hast itselde ding. Dit betsjut dat it ferskil net te grut is en it is de muoite wurdich om in nij produkt yn te fieren. Hoewol AWS Lambda wie ien fan 'e stjerren fan' e opkomst fan serverless technology en ien fan de meast populêre eleminten fan serverless arsjitektuer, d'r is mear oan dizze arsjitektuer dan FaaS.
It kearnprinsipe fan serverless is dat jo gjin soargen hoege te meitsjen oer it behearen of skaaljen fan jo ynfrastruktuer, jo betelje allinich foar wat jo brûke. In protte tsjinsten passe oan dizze kritearia - AWS DynamoDB, S3, SNS of SQS, Graphcool, Auth0, Now, Netlify, Firebase en in protte oaren. Yn 't algemien betsjut serverless it brûken fan alle mooglikheden fan cloud computing sûnder de needsaak om de ynfrastruktuer te behearjen en te optimalisearjen om't skaalfergrutting. It betsjut ek dat feiligens op it ynfrastruktuernivo net langer jo probleem is, wat in enoarm foardiel is sjoen de muoite en kompleksiteit fan it foldwaan oan feiligensnormen. Uteinlik hoege jo de oan jo levere ynfrastruktuer net te keapjen.
Serverless kin beskôge wurde as in "state of mind": in bepaalde mentaliteit by it ûntwerpen fan oplossingen. Mije oanpakken dy't ûnderhâld fan elke ynfrastruktuer nedich binne. Mei in oanpak sûnder server besteegje wy tiid oan it oplossen fan problemen dy't direkte ynfloed hawwe op it projekt en wearde bringe oan ús brûkers: robúste saaklike logika meitsje, brûkersynterfaces ûntwikkelje en responsive en betroubere API's ûntwikkelje.
As it bygelyks mooglik is om it behearen en ûnderhâlden fan in frije tekstsykplatfoarm te foarkommen, dan sille wy dat dwaan. Dizze oanpak foar it bouwen fan applikaasjes kin de tiid foar merk dramatysk fersnelle, om't jo net langer hoege te tinken oer it behearen fan komplekse ynfrastruktuer. Befrij josels fan 'e ferantwurdlikheden en kosten fan ynfrastruktuerbehear en fokusje op it bouwen fan de applikaasjes en tsjinsten dy't jo klanten nedich binne. Patrick Debois neamde dizze oanpak , dizze term wurdt akseptearre yn de serverless mienskip. Funksjes moatte wurde tocht as de lijm dy't tsjinsten byinoar bynt as ynsetbere modules (ynstee fan it ynsetten fan in folsleine bibleteek of webapplikaasje). Dit soarget foar ongelooflijke granulariteit foar it behearen fan ynset en wizigingen oan 'e applikaasje. As jo gjin funksjes kinne ynsette op dizze manier, kin it oanjaan dat de funksjes tefolle dingen dogge en moatte wurde refaktorearre.
Guon minsken wurde betize troch ferkeaperôfhinklikens by it ûntwikkeljen fan wolkapplikaasjes. Itselde is wier mei serverless technologyen, en dit is nei alle gedachten it gefolch fan in misfetting. Yn ús ûnderfining is it bouwen fan serverleaze applikaasjes op AWS, keppele oan AWS Lambda's fermogen om oare AWS-tsjinsten te aggregearjen, diel fan wat serverleaze arsjitektueren sa geweldich makket. Dit is in goed foarbyld fan synergy, as it resultaat fan in kombinaasje grutter is as allinich de som fan syn dielen. Besykje te foarkommen dat ferkeaper lock-in kin liede ta noch mear problemen. By it wurkjen mei konteners is it makliker om jo eigen abstraksjelaach te behearjen tusken wolkproviders. Mar as it giet om oplossings sûnder server, sil de ynspanning net betelje, foaral as jo fan it begjin ôf oan kosten-effektiviteit beskôgje. Wês wis te finen hoe't leveransiers tsjinsten leverje. Guon spesjalisearre tsjinsten fertrouwe op yntegraasjepunten mei oare leveransiers en kinne plug-and-play-ferbining út 'e doaze leverje. It is makliker om in Lambda-oprop te leverjen fan in gateway API-einpunt dan it fersyk te proxyjen nei in kontener as EC2-eksimplaar. Graphcool soarget foar maklike konfiguraasje mei Auth0, wat makliker is dan it brûken fan autentikaasje-ark fan tredden.
De juste ferkeaper kieze foar jo serverleaze applikaasje is in beslút op arsjitektoanysk nivo. As jo in applikaasje oanmeitsje, ferwachtsje jo net ien dei werom te kommen nei it behearen fan servers. It kiezen fan in wolkferkeaper is net oars as it kiezen fan konteners as in databank, of sels in programmeartaal.
Beskôgje:
- Hokker tsjinsten hawwe jo nedich en wêrom.
- Hokker tsjinsten leverje wolkproviders en hoe kinne jo se kombinearje mei jo keazen FaaS-oplossing.
- Hokker programmeartalen wurde stipe (dynamysk as statysk typearre, kompilearre of ynterpretearre, wat binne de benchmarks, wat is de prestaasjes fan 'e kâlde start, wat is it iepen boarne-ekosysteem, ensfh.).
- Wat binne jo feiligenseasken (SLA, 2FA, OAuth, HTTPS, SSL, ensfh.).
- Hoe kinne jo jo CI / CD en softwareûntwikkelingssyklusen beheare.
- Hokker oplossings foar ynfrastruktuer as koade kinne jo profitearje fan?
As jo in besteande applikaasje útwreidzje en serverless funksjes taheakje, kin dit de beskikbere mooglikheden wat beheine. Lykwols, hast alle serverless technologyen jouwe in soarte fan API (fia REST of berjocht wachtrige) dat kinne jo meitsje tafoegings ûnôfhinklik fan de applikaasje kearn en mei maklike yntegraasje. Sjoch foar tsjinsten mei dúdlike API's, goede dokumintaasje en in sterke mienskip, en jo kinne net ferkeard gean. Gemak fan yntegraasje kin faaks in wichtige metryk wêze, en is wierskynlik ien fan 'e wichtichste redenen wêrom't AWS suksesfol is sûnt Lambda útkaam yn 2015.
Wannear is serverless nuttich?
Serverless technologyen kinne hast oeral brûkt wurde. Har foardielen binne lykwols net beheind ta allinich de metoaden fan tapassing. De barriêre foar yngong foar cloud computing is hjoed sa leech krekt fanwegen serverless technologyen. As ûntwikkelders in idee hawwe, mar se net witte hoe't se wolkynfrastruktuer beheare en kosten optimisearje, dan hoege se net te sykjen nei in yngenieur om it te dwaan. As in startup in platfoarm bouwe wol, mar benaud is dat de kosten út 'e kontrôle komme kinne, kinne se maklik nei serverleaze oplossingen wikselje.
Mei tank oan kosten besparring en gemak fan skaalfergrutting, serverless oplossings binne like fan tapassing foar sawol ynterne as eksterne systemen, oant in webapplikaasje mei in multimiljoen-dollar publyk. Accounts wurde mjitten yn sinten ynstee fan euro. It hieren fan de ienfâldichste AWS EC2-eksimplaar (t1.micro) foar in moanne kostet € 15, sels as jo der neat mei dogge (wa is oait fergetten om it út te setten?!). Yn ferliking, om dit nivo fan útjeften oer deselde perioade te berikken, soene jo in 512 MB Lambda moatte rinne foar 1 sekonde sawat 3 miljoen kear. En as jo dizze funksje net brûke, betelje jo neat.
Om't serverless primêr barren-oandreaune is, is it frij maklik om serverless ynfrastruktuer ta te foegjen oan legacy systemen. Bygelyks, mei help fan AWS S3, Lambda, en Kinesis, kinne jo meitsje in analytyske tsjinst foar in legacy retail systeem dat kin ûntfange gegevens fia in API.
De measte serverless platfoarms stypje meardere talen. Meastentiids binne dit Python, JavaScript, C#, Java en Go. Typysk hawwe alle talen gjin beheiningen foar it brûken fan biblioteken, dus jo kinne jo favorite iepen boarne-biblioteken brûke. It is lykwols oan te rieden om ôfhinklikens net te brûken, sadat jo funksjes optimaal prestearje en de foardielen fan 'e enoarme skaalberens fan jo serverless applikaasjes net annulearje. Hoe mear pakketten dy't yn 'e kontener laden wurde moatte, hoe langer de kâlde start duorret.
In kâlde start is as jo earst de kontener, runtime en flaterhanneler moatte inisjalisearje foardat jo se brûke. Hjirtroch kin de fertraging yn it útfieren fan funksjes oant 3 sekonden wêze, en dit is net de bêste opsje foar ûngeduldige brûkers. Kâlde starts komme lykwols foar by de earste oprop nei in pear minuten fan idle-funksje. Safolle beskôgje dit as in lyts oerlêst dat kin wurde omwurke troch de funksje regelmjittich te pingen om it idling te hâlden. Of se negearje dit aspekt hielendal.
Hoewol't AWS útbrochtSQL-databases binne lykwols net ideaal foar dit type gebrûk, om't se fertrouwe op ferbiningen om transaksjes út te fieren, dy't gau in knelpunt wurde kinne as d'r in soad ferkear is op AWS Lambda. Ja, ûntwikkelders ferbetterje Serverless Aurora konstant, en jo moatte dermei eksperimintearje, mar hjoed NoSQL-oplossingen lykas. D'r is lykwols gjin twifel dat dizze situaasje heul gau sil feroarje.
De toolkit stelt ek in protte beheiningen op, foaral op it mêd fan pleatslike testen. Hoewol d'r oplossingen binne lykas Docker-Lambda, DynamoDB Local en LocalStack, se fereaskje mânske wurk en in signifikante hoemannichte konfiguraasje. Al dizze projekten ûntwikkelje lykwols aktyf, dus it is mar in kwestje fan tiid foardat de ark it nivo berikke dat wy nedich binne.
De ynfloed fan serverless technologyen op 'e ûntwikkelingssyklus
Sûnt jo ynfrastruktuer gewoan konfiguraasje is, kinne jo koade definiearje en ynsette mei skripts, lykas shell-skripts. Of jo kinne taflecht ta konfiguraasje-as-koade klasse oplossings lykas . Hoewol dizze tsjinst gjin konfiguraasje foar alle gebieten leveret, kinne jo spesifike boarnen definiearje foar gebrûk as Lambda-funksjes. Dat is, wêr't CloudFormation jo mislearret, kinne jo jo eigen boarne skriuwe (Lambda-funksje) dy't dizze gat slute sil. Op dizze manier kinne jo alles dwaan, sels ôfhinklikens konfigurearje bûten jo AWS-omjouwing.
Om't it allegear gewoan konfiguraasje is, kinne jo jo ynsetskripts parameterisearje foar spesifike omjouwings, regio's en brûkers, foaral as jo ynfrastruktuer-as-koade-oplossingen brûke lykas CloudFormation. Jo kinne bygelyks in kopy fan 'e ynfrastruktuer ynsette foar elke tûke yn' e repository, sadat jo se folslein yn isolemint kinne testen tidens ûntwikkeling. Dit fersnelt radikaal de tiid dat ûntwikkelders feedback krije as se wolle begripe oft har koade adekwaat prestearret yn in live omjouwing. Behearders hoege gjin soargen te meitsjen oer de kosten fan it ynsetten fan meardere omjouwings, om't se allinich betelje foar werklik gebrûk.
DevOps hawwe minder te soargen oer, om't se allinich moatte soargje dat ûntwikkelders de juste konfiguraasje hawwe. Gjin mear eksimplaren, balancers of feiligensgroepen beheare. Dêrom wurdt de term NoOps hieltyd mear brûkt, hoewol it noch altyd wichtich is om de ynfrastruktuer te konfigurearjen, benammen as it giet om IAM-konfiguraasje en optimisaasje fan wolkboarnen.
D'r binne heul krêftige ark foar tafersjoch en sichtberens lykas Epsagon, Thundra, Dashbird en IOPipe. Se tastean jo de aktuele tastân fan serverless applikaasjes te kontrolearjen, logs en spoaren te leverjen, prestaasjesmetriken en arsjitektoanyske knyppunten te fangen, kostenanalyse en prognose út te fieren, en folle mear. Net allinich jouwe se DevOps-yngenieurs, ûntwikkelders en arsjitekten in wiidweidich sicht op applikaasjeprestaasjes, mar se meitsje ek managers yn steat om sichtberens te krijen yn real-time, twadde-by-sekonde besteging fan boarnen en kostenfoarsizzing. It is folle dreger om dit te organisearjen mei in behearde ynfrastruktuer.
It ûntwerpen fan tsjinnerleaze applikaasjes is folle makliker, om't jo gjin webservers hoege te ynsetten, firtuele masines of konteners, patchservers, bestjoeringssystemen, ynternetpoarten, ensfh. bedriuw en klant behoeften.
Wylst it ark better koe (it wurdt elke dei ferbettere), kinne ûntwikkelders har rjochtsje op it ymplementearjen fan saaklike logika en hoe't jo de kompleksiteit fan 'e applikaasje it bêste kinne fersprieden oer ferskate tsjinsten binnen de arsjitektuer. Serverless applikaasjebehear is evenemint-basearre en abstrahearre troch de wolkprovider (bygelyks SQS, S3-eveneminten of DynamoDB-streamen). Dêrom hoege ûntwikkelders allinich saaklike logika te skriuwen om te reagearjen op bepaalde eveneminten, en hoege net te soargen oer hoe't jo it bêste databases en berjochtwachtrige kinne ymplementearje, of hoe't jo optimaal wurkje mei gegevens yn spesifike hardware-opslach.
Koade kin lokaal wurde útfierd en debuggen, lykas by elk ûntwikkelingsproses. Unit testen bliuwt itselde. De mooglikheid om in folsleine applikaasje-ynfrastruktuer yn te setten mei in oanpaste stackkonfiguraasje lit ûntwikkelders fluch wichtige feedback krije sûnder har soargen te meitsjen oer de kosten fan testen of de ynfloed op djoere behearde omjouwings.
Tools en techniken foar it bouwen fan serverless applikaasjes
D'r is gjin spesifike manier om serverless applikaasjes te bouwen. Lykas in set fan tsjinsten foar dizze taak. De lieder ûnder machtige serverless oplossingen hjoed is AWS, mar betelje omtinken oan , и . As jo AWS brûke, dan kinne wy oanbefelje as in oanpak foar it sammeljen fan applikaasjes (SAM), benammen by it brûken fan C #, om't Visual Studio geweldige ark hat. De SAM CLI kin alles dwaan wat Visual Studio kin dwaan, dus jo sille neat ferlieze as jo oerstappe nei in oare IDE of tekstbewurker. Fansels wurket SAM ek mei oare talen.
As jo yn oare talen skriuwe, is it Serverless Framework in poerbêst iepen boarne-ark wêrmei jo alles kinne konfigurearje mei heul krêftige YAML-konfiguraasjebestannen. Serverless Framework stipet ek ferskate wolktsjinsten, dus wy riede it oan oan dyjingen dy't op syk binne nei in multi-cloud-oplossing. It hat in enoarme mienskip dy't in boskje plugins hat makke foar elke need.
Foar lokale testen binne iepen boarne-ark Docker-Lambda, Serverless Local, DynamoDB Local en LocalStack goed geskikt. Serverless technologyen binne noch yn in ier stadium fan ûntwikkeling, lykas de ark foar har, dus jo sille hurd moatte wurkje by it opsetten fan komplekse testsenario's. It gewoan ynsetten fan de stapel yn 'e omjouwing en it testen dêr blykt lykwols ongelooflijk goedkeap te wêzen. En jo hoege gjin krekte lokale kopy fan jo wolkomjouwings te meitsjen.
Brûk AWS Lambda-lagen om ynsette pakketgrutte te ferminderjen en laden tiden te fersnellen.
Brûk de juste programmeartalen foar spesifike taken. Ferskillende talen hawwe har eigen foardielen en neidielen. D'r binne in protte benchmarks, mar JavaScript, Python en C# (.NET Core 2.1+) binne de lieders yn termen fan AWS Lambda-prestaasjes. AWS Lambda hat koartlyn in Runtime API yntrodusearre wêrmei jo jo winske taal en runtime-omjouwing kinne opjaan, dus eksperimintearje.
Hâld ynsetpakketgrutte lyts. Hoe lytser se binne, hoe flugger se lade. Foarkom it brûken fan grutte bibleteken, foaral as jo in pear funksjes fan har brûke. As jo programmearje yn JavaScript, brûk dan bouwark lykas Webpack om jo build te optimalisearjen en allinich op te nimmen wat jo echt nedich binne. .NET Core 3.0 omfettet QuickJit en Tiered Compilation, dy't de prestaasjes ferbetterje en sterk helpe by kâlde starts.
De ôfhinklikens fan serverless funksjes fan eveneminten kin it earst lestich meitsje om saaklike logika te koördinearjen. Berjochtwachtrijen en steatmasines kinne yn dit ferbân ongelooflijk nuttich wêze. Lambda funksjes kinne skilje inoar, mar doch dit allinne as jo net ferwachtsje in antwurd ("fjoer en ferjitte") - jo net wolle krije fakturearre foar it wachtsjen op in oare funksje te foltôgjen. Berjochtwachtrijen binne nuttich foar it isolearjen fan stikken saaklike logika, it behearen fan knelpunten fan applikaasjes, en it ferwurkjen fan transaksjes (mei FIFO-wachtrijen). AWS Lambda funksjes kinne wurde tawiisd oan SQS wachtrijen as fêst berjocht wachtrijen dy't track mislearre berjochten foar lettere analyze. AWS Step Functions (steatmasines) binne heul nuttich foar it behearen fan komplekse prosessen dy't ketting fan funksjes nedich binne. Yn stee fan in Lambda funksje ropt in oare funksje, Step funksjes kinne koördinearje steat transysjes, trochjaan gegevens tusken funksjes, en beheare de globale steat fan funksjes. Hjirmei kinne jo betingsten foar opnij besykje te definiearjen, of wat te dwaan as in spesifike flater optreedt - in heul krêftich ark ûnder bepaalde betingsten.
konklúzje
Yn 'e ôfrûne jierren binne serverless technologyen ûntwikkele yn in ungewoane tempo. D'r binne bepaalde misferstannen ferbûn mei dizze paradigmaferoaring. Troch ynfrastruktuer te abstraheren en skaalberens te behearjen, biede serverless-oplossingen wichtige foardielen, fan ferienfâldige ûntwikkeling en DevOps-prosessen oant grutte ferlegings yn operasjonele kosten.
Hoewol de serverleaze oanpak net sûnder syn neidielen is, binne d'r betroubere ûntwerppatroanen dy't kinne wurde brûkt om robúste serverleaze applikaasjes te meitsjen of serverleaze eleminten te yntegrearjen yn besteande arsjitektuer.
Boarne: www.habr.com