Pull to refresh

Comments 58

Все просто. Эта фича уменьшит прибыли и поэтому нет смысла ее реализовывать

В очередной раз обсасывается эта тема. Да, если настроить неограниченное масштабирование можно попасть на деньги. Но даже в статье написана правда: практически невозможно сделать биллинг в реальном времени.
Вот у вас один маленький аккаунт S3, который стоит положим 0.001 цента за операцию и ваше маленькое приложение делает всего 100 операций в минуту. Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга, пересчитать сколько вы потратили и проверить ваши лимиты. То есть автоматом, ваш аккаунт начинает работать в среднем в два раза медленее (ведь надо и в аккаунт записать и в биллинг) и так во всех сервисах.
А теперь прикинем, что есть премиум аккаунты, которые должны уметь выдавать 100к операций в секунду. Физически невозможно, чтобы такие аккаунты выдавали метрику по цене на каждый запрос и чтобы эта метрика в реальном времени проверялась против лимита расходов.
Не знаю как в AWS, Azure для всех автомасштабирований требует указать лимит в единицах измерения сервиса. То есть для виртуальной машины в количестве ядер, для базы данных в гигабайтах и так далее. Может показаться, что это не столь удобно как в деньгах. Но это недоубно, только если вы пришли первый раз и хотите просто поиграться и сами не особо понимаете чего конкретно хотите. Если же вы создаёте даже маленькое, но приложение с конкретной целью, то вы более или менее представляете какие ресурсы будут нужны вашему приложению и наоборот удобнее указать лимиты в ресурсах. Azure вам сразу покажет сколько это примерно будет стоить в деньгах и будет списывать эту сумму равномерными долями

Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга
Да хотя бы раз в минуту проверяли состояния счета и блокировали если нет средств. Счета на десятки тысяч долларов все-таки на за 1 минуту обычно набегают.

На сколько я знаю, работа в этом направлении идёт и уже есть сервисы с поминутным биллингом

Так ведь одна из веток поста о том, что у них уже лет 10, как идёт. Но для клиента воз и ныне там. Если не напутал ничего.
Есть сервисы и с посекундным биллингом, только что толку, если этот самый биллинг станет доступен спустя сутки? Об этом статья.

Нужна защита от дурака. Если я заказываю себе поменять дверь или окно за 200$ это не должно приводить к убыткам в десятки тысяч долларов из-за какой-то опечатки или непонимания. Пусть даже почасовая оплата будет. Даже так нельзя десятки тысяч долларов убытков получить. И должны быть вменчемые лимиты. А снятие лимитов должно происходить только после подписания договора с клиентом, а не для любого пользователя . Почему-то Амазон может выводить поминутную статистику использования лимитов. А вот умножить число инстансов на тариф не может. Как и все западные сервисы он оптимизирован для вытягивания денег, а не для удобства пользователя, поэтому описанные выше фичи не будут реализованы никогда

Amazon, как и другие облачные сервисы оптимизирован для больших клиентов, у которых траты в месяц тысячи долларов. Мелкие разработчики, с бюджетами в 10$ в месяц не дают никакой значительной прибыли. Не надо облака сравнивать с мобильными донат играми

Однако многие будут внедрять в стартапы именно те облака, с которыми они знакомы.
Хоть месячные счета в таких кампаниях будут небольшими, в среднем в пару тысяч долларов, но их достаточно много.

Чтобы получить у Амазон виртуальную машину с 4TB+ оперативки надо писать в поддержку и пояснять, для чего потребовалось. Чтобы получить у Гугл больше 12 ядер на их бесплатном пакете в 300$ надо тоже писать… и все равно лимит не увеличат, даже если деньги на счету есть и этот стартовый пакет все равно не используется:) и так далее.

Да, но и на 3.99ТБ RAM можно быстро разориться.
А что бы при масштабировании получить сотню виртуальных машин с 64 гб оперативки, ничего не надо.

Насколько я помню вы и одну машину на 64гб оперативки без поднятия лимита не запустите, что как раз и сделано для того, чтобы вы имея 2 бакса на карте не попали на пару десятков тысяч.

Если я заказываю себе поменять дверь или окно за 200$ это не должно приводить к убыткам в десятки тысяч долларов из-за какой-то опечатки или непонимания.

Если вас выпустить из автошколы без инструктора, то вы можете устроить аварию или даже кого-то убить. Но это же не значит, что отныне вы должны всегда ездить с инструктором, и жить с мамой. Пора учиться брать ответственность на себя и решать проблему лавинообразного нарастания запросов на СВОЕЙ стороне — ежеминутно наблюдать за приложением, трафиком и балансом счёта, и немедленно исправлять обнаруженные ошибки. AWS за всеми вами тяжело уследить.
Пора учиться брать ответственность на себя и решать проблему лавинообразного нарастания запросов на СВОЕЙ стороне — ежеминутно наблюдать за приложением, трафиком и балансом счёта, и немедленно исправлять обнаруженные ошибки.

это чушь. Потому что входящий трафик вы не контролируете. Можно представить себе ситуацию, что конкуренты решили дешевыми инстансами нагенерить на своей стороне трафика и пустить его на ваш сервис — и ничего вас не спасет. Либо ваш сервис ляжет, либо Амазон вас отскалирует верх. Самый плохой сценарий — когда будет и то, и то (клиенты все равно будут недовольны, а Амазон срубит кучу денег). Вставать за защиту — вариант, но не абсолютный, увы.

Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга

Так он это и так делает — счета то выставляются.
Тут надо не делать запись, а делать проверку, и ее можно делать даже не на каждое действие, а раз в 10 запросов, раз в 100 запросов, раз в час.

Как все быстро забыли, что еще 15-20 лет назад у всех или почти всех местечковых провайдеров интернет биллинг вообще раз в месяц считался. И если среди месяца провайдер звонил — значит, мы опять выбрали весь его лимит у вышестоящего провайдера и дело плохо. Впрочем, это обычно решалось балансировкой трафика — надо было восстановить нужное соотношение входящего к исходящему для обнуления тарифа. Так все мои друзья-админы тех времен сейчас облака манной небесной по удобству тарификации считают:) И я с ними согласен.

Вот у вас один маленький аккаунт S3, который стоит положим 0.001 цента за операцию и ваше маленькое приложение делает всего 100 операций в минуту. Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга, пересчитать сколько вы потратили и проверить ваши лимиты.

При наличии желания это решается очень просто. Например, на ресурс задаётся предел темпа потребления в деньгах или пропорциональных им условных попугаях. Дальше производится локальный для ресурса учёт, который проверяется по базе и сливается в неё раз в K минут. И опять же делается остановка потребления при снижении общего акаунта ниже некоторой предельной суммы (причём по умолчанию я бы вообще ставил ноль, и давал минус только при показе платёжеспособности...)


А теперь прикинем, что есть премиум аккаунты, которые должны уметь выдавать 100к операций в секунду.

Да. Посмотрели на счёт — есть на ближайшие 5 минут ещё 300$? разрешили на такой темп. Есть только 20$? Разрешили только 20000 операций, а дальше стоп. Раз в 5 минут выдержит любой подобный биллинг.


Тут, конечно, интересный вопрос — что, если даже типов таких ресурсов штук 20 и проверка на каждом будет независимой. Но если дать ставить галочку "допускать только если денег есть на все ресурсы с гарантией" или "можно опускать с учётом всех запасов до -200$" — уже все пострадавшие и потенциально пострадавшие будут благодарны.


Если это не делают — как сказано в статье — причина одна: явное нежелание делать то, на чём потеряют возможность дрючить "лохов" (термин, увы, адекватный тут).

И повышает репутационные издержки, мотивирует разработчиков меньше пробовать продукты AWS. Я, например, прочитав много таких историй, никогда не пробую продукты которых не знаю, и большую часть времени работы с AWS пытаюсь понять сколько это будет стоить и где могу влететь на деньги.
Да такое много где есть, просто где-то больше, где-то меньше.
Я как-то влетел на деньги в GCP. Создал небольшой инстанс, всё было хорошо.
Потом пришли люди (боты?) из Китая, и внезапно оказалось, что с ВМ идёт трафик («в комплекте»), но у этого «в комплекте»* есть звездочка. И там, помимо прочих условий, указывались регионы, откуда (и куда) трафик всегда платный. Независимо от его количества. Китай, Океания, еще кто-то там…

Там есть подводный камень с тем, что истории обычно "хорошо" заканчиваются, поддержка amazon идет на встречу, причем не только к хардкорным компаниям, но даже разработчикам-одиночкам. В моем опыте прощали даже откровенно и точно пожранные нами ресурсы, в следствии ошибок devops или вовсе забытые.


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


Вот ценообразование и "калькулятор стоимости" жуть

На генерируемое уведомление о превышении бюджета можно назначить произвольные обработчики, которые удалят или остановят что требуется, или даже заблокируют биллинг для проекта, что автоматически приведет к удалению всех платных ресурсов. Например, для облака гугл первая же ссылка в их поисковике выдает исчерпывающие инструкции: How do I set a cost limit in Google Developers Console Аналогично у всех облачных провайдеров делается.

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

Билинг в реальном времени нельзя сделать по вполне объективным причинам. Если пообещать жесткие лимиты в пользу клиента, то это не только станет поощрением халатности новичков, но и откроет большой простор для злоупотреблений. Поэтому в текущем виде решение выглядит как некий консенсус. Можно сказать это плата за обучение.

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

Потому что они… убогие? Без возможности развертывания сотни инстансов в секунду в автоматическом режиме и прочими возможностями облака.

И сейчас есть много хостингов с балансом в реальном времени. Вот только инстанс нужно руками из админки создавать + подниматься он будет в течении часа-двух.
Есть так называемые гибридные модели, где уже есть API, но тем не менее есть лимиты на вычислительные ресурсы.
К примеру, у Digital Ocean было 25 машин лимитом по-умолчанию. Скейлимся в лимит — упираемся — дальше лимита ресурсов не скейлимся — счёт на больше, чем лимит ресурсов * на их цену не придёт.
Почему Digital Ocean показывает цену инстанса при создании.

А у амазон эту цену надо фиг знает где искать:

По поводу урока. Как-то создал инстанс на амазоне чтобы потренировать нейронную сеть. И то-ли я не выключил то ли был какой-то глюк и не выключился но в итоге в конце месяца мне пришел счет на 600$. Это очень неприятный урок, в то время, когда я рассчитывал на 10$

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

По поводу урока. Как-то создал инстанс на амазоне чтобы потренировать нейронную сеть. И то-ли я не выключил то ли был какой-то глюк и не выключился но в итоге в конце месяца мне пришел счет на 600$. Это очень неприятный урок, в то время, когда я рассчитывал на 10$

я тоже так случайно влетел на фритир гугла и бонусными 300$. Кто ж знал, что айпишники платные и при удалении ресурсов, ты за айпишник все равно "платишь". Благо сумма была небольшая, но осадочек остался

А у амазон эту цену надо фиг знает где искать

потому что у амазон цена зависит от региона размещения. нормальный вариант, когда Орегон ~в два раза дешевле Франкфурта.

Когда я открываю это окно, то регион у меня уже выбран

Огромная задержка оповещений именно у Амазона, насколько я понимаю. Мне от них оповещения вообще как-то рандомно приходили. У других провайдеров попроще. А еще можно выставить кучу лимитов вроде доступных вычислительных ядер и прочее, чтобы оставаться в разумных пределах. Не знаю, как насчет сложных сервисов типа BigQuery AutoML, где заранее вычислить затраты не получится и с лимитами может быть сложно разобраться, но с базовыми сервисами задача вполне решаема.

Если пообещать жесткие лимиты в пользу клиента, то это не только станет поощрением халатности новичков, но и откроет большой простор для злоупотреблений.

Microsoft Azure имеет жесткие лимиты. В том числе именно так работают «виртуальные» 120$ в месяц для MSDN-подписчиков.
Немного неудобно, что оно не восстанавливается само в начале нового периода а надо вручную перестартовать-передеплоить… вот это плата за обучение.

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

Технически реально сделать достаточно точный биллинг, если резервировать деньги чуть с запасом. Условно, есть глобальный сервис, который резервирует деньги, попутно проверяя лимит + даёт грубый прогноз по использованию на, например, минуту вперед.

Каждый сервис синхронно берет себе среднеминутный лимит, локально его уменьшает, и при окончании берет ещё. Тогда нетфликс будет откусывать на свои S3 по $1000 за раз, а стартапер Вася по $0.001

Уверен, что все резко стало бы возможным, появись правильный закон или прецендент в суде против скотов.

Да уже сейчас всё возможно, если это нужно сервису. На любом бесплатном, условно-бесплатном или триальном плане умеют точный биллинг и ни байта сверху не подарят. А когда можно выставить счёт — так уже разучились.

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

Все можно.
И есть широко известный пример.
Сотовая телефония.
Был постоплатный биллинг раз в месяц.
Но сейчас имеем как норму — посекундную тарификацию.
Просто оказалось выгодно найти решение.


А насчет облачных сервисов — у Selectel'а ж было облако и с посекундной тарификаций cpu и (насколько помню) учетом операций ввода-вывода с диском по одному запросу.

Вот и сотовые операторы утверждали, что "нельзя сделать". А после прецедента с Мегафоном как-то исхитрились и биллинг стал обновляться почаще, чем раз в неделю.
Наказание рублем почему-то сразу открывает новые технические возможности.

Интересно, есть ли уже какие-то решения, которые отслеживают биллинг/провиженинг в реальном времени, чтобы если не остановить сервисы, то хотя бы уведомить клиента?


В том же GCP, насколько знаю, биллинговые данные попадают в bigquery, оттуда можно как-то мониторить. Ну и тот же cloud pub/sub с уведомлениями — но опять же, насколько вовремя они туда попадают?


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


Те же кубы и виртуалки вполне себе легко посчитать + явно задаются лимиты автоскейлинга. А вот эти модно-молодежные лямбды и фаербейзы — работа "по волшебству" имеет две стороны медали — нужно меньше Ops, но и не понятно, когда сколько реального потребления и сколько придется заплатить.

Вопрос: а почему бы не подключить тариф с безлимитной или пакетной лимитной нагрузкой, а не с оплатой за операции поштучно?

Интересно, есть ли уже какие-то решения, которые отслеживают биллинг/провиженинг в реальном времени, чтобы если не остановить сервисы, то хотя бы уведомить клиента?

Насколько понимаю, все внешние решения пользуются billing data от хостера, то есть быстрее не получится.

А вот эти модно-молодежные лямбды и фаербейзы — работа «по волшебству» имеет две стороны медали — нужно меньше Ops, но и не понятно, когда сколько реального потребления и сколько придется заплатить.

+1

Да, конечно есть. Наша компания как раз этим и занимается. Одним из первых фичеров который зашёл нашим клиентам был как раз «риал-тайм» биллинг. Мы динамически опрашивали прайсинг амазона и считали на нашей стороне сколько сжигает клиент и оповещали об аномалиях. Название компании публиковать не буду, чтобы не подумали что это реклама

Мне жаль, но читайте документацию, ограничивайте autoscaling, настройте оповещение. Хотя бы пройдите базовый курс по AWS где об этом расскажут и покажут. Сам однажды налетел на 5000$, затем быстро изучил billing, autoscaling и т.д. затем прошел курсы :)
Это всё ради одной поля с суммой ограничений на траты? Не слишком ли мало AWS думает о своих клиентах?
Открыл когда-то AWS аккаунт поиграться. Через год он стал биллить по 80 центов. Ну я решил его закрыть. Оказалось, что мой имеил привязан к двум аккаунтам — AWS и потребительский. И при попытке залогиниться используя имеил AWS предлагает создать новый аккаунт. То есть на старый AWS аккаунт попасть нельзя.
Переписка с саппортом успехом не увенчалась. Вариантов решения от них всего два. Либо потанцевать со сменой имейла на потребительском аккаунте, что б получить доступ к оригинальному AWS. Либо заблокировать платежи в банке, типа аккаунт автоматически закроется. С аккаунтом что-либо делать на своей стороне они наотрез отказались. Видите ли требования безопасности такие. *тут меня уже трясти начинает*
Но вскоре банковскую карту пришлось заблокировать по другому поводу. И вот тут началось самое интересное. Амазон исправно каждый месяц шлет, что я им должен 80 центов. И если я не оплачу, то аккаунт закроется. А аккаунт не закрывается. После переписки с саппортом, в которой они опять мне предлагали потанцевать со ссменой имейла, до них таки дошло, что у них система сбоит. Пообещали исправить, но опять пришли письма об оплате. Я их переслал саппорту. Но надежды нет. Скорее всего поставлю спам фильтр.
Тех. поддержка некоторых корпораций просто ужасна. С одной стороны у вас товар примут обратно без вопросов, без чека, в любом состоянии, даже если возврату не подлежит. А с другой стороны «Компьютер говорит нет».
В чем проблема-то? Не используйте AWS.
Интересный вопрос — насколько использование облаков выгодно для среднего (и тем более малого) бизнеса?
С корпорациями всё понятно — штат разработчиков и админов, которые и посчитают, и настроят, и код напишут без ошибок, приводящих к увеличению биллинга (на самом деле нет). Но главное — $70k для них мелочь, заплатят ни не поперхнутся, ну разве что лишат премии виновника.
А вот у середнячков и мелочи все иначе — задачи, требования и возможности там иные. Во многих случаях хватило бы и On-Premise и VDS. К тому же экономическая выгода и окупаемость для небольших проектов, мягко говоря, не очевидны. Но реклама настаивает, что весь цивилизованный мир давно в облаках, открой бесплатный аккаунт, мол не пожалеешь.
В общем, смысл такой — нужно определиться заранее где облако необходимо, а где без него можно (и нужно) обойтись.

Нет, это НЕ интересный вопрос. Какой-то странный образ у вас "облаков". Вы вообще с ними работали?

Да. Писал для Azure. Serverless на .Net + API Gateway + Cosmos DB (Gremlin). Плюс разбирался с кучей других технологий. Разбирался с AWS, смотрел в чем там отличия.
Суть моего поста — есть некий проект Х, что для него выгоднее — использовать инфраструктуру On-Premise, либо развернуть VDI с необходимой инфраструктурой у хостера с фиксированной оплатой, либо развернуть тот же VDI в Azure/AWS, либо использовать специфические облачные механизмы (типа того же Serverless/Lambda), которые вне облака уже использовать невозможно.
Готовы сходу дать такую экспертизу по любому проекту?
Суть вашего поста пойти к облачному провайдеру и своими силами или с помощью менеджера (или даже архитектора) посчитать, что вам надо, а чего не надо. Очевидно, что тут никто вам экспертизу не будет делать в принципе.
Подобные заявления были бы к месту 10-20 лет назад, но не когда этот вопрос обсосан со всех сторон и с позиции практически каждого провайдера. Не знаю кому и что вы там писали, но вопрос даже близко не от человека который хотя бы просто знаком с этой сферой.

VDI своими силами точно будет разворачивать сильно дороже.

а что будет если ктото привяжет к сервису виртуалку на которой 5 копеек и использует быстро много ресурсов?
У амазона есть оповещалка о том, что биллинг выполз за определенный порог — письма вполне себе приходят. Прикрутить автоматику, которая по таким письмам попришибает все инстансы нафиг — задача вполне себе решаемая.
Так «не ходите дети в африку гулять...»
Это взрослые штуки для взрослых компаний, с юристами бухгалтериами кучей спецов и тд. например нетфликс.
Конечно это крайне неудобно и несправедливо!!! А кто обещал справедливость?
Куча бизнесов работаю по схемам похлеще этой, продажа бутилированной воды из под крана например.
Реклама, в том числе и проф кругах сделала свое дело все считают амаон = дешево… =)))))))))
Ник то же не хочет платить деньги(например админу, не говоря уже о том что бы сервер купить), вот вас и разводят на деньги супер професионалы, акулы бизнеса.
Левацкая какая-то статья. Не хотите — не пользуйтесь. В чем проблема? Не понимаю.
Only those users with full accounts are able to leave comments. Log in, please.