Одной из новых тенденций в облачных вычислениях является интерес к бессерверным вычислениям, позволяющим вместо аренды виртуальных машин платить за фактическое время работы запускаемых приложений. Портал TechTarget обсуждает, на какие вопросы должны обращать внимание корпоративные ИТ-департаменты, прежде чем выбрать конкретного провайдера бессерверной платформы.

Ценовые модели и расчет будущих затрат являются важными соображениями при оценке предлагаемых сегодня бессерверных платформ, примерами которых, в частности, являются Amazon Lambda, Azure Functions и Google Cloud Functions. Однако ИТ-организации должны учитывать и ряд других важных соображений. Первое, о чем надо помнить, это то, что бессерверные вычисления каждый облачный провайдер понимает по-своему и их бессерверные платформы могут поддерживать разные типы приложений.

Бессерверные вычисления первоначально мыслились как способ эксплуатации временно запускаемых приложений, откликающихся на какое-то событие. Обработав его, эти приложения не сохраняли свое состояние, и, следовательно, не могли воспринимать контекст серии связанных событий. Разработчикам это давало возможность свободно загружать, запускать и тиражировать эти приложения.

Существует два разных типа приложений, не сохраняющих свое текущее состояние, которые можно использовать на бессерверных платформах. Первый тип известен как функциональные, или лямбда-вычисления, и в этой модели вывод приложения просто является функцией ввода. Неважно сколько раз и где запускается это приложение, вы всегда получите тот же самый результат.

Во втором типе состояние контролируется бэкэндом. В приложениях этого сорта контекст многошагового процесса сохраняется базой данных, и когда наступает новое событие, которое надлежит обработать как следующий шаг, приложение может стартовать с места последней остановки.

Другой важный вопрос, от которого зависит производительность бессерверного решения, состоит в том, где будут размещаться ваши функции.

Функциональная модель чревата проблемами, потому что большинство приложений так или иначе нуждается в запоминании состояний, например, путем записи в базу данных или благодаря поддержке многоступенчатых транзакционных процессов. Если платформа бессерверного провайдера требует функционального поведения, вам придется расчленять свое приложение на куски, не требующие запоминания состояния. Если вы приобрели это приложение на стороне, либо для этой переделки у вас нет специалистов или времени, то бессерверная модель будет для вас непригодна.

В опции с контролирующим бэкэндом важно, где и как будет работать соответствующий дата-центр. Где будет находиться база данных для сохранения состояний, и какие задержки будут возникать при взаимодействии с ней. Задержки зачастую довольно велики (как сообщают пользователи, вплоть до секунд), и это может убить производительность приложения. Если в физическом плане ваши бессерверные приложения территориально разбросаны, задержки могут зависеть от конкретной географии.

Бессерверные платформы отличаются по времени, которое требуется, чтобы доставить данные к приложению, запустить его, а потом обработать эти данные. Каждая лишняя миллисекунда будет удлинять задержки. Если разместить приложение далеко от источника обрабатываемых событий, сетевые задержки могут создавать проблемы. С другой стороны, если все будет замкнуто в одном дата-центре, решение может потерять в надежности. Наконец, если вторичные компоненты решения будут сильно отдалены от первичных, задержки, связанные с бэкэнд-синхронизацией состояний, могут оказаться слишком большими.

Разработчики приложения заботятся о его оптимальной производительности, но как это сделать тоже зависит от конкретной бессерверной платформы. Это означает, что бессерверные приложения, написанные под одного провайдера, наверняка придется переделывать в случае перехода в облако другого провайдера. Это особенно актуально в виду того, что бессерверные вычисления обычно являются частью более широкой экосистемы обработки событий или Интернета вещей, которую поддерживают веб-сервисы облачного провайдера. Чем больше таких сервисов вы используете, тем менее вероятно, что вы сможете безболезненно переместить свои бессерверные приложения к другому провайдеру.

Другая проблема переносимости связана с тем фактом, что бессерверные провайдеры поддерживают не все языки программирования и не всякое промежуточное ПО, и значит, что если вам не хватает гибкости в выборе средств программирования, нет гарантии, что ваши бессерверные приложения вообще будут переносимыми. Средства, поддерживаемые облачными провайдерами, быстро меняются, и поэтому, начиная бессерверный проект, вы должны тщательно проанализировать ваши опции. При современном характере поддержки инструментария для максимальной переносимости приложений разумно использовать Node.js.

Версия для печати