Как стать автором
Обновить

Комментарии 34

Но где же само приложение, чтобы мы начали уже вгонять вас в долги? Разрешите проверить, насколько вы учли в расчетах так называемый «хабраэффект».
.Net Core в Lambda дюже медленно стартует — даже держать «горячим» с помощью запросов по таймеру почему то не помогает.

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


Гораздо проще и дешевле арендовать VPS и захостить там приложение на PHP. Не нужно будет кучи микросервисов, все будет работать просто и надежно. Поменяли строчку в коде, запушили в мастер, оно само задеплоилось. А тут надо что-то поменять — надо лезть в кривые запутанные админки амазона и искать, какую кнопку нажать.


Или другой пример: надо вам узнать, сколько у вас пользователей в БД. Набираете в mysql SELECT COUNT(*) FROM user и получаете ответ. Надо узнать, сколько пользователей, купивших хоть один товар, но не подписавшихся на рассылку — опять же, несложный запрос и ответ. А что вы будете делать в Амазоне в убогой DynamoDB? Мучительно искать галочку в админке, которой там нету? Руками JSON составлять? Ну-ну, удачи.


Вдобавок вы еще и вендор-лок получаете — все ваше приложение прибито гвоздями к Амазону и переехать никуда невозможно. В отличие от VPS-хостинга, коих море.


Плохо представляю сценарий, когда все это выгодно. Крупным сервисам с огромным трафиком дешевле будет купить свои сервера, маленьким дешевле VPS.

Вы полностью правы и спорить с этим нет смысла, если речь идёт про продуктив и такой простой сайт. :)

Автор у себя в подписи указал, что он является «Архитектором облачных решений», поэтому его статья — это демонстрация возможностей конкретных сервисов в AWS на примере простого Web-сервиса. Это очень полезная информация для тех, кто только начинает знакомиться c возможностями AWS. Когда новичок открывает список сервисов в AWS, то глаза начинают разбегаться и начинается паника, поэтому наличие конкретного примера, который можно самостоятельно повторить, является очень полезным.

Автору спасибо за статью, прочитал с удовольствием. :)

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

А разве концепция «один раз настроить» работает в современном мире?
Не понравилось ваше сравнение DynamoDB с mysql. Надо понимать, что DynamoDB относится к базам NoSQL и никаких SELECT'ов там быть не должно. AWS не позиционирует DynamoDB как базу для крупных сервисов, для этого у них есть RDS (если хотите SQL) или DocumentDB (MongoDB).

DynamoDB отлично подходит для каких-то маленьких проектов, 25 ГБ + 200 млн запросов у вас всегда бесплатно. USE CASE: маленькое мобильное приложение, Firebase Storage от гугла предлагает за бесплатно только 1 ГБ к сравнению.

А для управление множеством сервисов DevOps'ы порекомендуют Infra as a Code (Terraform например). Очень удобная штука.

В любом случае, то что я описал в своем комментарии решают специалисты называющие себя Solutions Architects :)
У вас как-то все перепуталось. DynamoDB — это штука для больших данных/нагрузок, когда вы жертвуете гибкостью схемы ради «бесконечного» скалирования. Посмотрите стримы Rick Houlihan про применение single table design или его доклады на re:invent.

Вендор лок в целом не такая большая проблема как ее описывают и с ним можно жить. Максимально универсальное приложение работающее везде будет сильно ограничено и при этом стоимость поддержки будет заметно дороже. Нужно ли это? Перенос сложных систем между платформами это всегда проблема. Не зависимо от использования лямбд.
На счёт count(*) — на мой взгляд для хайлоад такое не очень подходит. Если нагрузка не большая то можно использовать Аврору. Там обычная база. ДинамоДБ это все таки NoSQL и там свои плюсы и минусы как у любого NoSQL

Полностью согласен про «вендор лок».
Жизнь в мире без «какой-то лок» невозможна. Лок на «Васю, что написал нам сайт», например, тот еще лок.
Просто в этом мире лучше ставить на лидера.
Плохо представляю сценарий, когда все это выгодно. Крупным сервисам с огромным трафиком дешевле будет купить свои сервера, маленьким дешевле VPS.


Нестабильный трафик, когда в один день пусто а в другой густо. Либо создавать кластер с автоскейлингом, что требует нормальной такой экспертизы(да и притормаживает обычно скейлинг, хотя это очень редко бывает критично), либо вот эти вот лямбды где уже подумали за вас.
По стоимости обработки одного вызова API это будет примерно так:
1) Самое дорогое это конечно лямбды.
2) Кластер из амазоновских серверов с автоскейлингом
3) Кластер где скейлинг происходит за счет спотовых инстансов, которые стоят от 2 до 4 раз дешевле. Недостатки — их может не быть в данный момент времени и это нужно предусмотреть, их могут отобрать с 30секундным уведомлением и ваша архитектура должна это так же предусматривать.

По капитальным затратам — то есть стоимость приложения и создания инфраструктуры, все ровно наоборот.

Насчет лямбды-сама по себе лямбда в такой концепции условно бесплатная по сравнению с другими сервисами, АПИ гейтвейц или тот же клаудвоч жрет на несколько порядков больше денег чем лямбда.

надо управлять множеством неподконтрольных отдельных сервисов

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

Тема стоимости не раскрыта, а она стоит того. EC2 стоит вагон денег, EBS тоже, а трафик в Амазоне стоит столько, что приложение, по факту, нужно специально затачивать под это ограничение. Взамен получаем 100-500 сервисов, которые ещё сильнее прибивают к AWS. И нужно как-то решить, стоит ли оно того. Не на уровне — «aws для растущих компаний», а как-то поподробнее, чтобы понимать как aws экономит деньги. Мой опыт говорит, что aws легко может стоить дороже ценой команды devops, но все ещё требует эту команду, то есть все недостатки и минимум достоинств.

Сравнение стоимости владения EC2 vs корп.дата центр — это, согласен, очень интересная тема. Но, к сожалению, ее в лоб не решить. Все рассчеты TCO для копр.сервисов, что я видел — это так, палкой в небо. Для экономии есть SPOT — инстансы и SAVING PLANS. Сделаю про это отдельный обзор, условно «Когда вам пора старовать в облака»
Простейший кейс, что я вижу, это когда нагрузка нужна уже сейчас, а сервера застряли на таможне :))) Т.к. деньги — деньгами, а репутацию никто не отменял.
Для экономии есть SPOT — инстансы и SAVING PLANS

Как по мне так это так себе опции. Spot instance исчезает в любой момент и потому требует особой поддержки со стороны кода приложения. Так себе экономия, сначала создаём себе проблему в виде высокой стоимости, а затем героически решаем. Saving Plan это когда комитимся на 3 года чтобы получить стоимость железа аналогичную Digital Ocean или Linode. При этом все ещё платим в 10 раз дороже за трафик.


Простейший кейс, что я вижу, это когда нагрузка нужна уже сейчас, а сервера застряли на таможне :)))

Это единственный кейс, который я вижу и который постоянно всплывает в маркетинге. А вот на практике так бывает крайне редко, если бывает вообще. Отличный пример — stack overflow и ещё десятки историй о том как крупные компании вроде Dropbox мигрировали из AWS.

На мой сугубо дилетантский взгляд — AWS это супер дорогая шутка для смузи-стартапов, которым некуда совать деньги. Что она 146% делать не будет — ни защищать от рисков, ни экономить. При этом Amazon гиперориентирован именно на Америку, а если поточнее — куда-то в Калифорнию. Основная проблема — платен каждый чих, при это стоимость часа того же ec2 ничерта не меньше простого и удобного дигитал оушен. Да, есть вагон и маленькая тележка сервисов, но когда я их вижу задаюсь лишь вопросом — ведь кто-то всё это поддерживает и получает за это деньги.


К тому же, РФ (и СНГ) находятся в серьёзном продуктовом вакууме в том числе по причине раздутости цен. Хотя тот же Azure мне показался куда более щадящим и понятным. Не без заморочек, но объективно месяц интенсива абсолютно всё оставят без вопросов. При этом ворох сервисов как-то адаптирован под мелкомягкую платформу.


Но. Основная проблема клауда — высочайшая сложность объективной оценки. Слышал с десяток баек, как некоторый заказчик сэкономил тонны нефти перенеся существующую (!) инфраструктуру в клауд, в т.ч. в контексте AWS. И пару историй от стартапов, которых похоронили ценники операторов.


А почему? Потому что первые обычно оперировали огромными собственными датацентрами, которые не нагружались и на 10% почти всегда, а иногда — нагружались ну на половину. И распродав всю мишуру, сократив половину раздутого персонала, играющего в карты на зп, забыв про многотысячные счета на электричество — можно действительно сэкономить.


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


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

Автору благодарность за упрощенную концепцию приложения задешево и быстро. После тестирования облачного proof of concept, решение всегда можно перенести on-prem.
Не работал через Cognito, но слышал от тебят хорошие отзывы при интеграции.

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

Насчет денег — не беспокоит, совсем. Статья же про прототип (простое приложение). Устоявшийся подход прототипировать в облаке, а prod хостить либо в гибриде, либо на своем оборудовании — дешевле выйдет.

Кстати, Lambda на Питон можно писать с использованием Chalice: в одной библиотеке решается задача создания Endpoint, Lambda и авто-деплой на AWS.
Значительно экономит время.

Также можно использовать expressjs для nodejs

Latency какой получился? Смотрел на этот стек пару лет назад — у лямбды высокое и нестабильное время ответа, S3 тоже работает существенно медленнее, чем хостинг на EC2 + nginx

Уже разобрал лабу, сорри.
По логам выполнение Lambda 2ms, задержка около 150 ms
Что касается S3 (без API Gateway + Lambda)
time_namelookup: 0.015000s
time_connect: 0.078000s
time_appconnect: 0.203000s
time_pretransfer: 0.203000s
time_redirect: 0.000000s
time_starttransfer: 0.703000s
чем хостинг на EC2 + nginx

в случае перегрузки — тут тоже будет нестабильное время ответа + EC2 может в любой момент времени быть перезагружена, а если спот — и отобрана

НЛО прилетело и опубликовало эту надпись здесь
Да, и что?
НЛО прилетело и опубликовало эту надпись здесь
придется нанимать того, кто умеет писать то же самое, но с учетом костылей lambda

Не уверен что на .Net Core под Lambda на данный момент можно сделать нормально стартующий сайт. Мне понадобился сайт очень простой из 2 форм и 1 страницы. Задеплоил на Lambda. Вроде нормально, но потом, как выяснилось, стартует очень долго — секунд 5. Попытался держать «горячим» с помощью запросов по таймеру — не помоглось.

Интересно было бы увидеть реально работающий сайт на этом вашем Lambda. Хотя, не исключаю, что на других платформах этой проблемы нет.
Очень странная задержка. Могу логи скинуть в личку, но 150-250ms, больше не видел (но это не .NET)
Меня интересует только .Net.

На прошлой проекте переводили на лямбду АПИ слой-у меня было несколько сотен эндпоинтов.
Вполне нормально работает, хотя очень много подводных камней, возможно если нету никакой экспертизы то лезть не стоит.

.Net?

Для справки, небольшой пример неожиданной стоимости.


Если вы хотите использовать VPC (то есть, изолировать свою инфраструктуру от внешнего интернета), и при этом, естественно, захотите получать информацию из внешнего мира, то окажется, что с большой вероятностью вам потребуется NAT. Что же здесь такого, спросит неискушённый читатель? Стоимость сервиса, предлагаемого AWS (NAT Gateway) (в среднем, по регионам отличается):


  • $0.05 в час
  • $0.05 за Гб трафика.

То есть, если вы собрали Hello World, в котором используется NAT Gateway, то за месяц, даже если приложение не используется, придётся заплатить $36.


Если захотите использовать нормальную базу данных (в терминологии AWS — RDS), то стоимость — $0,07 в час.


Бесплатный сыр, как известно, в мышеловке, и за Free Tier (уровень бесплатного использования) кто-то всё-таки должен заплатить...

Ну NAT нужен только для того чтобы инстансы в приватной подсети могли лазить в инет. Можно запустить Nat-instance на t1.micro за $0,01 в час, можно поднимать его через CloudFormation только на нужно время. А с дуру можно поднять, например, r5dn.16xlarge с 96 vCPU и 768 Гб памяти за ....8 баксов в час.
В этой лавке полно товара на любой кошелек :)))

Действительно, можно найти обходной путь. Который, в свою очередь, увеличивает сложность, и на котором тоже сделаны ловушки неожиданных расходов.
Мне всё же кажется, что цена в $36/месяц (=$432/год) несколько неадекватна за такой, в общем-то, несложный сервис как NAT.
Ценовая политика местами выглядит грабительски.

Ну смотрите, NAT Gateway стоит $0,045 в час и по большому счету нужен только для обновления ПО инстансов в приватных подсетях.
Создается NAT Gateway за несколко секунд консольной командой «aws ec2 create-nat-gateway» и удаляется с такой же простотой. Даже если дела обстоят так, что он нужен 24/7, то $36 — это стоимость получаса — часа работы технического специалиста средней руки. Не вижу ничего грабительского. Вот Kinesis да, нужно сильно подумать прежде чем его использовать.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории