`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Константин Введенский

Пример эффективного serverless приложения

+22
голоса

Последним хайпом после контейнеров были serverless или, так называемые, безсерверные вычисления. О том, как это работает, а также о преимуществах уже много всего немало написано. Как и обо всех минусах этого типа решений – в первую очередь огромной стоимости.

Тем более, думаю, интересно было бы вспомнить успешный опыт одного крупного заказчика, с которым пришлось недавно работать. Речь шла как раз о переезде с монолита на serverless. Дано: существующее приложение для оркестрации инфраструктуры – от VMware до OpenStack. Большой монолит, много legacy, весьма широкий функционал. Проблемы очевидны: добавление новых функций сложное,  требует гору ресурсов и пр.

Бизнес принял решение - максимально отказаться от локальной инфраструктуры для запуска test&dev окружений и переехать в облако. Логично мигрировать инструменты также в облако. Однако провести это в существующем виде невыгодно и сложно – всё завязано на внутренние элементы, система не отчуждаема от своего окружения.

Вместе с тем система оркестрации не работает 24х7 и скорее является транзакционной. Как решение: рефакторинг кода и переход на безсерверную модель. Стек простой и понятный: AWS Lambda - вычисления, API Gateway – точка входа и управления вызовами к лямбда-функциям, DynamoDB – хранение данных. На момент создания решения ограничения сервиса Lambda никак не сказывались на функциональности продукта. Позже выяснилось, что для выполнения некоторых заданий, требующих сохранения состояния, Step Functions, сервис машин состояний, достаточно мало функционален и проще написать свое. Таким образом, итоговое решение могло само себя обновлять.

После переезда полностью на Lambda стоимость решения оказалась прекрасная – несколько десятков долларов на первых пять пользователей и далее по доллару в месяц на пользователя.

Обратная сторона решения — это то что общее количество лямбда функций достигло 250+. Так как сложность проекта была весьма высокой, часть функций использовалась для обслуживания самого комплекса – выкатка новых версий и т.д.

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

Приобретённый опыт практически доказал узость применения Lambda функций и необходимость дизайна с нуля именно под безсерверную модель вычисления. Вместе с тем именно такой подход позволяет обеспечить минимальную стоимость решения, простоту обслуживания и расширяемость.

Как всегда, нужно использовать правильный инструмент под конкретную задачу.

Дізнайтесь більше про мікро-ЦОД EcoStruxure висотою 6U

+22
голоса

Напечатать Отправить другу

Читайте также

 

Slack подает жалобу на Microsoft и требует антимонопольного расследования от ЕС

 
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT