Комментарии 34
Получилось переусложненное (надо управлять множеством неподконтрольных отдельных сервисов) и дорогое (сравните с ценой аренды VPS) решение. Если вы не хотите держать админов, то арендовать VPS и один раз настроить деплой будет дешевле и проще, и при этом у вас будет root-доступ к серверу с возможностью ставить любой софт.
Гораздо проще и дешевле арендовать VPS и захостить там приложение на PHP. Не нужно будет кучи микросервисов, все будет работать просто и надежно. Поменяли строчку в коде, запушили в мастер, оно само задеплоилось. А тут надо что-то поменять — надо лезть в кривые запутанные админки амазона и искать, какую кнопку нажать.
Или другой пример: надо вам узнать, сколько у вас пользователей в БД. Набираете в mysql SELECT COUNT(*) FROM user и получаете ответ. Надо узнать, сколько пользователей, купивших хоть один товар, но не подписавшихся на рассылку — опять же, несложный запрос и ответ. А что вы будете делать в Амазоне в убогой DynamoDB? Мучительно искать галочку в админке, которой там нету? Руками JSON составлять? Ну-ну, удачи.
Вдобавок вы еще и вендор-лок получаете — все ваше приложение прибито гвоздями к Амазону и переехать никуда невозможно. В отличие от VPS-хостинга, коих море.
Плохо представляю сценарий, когда все это выгодно. Крупным сервисам с огромным трафиком дешевле будет купить свои сервера, маленьким дешевле VPS.
Автор у себя в подписи указал, что он является «Архитектором облачных решений», поэтому его статья — это демонстрация возможностей конкретных сервисов в AWS на примере простого Web-сервиса. Это очень полезная информация для тех, кто только начинает знакомиться c возможностями AWS. Когда новичок открывает список сервисов в AWS, то глаза начинают разбегаться и начинается паника, поэтому наличие конкретного примера, который можно самостоятельно повторить, является очень полезным.
Автору спасибо за статью, прочитал с удовольствием. :)
А сейчас мода все переусложнять. Какое-то древо ради дрчива. Делают на простых вещах целый подвал различных подпорок и сложных решений, а на выходе получают тормозящий сайт кушающий не только траффик клиента, но и его CPU и оперативку. Зато можно на конференциях каждый год говорить как они преодолевают трудности и борются с высокой нагрузкой внедрением новой фишки вышедшей позавчера, добавляющей еще пару слоев.
DynamoDB отлично подходит для каких-то маленьких проектов, 25 ГБ + 200 млн запросов у вас всегда бесплатно. USE CASE: маленькое мобильное приложение, Firebase Storage от гугла предлагает за бесплатно только 1 ГБ к сравнению.
А для управление множеством сервисов DevOps'ы порекомендуют Infra as a Code (Terraform например). Очень удобная штука.
В любом случае, то что я описал в своем комментарии решают специалисты называющие себя Solutions Architects :)
Вендор лок в целом не такая большая проблема как ее описывают и с ним можно жить. Максимально универсальное приложение работающее везде будет сильно ограничено и при этом стоимость поддержки будет заметно дороже. Нужно ли это? Перенос сложных систем между платформами это всегда проблема. Не зависимо от использования лямбд.
На счёт count(*) — на мой взгляд для хайлоад такое не очень подходит. Если нагрузка не большая то можно использовать Аврору. Там обычная база. ДинамоДБ это все таки NoSQL и там свои плюсы и минусы как у любого NoSQL
Плохо представляю сценарий, когда все это выгодно. Крупным сервисам с огромным трафиком дешевле будет купить свои сервера, маленьким дешевле VPS.
Нестабильный трафик, когда в один день пусто а в другой густо. Либо создавать кластер с автоскейлингом, что требует нормальной такой экспертизы(да и притормаживает обычно скейлинг, хотя это очень редко бывает критично), либо вот эти вот лямбды где уже подумали за вас.
По стоимости обработки одного вызова API это будет примерно так:
1) Самое дорогое это конечно лямбды.
2) Кластер из амазоновских серверов с автоскейлингом
3) Кластер где скейлинг происходит за счет спотовых инстансов, которые стоят от 2 до 4 раз дешевле. Недостатки — их может не быть в данный момент времени и это нужно предусмотреть, их могут отобрать с 30секундным уведомлением и ваша архитектура должна это так же предусматривать.
По капитальным затратам — то есть стоимость приложения и создания инфраструктуры, все ровно наоборот.
надо управлять множеством неподконтрольных отдельных сервисов
В этом есть и несомненные плюсы. т.к. микросервисы могут переиспользоваться, поддерживаться и развиваться независимо от других частей основного приложения. И аутентификация и авторизация, вынесенная в отдельный сервис яркий тому пример.
Тема стоимости не раскрыта, а она стоит того. EC2 стоит вагон денег, EBS тоже, а трафик в Амазоне стоит столько, что приложение, по факту, нужно специально затачивать под это ограничение. Взамен получаем 100-500 сервисов, которые ещё сильнее прибивают к AWS. И нужно как-то решить, стоит ли оно того. Не на уровне — «aws для растущих компаний», а как-то поподробнее, чтобы понимать как aws экономит деньги. Мой опыт говорит, что aws легко может стоить дороже ценой команды devops, но все ещё требует эту команду, то есть все недостатки и минимум достоинств.
Простейший кейс, что я вижу, это когда нагрузка нужна уже сейчас, а сервера застряли на таможне :))) Т.к. деньги — деньгами, а репутацию никто не отменял.
Для экономии есть SPOT — инстансы и SAVING PLANS
Как по мне так это так себе опции. Spot instance исчезает в любой момент и потому требует особой поддержки со стороны кода приложения. Так себе экономия, сначала создаём себе проблему в виде высокой стоимости, а затем героически решаем. Saving Plan это когда комитимся на 3 года чтобы получить стоимость железа аналогичную Digital Ocean или Linode. При этом все ещё платим в 10 раз дороже за трафик.
Простейший кейс, что я вижу, это когда нагрузка нужна уже сейчас, а сервера застряли на таможне :)))
Это единственный кейс, который я вижу и который постоянно всплывает в маркетинге. А вот на практике так бывает крайне редко, если бывает вообще. Отличный пример — stack overflow и ещё десятки историй о том как крупные компании вроде Dropbox мигрировали из AWS.
На мой сугубо дилетантский взгляд — AWS это супер дорогая шутка для смузи-стартапов, которым некуда совать деньги. Что она 146% делать не будет — ни защищать от рисков, ни экономить. При этом Amazon гиперориентирован именно на Америку, а если поточнее — куда-то в Калифорнию. Основная проблема — платен каждый чих, при это стоимость часа того же ec2 ничерта не меньше простого и удобного дигитал оушен. Да, есть вагон и маленькая тележка сервисов, но когда я их вижу задаюсь лишь вопросом — ведь кто-то всё это поддерживает и получает за это деньги.
К тому же, РФ (и СНГ) находятся в серьёзном продуктовом вакууме в том числе по причине раздутости цен. Хотя тот же Azure мне показался куда более щадящим и понятным. Не без заморочек, но объективно месяц интенсива абсолютно всё оставят без вопросов. При этом ворох сервисов как-то адаптирован под мелкомягкую платформу.
Но. Основная проблема клауда — высочайшая сложность объективной оценки. Слышал с десяток баек, как некоторый заказчик сэкономил тонны нефти перенеся существующую (!) инфраструктуру в клауд, в т.ч. в контексте AWS. И пару историй от стартапов, которых похоронили ценники операторов.
А почему? Потому что первые обычно оперировали огромными собственными датацентрами, которые не нагружались и на 10% почти всегда, а иногда — нагружались ну на половину. И распродав всю мишуру, сократив половину раздутого персонала, играющего в карты на зп, забыв про многотысячные счета на электричество — можно действительно сэкономить.
А вот вторым порой будет намного выгоднее взять пару серваков в стойках и развернуть свой микрокластер. Потому что неаккуратный скейлинг может не просто потопить начинание, а привести к значительным долгам. Тут правда есть один лайфхак — имеет смысл написать в саппорт, мол так и так. Почти всегда идут навстречу и пересчитывают, что сокращает сумму на порядки. И ещё имеет смысла завести в знакомых евангелиста или ментора, которому обычно выделяют сильные квоты и очень часто они не против и поделится.
В любом случае, посчитать очень тяжело. Настолько, что многие стартапы выбирают неадекватный ценник с серьёзными возможностями абуза, что запускает лавинный приток пользователей, каждый из которых себя не окупает. Это нередкая проблема сегодня, кстати.
Не работал через Cognito, но слышал от тебят хорошие отзывы при интеграции.
Согласен с комментами выше — хорошо бы примеры, хотя бы на уровне каркаса приложения. Дальше каждый сам решит, какую базу использовать, или на чем lambda писать.
Насчет денег — не беспокоит, совсем. Статья же про прототип (простое приложение). Устоявшийся подход прототипировать в облаке, а prod хостить либо в гибриде, либо на своем оборудовании — дешевле выйдет.
Кстати, Lambda на Питон можно писать с использованием Chalice: в одной библиотеке решается задача создания Endpoint, Lambda и авто-деплой на AWS.
Значительно экономит время.
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. Хотя, не исключаю, что на других платформах этой проблемы нет.
На прошлой проекте переводили на лямбду АПИ слой-у меня было несколько сотен эндпоинтов.
Вполне нормально работает, хотя очень много подводных камней, возможно если нету никакой экспертизы то лезть не стоит.
Для справки, небольшой пример неожиданной стоимости.
Если вы хотите использовать VPC (то есть, изолировать свою инфраструктуру от внешнего интернета), и при этом, естественно, захотите получать информацию из внешнего мира, то окажется, что с большой вероятностью вам потребуется NAT. Что же здесь такого, спросит неискушённый читатель? Стоимость сервиса, предлагаемого AWS (NAT Gateway) (в среднем, по регионам отличается):
- $0.05 в час
- $0.05 за Гб трафика.
То есть, если вы собрали Hello World, в котором используется NAT Gateway, то за месяц, даже если приложение не используется, придётся заплатить $36.
Если захотите использовать нормальную базу данных (в терминологии AWS — RDS), то стоимость — $0,07 в час.
Бесплатный сыр, как известно, в мышеловке, и за Free Tier (уровень бесплатного использования) кто-то всё-таки должен заплатить...
В этой лавке полно товара на любой кошелек :)))
Действительно, можно найти обходной путь. Который, в свою очередь, увеличивает сложность, и на котором тоже сделаны ловушки неожиданных расходов.
Мне всё же кажется, что цена в $36/месяц (=$432/год) несколько неадекватна за такой, в общем-то, несложный сервис как NAT.
Ценовая политика местами выглядит грабительски.
Создается NAT Gateway за несколко секунд консольной командой «aws ec2 create-nat-gateway» и удаляется с такой же простотой. Даже если дела обстоят так, что он нужен 24/7, то $36 — это стоимость получаса — часа работы технического специалиста средней руки. Не вижу ничего грабительского. Вот Kinesis да, нужно сильно подумать прежде чем его использовать.
Архитектура и стоимость простого бессерверного веб-приложения Amazon Web Services