Хоць бессерверныя тэхналогіі ў апошнія гады хутка набіраюць папулярнасць, з імі ўсё яшчэ звязана шмат памылак і асцярог. Залежнасць ад вендара, інструментарый, кіраванне выдаткамі, халодны старт, маніторынг і жыццёвы цыкл распрацоўкі - усе гэтыя тэмы актыўна абмяркоўваюцца, калі гаворка заходзіць аб бессерверных тэхналогіях. У гэтым артыкуле мы разгледзім некаторыя са згаданых тэм, а таксама падзелімся парадамі і спасылкамі на карысныя крыніцы інфармацыі, з дапамогай якіх навічкі змогуць стварыць магутныя, гнуткія і эканамічныя бессерверныя прыкладанні.
Памылкі адносна бессерверных тэхналогій
Шмат хто лічыць, што бессервернасць і пазасерверная апрацоўка дадзеных (, FaaS) - гэта амаль адно і тое ж. Значыць, розніца не занадта вялікая і варта ўкараніць навінку. Хоць AWS Lambda была адной з "зорак" росквіту бессерверных тэхналогій і адным з самых папулярных элементаў бессервернай архітэктуры, аднак гэтая архітэктура ўяўляе сабой нешта большае, чым FaaS.
Асноўны прынцып бессерверных тэхналогій заключаецца ў тым, што вам не трэба клапаціцца аб кіраванні і маштабаванні інфраструктуры, вы плаціце толькі за тое, чым карыстаецеся. Пад гэтыя крытэры падыходзіць мноства сэрвісаў – AWS DynamoDB, S3, SNS або SQS, Graphcool, Auth0, Now, Netlify, Firebase і многія іншыя. У цэлым, бессервернасць мае на ўвазе выкарыстанне ўсіх магчымасцяў хмарных вылічэнняў без неабходнасці кіравання інфраструктурай і яе аптымізацыі дзеля маштабавання. Таксама гэта азначае, што бяспека на ўзроўні інфраструктуры больш не ваша праблема, а гэтая велізарная перавага, улічваючы цяжкасць і складанасць захавання стандартаў бяспекі. Нарэшце, вам не трэба купляць прадстаўленую вам у карыстанне інфраструктуру.
Бессервернасць можна лічыць "станам розуму": пэўнай ментальнасцю пры праектаванні рашэнняў. Пазбягайце падыходаў, якія патрабуюць абслугоўвання любой інфраструктуры. Пры бессерверным падыходзе мы трацім час на вырашэнне задач, якія непасрэдна ўплываюць на праект і прыносяць выгаду для нашых карыстальнікаў: ствараем устойлівую бізнес-логіку, развіваем карыстацкія інтэрфейсы і распрацоўваем адаптыўныя і надзейныя API.
Напрыклад, калі можна пазбегнуць кіравання і суправаджэння платформы свабоднага тэкставага пошуку, то менавіта так мы і зробім. Такі падыход да зборкі прыкладанняў здольны моцна паскорыць выснову прадукта на рынак, бо вам не трэба больш думаць аб кіраванні складанай інфраструктурай. Пазбаўляйцеся ад абавязкаў і выдаткаў на кіраванне інфраструктурай і засяродзьцеся на стварэнні прыкладанняў і сэрвісаў, якія патрэбны вашым кліентам. Патрык Дэбуа назваў такі падыход , гэты тэрмін прыняты ў бессервернай супольнасці. Функцыі трэба разглядаць як злучнае звяно для сэрвісаў у выглядзе разгортваемых модуляў (замест разгортвання цэлай бібліятэкі або вэб-прыкладанні). Гэта забяспечвае неверагодную гранулярнасць кіравання разгортваннем і зменамі ў дадатку. Калі вы не можаце такім чынам разгортваць функцыі, тое гэта можа казаць аб тым, што функцыі выконваюць занадта шмат задач і павінны быць адрэфактараны.
Некаторых бянтэжыць залежнасць ад вендара пры распрацоўцы хмарных прыкладанняў. Тое ж самае і з бессервернымі тэхналогіямі, і наўрад ці гэта следства памылкі. Па нашым досведзе, стварэнне бессерверных прыкладанняў на AWS у спалучэнні са здольнасцю AWS Lambda аб'ядноўваць іншыя AWS-сэрвісы – усё гэта збольшага і фармуе добрыя якасці бессерверных архітэктур. Гэта добры прыклад сінэргіі, калі вынік аб'яднання атрымліваецца большы, чым проста сума складнікаў. Спрабуючы пазбегнуць залежнасці ад вендара, вы можаце сутыкнуцца з яшчэ вялікімі праблемамі. Пры працы з кантэйнерамі прасцей кіраваць уласным узроўнем абстракцыі паміж хмарнымі правайдэрамі. Але калі гаворка заходзіць аб бессерверных рашэннях, намаганні не будуць акупляцца, асабліва калі з самага пачатку ўлічваць эканамічную эфектыўнасць. Абавязкова высветліце, як вендары забяспечваюць прадастаўленне паслуг. Некаторыя спецыялізаваныя сэрвісы залежаць ад кропак інтэграцыі з іншымі вендарамі, і са скрынкі могуць падаваць магчымасць падлучэння ў стылі plug-and-play. Прасцей забяспечыць выклік Lambda з канчатковай кропкі API шлюза, чым праксіраваць запыт у нейкі кантэйнер або асобнік EC2. Graphcool забяспечвае простае канфігураванне з дапамогай Auth0, а гэта прасцей, чым выкарыстоўваць іншыя сродкі аўтэнтыфікацыі.
Выбар правільнага вендара для вашага бессервернага прыкладання - гэта рашэнне архітэктурнага ўзроўню. Пры стварэнні прыкладання вы не разлічваеце, што аднойчы вернецеся да кіравання серверамі. Выбар хмарнага вендара нічым не адрозніваецца ад выбару выкарыстання кантэйнераў ці базы дадзеных, ці нават мовы праграмавання.
Абдумайце:
- Якія сэрвісы вам патрэбны і чаму.
- Якія сэрвісы падаюць хмарныя правайдэры і як вы можаце аб'яднаць іх з дапамогай абранага FaaS-рашэнні.
- Якія мовы праграмавання падтрымліваюцца (з дынамічным ці статычным тыпізаваннем, кампіляваныя ці інтэрпрэтаваныя, якія ёсць бенчмаркі, якая прадукцыйнасць пры халодным старце, якая open source-экасістэма і г.д.).
- Якія вашыя патрабаванні па бяспецы (SLA, 2FA, OAuth, HTTPS, SSL і г.д.).
- Як кіраваць вашым CI/CD і цыкламі распрацоўкі ПЗ.
- Перавагамі якіх рашэнняў класа infrastructure-as-code вы можаце скарыстацца.
Калі вы пашыраеце наяўнае прыкладанне і інкрыментальна дадаеце бессерверныя функцыі, тое гэта можа некалькі абмежаваць даступныя магчымасці. Аднак амаль усе бессерверныя тэхналогіі падаюць нейкія API (праз REST ці чэргі паведамленняў), якія дазваляюць ствараць пашырэнні незалежна ад ядра прыкладання і з простай інтэграцыяй. Шукайце сэрвісы са зразумелымі API, добрай дакументацыяй і моцнай супольнасцю, і не памыліцеся. Прастата інтэграцыі часцяком можа быць ключавой метрыкай, і, верагодна, гэта адна з галоўных прычын поспеху AWS з тых часоў, як у 2015-м выйшла Lambda.
Калі карысная бессервернасць
Бессерверныя тэхналогіі можна прымяняць практычна ўсюды. Аднак іх добрыя якасці не абмяжоўваюцца аднымі толькі спосабамі ўжывання. Парог уваходу для хмарных вылічэнняў сёння так нізкі менавіта дзякуючы бессерверным тэхналогіям. Калі ў распрацоўшчыкаў ёсць ідэя, але яны не ведаюць, як кіраваць хмарнай інфраструктурай і аптымізаваць выдаткі, то ім не трэба шукаць нейкага інжынера для гэтага. Калі стартап жадае стварыць платформу, але асцерагаецца, што выдаткі могуць выйсці з-пад кантролю, ён лёгка можа звярнуцца да бессерверных рашэнняў.
Дзякуючы эканоміі выдаткаў і прастаце маштабавання, бессерверныя рашэнні аднолькава дастасавальныя як для ўнутраных сістэм, так і для вонкавых, аж да вэб-прыкладанні са шматмільённай аўдыторыяй. Рахункі вымяраюцца хутчэй не ў еўра, а ў цэнтах. Арэнда самага простага асобніка AWS EC2 (t1.micro) на працягу месяца абыйдзецца ў €15, нават калі вы нічога з ім не робіце (хто ні разу не забываў выключыць?!). Для параўнання, каб дасягнуць такога ўжо ўзроўню выдаткаў за той жа перыяд часу, вам спатрэбіцца запусціць Lambda памерам 512 Мб на 1 секунду прыкладна 3 мільёны разоў. А калі вы не выкарыстоўваеце гэтую функцыю, то нічога не плаціце.
Бо бессерверная тэхналогія залежыць пераважна ад падзей, можна даволі лёгка дадаць у старыя сістэмы бессерверную інфраструктуру. Напрыклад, з дапамогай AWS S3, Lambda і Kinesis вы можаце стварыць аналітычны сэрвіс для старой раздробнай сістэмы, які зможа атрымліваць дадзеныя праз API.
Большасць бессерверных платформаў падтрымліваюць розныя мовы. Часцей за ўсё гэта Python, JavaScript, C#, Java і Go. Звычайна ва ўсіх мовах няма ніякіх абмежаванняў па выкарыстанні бібліятэк, так што можаце прымяняць свае любімыя open source-бібліятэкі. Аднак пажадана не марнатравіць залежнасцямі, каб вашы функцыі выконваліся аптымальна і не абнулялі перавагі велізарнай маштабаванасці вашых бессерверных прыкладанняў. Чым больш пакетаў трэба загрузіць у кантэйнер, тым даўжэй будзе выконвацца халодны запуск.
Халодны запуск - гэта калі неабходна спачатку ініцыялізаваць кантэйнер, асяроддзе выканання і апрацоўшчык памылак, перш чым імі карыстацца. З-за гэтага затрымка выканання функцый можа дасягаць 3 секунд, а гэта не найлепшы варыянт для нецярплівых карыстальнікаў. Аднак халодныя запускі бываюць пры першым звароце праз некалькі хвілін прастою функцыі. Так што многія лічаць гэта нязначным нязручнасцю, якое можна абыйсці з дапамогай рэгулярнага пінгавання функцыі, каб падтрымліваць яе на халастым ходу. Ці ўвогуле ігнаруюць гэты аспект.
Хаця AWS выпусціла, усё ж SQL-базы не ідэальныя для падобнага ўжывання, бо пры выкананні транзакцый яны залежаць ад падлучэнняў, якія могуць хутка стаць вузкім месцам пры вялікім трафіку на AWS Lambda. Так, распрацоўнікі стала паляпшаюць Serverless Aurora, і вам варта паэксперыментаваць з ёй, аднак сёння для бессерверных сістэм значна лепш падыходзяць NoSQL-рашэнні накшталт. Зрэшты, несумненна, што гэтая сітуацыя вельмі хутка зменіцца.
Інструментарый таксама накладвае нямала абмежаванняў, асабліва ў сферы лакальнага тэсціравання. Хоць і існуюць рашэнні накшталт Docker-Lambda, DynamoDB Local і LocalStack, аднак яны патрабуюць карпатлівай працы і значнага аб'ёму канфігуравання. Зрэшты, усе гэтыя праекты актыўна развіваюцца, так што гэта толькі пытанне часу, калі інструментарый дасягне неабходнага нам узроўня.
Уплыў бессерверных тэхналогій на цыкл распрацоўкі
Паколькі ваша інфраструктура ўяўляе сабой проста канфігурацыю, можна задаць і разгарнуць код з дапамогай скрыптоў, напрыклад, shell-скрыптоў. Ці можна звярнуцца да рашэнняў класа configuration-as-code накшталт . Хоць гэты сэрвіс і не падае канфігурацыю для ўсіх сфер, але затое дазваляе вызначаць пэўныя рэсурсы для выкарыстання ў якасці Lambda-функцый. Гэта значыць там, дзе CloudFormation вас падвядзе, вы можаце напісаць свой рэсурс (Lambda-функцыю), які закрые гэты пралом. Такім чынам, вы можаце зрабіць што заўгодна, нават сканфігураваць залежнасці за межамі вашага AWS-акружэння.
Паколькі ўсё гэта проста канфігурацыя, вы можаце параметрызаваць вашыя скрыпты разгортвання пад пэўныя асяроддзі, рэгіёны і карыстачоў, асабліва калі ўжываеце рашэнні класа infrastructure-as-code накшталт CloudFormation. Напрыклад, вы можаце разгарнуць копію інфраструктуры для кожнай галінкі ў рэпазітары, каб цалкам ізалявана тэставаць іх у ходзе распрацоўкі. Гэта радыкальна паскарае атрыманне распрацоўшчыкамі зваротнай сувязі, калі жадаюць зразумець, ці адэкватна працуе іх код у жывым асяроддзі. Кіраўнікам не трэба турбавацца аб кошце разгортвання шматлікіх акружэнняў, бо аплачваецца толькі фактычнае выкарыстанне.
У DevOps становіцца менш клопатаў, паколькі ім трэба толькі пераканацца, што ў распрацоўшчыкаў карэктная канфігурацыя. Больш не трэба кіраваць інстансамі, балансавальнікамі або групамі бяспекі. Таму ўсё часцей ужываюць тэрмін NoOps, хоць усё яшчэ важна ўмець канфігураваць інфраструктуру, асабліва калі гаворка ідзе аб IAM-канфігурацыі і аптымізацыі хмарных рэсурсаў.
Ёсць вельмі магутныя прылады для маніторынгу і навочнага прадстаўлення накшталт Epsagon, Thundra, Dashbird і IOPipe. Яны дазваляюць адсочваць бягучы стан бессерверных прыкладанняў, падаюць часопісы і трасіроўку, рэгіструюць метрыкі прадукцыйнасці і вузкія месцы архітэктуры, выконваюць аналіз і прагназаванне выдаткаў, і шматлікае іншае. Яны не толькі даюць DevOps-інжынерам, распрацоўшчыкам і архітэктарам вычарпальнае ўяўленне аб рабоце прыкладанняў, але і дазваляюць кіраўнікам адсочваць сітуацыю ў рэальным часе, з пасекунднымі выдаткамі на рэсурсы і прагназаваннем выдаткаў. Арганізаваць такое з кіруемай інфраструктурай значна цяжэй.
Праектаваць бессерверныя прыкладанні значна прасцей, таму што вам не трэба разгортваць вэб-серверы, кіраваць віртуальнымі машынамі ці кантэйнерамі, патчыць серверы, аперацыйныя сістэмы, інтэрнэт-шлюзы і т. д. Абстрагаванне ад усіх гэтых абавязкаў дазваляе бессервернай архітэктуры засяродзіцца на галоўным - на рашэнні патрэбаў бізнесу і кліентаў.
Хоць інструментар мог быць і лепш (ён паляпшаецца з кожным днём), аднак распрацоўшчыкі могуць засяродзіцца на рэалізацыі бізнес-логікі і найлепшым размеркаванні складанасці прыкладання па розных сэрвісах у межах архітэктуры. Кіраванне бессервернымі праграмамі выконваецца на аснове падзей і абстрагавана хмарным правайдэрам (напрыклад, SQS, S3-падзеі або DynamoDB-струмені). Таму распрацоўшчыкам дастаткова толькі прапісаць бізнес-логіку для рэакцыі на пэўныя падзеі, і можна не турбавацца аб тым, як лепш рэалізаваць базы даных і чэргі паведамленняў, або як арганізаваць аптымальную работу з дадзенымі ў канкрэтных апаратных сховішчах.
Код можна выконваць і адладжваць лакальна, як і пры любым працэсе распрацоўкі. Модульнае тэсціраванне застаецца ранейшым. Магчымасць разгортваць цэлую інфраструктуру прыкладання з дапамогай наладжвальнай канфігурацыі стэка дазваляе распрацоўнікам хутка атрымліваць важную зваротную сувязь, не думаючы аб кошце тэставання ці аб уплыве на дарагія кіраваныя асяроддзі.
Інструменты і методыкі зборкі бессерверных прыкладанняў
Не існуе пэўнага спосабу зборкі бессерверных дадаткаў. Як і наборы сэрвісаў для гэтай задачы. Лідэрам сярод магутных бессерверных рашэнняў сёння з'яўляецца AWS, аднак звернеце ўвагу яшчэ на , и . Калі вы выкарыстоўваеце AWS, то ў якасці падыходу да збору прыкладанняў можна парэкамендаваць (SAM), асабліва пры выкарыстанні C#, паколькі ў Visual Studio выдатны інструментар. SAM CLI можа рабіць усё тое ж самае, што і Visual Studio, так што вы нічога не страціце, калі пяройдзеце на іншы IDE або тэкставы рэдактар. Вядома, SAM працуе і з іншымі мовамі.
Калі вы пішаце на іншых мовах, то Serverless Framework - цудоўны open source-інструмент, які дазваляе сканфігураваць што заўгодна з дапамогай вельмі магутных канфігурацыйных YAML-файлаў. Таксама Serverless Framework падтрымлівае розныя хмарныя сэрвісы, таму рэкамендуемы яго тым, хто шукае мультывоблачнае рашэнне. У яго велізарная супольнасць, якое стварыла кучу плагінаў пад любыя патрэбы.
Для лакальнага тэсціравання добра падыходзяць open source-інструменты Docker-Lambda, Serverless Local, DynamoDB Local і LocalStack. Бессерверныя тэхналогіі пакуль яшчэ знаходзяцца ў ранняй стадыі развіцця, як і інструментар для іх, так што пры наладзе пад складаныя сцэнары тэставання прыйдзецца папацець. Аднак проста разгарнуць стэк у асяроддзі і пратэставаць там атрымліваецца неверагодна танна. І вам не трэба рабіць дакладную лакальную копію хмарных асяродкаў.
Для памяншэння памераў разгорнутых пакетаў і паскарэння загрузкі выкарыстоўвайце AWS Lambda Layers.
Выкарыстоўвайце для канкрэтных задач правільныя мовы праграмавання. У розных моў свае добрыя якасці і недахопы. Існуе шмат бенчмаркаў, але JavaScript, Python і C# (.NET Core 2.1+) – лідэры з пункту гледжання прадукцыйнасці AWS Lambda. Нядаўна ў AWS Lambda з'явіўся Runtime API, які дазваляе паказваць жаданую мову і асяроддзе выканання, так што эксперыментуйце.
Падтрымлівайце невялікі памер пакетаў для разгортвання. Чым яны меншыя, тым хутчэй загружаюцца. Пазбягайце выкарыстання вялікіх бібліятэк, асабліва калі выкарыстоўваеце з іх пару фіч. Калі праграмуеце на JavaScript, то выкарыстоўвайце прылады для зборкі накшталт Webpack, каб аптымізаваць зборку і ўключаць толькі тое, што вам сапраўды трэба. У .NET Core 3.0 ёсць QuickJit і Tiered Compilation, якія паляпшаюць прадукцыйнасць і моцна дапамагаюць пры лядоўнях запусках.
Залежнасць бессерверных функцый ад падзей спачатку можа абцяжарыць каардынаванне бізнес-логікі. У сувязі з гэтым неверагодна карыснымі могуць быць чэргі паведамленняў і канчатковыя аўтаматы. Lambda-функцыі здольныя выклікаць адзін аднаго, але рабіце гэта толькі ў тым выпадку, калі не чакаеце атрымання адказу ("стрэліў і забыўся") - вы ж не хочаце атрымліваць рахунак за чаканне завяршэння іншай функцыі. Чэргі паведамленняў карысныя для адасаблення частак бізнес-логікі, кіравання вузкімі месцамі прыкладанняў і апрацоўкі транзакцый (з дапамогай FIFO-чэргаў). Функцыі AWS Lambda могуць быць прыпісаны да SQS-чаргаў у якасці чэргаў «якія завіслі» паведамленняў, якія адсочваюць збойныя паведамленні для наступнага аналізу. Функцыі AWS Step Functions (канчатковыя аўтаматы) вельмі карысныя для кіравання складанымі працэсамі, якія патрабуюць стварэння ланцужкоў функцый. Замест таго каб Lambda-функцыя выклікала іншую функцыю, Step-функцыі могуць каардынаваць пераходы станаў, перадаваць дадзеныя паміж функцыямі і кіраваць глабальным станам функцый. Гэта дазваляе вызначаць умовы паўторных спроб, ці што трэба рабіць пры ўзнікненні канкрэтнай памылкі — у пэўных умовах вельмі магутная прылада.
Заключэнне
У апошнія гады бессерверныя тэхналогіі развіваюцца нябачанымі тэмпамі. З гэтай зменай парадыгмы звязаны пэўныя памылкі. Дзякуючы абстрагаванню інфраструктуры і кіраванні маштабаваннем бессерверныя рашэнні прапануюць значныя выгады: ад спрашчэння распрацоўкі і DevOps-працэсаў, да вялікага зніжэння аперацыйных выдаткаў.
І хоць бессерверны падыход не пазбаўлены недахопаў, аднак існуюць надзейныя методыкі патэрны праектавання, з дапамогай якіх можна стварыць устойлівыя бессерверныя прыкладанні ці інтэграваць бессерверныя элементы ў наяўныя архітэктуры.
Крыніца: habr.com