Акыркы жылдары серверсиз технологиялар тез популярдуулукка ээ болгону менен, алар менен байланышкан көптөгөн жаңылыш түшүнүктөр жана коркуулар дагы эле бар. Сатуучуга көз карандылык, шаймандар, чыгымдарды башкаруу, муздак баштоо, мониторинг жана иштеп чыгуунун жашоо цикли серверсиз технологияларга келгенде ысык темалар. Бул макалада биз кээ бир айтылган темаларды изилдейбиз, ошондой эле жаңы баштагандарга күчтүү, ийкемдүү жана үнөмдүү серверсиз тиркемелерди түзүүгө жардам берүү үчүн кеңештерди жана пайдалуу маалымат булактарына шилтемелерди бөлүшөбүз.
Серверсиз технологиялар жөнүндө жаңылыш ойлор
Көптөр серверсиз жана серверсиз иштетүү (, FaaS) дээрлик бирдей нерсе. Бул айырма өтө чоң эмес жана бир жаңылык киргизүүгө арзыйт дегенди билдирет. AWS Lambda серверсиз гүлдөп турган доордун жылдыздарынын бири жана серверсиз архитектуранын эң популярдуу элементтеринин бири болгонуна карабастан, бул архитектура FaaSге караганда алда канча көп.
Серверсиз технологиялардын негизги принциби - инфраструктураңызды башкаруу жана масштабдоо жөнүндө тынчсыздануунун кереги жок, сиз колдонгонуңуз үчүн гана төлөйсүз. Көптөгөн кызматтар ушул критерийлерге туура келет - AWS DynamoDB, S3, SNS же SQS, Graphcool, Auth0, Now, Netlify, Firebase жана башкалар. Жалпысынан, серверсиз инфраструктураны башкаруунун жана масштабдоо үчүн оптималдаштыруунун зарылдыгы жок булуттагы эсептөөнүн толук күчүн колдонууну билдирет. Бул ошондой эле инфраструктуралык деңгээлдеги коопсуздук мындан ары сизди кызыктырбай турганын билдирет, бул коопсуздук стандарттарына жооп берүүнүн татаалдыгын жана татаалдыгын эске алганда, чоң пайда. Акыры, сизге берилген инфраструктураны сатып алуунун кереги жок.
Серверсиз "акыл абалы" деп эсептесе болот: чечимдерди иштеп чыгууда белгилүү бир менталитет. Кандайдыр бир инфраструктураны тейлөөнү талап кылган ыкмалардан алыс болуңуз. Серверсиз ыкма менен биз долбоорго түздөн-түз таасир этүүчү жана колдонуучуларыбызга пайда алып келген маселелерди чечүүгө убакыт короттук: биз туруктуу бизнес логикасын түзөбүз, колдонуучу интерфейстерин иштеп чыгабыз жана адаптацияланган жана ишенимдүү APIлерди иштеп чыгабыз.
Мисалы, эркин текст издөө платформасын башкаруудан жана тейлөөдөн качуу мүмкүн болсо, анда биз эмне кылабыз. Тиркемелерди курууга мындай ыкма рынокко чыгуу убактысын бир топ тездетет, анткени мындан ары татаал инфраструктураны башкаруу жөнүндө ойлонуунун кереги жок. Инфраструктураны башкаруу боюнча жоопкерчиликтерди жана чыгымдарды жок кылыңыз жана кардарларыңыз керек болгон тиркемелерди жана кызматтарды түзүүгө көңүл буруңуз. Бул ыкманы Патрик Дебуа деп атады , термин серверсиз коомчулукта кабыл алынган. Функцияларды жайгаштырылуучу модулдар катары кызматтарга шилтеме катары кароо керек (бүтүн китепкананы же веб тиркемесин жайылтуунун ордуна). Бул колдонмону жайгаштырууну жана өзгөртүүнү башкаруу үчүн укмуштуудай гранулдуулукту камсыз кылат. Эгер сиз функцияларды ушундай жол менен жайгаштыра албасаңыз, анда бул функциялар өтө көп тапшырмаларды аткарып жатканын жана рефакторациялоону талап кылышы мүмкүн.
Кээ бирлери булут тиркемелерин иштеп чыгууда сатуучуга көз карандылык менен чаташтырышат. серверсиз технологиялар менен да ушундай болот жана бул туура эмес түшүнүк. Биздин тажрыйбабызда AWSде серверсиз тиркемелерди куруу, AWS Lambdaнын башка AWS кызматтарын бириктирүү жөндөмдүүлүгү менен айкалыштыруу серверсиз архитектуралардын күчтүүлүгүнүн бир бөлүгү болуп саналат. Бул синергетиканын жакшы мисалы, айкалыштыруу натыйжасы терминдердин суммасынан да көп болгондо. Сатуучуга көз карандылыктан качууга аракет кылуу дагы көп көйгөйлөргө алып келиши мүмкүн. Контейнерлер менен иштөөдө булут провайдерлеринин ортосунда өзүңүздүн абстракция катмарыңызды башкаруу оңой. Бирок серверсиз чечимдерге келгенде, күч-аракет өз жемишин бербейт, айрыкча рентабелдүүлүк башынан эле эске алынса. Сатуучулар кантип кызмат көрсөтөөрүн билип алыңыз. Кээ бир адистештирилген кызматтар башка сатуучулар менен интеграциялоо пункттарына таянышат жана кутудан тышкары плагин жана ойнотуу байланышын камсыз кылышы мүмкүн. Сурамды кандайдыр бир контейнерге же EC2 инстанциясына проксиге өткөрүүгө караганда, шлюз API акыркы чекитинен Lambda чалуу менен камсыз кылуу оңой. Graphcool Auth0 менен оңой конфигурацияны камсыз кылат, бул үчүнчү тараптын аутентификация куралдарын колдонуудан оңой.
Серверсиз тиркемеңиз үчүн туура сатуучуну тандоо архитектуралык чечим болуп саналат. Тиркемени түзүп жатканда, сиз бир күнү серверлерди башкарууга кайтып келет деп ойлобойсуз. Булут сатуучуну тандоо контейнерлерди же маалымат базасын, ал тургай программалоо тилин колдонууну тандоодон эч кандай айырмасы жок.
карап көрөлү:
- Сизге кандай кызматтар керек жана эмне үчүн.
- Булут провайдерлери кандай кызматтарды көрсөтөт жана аларды сиз тандаган FaaS чечими менен кантип айкалыштыра аласыз.
- Кандай программалоо тилдери колдоого алынат (динамикалык же статикалык терүү менен, компиляцияланган же интерпретацияланган, эталондор кандай, муздак старттын натыйжалуулугу кандай, ачык булак экосистемасы кандай ж.б.).
- Сиздин коопсуздук талаптарыңыз кандай (SLA, 2FA, OAuth, HTTPS, SSL, ж.б.).
- CI/CD жана программалык камсыздоону иштеп чыгуу циклдерин кантип башкаруу керек.
- Кайсы инфраструктура-код чечимдеринен пайдалана аласыз.
Эгер сиз учурдагы тиркемени кеңейтип, серверсиз функцияларды акырындап кошсоңуз, бул жеткиликтүү мүмкүнчүлүктөрдү бир аз чектеши мүмкүн. Бирок, дээрлик бардык серверсиз технологиялар API'нин кандайдыр бир түрүн (REST же билдирүү кезеги аркылуу) камсыздайт, бул колдонмонун өзөгүнөн көз карандысыз жана оңой интеграцияланган кеңейтүүлөрдү түзүүгө мүмкүндүк берет. Таза API'лери, жакшы документтери жана күчтүү коомчулугу бар кызматтарды издеңиз жана жаңылбайсыз. Интеграциянын жөнөкөйлүгү көбүнчө негизги көрсөткүч болушу мүмкүн жана AWS 2015-жылы Lambda чыгарылгандан бери ушунчалык ийгиликтүү болушунун негизги себептеринин бири болсо керек.
Серверсиз жакшы болгондо
Серверсиз технологиялар дээрлик бардык жерде колдонулушу мүмкүн. Бирок, алардын артыкчылыктары колдонуунун бир гана жолу менен чектелбейт. Бүгүнкү күндө серверсиз технологиялардын аркасында булуттагы эсептөөлөргө кирүүдөгү тоскоолдук абдан төмөн. Эгерде иштеп чыгуучулардын идеясы бар болсо, бирок алар булут инфраструктурасын кантип башкарууну жана чыгымдарды оптималдаштырууну билишпесе, анда бул үчүн кандайдыр бир инженерди издөөнүн кереги жок. Эгерде стартап платформа кургусу келсе, бирок чыгымдар көзөмөлдөн чыгып кетиши мүмкүн деп корксо, алар серверсиз чечимдерге оңой кайрыла алышат.
Чыгымдарды үнөмдөөнүн жана масштабдаштыруунун жөнөкөйлүгүнөн улам серверсиз чечимдер ички жана тышкы системалар үчүн бирдей колдонулат, көп миллион аудиториясы бар веб-тиркемеге чейин. Эсептер евро менен эмес, цент менен өлчөнөт. AWS EC2 (t1.micro) эң жөнөкөй нускасын бир айга ижарага алуу €15 турат, аны менен эч нерсе кылбасаңыз да (ким аны өчүрүүнү эч качан унутпаган?!). Салыштыруу үчүн, ошол эле убакыттын ичинде чыгымдын мындай деңгээлине жетүү үчүн 512 МБ Lambdaны 1 секундага болжол менен 3 миллион жолу иштетишиңиз керек болот. Ал эми бул функцияны колдонбосоңуз, анда сиз эч нерсе төлөбөйсүз.
Серверсиз, негизинен, окуяга негизделгендиктен, эски системаларга серверсиз инфраструктураны кошуу оңой. Мисалы, AWS S3, Lambda жана Kinesis колдонуп, сиз API аркылуу маалыматтарды ала турган эски чекене система үчүн аналитика кызматын түзө аласыз.
Көпчүлүк серверсиз платформалар бир нече тилди колдойт. Көбүнчө бул Python, JavaScript, C#, Java жана Go. Адатта бардык тилдердеги китепканаларды колдонууга эч кандай чектөөлөр жок, ошондуктан сиз сүйүктүү ачык булак китепканаларын колдоно аласыз. Бирок, сиздин функцияларыңыз оптималдуу иштеши жана серверсиз тиркемелериңиздин чоң масштабдуулугунун артыкчылыктарын жокко чыгарбашы үчүн, көз карандылыкты кыянаттык менен пайдаланбоо сунушталат. Контейнерге канчалык көп таңгактарды салуу керек болсо, сууктун башталышы ошончолук узакка созулат.
Контейнерди, иштөө убактысын жана каталарды иштеткичти колдонуудан мурун инициализациялоо керек болгондо суук баштоо. Ушундан улам, функциялардын аткарылышынын кечигиши 3 секундга чейин болушу мүмкүн жана бул чыдамсыз колдонуучулар үчүн эң жакшы вариант эмес. Бирок, сууктун башталышы биринчи чакырууда бир нече мүнөттүк иштебей тургандан кийин пайда болот. Көптөр муну анча-мынча кыжырдануу деп эсептешет, аны иштебей кармап туруу үчүн функцияны үзгүлтүксүз пинг аркылуу чечсе болот. Же бул жагын такыр этибарга алышпайт.
AWS чыгарылган болсо даБирок, SQL маалымат базалары бул колдонмо үчүн идеалдуу эмес, анткени алар транзакцияларды жүргүзүү үчүн туташууларга көз каранды, алар тез эле AWS Lambda трафиктин оордугуна алып келиши мүмкүн. Ооба, иштеп чыгуучулар Serverless Aurora дайыма өркүндөтүп жатышат, жана сиз аны менен эксперимент кылышыңыз керек, бирок бүгүн NoSQL чечимдери. Бирок, бул абалдын тез арада өзгөрөөрүндө шек жок.
Инструменттер топтому да көптөгөн чектөөлөрдү киргизет, айрыкча жергиликтүү тестирлөө тармагында. Docker-Lambda, DynamoDB Local жана LocalStack сыяктуу чечимдер бар болсо да, алар оор эмгекти жана олуттуу конфигурацияны талап кылат. Бирок, бул долбоорлордун баары жигердүү иштелип чыккан, ошондуктан инструменттер топтому бизге керектүү деңгээлге жетүү аз гана маселе.
Серверсиз технологиялардын өнүгүү циклине тийгизген таасири
Инфраструктураңыз жөн гана конфигурация болгондуктан, сиз скрипттердин жардамы менен кодду аныктап, жайгаштырсаңыз болот, мисалы, кабык скрипттери. Же сиз конфигурация-код классындагы чечимдерге кайрыла аласыз . Бул кызмат бардык аймактар үчүн конфигурацияны камсыз кылбаса да, Ламбда функциялары катары колдонуу үчүн атайын ресурстарды аныктоого мүмкүндүк берет. Башкача айтканда, CloudFormation сизди аткарбай калса, сиз бул боштукту жаап турган өз ресурсуңузду (Lambda функциясы) жаза аласыз. Ушундай жол менен сиз каалаган нерсени кыла аласыз, атүгүл AWS чөйрөңүздөн тышкары көз карандылыктарды конфигурациялай аласыз.
Мунун баары жөн гана конфигурация болгондуктан, сиз жайылтуу скрипттериңизди конкреттүү чөйрөлөр, аймактар жана колдонуучулар үчүн ыңгайлаштыра аласыз, айрыкча 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 - бул абдан күчтүү YAML конфигурация файлдары менен каалаган нерсени конфигурациялоого мүмкүндүк берген эң сонун ачык булак куралы. Serverless Framework ошондой эле ар кандай булут кызматтарын колдойт, ошондуктан биз аны көп булуттуу чечимди издегендерге сунуштайбыз. Бул ар кандай муктаждыктар үчүн плагиндердин бир тобун жараткан чоң коомчулукка ээ.
Жергиликтүү тестирлөө үчүн 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 процесстеринен операциялык чыгымдарды массалык түрдө кыскартууга чейин олуттуу артыкчылыктарды сунуштайт.
Серверсиз ыкманын кемчиликтери болбосо да, серверсиз тиркемелерди куруу же серверсиз элементтерди учурдагы архитектурага интеграциялоо үчүн колдонула турган бекем дизайн үлгүлөрү бар.
Source: www.habr.com