Клучните точки
- Веќе неколку години ни беше ветено дека пресметувањето без сервер ќе воведе нова ера без специфичен ОС за извршување на апликации. Ни беше кажано дека оваа структура ќе реши многу проблеми со приспособливост. Всушност, сè е поинаку.
- Додека многумина гледаат без сервери како нова идеја, неговите корени можат да се следат уште во 2006 година со појавата на Zimki PaaS и Google App Engine, кои користат архитектура без сервер.
- Постојат четири причини зошто револуцијата без сервери е запрена, почнувајќи од ограничена поддршка на програмскиот јазик до проблеми со перформансите.
- Пресметувањето без сервер не е толку бескорисно. Воопшто не. Сепак, тие не треба да се сметаат за директна замена за серверите. За некои апликации тие можат да бидат корисна алатка.
Серверот е мртов, да живее серверот!
Ова е борбен крик на револуцијата без сервери. Само еден брз поглед на печатот во индустријата во изминатите неколку години и лесно е да се заклучи дека традиционалниот модел на сервер е мртов и дека во рок од неколку години сите ние ќе користиме архитектури без сервери.
Како што знае секој во индустријата, и како што исто така истакнавме во нашата статија за , ова е погрешно. И покрај многуте написи за заслугите , никогаш не се одржа. Всушност, дека оваа револуција можеби дошла во ќорсокак.
Некои од ветувањата за модели без сервер секако се реализирани, но не сите. Не сите.
Во оваа статија сакам да ги разгледам причините за оваа состојба. Зошто недостатокот на флексибилност на моделите без сервер сè уште е пречка за нивно пошироко усвојување, иако тие остануваат корисни во специфични, добро дефинирани околности.
Што ветија експертите за компјутери без сервери
Пред да навлеземе во предизвиците на компјутерите без сервери, ајде да погледнеме што требаше да обезбеди. беа многубројни и - на моменти - многу амбициозни.
За оние кои не се запознаени со терминот, еве брза дефиниција. Пресметувањето без сервер дефинира архитектура во која апликациите (или делови од апликациите) работат на барање во опкружувања за траење кои обично се хостирани од далечина. Покрај тоа, системи без сервер може да се хостираат дома. Изградбата на еластични системи без сервер беше главна грижа за системските администратори и SaaS компаниите во последните неколку години, бидејќи (се тврди) оваа архитектура нуди неколку клучни предности во однос на „традиционалниот“ модел клиент-сервер:
- Моделите без сервер не бараат од корисниците да одржуваат сопствени оперативни системи, па дури и да создаваат апликации компатибилни со одредени оперативни системи. Наместо тоа, програмерите создаваат заеднички код, го поставуваат на платформа без сервер и гледаат како работи.
- Ресурсите во рамки без сервер обично се наплаќаат во минута (или дури и секунда). Ова значи дека клиентите плаќаат само за времето кога всушност го извршуваат кодот. Ова поволно се споредува со традиционалниот Cloud VM, каде што машината е неактивен поголемиот дел од времето, но треба да платите за тоа.
- Решен е и проблемот со приспособливост. Ресурсите во рамки без сервери се динамички доделени така што системот лесно може да се справи со ненадејните скокови на побарувачката.
Накратко, моделите без сервер обезбедуваат флексибилни, евтини, скалабилни решенија. Изненадувачки е што не помисливме на оваа идеја порано.
Дали е ова навистина нова идеја?
Всушност, идејата не е нова. Концептот да им се дозволи на корисниците да плаќаат само за времето кога кодот всушност работи постои уште од неговото воведување во 2006 година и во исто време Google App Engine понуди многу слично решение.
Всушност, она што сега го нарекуваме модел „без сервер“ е постар од многу технологии кои сега се нарекуваат „народен облак“ кои го обезбедуваат речиси истото. Како што е наведено, моделите без сервер во суштина се само продолжение на бизнис моделот SaaS кој постои со децении.
Исто така, вреди да се признае дека без сервер не е архитектура FaaS, иако постои врска помеѓу двете. FaaS во суштина е пресметковно-центричен дел од архитектурата без сервер, но не го претставува целиот систем.
Па за што е целата врева? Па, како што стапката на пенетрација на интернет продолжува да расте вртоглаво во земјите во развој, побарувачката за компјутерски ресурси исто така се зголемува во исто време. На пример, многу земји со рапидно растечки сектори за е-трговија едноставно немаат компјутерска инфраструктура за апликации на овие платформи. Тука влегуваат платформите без сервери кои се плаќаат.
Проблеми со модели без сервер
Финтата е што моделите без сервер имаат... проблеми. Не ме сфаќајте погрешно: не велам дека се лоши сами по себе или не даваат значителна вредност на некои компании во некои околности. Но, главното тврдење на „револуцијата“ - дека архитектурата без сервер брзо ќе ја замени традиционалната архитектура - никогаш не се материјализира.
Затоа.
Ограничена поддршка за програмски јазици
Повеќето платформи без сервер ви дозволуваат да извршувате само апликации кои се напишани на одредени јазици. Ова сериозно ја ограничува флексибилноста и приспособливоста на овие системи.
Се смета дека платформите без сервер ги поддржуваат повеќето главни јазици. Функциите AWS Lambda и Azure исто така обезбедуваат обвивка за извршување на апликации и функции на неподдржани јазици, иако ова често доаѓа со трошоци за изведба. Така, за повеќето организации ова ограничување обично не е голема работа. Но, тука е работата. Една од придобивките на моделите без сервер се претпоставува дека е тоа што малку познатите, ретко користените програми може да се користат поевтино бидејќи плаќате само за времето што тие се извршуваат. А малку познатите, ретко користените програми често се пишуваат на... малку познати, ретко користени програмски јазици.
Ова ја поткопува една од клучните придобивки на моделот без сервер.
Обврзувачки за продавачот
Вториот проблем со платформите без сервер, или барем начинот на кој тие моментално се имплементирани, е тоа што тие обично не се слични една на друга на оперативно ниво. Практично нема стандардизација во однос на функциите за пишување, распоредување и управување. Ова значи дека мигрирањето на функциите од една на друга платформа е исклучително одзема време.
Најтешкиот дел од преместувањето кон модел без сервер не се пресметувачките функции, кои обично се само фрагменти од код, туку како апликациите комуницираат со поврзаните системи како што се складирање на објекти, управување со идентитетот и редици. Функциите може да се преместат, но остатокот од апликацијата не може. Ова е сосема спротивно од евтините и флексибилни платформи кои се ветени.
Некои тврдат дека моделите без сервер се нови и немаше време да се стандардизира како функционираат. Но, тие не се толку нови, како што забележав погоре, и многу други облак технологии, како што се контејнерите, веќе станаа многу поупотребливи благодарение на развојот и широкото усвојување на добри стандарди.
Перформанси
Компјутерските перформанси на платформите без сервер е тешко да се измерат, делумно затоа што продавачите имаат тенденција да ги чуваат информациите приватни. Повеќето тврдат дека функциите на оддалечените платформи без сервер работат исто толку брзо како и оние на внатрешните сервери, со исклучок на неколку неизбежни проблеми со латентност.
Меѓутоа, поединечните факти го покажуваат спротивното. Функциите што претходно не се извршувале на одредена платформа или не се извршувале некое време, ќе биде потребно извесно време за да се иницијализираат. Ова најверојатно се должи на фактот дека нивниот код е пренесен на некој помалку достапен медиум за складирање, иако - како и со одредниците - повеќето продавачи нема да ви кажат за миграцијата на податоците.
Се разбира, постојат неколку начини околу ова. Една од нив е да се оптимизираат функциите за кој било облак јазик на кој работи вашата платформа без сервер, но ова донекаде го поткопува тврдењето дека овие платформи се „агилни“.
Друг пристап е да се осигура дека програмите кои се критични за продуктивноста се извршуваат редовно за да се одржуваат свежи. Овој втор пристап, се разбира, е малку контрадикторен со тврдењето дека платформите без сервер се поисплатливи затоа што плаќате само за времето кога се извршуваат вашите програми. Обезбедувачите на облак воведоа нови начини за намалување на ладните стартови, но многу од нив бараат „скала до еден“, што ја поткопува оригиналната вредност на FaaS.
Проблемот со ладното стартување може делумно да се реши со водење системи без сервери во куќата, но ова доаѓа со свои трошоци и останува нишана опција за тимови со добро ресурси.
Не можете да извршите цели апликации
Конечно, можеби најважната причина зошто архитектурите без сервер нема да ги заменат традиционалните модели во скоро време: тие (обично) не можат да извршуваат цели апликации.
Поточно, тоа е непрактично од гледна точка на трошоци. Вашиот успешен монолит веројатно не треба да се претвори во збир од четири дузина функции поврзани со осум порти, четириесет редици и десетина примероци на база на податоци. Поради оваа причина, без сервер е подобро прилагоден за нови случувања. Речиси ниту една постоечка апликација (архитектура) не може да се мигрира. Можете да мигрирате, но мора да започнете од нула.
Ова значи дека во огромното мнозинство на случаи, платформите без сервер се користат како дополнување на задни сервери за извршување на задачи со интензивна пресметка. Ова ги прави многу различни од другите две форми на облак технологии - контејнери и виртуелни машини - кои нудат холистички начин за извршување на далечинско пресметување. Ова го илустрира еден од предизвиците за преминување од микросервис до без сервер.
Се разбира, ова не е секогаш проблем. Способноста периодично да се користат масивни компјутерски ресурси без да се купува сопствен хардвер може да донесе вистински, трајни придобивки за многу организации. Но, кога некои апликации се наоѓаат на внатрешни сервери, а други на облак архитектури без сервери, управувањето добива ново ниво на сложеност.
Да живее револуцијата?
И покрај сите овие поплаки, јас не сум против решенија без сервер сами по себе. Искрено. Програмерите само треба да разберат - особено ако истражуваат без сервери за прв пат - дека технологијата не е директна замена за серверите. Наместо тоа, проверете ги нашите совети и ресурси за и одлучете како најдобро да го примените моделот.
Извор: www.habr.com