EnterpriseTales Мали, помали, AWS Ламбда
Од кога стана најсовремена да се поделат монолитите во уредни, мали модули - ака микросервиси - се навикнавме на фактот дека традиционалниот сервер за апликации се смета дека е укинат. Наместо да се потпирате на големо траење, во денешно време потребните фрагменти на серверот се спакувани директно со техничкиот код, давајќи му некаква интегрирана околина за време на траење. Целата работа е спакувана во неколку контејнери, обезбедени со малку функционалност за управување и следење и апликацијата е подготвена.
Како да не беше доволно, терминот апликации без сервер се појавуваше сè повеќе и повеќе во блиското минато. Уште еднаш, Амазон е пионер со AWS Lambda. Но, конкурентите како што се IBM со openWhisk, Google со Cloud Functions или Microsoft со Azure Functions се во почетните блокови. Значи, може ли во иднина серверите и инфраструктурата да се испуштаат целосно? Ако е така, како треба да работи тоа? И за кого е тоа дури интересно? Потребно е појаснување. Случај за Enterprise Tales!
Што е апликација без сервер?
Терминот апликација без сервер е малку иритирачка затоа што сугерира дека можете да направите без околина за време на траење за вашиот сопствен код на апликација. Ова не е случај. Наместо тоа, терминот сака да изрази дека апликациите без сервер интензивно користат услуги од трети страни, како што се бази на податоци во облак, датотечни системи и портали на API (заднински дел како услуга или скратено BaaS) или сопствен код за апликација во подеднакво надворешен, нестабилен компјутер Контејнерот истекува (Функција како услуга, скратено FaaS). Комбинациите на двата пристапа секако се исто така дозволени. Гугл пишува: „Функциите се лесно, асинхроно компјутерско решение засновано на настани, што ви овозможува да креирате мали, еднонаменски функции кои реагираат на облачни настани без потреба да управувате со сервер или околина за време на траење“.
Без сервер во фокусот
Тековното списание Јава општо се занимава со програмирање без сервери.
Апликации со допир на ништо: Архитектура без сервер
Ние го придружуваме фокусот на проблемот на JAXenter со понатамошни написи на оваа тема.
Објавено досега:
PaaS, BaaS или FaaS?
Со многу акроними можете да се збуните. Додека PaaS (Платформата како услуга) сака да се сфати повеќе како платформа за развој и распоредување, т.е. е одговорен за управување, извршување и следење на апликациите и нивниот код, BaaS обезбедува корисни системи за заднини како што се бази на податоци, датотечни системи или автентикација Услуги на кои програмерите можат да им се обраќаат директно од нивните апликации.
Но, како FaaS се вклопува во сликата? Идејата на FaaS е дека развивачот на апликации спроведува код од страна на серверот (функции), но ниту еден сервер за апликации или вграден сервер не се користи како време на траење, туку „контејнер за пресметување без држави“ заснован на облак. Со други зборови, инвеститорот едноставно ја распоредува својата функција со вчитување на поврзаниот код директно во облакот и дефинирање на активирање, односно настан што предизвикува извршување на кодот. Таков настан може на пр. Ова може да биде, на пример, зачувување на датотека во системот за датотеки во облак, додавање на запис за податоци во базата на податоци на облак или барање против портал на облак API. Веднаш штом ќе се активира соодветен настан, функцијата FaaS започнува и извршува во посебен процес. Ресурсите за време на траење, како што се процесорот или меморијата, се користат само кога постои реална потреба.
Главната единствена продажна точка на FaaS е тоа што можете да извршите код за заднини без да мора да управувате со сопствени сервери за апликации или серверски апликации. Исто така, нема потреба да управувате со контејнери. Скалирањето го дава давателот на ФааС. Бесплатно? Па, не точно. Како по правило, сметките се засноваат на повици или време на процесорот - со AWS Lambda во чекори од 100 ms. Колку е повисок или поинтензивно компјутерски повик, толку е поскапа функцијата при извршување.
Ве молам, пример?
Типичен пример за FaaS функција ќе биде услуга за обработка на заднина за обработка на ресурси, на пр. Б. Слики. Ако корисникот вчита слика во облакот, настан може да се активира со зачувување на сликата во датотечниот систем заснован на облак, што ја активира функцијата FaaS, што потоа автоматски генерира сликички или алтернативни формати на слики. За возврат, овие се зачувани и во датотечниот систем заснован на облак.
Но, што е со апликациите управувани од UI, на пр. Б. веб-продавница? Тука може да се замисли и апликација без сервер. Да претпоставиме како почетна точка дека интерфејсот на веб-продавницата е имплементиран како апликација со една страница (СПА), т.е. дел од деловната логика се наоѓа во клиентот. Автентикацијата може да се изврши преку услугата BaaS заснована на облак; едноставни, прочитајте прашања на базата, исто така, на пр. B. да ги наведе достапните производи. Можеме да спроведеме покомплексни дејства, како што е пребарувањето што може да се парамеризира, користејќи ја функцијата FaaS што вметнува пристап до основната база на податоци за облак. Но, како се активира ова? Ова е местото каде влегува API-портата, т.е. еден вид конфигуриран HTTP-сервер кој го прима нашето барање за пребарување како http-барање, ги трансформира пренесените параметри на влезните параметри на нашата функција и подоцна го враќа резултатот во форма на исто трансформиран одговор на HTTP. Самиот портал API е секако и компонента заснована на облак што треба само да се конфигурира.
За спроведување на функциите FaaS, Amazon Lambda нуди поддршка за програмските јазици JavaScript, Python и Java. Планирани се понатамошни јазици. Од друга страна, функциите на Google поддржуваат само JavaScript, IBM OpenWhisk JavaScript и Swift. Најшироката поддршка моментално ја обезбедуваат Microsoft Azure Functions со JavaScript, C #, Python и PHP.
Состојба и перформанси
По дефиниција, функциите на FaaS не споделуваат меморија и затоа треба да бидат без државјанство. Или извршувате само трансформации или пресметки на пренесените параметри или ја добивате состојбата потребна за пресметка од бази на податоци во облак, датотечни системи или мемории за вкрстена апликација.
Функцијата FaaS е започната, извршена и потоа повторно завршена кога е потребно. Во зависност од избраниот програмски јазик или основното траење, може да има одредена почетна латентност. Во случај на JavaScript или Python, ова тешко е важно во однос на вистинскиот код. Изгледа малку поинаку кога кодот се извршува во JVM. Во неповолни соelвездија, ова може да доведе до значителни почетни одложувања. Ова е секогаш случај ако помине многу време помеѓу два повика или врвовите доведуваат до значително повеќе повици од вообичаеното. Како по правило, овој проблем може да се занемари освен ако не треба да се спроведе апликација со барања во реално време.
Функциите на FaaS обично се ограничени во времето на извршување. Amazon Lambda има ограничување од 300 секунди. Ако сакате да моделирате долготрајни процеси, треба да дизајнирате соодветна архитектура што ќе ги подели на неколку функции на FaaS.
Како работи тестирањето со без сервер?
Бидејќи кодот на функцијата FaaS обично не е потребна состојба или го добива од систем на трета страна што лесно се потсмева, единичните тестови се лесни за спроведување. Но, што е со тестовите за интеграција? Овде станува малку потешко, бидејќи тие во голема мера зависат од разните облачни услуги. Значи, се поставува прашањето колку овие системи на трети лица се соодветни за тест сценарија. Дали е наменет дури и за употреба во тестови? Дали има тест никулци што можат да се развијат против? Колку лесно може да се полнат системите со значајни податоци од тестот? И, каква стратегија користи давателот за тест за наплата во облакот? Секако, во многу малку случаи ќе биде можно да се извршат тестови за интеграција или прифаќање целосно на вашиот локален компјутер или на компјутер кој не е поврзан со облакот.
Раскажете во колоната Enterprise Tales Ларс Ровекамп, Свен Келпин и Арне Лимбург (отворено знаење) интересни приказни и дава информативни согледувања за Java EE и шарениот свет на Enterprise Java.
Заклучок
Исклучително едноставниот модел треба да се оцени позитивно. Како развивач, не треба да се грижам за ништо друго освен за кодот на апликацијата. Нема потреба да управувате со сервери или контејнери. Трошоците се прават само кога апликацијата генерира оптоварување, што автоматски се размерува. Ова е особено забележливо во случај на врвови, за кои дополнителната инфраструктура нормално треба да биде подготвена. Распоредувањето на нова верзија на функцијата FaaS е исто така многу лесно. Едноставно испратете го кодот или, во случај на Java, спакувајте го претходно, а новата верзија е достапна.
Заклучувањето на продавачот сигурно се смета како неповолна положба. Функциите на FaaS можат да бидат напишани на стандардни јазици како што се Java или JS, но сè друго е специфично за производителот, на пр. B. предизвикувачите и поврзаниот BaaS. Пренесување апликација од Амазон до Гугл не би било можно без понатамошно разбирање. Особено, овој чекор би значел дека поврзаните системи, како што се системи со датотеки во облак или бази на податоци во облак, исто така, треба да бидат пренесени. Овде би биле пожелни решенија за почетна основа и рамки за апстракција за да се зголеми преносливоста.
Промените на API, новите големи изданија или променетиот модел на цени може да станат вистински ризик. Друг недостаток може да резултира од префрлување на деловната логика кон клиентот. Ако сакате неколку различни клиенти, треба да го имплементирате овој код неколку пати. Тековните SLAs на различни даватели на услуги, исто така, може да се претворат во неповолна положба во одделни случаи. Амазон дозволува максимум 1.000 паралелни егзекуции на Ламбдас. На почетокот звучи многу, но според сегашниот модел може да се види како максимум над сите функции на ламбда. Интензивен тест може да ја парализира продуктивната средина.
За да бидеме фер, мора да се каже дека сè уште сме во многу рана фаза и затоа може да се претпостави дека некои од споменатите проблеми се веќе на агендата на давателите. Имајќи го ова предвид: Останете во тек ...!