Pull to refresh

Comments 19

Бессерверные приложения — это как безрамочные телефоны. Вся статья про серверный код, но делаем вид, что сервера нет.
Не путайте выделенный сервер с сервисом Lambda и подобными. Это разные вещи. Когда вам сервер не нужен или нет нагрузки на него — он работает в холостую и ест деньги в любом случае.
Когда не работает Lambda она не ест деньги.

Безсерверным решение было если бы картинки обрабатывались на клиенте. А так все на сервере, только в облаке.


Статья годная, но название и акценты на «безсерверность» всё впечатление портят.

Так нет сервера же, есть сервис который обрабатывает изображения.

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

Хабр не только в РФ читают.
И да, блокировки обходятся.
В теории выглядит очень привлекательно. Но мне до сих пор не ясно как такой способ построения системы дружит с
* отладкой
* тестированием
* контролем версий
* dev/stage/production окружением
  • oтладка/тестирование. Код лямбды — обычная функция. Чтобы протестировать, импортируем ее, вызываем с желаемыми параметрами и проверяем результат в коллбэке. Абсолютно так же, как вы бы тестировали ее, если бы это была часть традиционного приложения. Есть библиотеки, которые берут на себя часть бойлерплейта. Например, тут: https://www.npmjs.com/package/lambda-local#use-lambda-local-to-mock
  • контролем версий — Лямбда — это код. Нет никаких проблем хранить его в СКВ.
  • dev/stage/production окружение. Мы делали отдельную функцию для каждого окружения. Допустим process-image-prod, process-image-dev.
Кроме лямбды есть ещё ручное разворачивание, которое не под контролем версий. По мере развития может образоваться путаница. Так же может оказаться, что нужно переехать в другой регион. Смотрели на автоматизацию этой части?

А зачем разворачивать вручную? Все автоматизируется.
Можно банально написать свой скрипт, который деплоит через aws api. Можно воспользоваться готовыми утилитами наподобие https://github.com/motdotla/node-lambda.


Ну то есть опять же — ничем принципиально не отличается от деплоя на EC2 или ECS.

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

По поводу отладки — нетривиальные функции часто работают с БД, S3 и прочим. Можно ли такие вещи отлаживать локально или надо обязательно размещать функцию в облаке?
кликать нужно три раза, для каждого окружения

Создание лямбд (как и любых других инфраструктурных ресурсов) можно (и нужно) описать в виде кода. Например, с Terraform.


Допустим, у вас код деплоится не в лямбду, а в EC2, ECS, CodeDeploy, etc — как вы убедитесь, что различные окружения (дев, прод) настроены одинаково? Вот точно так же это делается и с лямбдой.


Можно ли такие вещи отлаживать локально или надо обязательно размещать функцию в облаке

А как вы это делаете без лямбды, с обычным приложением? Точно так же поднимаете локальную базу, прописываете ее в конфиге для вашего локального окружения. Не вижу никакой разницы с лямбдой. Задача сводится к тому, чтобы подсунуть ей правильный конфиг.

  • oтладка/тестирование. Код лямбды — обычная функция. Чтобы протестировать, импортируем ее, вызываем с желаемыми параметрами и проверяем результат в коллбэке. Абсолютно так же, как вы бы тестировали ее, если бы это была часть традиционного приложения. Есть библиотеки, которые берут на себя часть бойлерплейта. Например, тут: https://www.npmjs.com/package/lambda-local#use-lambda-local-to-mock
  • контролем версий — Лямбда — это код. Нет никаких проблем хранить его в СКВ.
  • dev/stage/production окружение. Мы делали отдельную функцию для каждого окружения. Допустим process-image-prod, process-image-dev.
Вопрос про обработки ошибок и стоимость.

В функции вы пишете log.error и на этом всё. Дальше это как-то мониторится/где-то видно. Есть механизм повтора преобразования (с или без исправления кода функции)?

По стоимости достаточно сложно подсчитать, но на сколько в процентах (?) вырос счёт на эту часть после введения лямбды? Я смотрел в сторону managed MySQL в AWS, и он где-то на 40 процентов дороже, чем просто такая же EC2. Наверняка что-то подобное и с лямбдами. Да, оплата идёт только за использование, но она дороже, чем для обычных виртуалок. При заметном объеме и учете того, что все равно управляете другими EC2, возможно, будет заметно дешевле поднять ASG с соответствующими обработчиками SNS.
Дороже он в том числе и потому, что его не нужно постоянно патчить руками (и ОС и сервер). То же самое и с лямбдами
Это очевидно. Неочевидно оправдываемся такой аутсорсинг или нет. Для этого нужны цифры. Об этом и вопрос.
Хорошая статья, это не проблема автора, что многие читатели не понимают значения термина «serverless» и отчего-то считают, что при этом серверов вообще быть не должно.
Немного режет глаз: «Будучи разработчиком фреймворка Ruby on Rails...»
Уж было подумал, что перевод статьи того же Девида Хейнемейер Ханссона, но нет.

В оригинале «Being a Ruby on Rails developer...» я бы предложил более корректно перевести как «Будучи разработчиком на фреймворке Ruby on Rails...» или «Будучи Ruby on Rails разработчиком...»
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Кипр
Website
fun.co
Employees
51–100 employees
Registered
Representative
Account_is_busy