Смешивание API Node.js с AWS Lambda

Просто добавлю некоторые мысли о предыдущих ответах:

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

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

Во-вторых, насколько мне известно, пока нет обещанного SLA для AWS Lambda по его доступности и надежности. Это просто заставляет меня колебаться, принимая Lambda для создания RESTful API.

AWS Lambda работает в инфраструктуре «вычислительного уровня» AWS, поэтому я считаю, что если они столкнутся с проблемой на вычислительном уровне, наверняка ваши инстансы EC2 также столкнутся с перебоями.

После того, как мы настроим Node API на экземплярах EC2, я думаю, будет более продуктивно подумать о настройке автоматического масштабирования или о том, как использовать все ресурсы, работающие на текущих экземплярах EC2.

Я так не думаю. Бессерверный стек масштабируется без усилий, вам не нужно управлять инфраструктурой.

Я пробовал это раньше, но это вызвало у меня много путаницы. Я чувствую, что при создании API лучше выбрать Node API или AWS Lambda API, а не смешивать их вместе.

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

Еще одна вещь, которую следует учитывать при разговоре с менеджерами об архитектуре: Стоимость.

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

Нижняя линия:

Нет, неплохо смешивать ресурсы по желанию вашего менеджера.

Да, проще просто получить фреймворк для написания API, настроить экземпляр EC2 и группу автоматического масштабирования.

Да, при разъединении сервисов возникает тяжелая работа, но это окупается при работе в производственной среде.

Хорошо, пойдем по одному. Первое первым. Ваша первая проблема - протестировать Lambda в вашей локальной сети, и это вполне возможно сделать с помощью SAM.

Пожалуйста, взгляните на - http://docs.aws.amazon.com/lambda/latest/dg/test-sam-local.html

Самое важное дизайнерское решение. Если ваше приложение является монолитным и вы не хотите переделывать его для микросервисов, придерживайтесь EC2.

Теперь о вашем дизайне для гибридного API (Lambda и EC2). Я не думаю, что это анти-шаблон или плохая идея. Это полностью основано на вашем требовании. Допустим, у вас есть существующий набор API в EC2 (может быть монолитным), и вы хотите постепенно перенести его на бессерверные и микросервисы. Вам не нужно мигрировать все вместе на бессерверные системы. Вы можете начать один за другим. Помните, что общение происходит через Http, и не имеет значения, распределены ли ваши сервисы между EC2 и Lambda. В мире микросервисов не имеет значения, что сервисы находятся на одном сервере или распределены по многим серверам.

Скорость связи сильно изменилась за последние несколько лет, и это одна из основных причин появления микросервиса.

Таким образом, в двух словах неплохо иметь гибридный API, но полностью основанный на вашей архитектуре дизайна. Если монолитный, то не выбирайте Lambda.

Есть случаи, когда вам нужно запускать экземпляры Lambda и EC2 вместе (например, проекты миграции Monolith в Microservices, NodeJS с Express в качестве веб-сервера), что может иметь смысл.

Для этого существует несколько подходов. Следует использовать два распространенных подхода (для запроса-ответа).

1. Если вы планируете обслуживать только RESTful API из экземпляров Lambda и NodeJS EC2, вы можете использовать API Gateway в качестве прокси для них обоих.
2. Если экземпляр NodeJS EC2 используется в качестве веб-сервера для обслуживания как динамических страниц, так и т. д., вы можете использовать AWS CloudFront в качестве прокси-сервера, но вам все равно потребуется шлюз API для подключения к Lambda.

Примечание. Для асинхронных рабочих процессов вы можете использовать Lambda вместе с другими сервисами AWS, такими как AWS Step Functions, SQS, SNS, в зависимости от характера рабочего процесса.