Эмне үчүн серверсиз революция токтоп калды

Негизги учурлар

  • Бир нече жылдан бери бизге серверсиз эсептөөлөр тиркемелерди иштетүү үчүн конкреттүү ОС жок жаңы доорду ачат деп убадаланган. Бизге бул структура масштабдуулуктун көптөгөн көйгөйлөрүн чечет деп айтышкан. Чынында, баары башкача.
  • Көпчүлүк серверсизди жаңы идея катары карашса да, анын тамырын 2006-жылга чейин Zimki PaaS жана Google App Engine пайда болушу менен издөөгө болот, экөө тең серверсиз архитектураны колдонушат.
  • Серверсиз революциянын токтоп калганынын төрт себеби бар, алар чектелген программалоо тилин колдоодон баштап аткаруу маселелерине чейин.
  • Серверсиз эсептөө анчалык деле пайдасыз эмес. Эч нерсе эмес. Бирок, алар серверлерди түздөн-түз алмаштыруу катары каралбашы керек. Кээ бир колдонмолор үчүн алар ыңгайлуу курал болушу мүмкүн.

Сервер өлдү, жашасын сервер!

Бул серверсиз революциянын согуштук кыйкырыгы. Акыркы бир нече жылдагы өнөр жай прессасына тез көз чаптырсаңыз, салттуу сервер модели өлүп калган жана бир нече жылдан кийин биз бардыгыбыз серверсиз архитектураларды колдонобуз деп тыянак чыгаруу оңой.

Бул тармактагы ар бир адам билет, жана биз дагы биздин макалада белгилегендей серверсиз эсептөө абалы, бул андай эмес. артыкчылыгы жөнүндө көптөгөн макалаларга карабастан серверсиз революция, ал эч качан болгон эмес. Чындыгында, акыркы изилдөө көрсөтүп туратбул революция туюк чекке жеткен болушу мүмкүн деп.

Серверсиз моделдердин кээ бир убадалары аткарылды, бирок баары эмес. Баары эмес.

Бул макалада мен бул абалдын себептерин карап келет. Эмне үчүн серверсиз моделдердин ийкемдүүлүгүнүн жоктугу, алар конкреттүү, так аныкталган шарттарда пайдалуу бойдон калса дагы, аларды кеңири кабыл алуу үчүн тоскоолдук болуп саналат.

Серверсиз эсептөө чеберлери эмнени убада кылышкан

Серверсиз эсептөөнүн көйгөйлөрүнө кирүүдөн мурун, анын эмне менен камсыз болушу керек экенин карап көрөлү. Серверсиз революциянын убадасы көп болгон жана - кээде - абдан дымактуу.

Терминди билбегендер үчүн бул жерде кыскача аныктама. Серверсиз эсептөөлөр, адатта, алыстан жайгаштырылган иштөө чөйрөлөрүндө өтүнмөлөр (же колдонмолордун бөлүктөрү) талап боюнча иштей турган архитектураны аныктайт. Мындан тышкары, серверсиз системаларды үйдө жайгаштырууга болот. Туруктуу серверсиз системаларды куруу акыркы бир нече жыл ичинде системалык администраторлор жана SaaS компаниялары үчүн негизги көйгөй болуп келген, анткени (делип айтылган) бул архитектура "салттуу" кардар-сервер моделине караганда бир нече негизги артыкчылыктарды сунуш кылат:

  1. Серверсиз моделдер колдонуучулардан өздөрүнүн операциялык системаларын сактоону, атүгүл белгилүү бир ОС менен шайкеш тиркемелерди түзүүнү талап кылбайт. Анын ордуна, иштеп чыгуучулар жалпы кодду түзүп, аны серверсиз платформага жүктөп, анын иштешин көрүшөт.
  2. Серверсиз алкактардагы ресурстар, адатта, мүнөткө (же секундасына) эсепке алынат. Бул кардарлар кодду иштеткен убакыт үчүн гана төлөшөт дегенди билдирет. Бул салттуу булут VM менен жакшы салыштырылат, мында машина көпчүлүк убакта иштебейт, бирок сиз аны төлөшүңүз керек.
  3. Масштабдуулук маселеси да чечилди. Серверсиз алкактардагы ресурстар динамикалык түрдө дайындалган, ошондуктан система суроо-талаптын күтүлбөгөн жерден көтөрүлүшүнө оңой туруштук бере алат.

Кыскача айтканда, серверсиз моделдер ийкемдүү, арзан, масштабдуу чечимдерди камсыз кылат. Бул идеяны эртерээк ойлонбогонубуз таң калыштуу.

Бул чындап эле жаңы идеябы?

Чынында, идея жаңы эмес. Колдонуучуларга код иштеп жаткан убакыт үчүн гана төлөөгө уруксат берүү концепциясы аны киргизгенден бери бар Zimki PaaS 2006-жылы жана ошол эле убакта Google App Engine абдан окшош чечимди сунуш кылган.

Чындыгында, биз азыр "серверсиз" модел деп атаган нерсе, азыр "булуттагы жергиликтүү" деп аталган көптөгөн технологияларга караганда бир эле нерсени камсыз кылат. Белгиленгендей, серверсиз моделдер негизинен ондогон жылдар бою болуп келген SaaS бизнес моделинин кеңейтилиши болуп саналат.

Экөөнүн ортосунда байланыш бар болсо да, серверсиз FaaS архитектурасы эмес экенин моюнга алуу керек. FaaS негизинен серверсиз архитектуранын эсептөө борборлоштурулган бөлүгү, бирок ал бүт системаны билдирбейт.

Анда эмне ызы-чуу болуп жатат? Өнүгүп келе жаткан өлкөлөрдө интернеттин кирүү ылдамдыгы өсүп жаткандыктан, ошол эле учурда эсептөө ресурстарына суроо-талап да өсүп жатат. Мисалы, тез өнүгүп жаткан электрондук коммерция секторлору бар көптөгөн өлкөлөрдө бул платформалардагы тиркемелер үчүн эсептөө инфраструктурасы жок. Бул жерде акы төлөнүүчү серверсиз платформалар пайда болот.

Серверсиз моделдер менен көйгөйлөр

Серверсиз моделдердин... көйгөйлөрү бар. Мени жаңылыштырбаңыз: мен алар жаман деп айтуудан алысмын же кээ бир шарттарда кээ бир компанияларга олуттуу маани бербейт. Бирок "революциянын" негизги талабы - серверсиз архитектура салттуу архитектураны тез алмаштырат - эч качан ишке ашпайт.

Ошол үчүн.

Программалоо тилдери үчүн чектелген колдоо

Көпчүлүк серверсиз платформалар белгилүү тилдерде жазылган тиркемелерди иштетүүгө гана мүмкүнчүлүк берет. Бул бул системалардын ийкемдүүлүгүн жана ийкемдүүлүгүн олуттуу чектейт.

Серверсиз платформалар көпчүлүк негизги тилдерди колдойт деп эсептелет. AWS Lambda жана Azure Functions ошондой эле колдоого алынбаган тилдердеги тиркемелерди жана функцияларды иштетүү үчүн каптаманы камсыз кылат, бирок бул көбүнчө аткаруу баасы менен коштолот. Ошентип, көпчүлүк уюмдар үчүн бул чектөө, адатта, чоң иш эмес. Бирок кеп мына ушунда. Серверсиз моделдердин артыкчылыктарынын бири аз белгилүү, сейрек колдонулган программаларды арзаныраак колдонсо болот, анткени сиз алар иштеген убакыт үчүн гана төлөйсүз. Ал эми анча белгилүү эмес, сейрек колдонулган программалар көбүнчө... аз белгилүү, сейрек колдонулган программалоо тилдеринде жазылат.

Бул серверсиз моделдин негизги артыкчылыктарынын бирин жокко чыгарат.

Сатуучуга милдеттүү

Серверсиз платформалардын экинчи көйгөйү, же жок эле дегенде, алардын азыркы учурда ишке ашырылышы, адатта, операциялык деңгээлде бири-бирине окшош эмес. Жазуу функциялары, жайылтуу жана башкаруу жагынан стандартташтыруу дээрлик жок. Бул функцияларды бир платформадан экинчи платформага көчүрүү өтө көп убакытты талап кылат дегенди билдирет.

Серверсиз моделге өтүүнүн эң кыйын бөлүгү, адатта, коддун үзүндүлөрү болгон эсептөө функциялары эмес, тиркемелер объект сактагыч, идентификацияны башкаруу жана кезек сыяктуу туташкан системалар менен кантип байланышат. Функцияларды жылдырса болот, бирок колдонмонун калган бөлүгүн жылдыра албайт. Бул убада кылынган арзан жана ийкемдүү платформалардын так карама-каршылыгы.

Айрымдар серверсиз моделдер жаңы жана алардын иштешин стандартташтырууга убакыт болгон жок деп ырасташат. Бирок алар мен жогоруда белгилегендей жаңы эмес жана башка көптөгөн булут технологиялары, мисалы, контейнерлер жакшы стандарттарды иштеп чыгуунун жана кеңири жайылтуунун аркасында алда канча колдонууга жарамдуу болуп калды.

кирешелүүлүк

Серверсиз платформалардын эсептөө көрсөткүчтөрүн өлчөө кыйын, анткени сатуучулар маалыматты купуя сакташат. Көпчүлүгү алыскы, серверсиз платформалардагы функциялар ички серверлердегидей тез иштейт деп ырасташат, бир нече сөзсүз кечигүү маселелерин кошпогондо.

Бирок айрым фактылар мунун тескерисин көрсөтүп турат. Мурда белгилүү бир платформада иштебеген же бир нече убакыт бою иштебеген функцияларды инициализациялоо үчүн бир аз убакыт талап кылынат. Бул, кыязы, алардын коду азыраак жеткиликтүү сактагычка көчүрүлгөндүгүнө байланыштуу болушу мүмкүн, бирок - эталондордогудай - көпчүлүк сатуучулар сизге маалыматтардын миграциясы жөнүндө айтышпайт.

Албетте, мунун бир нече жолу бар. Алардын бири - серверсиз платформаңыз кайсы булут тилинде иштебесин, функцияларды оптималдаштыруу, бирок бул бул платформалар "шапкы" деген дооматты бир аз жокко чыгарат.

Дагы бир ыкма өндүрүмдүүлүккө байланыштуу маанилүү программаларды жаңыртуу үчүн үзгүлтүксүз ишке ашырылышын камсыз кылуу болуп саналат. Бул экинчи ыкма, албетте, серверсиз платформалар үнөмдүү деген дооматка бир аз карама-каршы келет, анткени сиз программаларыңыз иштеп жаткан убакыт үчүн гана төлөйсүз. Булут провайдерлери сууктун башталышын азайтуунун жаңы жолдорун киргизишти, бирок алардын көбү "бирге масштабды" талап кылат, бул FaaSтин баштапкы маанисин жокко чыгарат.

Муздак баштоо көйгөйүн жарым-жартылай серверсиз системаларды үй ичинде иштетүү менен чечсе болот, бирок бул өзүнүн чыгымдары менен коштолот жана жакшы ресурстар менен камсыз болгон командалар үчүн эң сонун вариант бойдон калууда.

Сиз толук колдонмолорду иштете албайсыз

Акырында, серверсиз архитектуралар салттуу моделдерди тез арада алмаштыра албашынын эң маанилүү себеби: алар (көбүнчө) тиркемелерди толугу менен иштете албайт.

Тагыраагы, чыгымдык көз караштан алганда иш жүзүнө ашпайт. Сиздин ийгиликтүү монолитиңиз сегиз шлюз, кырк кезек жана ондогон маалымат базасы инстанциялары менен байланышкан төрт ондогон функциялардын жыйындысына айланбашы керек. Ушул себептен улам, серверсиз жаңы иштеп чыгуулар үчүн ылайыктуу. Колдонмого дээрлик эч кандай (архитектура) көчүрүлбөйт. Миграция кыла аласыз, бирок нөлдөн башташыңыз керек.

Бул көпчүлүк учурларда серверсиз платформалар интенсивдүү эсептөөлөрдү талап кылган тапшырмаларды аткаруу үчүн сервердик серверлерге кошумча катары колдонулат дегенди билдирет. Бул аларды алыстан эсептөөнү аткаруунун бирдиктүү жолун сунуш кылган булут технологияларынын башка эки формасынан – контейнерлерден жана виртуалдык машиналардан абдан айырмалайт. Бул микросервистерден серверсизге өтүүдөгү кыйынчылыктардын бирин көрсөтөт.

Албетте, бул дайыма эле көйгөй боло бербейт. Өзүңүздүн аппараттык жабдууңузду сатып албай туруп, мезгил-мезгили менен масштабдуу эсептөө ресурстарын колдонуу мүмкүнчүлүгү көптөгөн уюмдарга реалдуу, туруктуу пайда алып келет. Бирок кээ бир тиркемелер ички серверлерде, башкалары серверсиз булут архитектурасында болгондо, башкаруу татаалдыктын жаңы деңгээлине өтөт.

Жашасын революция?

Бардык бул даттанууларга карабастан, мен серверсиз чечимдерге каршы эмесмин. Чынын айтсам. Иштеп чыгуучулар жөн гана түшүнүшү керек, өзгөчө, эгерде алар серверсиз серверди биринчи жолу изилдеп жатышса, технология серверлерди түз алмаштыруу эмес. Анын ордуна, биздин кеңештерди жана ресурстарды карап көрүңүз серверсиз тиркемелерди түзүү жана моделди кантип колдонууну чечиңиз.

Source: www.habr.com

Комментарий кошуу