EnterpriseTales Малки, по-малки, AWS ламбда

по-малки

Откакто стана модерно да се разделят монолитите на спретнати, малки модули - известни още като микроуслуги - ние свикнахме с факта, че традиционният сървър за приложения се счита за бракуван. Вместо да разчитат на тежко време на изпълнение, необходимите фрагменти на сървъра сега са свързани директно с техническия код, което му дава вид интегрирана среда за изпълнение. Цялото нещо е опаковано в няколко контейнера, снабдено с малко функционалност за управление и наблюдение и приложението е готово.

Сякаш това не беше достатъчно, терминът безсървърни приложения се появява все повече в близкото минало. За пореден път Amazon е пионер в AWS Lambda. Но конкуренти като IBM с openWhisk, Google с облачни функции или Microsoft с Azure функции са в началните блокове. Така че може ли сървърите и инфраструктурата да се освободят изцяло в бъдеще? Ако да, как трябва да работи това? И за кого това е дори интересно? Необходимо е изясняване. Казус за Enterprise Tales!

Какво е безсървърно приложение?

Терминът безсървърно приложение е малко дразнещ, защото предполага, че можете да се справите без среда на изпълнение за вашия собствен код на приложение. Това не е така. По-скоро терминът иска да изрази, че безсървърните приложения използват интензивно услуги на трети страни, като базирани на облак бази данни, файлови системи и API шлюзове (бекенд като услуга или накратко BaaS) или собствен код на приложение в също толкова външен, нестабилен компютър Контейнерът изтича (Функция като услуга, FaaS за кратко). Разбира се, също са разрешени комбинации от двата подхода. Google пише: „Функциите са леки, базирани на събития, асинхронни изчислителни решения, които ви позволяват да създавате малки, еднозначни функции, които отговарят на събития в облака, без да е необходимо да управлявате сървър или среда на изпълнение.“

Фокус без сървъри

Настоящото списание Java се занимава широко с безсървърно програмиране.

Приложения с докосване на нищо: Безсървърна архитектура
Придружаваме фокуса на проблема върху JAXenter с допълнителни статии по темата.

Публикувано досега:

PaaS, BaaS или FaaS?

С многото съкращения можете да се объркате. Докато PaaS (платформа като услуга) иска да се разбира по-скоро като платформа за разработка и внедряване, т.е.отговаря за управлението, изпълнението и наблюдението на приложенията и техния код, BaaS предоставя полезни бекенд системи като бази данни, файлови системи или удостоверяване Услуги, които могат да бъдат адресирани директно от разработчиците от техните приложения.

Но как FaaS се вписва в картината? Идеята на FaaS е, че разработчикът на приложения изпълнява сървърния код (функции), но като изпълнение не се използва сървър на приложения или вграден сървър, а базиран в облак „изчислителен контейнер без състояние“. С други думи, разработчикът просто разгръща своята функция, като зарежда свързания код директно в облака и дефинира задействане, т.е.събитие, което задейства изпълнението на кода. Такова събитие може напр. Б. съхранението на файл в облачната файлова система, добавянето на запис на данни в облачната база данни или заявка срещу облачен API шлюз. Веднага след като се задейства подходящо събитие, функцията FaaS се стартира и изпълнява в отделен процес. Следователно ресурси за изпълнение като CPU или памет се използват само когато има действителна нужда.

Основната уникална точка на продажба на FaaS е, че можете да изпълнявате бекенд кода, без да се налага да управлявате собствените си сървъри за приложения или сървърни приложения. Също така няма нужда да управлявате контейнери. Мащабиране се дава от доставчика на FaaS. Безплатно? Е, не точно. По правило сметките се базират на обаждания или време на процесора - с AWS Lambda на стъпки от 100 ms. Колкото повече или по-интензивно изчислително е повикването, толкова по-скъпа е функцията по време на изпълнение.

Пример, моля?

Типичен пример за функция FaaS би била услуга за обработка на бекенда за обработка на ресурси, напр. Б. Снимки. Ако потребител зареди изображение в облака, съхраняването на изображението в базираната на облак файлова система може да предизвика събитие, което задейства функцията FaaS, която след това автоматично генерира миниатюри или алтернативни формати на изображения. Те от своя страна също се съхраняват в базираната на облак файлова система.

Но какво да кажем за приложения, управлявани от потребителски интерфейс, напр. Б. уеб магазин? Тук е възможно и безсървърно приложение. Нека приемем като отправна точка, че потребителският интерфейс на уеб магазина е реализиран като приложение на една страница (SPA), т.е. част от бизнес логиката се намира в клиента. Удостоверяването може да се извърши чрез облачна услуга BaaS; прости, четете заявки и в базата данни, напр. Б. за изброяване на наличните продукти. Бихме могли да реализираме по-сложни действия като параметризиращо търсене, използвайки функция FaaS, която капсулира достъпа до основната облачна база данни. Но как се активира това? Тук влиза в действие API шлюз, т.е. вид конфигурируем HTTP сървър, който получава заявката ни за търсене като http заявка, трансформира прехвърлените параметри във входните параметри на нашата функция и по-късно връща резултата под формата на трансформиран по същия начин HTTP отговор. Самият шлюз на API разбира се също е базиран на облак компонент, който просто трябва да бъде конфигуриран.

За да приложи функциите FaaS, Amazon Lambda предлага поддръжка за програмните езици JavaScript, Python и Java. Предвиждат се допълнителни езици. Google Functions, от друга страна, поддържа само JavaScript, IBM OpenWhisk JavaScript и Swift. Понастоящем най-широката поддръжка се предоставя от Microsoft Azure Functions с JavaScript, C #, Python и PHP.

Състояние и изпълнение

По дефиниция функциите FaaS не споделят памет и следователно трябва да са без гражданство. Или извършвате само трансформации или изчисления на прехвърлените параметри или получавате състоянието, необходимо за изчислението, от базирани на облак бази данни, файлови системи или кеш на приложения.

Функция FaaS се стартира, изпълнява и след това се прекратява отново, когато е необходимо. В зависимост от избрания език за програмиране или основното време на изпълнение, може да има определена латентност при стартиране. При JavaScript или Python това едва ли е важно по отношение на действителния код. Изглежда малко по-различно, когато кодът се изпълнява в JVM. При неблагоприятни съзвездия това може да доведе до значително забавяне на стартирането. Това винаги е така, ако много време минава между две повиквания или пикове водят до значително повече обаждания от обикновено. По правило обаче този проблем може да бъде пренебрегнат, освен ако трябва да се приложи приложение с изисквания в реално време.

Функциите на FaaS обикновено са ограничени по време на изпълнение. Amazon Lambda има ограничение от 300 секунди. Ако искате да моделирате продължителни процеси, трябва да проектирате съответна архитектура, която ги разделя на няколко функции на FaaS.

Как работи тестването с безсървърни?

Тъй като кодът на FaaS функция обикновено не се нуждае от състояние или го получава от лесно подигравана система на трета страна, модулните тестове са много лесни за изпълнение. Но какво да кажем за тестовете за интеграция? Тук става малко по-трудно, тъй като те силно зависят от различните облачни услуги. Така възниква въпросът доколко тези системи на трети страни са подходящи за тестови сценарии. Въобще предназначено ли е да се използва при тестове? Има ли тестови заглушители, срещу които може да се разработи? Колко лесно системите могат да бъдат изпълнени със значими тестови данни? И каква стратегия използва доставчикът за тестване на фактури в облака? Разбира се, в много малко случаи ще бъде възможно да се извършат тестове за интеграция или приемане изцяло на вашия локален компютър или на компютър, който не е свързан с облака.

Кажете в колоната Enterprise Tales Ларс Рьовекамп, Свен Кьолпин и Арне Лимбург (отворени знания) интересни истории и дава информативна информация за Java EE и цветния свят на Enterprise Java.

Заключение

Изключително простият модел трябва да бъде оценен положително. Като разработчик не трябва да се притеснявам за нищо друго, освен за кода на приложението. Няма нужда да управлявате сървъри или контейнери. Разходите са направени само когато приложението генерира натоварване, което се мащабира автоматично. Това е особено забележимо в случаите на пикове, за които обикновено трябва да се поддържа допълнителна инфраструктура. Внедряването на нова версия на функция FaaS също е много лесно. Просто качете кода или, в случай на Java, го опаковайте предварително и новата версия е налична.

Заключването на доставчика със сигурност трябва да се разглежда като недостатък. Функциите на FaaS могат да бъдат написани на стандартни езици като Java или JS, но всичко останало е специфично за производителя, напр. Б. тригерите и свързаните BaaS. Пренасянето на приложение от Amazon в Google не би било възможно без допълнителни шумове. По-специално, тази стъпка би означавала, че свързани системи, като файлови системи в облак или бази данни в облак, също трябва да бъдат пренесени. Тук биха били желателни локални решения и рамкови абстракции за увеличаване на преносимостта.

Промените в API, нови основни версии или променен модел на ценообразуване могат да се превърнат в реален риск. Друг недостатък може да е резултат от прехвърлянето на бизнес логиката към клиента. Ако искате няколко различни клиента, трябва да внедрите този код няколко пъти. Настоящите SLA на различните доставчици също могат да се окажат недостатък в отделни случаи. Amazon позволява максимум 1000 паралелни екзекуции на Lambdas. В началото това звучи много, но според настоящия модел може да се разглежда като максимум за всички ламбда функции. Интензивен тест може да парализира производствената среда.

За да бъдем честни, трябва да се каже, че все още сме в много ранна фаза и следователно може да се приеме, че някои от споменатите проблеми вече са в дневния ред на доставчиците. Имайки предвид това: Следете ...!