Зашто је револуција без сервера у ћорсокаку

Кључне тачке

  • Већ неколико година нам је обећано да ће рачунарство без сервера увести нову еру без специфичног ОС-а за покретање апликација. Речено нам је да ће ова структура решити многе проблеме скалабилности. У ствари, све је другачије.
  • Иако многи сматрају да је без сервера нова идеја, њени корени се могу пратити до 2006. године са појавом Зимки ПааС-а и Гоогле Апп Енгине-а, од којих оба користе архитектуру без сервера.
  • Постоје четири разлога зашто је револуција без сервера застала, у распону од ограничене подршке програмског језика до проблема са перформансама.
  • Рачунарство без сервера није толико бескорисно. Нимало. Међутим, не треба их сматрати директном заменом за сервере. За неке апликације могу бити згодан алат.

Сервер је мртав, живео сервер!

Ово је бојни поклич револуције без сервера. Само брзи поглед на индустријску штампу у последњих неколико година и лако је закључити да је традиционални модел сервера мртав и да ћемо за неколико година сви користити архитектуре без сервера.

Као што свако у индустрији зна, и као што смо такође истакли у нашем чланку о стање рачунарства без сервера, ово није у реду. Упркос многим чланцима о заслугама револуција без сервера, никада се није догодило. Заправо, најновија истраживања показујуда је ова револуција можда дошла у ћорсокак.

Нека од обећања модела без сервера су свакако остварена, али не сва. Нису сви.

У овом чланку желим да погледам разлоге за ово стање. Зашто је недостатак флексибилности модела без сервера и даље препрека њиховом ширем усвајању, иако остају корисни у специфичним, добро дефинисаним околностима.

Оно што су адепти рачунарства без сервера обећали

Пре него што уђемо у изазове рачунарства без сервера, погледајмо шта је оно требало да пружи. Обећање револуције без сервера били бројни и - понекад - веома амбициозни.

За оне који нису упознати са термином, ево кратке дефиниције. Рачунарство без сервера дефинише архитектуру у којој апликације (или делови апликација) раде на захтев у окружењима која се обично хостују на даљину. Поред тога, системи без сервера могу бити смештени код куће. Изградња отпорних система без сервера била је главна брига за систем администраторе и СааС компаније у последњих неколико година, пошто (тврди се) ова архитектура нуди неколико кључних предности у односу на „традиционални“ клијент-сервер модел:

  1. Модели без сервера не захтевају од корисника да одржавају сопствене оперативне системе или чак да креирају апликације компатибилне са одређеним оперативним системима. Уместо тога, програмери креирају дељени код, отпремају га на платформу без сервера и гледају како ради.
  2. Ресурси у оквирима без сервера се обично наплаћују на минут (или чак на секунду). То значи да клијенти плаћају само за време када стварно покрену код. Ово је повољно у поређењу са традиционалним ВМ у облаку, где машина већину времена мирује, али за то морате да платите.
  3. Проблем скалабилности је такође решен. Ресурси у оквирима без сервера се динамички додељују тако да систем може лако да се носи са изненадним порастом потражње.

Укратко, модели без сервера пружају флексибилна, јефтина и скалабилна решења. Изненађујуће је да нам ова идеја није пала на памет.

Да ли је ово заиста нова идеја?

У ствари, идеја није нова. Концепт омогућавања корисницима да плаћају само за време када се код стварно покреће постоји од када га је увео Зимки ПааС 2006. године, а отприлике у исто време Гоогле Апп Енгине је понудио веома слично решење.

У ствари, оно што сада називамо моделом „без сервера“ старије је од многих технологија које се сада називају „нативе у облаку“ које пружају скоро исту ствар. Као што је наведено, модели без сервера су у суштини само продужетак СааС пословног модела који постоји деценијама.

Такође је вредно признати да без сервера није ФааС архитектура, иако постоји веза између њих. ФааС је у суштини део архитектуре без сервера усмерен на рачунаре, али не представља цео систем.

Дакле, око чега је сва гужва? Па, како стопе пенетрације интернета настављају да расту до неба у земљама у развоју, потражња за рачунарским ресурсима такође расте у исто време. На пример, многе земље са брзо растућим секторима е-трговине једноставно немају рачунарску инфраструктуру за апликације на овим платформама. Овде долазе плаћене платформе без сервера.

Проблеми са моделима без сервера

Квака је у томе што модели без сервера имају... проблеме. Немојте ме погрешно схватити: не кажем да су оне саме по себи лоше или да у неким околностима не пружају значајну вредност неким компанијама. Али главна тврдња „револуције“ – да ће архитектура без сервера брзо заменити традиционалну архитектуру – никада се не остварује.

Зато.

Ограничена подршка за програмске језике

Већина платформи без сервера вам омогућавају само покретање апликација које су написане на одређеним језицима. Ово озбиљно ограничава флексибилност и прилагодљивост ових система.

Сматра се да платформе без сервера подржавају већину главних језика. АВС Ламбда и Азуре функције такође пружају омотач за покретање апликација и функција на неподржаним језицима, иако то често долази са трошковима перформанси. Дакле, за већину организација ово ограничење обично није велика ствар. Али ево у чему је ствар. Једна од предности модела без сервера би требало да буде то што се мало познати, ретко коришћени програми могу користити јефтиније јер плаћате само време када раде. А мало познати, ретко коришћени програми су често написани на... мало познатим, ретко коришћеним програмским језицима.

Ово подрива једну од кључних предности модела без сервера.

Вендор биндинг

Други проблем са платформама без сервера, или барем начином на који се тренутно имплементирају, јесте то што оне обично нису сличне једна другој на оперативном нивоу. Практично не постоји стандардизација у погледу функција писања, распоређивања и управљања. То значи да је миграција функција са једне платформе на другу изузетно дуготрајна.

Најтежи део преласка на модел без сервера нису рачунарске функције, које су обично само делови кода, већ начин на који апликације комуницирају са повезаним системима као што су складиштење објеката, управљање идентитетом и редови. Функције се могу померати, али остатак апликације не може. Ово је сушта супротност јефтиним и флексибилним платформама које су обећане.

Неки тврде да су модели без сервера нови и да није било времена да се стандардизује њихов рад. Али они нису толико нови, као што сам горе приметио, и многе друге технологије у облаку, као што су контејнери, већ су постале много употребљивије захваљујући развоју и широком усвајању добрих стандарда.

Перформансе

Рачунарске перформансе платформи без сервера је тешко измерити, делом зато што продавци теже да информације чувају приватно. Већина тврди да функције на удаљеним платформама без сервера раде једнако брзо као оне на интерним серверима, са изузетком неколико неизбежних проблема са кашњењем.

Међутим, појединачне чињенице говоре супротно. Функцијама које раније нису радиле на одређеној платформи или нису радиле неко време биће потребно неко време да се иницијализују. Ово је вероватно због чињенице да је њихов код пренет на неки мање приступачан медијум за складиштење података, иако - као и код бенчмарка - већина добављача вам неће рећи о миграцији података.

Наравно, постоји неколико начина да се ово заобиђе. Један је да оптимизујете функције за било који клауд језик на којем ваша платформа без сервера ради, али то донекле подрива тврдњу да су ове платформе „агилне“.

Други приступ је да се осигура да се програми од кључне важности за продуктивност покрећу редовно како би били ажурирани. Овај други приступ је, наравно, помало контрадикторан тврдњи да су платформе без сервера исплативије јер плаћате само време које ваши програми раде. Провајдери у облаку увели су нове начине за смањење хладног стартовања, али многи од њих захтевају „размеру до један“, што поткопава првобитну вредност ФааС-а.

Проблем хладног покретања може се делимично решити покретањем система без сервера у кући, али то долази са сопственим трошковима и остаје ниша опција за тимове са добрим ресурсима.

Не можете покренути целе апликације

Најзад, можда најважнији разлог зашто архитектуре без сервера неће ускоро заменити традиционалне моделе: оне (обично) не могу да покрећу целе апликације.

Тачније, непрактично је са становишта трошкова. Ваш успешан монолит вероватно не би требало да се претвара у скуп од четири десетине функција повезаних са осам гатеваи-а, четрдесет редова и десетак инстанци базе података. Из тог разлога, сервер без сервера је погоднији за нови развој. Скоро ниједна постојећа апликација (архитектура) се не може мигрирати. Можете мигрирати, али морате почети од нуле.

То значи да се у великој већини случајева платформе без сервера користе као допуна позадинским серверима за обављање рачунарски интензивних задатака. Ово их чини веома различитим од друга два облика цлоуд технологија — контејнера и виртуелних машина — које нуде холистички начин за обављање даљинског рачунарства. Ово илуструје један од изазова преласка са микросервиса на без сервера.

Наравно, ово није увек проблем. Могућност повременог коришћења огромних рачунарских ресурса без куповине сопственог хардвера може донети стварне, трајне користи многим организацијама. Али када се неке апликације налазе на интерним серверима, а друге на архитектури облака без сервера, управљање поприма нови ниво сложености.

Живела револуција?

Упркос свим овим притужбама, нисам против решења без сервера сама по себи. Искрено. Програмери само треба да схвате – посебно ако први пут истражују без сервера – да технологија није директна замена за сервере. Уместо тога, погледајте наше савете и ресурсе за креирање апликација без сервера и одлучите како најбоље применити модел.

Извор: ввв.хабр.цом

Додај коментар