Комментарии 162
Есть три правила: не дарить, не играть в азартные игры, не выкидывать их
Девопс: А AWS можно использовать?
Джинн: 4 правила.
Напомнило комедию Brewster's Millions 1985 года. Там бедолага, для которого 300К это огромные деньги, тратит за месяц 30М что бы получить наследство в 300М :-)
Тем не менее, самый главный урок так и не был усвоен: хотя нафталиновые dedicated-сервера и не очень-то стильно смотрятся со стаканом смузи из сельдерея, они не так уж и плохи.
Если вам нужно хранить сотни гигабайт файлов, что s3 будет сильно дешевле выделенного сервера с таким объёмом хранилища. Одному клиенту перенесли файлы на s3, только не Амазон, а на местного провайдера. В итоге его затраты на инфраструктуру уменьшились на 3000$ в год. Это более, чем в два раза.
Но если такие объёмы хранилища не нужны, то безусловно дедик или VPS будет сильно дешевле, тут вы правы.
Вы тоже не усвоили этот урок.
Скажите, как вы в вашем кейсе "затраты на инфраструктуру уменьшились на 3000$" учли непредсказуемость ценообразования и риски от возможных санкционных/политических проблем? Каково матожидание того, что этот s3 будет работать для этого клиента весь год? Каков ущерб потери этих данных?
Нет, пока у вас сотни гигабайт, а не сотни террабайт, пока всё это влезает в стандартные блейды дедик всё-таки дешевле.
Я же написал "перенесли файлы на s3, только не Амазон, а на местного провайдера". Местный означает, что офис клиента и сервер с файлами географически находятся в одной стране. И даже в одном городе.
Риск непредсказуемости ценообразования решён был тем, что сайты наших клиентов уже много лет хостятся у этого провайдера, поэтому у нас был персональный менеджер, с которым можно было решить все проблемы.
Итого, на сегодняшний день клиент суммарно сэкономил порядка 15 тысяч долларов. И никаких непредсказуемых вещей за 5 лет не произошло, что говорит о том, что расчёт был сделан верно.
PS: на всякий случай поясню, если вдруг кто не знает, что есть такое понятие как "S3-совместимое хранилище", которое предоставляют большинство крупных хостинг-провайдеров по всему миру. В том числе и в странах СНГ. Все CLI-инструменты, библиотеки, интеграции с операционными системами и прочее с этими провайдерами работает абсолютно так же, как с Амазоном.
Хорошо. $15k сэкономленных на хранилище наводят меня на мысль, что изначально там всё было не на дедиках, а на не-S3 облаках. Как можно сэкономить на одном-двух блейдах такую сумму ума не приложу. Однако верю, что всё так и было. Просто меня обилие этих вот статей про непрозрачность современных S3-like облаков изрядно напрягает. И кажется, что актуальность таких решений работает только начиная с масштаба "нас был персональный менеджер, с которым можно было решить все проблемы".
15 тысяч - это 300 долларов в месяц в течение 5 лет. Там обычный VPS хостинг. Вот прямо сейчас смотрю разницу между VPS на 30ГБ и на 510ГБ (это максимальный объём, который можно у них сейчас взять). В зависимости от остальных параметров разница 100-150 долларов в месяц. Но там речь шла о цифрах 600-800ГБ с возможностью расширения. При этом хранить на s3 1 терабайт данных обходится всего в порядка 40 долларов в месяц. Сейчас вижу, что цифра в 300 долларов в месяц, вероятно, завышена (это наши маркетологи считали 5 лет назад). Но очевидно, что это минимум 100$ в месяц, что для того клиента уже двукратная экономия.
Вообще, S3 - это реально выгодная штука. Даже для обычного магазина на 30 тысяч товаров это уже выгодно. Единственный минус - время ответа сервера на отдачу файла будет минимум 150мс. Но скорее всего будет ближе к 300мс.
А вот где начинается жесть - это другие сервисы Амазон: EC2, RDS и т.д. Они заманивают маленькой стоимостью простых инстансов, но оказывается, что самый маленький EC2 вообще ничего не тянет, и надо брать побольше. А если у тебя 100% загрузка ЦП в течение 10 секунд и более, то тебе делают 10-кратный троттлинг процессора, в результате чего все твои приложения зависают намертво, помогает только рестарт инстанса. Чтобы этого избежать, надо брать инстансы чуть пожирнее, но всё равно 10 человек (да, всего десять) могут сговориться и зайти на твой сайт одновременно, из-за чего он опять зависнет. Поэтому нужно настраивать автомасштабирование. Для этого нужен хороший спец, а у них расценки от 50$ в час. И вот как раз из-за множественных прецедентов разбухания счетов за AWS тебе надо будет, чтобы этот спец не только всё хорошо настроил, но и посидел, помониторил нагрузки, многократно всё проверил. А там глядишь, неделя прошла - 2000$ только за настройку. А потом ты наймёшь сеошника, он скажет, надо просканировать сайт сеошной тулзой, чтобы проверить ошибки, и у тебя опять всё висит, опять вызывай девопса за 50$ в час и потом ещё отслюнявь Безосу пару косарей сверх обычного счёта.
У коллеги с бывшей работы есть клиент, который за хостинг AWS платит 2-3 тысячи $ в месяц и постоянно какие-то траблы. При том, что всё это можно было бы развернуть на Digital Ocean на дроплете за 300 долларов и всё бы просто летало. Но клиент ни в какую не хочет на обычный сервер, хочет по-модному. Я уже даже предлагал перенести всё тайком на DigitalOcean и сделать фэйковую админку облачного сервиса, чтобы просто рандомные графики ползли, чтобы клиент смотрел на графики, платил коллеге 2000$, а тот бы 1700 оставлял себе :D
А сколько стартапов загнулось просто из-за таких оверпрайсов за инфраструктуру, не счесть...
Вы что-то не то рассказываете. К примеру, если вам надо сложную обработку терабайтов геоданных за день выполнить, разворачиваете пачку инстансов RDS и один EC2 для загрузки и выгрузки данных, все делаете и удаляете все ресурсы. Вместо этого, вы хотите за сотню инстансов Digital Ocean минимум месяц платить?.. Аналогично с server-less functions - в облаке сотня тысяч запусков в сутки бесплатно, а с учетом неравномерности нагрузки на Digital Ocean вы будете немало за VPS платить, чтобы выдержать аналогичный трафик в пиковое время (скажем, тысячи обращений в секунду к разным ресурсам).
Во-первых, на DO тарификация почасовая, поэтому сразу за месяц платить совсем не обязательно.
Во-вторых, на DO и других подобных провайдерах есть автоматизация балансировщика нагрузки, чтобы увеличивать пропускную способность в пиковое время.
Ну и в-третьих, вы как раз привели пример, когда структура AWS даёт реальные преимущества. На деле же люди слушают всё это про терабайты, масштабирование, гибкость и т.д. и тоже думают, что им всё это надо, потому что у них "тоже микросервисы", а на деле там обычный фронт на нексте и бэк на пыхе и всё это разворачивается элементарно на чём угодно в 10 раз дешевле и проще, чем на амазоне.
Если тарификация почасовая, то чем оно отличается от амазоновского EC2 инстанса?
Это если пиковое время предсказать можно. Вот десяток или сотня студентов по команде преподавателя запускают мой софт, и за несколько секунд тысячи или десятки тысяч разных запросов к серверам отправляются. Ща один день это может произойти много раз или ни разу. Некогда тут масштабированием заниматься, а облачные функции легко справляются.
Насчет сценариев использования - практически всегда можно построить архитектуру, которая оптимальна для облаков. Другой вопрос, что это может быть не оправдано, когда уже есть рабочее решение. Попытка же перенести старый и часто «кривой» софт в облако это проблема квалификации, а вовсе не недостаток облачных сервисов.
Отличается тем, что Digital Ocean сильно дешевле и проц там быстрее.
Очевидно, ваше утверждение ложное. К примеру, много лет назад 6TB RAM инстанс на амазоне стоил мне меньше 30 баксов в час, и нужен был на час. Очевидно, месячная плата за такой инстанс (если есть) на Digital Ocean будет на пару порядков (в сотни раз) выше. Задача была обработать данные по океанам от NOAA на сотни гигабайт, можно написать оптимизированный алгоритм, который их будет обрабатывать по частям, но выигрыша от более дешевых инстансов на более продолжительное время не получалось, а ждать результатов пришлось бы намного дольше. Для такой очень неравномерной нагрузки постоянная аренда "железа" бессмысленна, а "облака" буквально за копейки позволяют решать практически любые задачи.
Очевидно, месячная плата за такой инстанс (если есть) на Digital Ocean будет на пару порядков (в сотни раз) выше.
Очевидно лишь то что вы сравниваете месячную аренду с почасовой. Только не понятно с какой целью, с учетом того что вы ровно одним комментарием выше выяснили что на DO тоже есть почасовая аренда.
Вы же не делаете вывод что в Новосибирске аренда кв в среднем будет дороже чем в Москве на том основании что в НС за месяц выходит больше чем за сутки в Москве?
Digital Ocean вам специальную конфигурацию на 6TB RAM под заказ на час не поставит. Куда им потом девать этот сервер после вашего часа использования? Хотите специальную конфигурацию - или колокейшен вашего собственного сервера или долгосрочный контракт с помесячной оплатой. В то время как у амазона вы без каких-либо долгосрочных обязательств просто арендуете на час этот сервер и после использования отключаете.
Если вы только на примере аренды недвижимости разбираетесь, то привезти нужный вам дом целиком из Москвы в Новосибирск с арендой на час стоит куда дороже, чем арендовать этот дом в Москве на час!
То есть вы привели пример опровергающий именно дешевизну DO сравнив часовую цену с месячной заведомо зная что
а) DO не предлагает почасовую ренту инстансов с 6TB.
б) DO не предлагает помесячную ренту инстансов с 6TB.
в) DO в принципе не предлагает ренту таких инстансов ни в каком виде и не предлагает колокейшна.
Все верно?
Возвращаясь к аренде недвижимости это как утверждать что 12 комнатные квартиры у Кремля дешевле в Москве потому что в Новосибирске их нет да и Кремль тоже отсутствует.
Может для вас это и логично но КМК в вопросе дешевле/дороже нужно сравнивать одинаковые товары имеющиеся в наличии. Например GPU сервера с H100. Или 2gb дроплет c t2.small.
Я объяснил, почему мне именно такой инстанс необходим был и как я его использовал. Вы же навязчиво «дедик» рекомендуете, невзирая на факты. Аналогично, я показывал выше стоимость трафика у Digital Ocean, так что мой средний чек составит только за трафик сотню баксов в месяц, тогда как у cloudflare это же я получаю бесплатно, а в случае непредвиденных скачков трафика счет будет неприемлемым для хобби проекта - порой, у меня рельеф всей планеты на терабайты скачивают несколько раз за месяц, если скачают сотню раз, на Digital Ocean это будет стоить тысячи долларов. И так далее.
Я вообще тут ничего не рекомендую ни DO ни AWS ни дедик(откуда они вообще взялись если вы обсуждали DO и AWS?) я писал исключительно про нестыковки в ваших комментарии.
Конкретно про то что сначала вы сравнили часовую стоимость с месячной а потом оказалось что и месячной(да и вообще никакой) стоимости то нет у одной из сторон сравнения. Аналогично поступаете и комментарием выше https://habr.com/ru/companies/wunderfund/articles/879130/comments/#comment_27903514. Та же самая логика, вы либо платите по часам либо просто у DO нет такого продукта. Такой опции как арендовать помесячно сотни инстансов отсуствующих в таблице прайсинга у DO у вас просто нет а значит и цену обсуждать бессмысленно. Либо если они все же есть вы так же можете арендовать по часам как и EC2.
В остальной части я с вами полностью согласен, если CF предоставляет что-то дешевле то почему его не взять? В идеале затраты владельца на сервис должны приближаться к 0$. Например сервис-медиаконвертер выполняющийся на клиентском Wasm а не требующий флота из 2000 инстансов на беке. Или на крайняк использующий спотовые инстансы.
На все ваши «почему» ответ вполне очевиден - если нужно решить конкретную задачу, составляется список требований и ищется подходящий провайдер нужных сервисов. Так вот выделенный сервер нужной конфигурации и нужной локации на заданное время найти реально только у облачных провайдеров, или нужно соглашаться на что дают и собирать инстансы от разных провайдеров. Следующий вопрос это стоимость трафика, внутри региона в облаках от амазон или гугл трафик бесплатный, а вот использование нескольких разных провайдеров зачастую делает стоимость трафика между ними неподъемной. А если еще и надежность учитывать, то платить за резервирование выходит куда дороже, чем брать облачные ресурсы с гарантированной доступностью.
И вы правы, как я выше и писал, нужно разумно выбирать реализацию и архитектуру и тогда в облаке будет комфортнее и выгоднее и без проблем с администрированием (привет админам из 90х, веселое было время, но больше не хочется).
Так вот выделенный сервер нужной конфигурации и нужной локации на заданное время найти реально только у облачных провайдеров
Так в том то и дело что в формулировке задачи "нужен 1 сервер с 6тб рам " DO(и еще много других) не дешевле или дороже а просто непригодны для ее решения. Не может быть отношения больше-меньше между числом и отсутствием числа.
О чем стоило написать что DO непригоден а не вводить в заблуждение что у DO есть по-месячный ценник для решения этой задачи.
Следующий вопрос это стоимость трафика, внутри региона в облаках от амазон или гугл трафик бесплатный, а вот использование нескольких разных провайдеров зачастую делает стоимость трафика между ними неподъемной.
Вот тут люди в посте кстати и влетели причем даже не на трафике. А на платных API запросах с response 403 сделанных сторонними людьми. Что вообще разумному подсчету не поддавалось, это полностью out of control. Тарифицировать подобное просто безумно. К счастью для них им счет простили но при этом как будто великодушие проявили.
В DO S3 такого не могло возникнуть, там только storage+трафик тарифицируются. И к тому же у них 1тб outbound + 250gb storage они идут за 5$. На AWS это будет около соточки за счет outbound. Ну и в целом outbound у DO в разы дешевле чем на AWS(наверное этот outbound траффик и делает для AWS всю кассу). В данном конкретном случае получается что DO лучше для разворачивания s3 чем AWS. Наверняка есть что-то лучше чем DO S3, как ваш CF Free Tier.
Есть у них ценник, сами напишите в поддержку и запросите, вам пришлют условия. Когда-то меня получалось, что в текущих ценах контракт на 3 года может быть выгоднее у Digital Ocean, чем на амазоне с предоплаченными серверами, но амазон за эти 3 года цены не раз скинет и железо обновит, а у Digital Ocean будет контракт с фиксированной оплатой и все то же "железо", поставленное под заказ. Ну и в чем смысл? И да, бывает и так, что надо 6TB на час, но хотя Digital Ocean и обещает широкий выбор конфигураций, на деле нужной конфигурации у них никогда нет.
На DigitalOcean нет таких огромных инстаносов. Но я этого и не утверждал :)
А CPU я тестировал с помощью sysbench и у DO результаты были гораздо лучше.
Cамый большой на DO - 256Гб/32 dedicated CPU стоит $2 за чаc.
в AWS такого размера инстанс(но с vCPU) , стоит также (я думал будет дороже...).
Мне казалось что облачные функции себя не оправдали и не особо востребованы. Их неудобно отлаживить и мониторить. Managed containers имеют схожие возможности, но гораздо удобнее в обслуживании.
Это вы эмбеддед разработкой четверть века назад не занимались :) А облачные функции отлично отлаживаются, посмотрите хотя бы онлайн среду отладки у Cloudflare (можно и в консоли, наверное, и IDE есть). Контейнеры для функций на доли секунды оверхед, а облачные функции стоят порядка микродоллара за вызов и с бесплатным трафиком.
А если вам надо обработку петабайтов данных, вы разворачиваете пачку инстансов и вам говорят "а нету" (квота превышена). И всё. Надо просить повысить квоту. А с той стороны логично говорят, что надо бы поучаствовать финансово. Так как простаивающие 75% времени сервера никому не нужны.
Облако имеет ещё и ограничение сверху, это тоже надо не забывать. Такое большое облако как AWS имеет большое ограничение, но не бесконечное.
Как будто вы в М-Видео просто зайдете и купите хранилище на петабайты, без предзаказа и прочих согласований. Помнится, как-то нужен был сервер с 6 TB RAM в облаке амазон, за несколько часов по заявке квоту повысили и за час меньше чем за 30$ я все вычисления выполнил (на меньших инстансах было на порядки дольше считать, а заказчик хотел оперативно получить результат). Сколько времени вам такой сервер по предзаказу везти будут и во что вам он обойдется?..
Вот Вы и выкатили четкий юзкейс для амазона и прочих "облаков": "непредсказуемая нагрузка, ненадолго". Есть и второй кейс - когда приток денег соизмерим с нагрузкой - условный "майнингоподобный" сервис - например, онлайн-игры, где риски закрытия проекта "вот прям завтра" и нагрузки с привязкой к часовым поясам - можно что-то выиграть на правильном масштабировании. Ну и "нагрузки всего-ничего" с "бесплатным" тарифом, но, "вдруг", возможностью влететь.
Если же вы каждый день "сложную обработку терабайтов" устраиваете, и это "будет годами" - то таки есть смысл посчитать дедикейтед ресурсы, причем, возможно, коло своей железки/стойки - окажется выгоднее уже через год. Тут привели ценник в 40$/TB. Это типа "каждые пару-тройку месяцев - диск новый за ваш счет".
В мире нет бесплатного - инженеры и инфраструктура облаков стоят денег. И или вы их платите "ихним", или "своим" за обслуживание своей инфраструктуры, причем часто свои "околобесплатны", т.к. уже з/п получают.
15 тысяч - это 300 долларов в месяц в течение 5 лет. Там обычный VPS хостинг.
Как я и говорил, это не дедикейтед
Беглый поиск нашел дедик в ниделандах с 22TB HDD за $70-80 в мес.
А если почитать условия https://www.digitalocean.com/community/tools/bandwidth, то уже за 10TB трафика в месяц еще столько же получится:
Estimated consumption: 10,000 GiB
Estimated overage: $80 (8,000 GiB @ $0.01 / GiB)
При сотне терабайт платного трафика за килобакс, возможно, до вас таки дойдет мысль, что что-то идет не так :)
То есть сначала вы пишете:
Скажите, как вы в вашем кейсе "затраты на инфраструктуру уменьшились на 3000$" учли непредсказуемость ценообразования и риски от возможных санкционных/политических проблем? Каково матожидание того, что этот s3 будет работать для этого клиента весь год? Каков ущерб потери этих данных?
А потом:
Беглый поиск нашел дедик в ниделандах с 22TB HDD за $70-80 в мес.
Даже не верится, что один пользователь мог написать два настолько противоречащих комментария. Надеюсь вы понимаете, что дедик с 22тб за 70 долларов происходит не от слова dedicated, а от слова dead?
Для справки дедик у приличного провайдера в СНГ с 1ТБ ssd обходится в 200-300$ в месяц. Что приблизительно на 30% дороже, чем VPS.
Ok,ok!
Я российских реалий знаю очень плохо.
Нидерландский дедик за $80/month нормально работает, слова dead там не встречалось. Но, да, если пользователь за РКН-стеной, то надо рассматривать хостинг в рф, тут ничего не попишешь. И приходится платить x3 от рынка.
Например, у Hetzner или OVH цены значительно выше тех, что вы привели. А платить втрое дешевле рынка за железо со свалки - ну такое. Даже если оно "нормально работает". Соглашусь, что для некоммерческого или низкомаржинального проекта, где никто тебя не засудит за потерю данных, это вполне себе рабочий вариант. Но напомню, что это не я завёл разговор про риски, санкции и SLA.
Что я делаю не так?
Не на те цифирки смотрите, вестимо. Сколько вам будет стоить резервирование, выделенный канал, трафик и срочная техподдержка, доступная 24/7? А просто железка без какой-либо гарантии работоспособности и доступности это не сервер.
Ладно, берём :D Не сразу увидел опцию добавления дополнительного диска. Но опять же надо учитывать, что S3 подразумевает репликацию данных, что даёт достаточно высокую отказоустойчивость. И уж тем более по сравнению с одним HDD. Понятно, что можно и самому на дедиках настроить репликацию, но это будет уже не 78 долларов.
А почему ты рассматриваешь дедик именно под данные, а сравниваешь с s3, который имеет oversubscription, shared compute и прочие прелести?
Ну закидай свой дедик дополнительной нагрузкой: веб-сайтик там, СУБД, балансировщик, мониторинг, что там ещё тебе нужно. В общем, примени к дедику те же низкие требования по SLA, на которые ты соглашаешься в случае с s3, и считай на круг.
@N-Cube: кстати, да, сколько там в Амазоне стоит поддержка 24/7?
Ты сейчас, наверное путаешь s3 и AWS. Т.к. s3 это именно файловое хранилище
сравниваешь с s3, который имеет oversubscription, shared compute и прочие прелести?
Что за бред? S3 это сервис хранения, а не вычислений (shared compute).И если вы считаете, что на диске провайдеры хранят больше, чем там физически помещается, вам у доктора провериться пора.
сколько там в Амазоне стоит поддержка 24/7?
Не знаю, сколько это стоит амазону, но проблемы со своими сервисами они решают когда те случаются, а не "в течении первой рабочей недели после новогодних праздников", как все эти digital ocean. Доступность сервисов тоже можно для любого региона посмотреть в реальном времени: https://health.aws.amazon.com/health/status
Что касается трэша типа дешевых dedicated server, порой при возникновении серьезных проблем kvm для доступа к серверу надо заказывать за неделю-другую, потому что "свободных нет и не скоро появятся", а скопировать данные с диска на другой или просто перенести диск на рабочий сервер стоит совершенно абсурдных денег и занимает несколько дней. А если там рейд обещают, то он или софтовый или на самых дерьмовых контроллерах и с десктопными дисками. Да на всем экономят, чтобы показать копеечный прайс. Если искать надежнее, то стоимость кратно выше, и тут уже считать надо, потому что и у амазона зарезервированные инстансы стоят в разы меньше.
https://aws.amazon.com/premiumsupport/pricing/
Там же внутри ссылка на сами планы. На developer никакими 24/7 и не пахнет (<12 hours это не 24/7 в том смысле, который обычно вкладывается, когда такое заявляют без уточнения «в течение 12 часов что-нибудь ответят»). Это, кстати, ничуть не лучше «сисадмин на выходных спит и глянет, когда проснется». А бизнесовый план от 10% месячного расхода.
Что касается дедика: вон там выше мерялка сервером аж на 64 гига оперативы и не с самым вялым процом. Это на складывалку файлов. Берешь Synology на 4 диска, везешь на colo — дешевле будет, и то, даже она (если на интеле) умеет даже в докер и всякое эдакое. Две коробки снюхиваются в репликацию парой кликов мыши. Вот отсюда и надо считать. То есть, примерно сопоставимые по уровню сервиса вещи. А сравнивать в лоб «система хранения размером с машзал за стенкой с временем восстановления не более 3 часов на любую дату в промежутке от сейчас до пара лет назад без права потери или порчи данных» с s3 любого вендора — такое. И лечиться надо именно тем, кто серьезно такое пытается сравнивать.
Что касается shared compute, то обвязка самой инфраструктуры s3 тоже где-то выполняется. Хоть 200, хоть 404 кто-то должен отдать. И выполняется она не на дедике, конечно же, а шарит вычисления с другими сервисами, иначе Амазон давно бы вылетел в трубу.
50 мс время отклика у Cloudflare CDN для 95% населения планеты требуют отнюдь не "Две коробки", вы сами-то понимаете, что ваши слова просто идиотизм? И для задач, требующих обработки данных (скажем, десятков гигабайт радарных спутниковых данных на каждый запрос - хотя бы потому, что снимок одной поляризации в архиве это около 5 GB, а для построения интерферограммы нужно два) ваши "Synology на 4 диска" только абсолютно технически безграмотный человек предложить может. И уровень сервиса выясняется просто - смотрим время недоступности за год и вычисляем %.
Абсолютно технически неграмотный человек может, напротив, на протяжении нескольких реплик забыть описать требования по своему кейсу, вместо этого размазывая обсуждение то на CDN, то на хранилку 30Tb.
Тебе вот прям критически важно в твоей задаче втянуть в рантайм, пусть будет 5Gb за 50мс? Ах, это всего лишь время отклика на запрос, а сколько времени занимает этот объем все же получить?
Ты задачу-то опиши. Сходи к грамотному специалисту, если придется.
Технических аргументов нет, началась подзаборная лексика и на ты? Мои проекты на гитхабе доступны, любой может посмотреть, кроме клинического идиота.
Ох уж мне эти «выкальщики», которые способны в одном предложении обратиться к человеку на «Вы» (с заглавной буквы!) и послать человека, будучи твёрдо убеждены в соблюдении всех необходимых приличий.
Сходи в правила Хабра, найди там про сетевой этикет. Сходи хотя бы на вики, почитай про этот этикет.
Далее, впредь, следи за темой, в которую лезешь, «технически грамотный».
Тема о том, что кто-то «сотни гигабайт» (то есть, даже не терабайт) перенес к локальному хостеру (забыли сразу про geo redundancy). https://habr.com/en/companies/wunderfund/articles/879130/comments/#comment_27902574
На что я заявил сразу же, что без сравнения предъявляемых требований по SLA сравнивать деньги невозможно.
Несколько соток гигабайт разместить на колокейшне можно как раз на Synology (давай даже считать Synology нарицательным, можешь заменить на любую подобную коробку по вкусу, мало ли, вдруг критический функционал именно Synology сейчас под санкциями): две коробки дадут ещё и redundancy, особенно, если разместить их у разных хостеров, не связанных общей инфраструктурой передачи данных. Это будет:
дешево
пердито
отказоустойчиво (причем, у именно Synology сразу два сетевых порта, которые могут работать как в режиме redundancy, так и в link aggregation, давая дополнительно ещё и скорость передачи данных)
минимальные телодвижения, и те мышкой в веб-интерфейсе коробок
Ах да, на всякий случай поясняю «технически грамотному»: SLA — это service level agreement (не statistics). Это именно договор, набор обязательств, которые хостер берет на себя на будущее, а не обзор инцидентов в прошлом. У серьезных пацанов SLA ещё стойко ассоциируется с финансовой ответственностью за несоблюдение этого самого SLA (иначе ничем не отличается от «мамой клянусь»).
Ты задачу-то опиши. Сходи к грамотному специалисту, если придется.
Послать собеседника, а потом апеллировать к правилам хабра, что не хамло - детсад какой-то.
две коробки дадут ещё и redundancy
У вас школьная перемена и охота написать на хабр?
Мам, смотри, я затролил деда, назвав его школьником!
Ясно. В такой постановке, конечно, только облака подойдут.
Раз вы не умеете в простую арифметику, то школьник это хорошо, лучше деда-идиота. У меня на гитхабе (см. отсылку выше) примеры спутниковой интерферометрии , которые обрабатывают в среднем 10 гигабайт данных, и десяток примеров требует скачать сотню гигабайт. Для университетской лекции на сотню студентов нужно скачать 10 терабайтов, а для открытой лекции это может быть и вдесятеро больше, то есть 100 терабайтов. Лекция длится полтора часа, а время скачивания всех данных не должно превышать 15-20 минут, иначе посчитать и посмотреть уже не успеют. Хотя бы с помощью нейросети посчитайте, сколько месяцев займет передача такого объема данных с вашей «коробочки» на вашем домашнем тарифе… Ну и кто еще, кроме школьника или неграмотного идиота, будет утверждать, что 15 минут и год это одно и то же?..
А, я начинаю понимать.
Поправь, где неправильно:
берем синолоджи, напихиваем дисками, сетапим, несем в коло
Там требуем к нему домашнее подключение
Хостер делает круглые глаза
Трясем пачкой денег
Хостер делает «сомнительно, но окэй, любой каприз за ваши деньги»
Ставим коробку у хостера на домашнем подключении
Оно работает медленно, тупит и брыкается
Бежим срочно всех называть идиотами за то, что не взяли S3, ведь вышло жутко дорого и всё равно не работает
у хетцнера в их подключаемых volume тоже репликация. правда бэкапа прямо из панели нет, надо самому изнутри системы делать.
Такие штуки появляются легко - осталось от клиента, заплатившего за сетап, или вообще как оплата кредита за железо (=профит с дельты между ценой кредита+свет/инет и 70 баксами). Единственная проблема - залить туда 22ТБ или их слить, и цена за +22ТБ доставить (и сколько их можно доставить) может неприятно удивить.
сидел на микро. С посещаемостью по гугль-аналитике >20К "сейчас на сайте". Только пришлось своп добавить.
Странно... 4 ТБ серверный HDD стоит порядка $100, если раз в месяц его менять, получается в 4 раза дешевле, чем s3 - видимо, примерно об этом пытался сказать Ваш оппонент. Решения on-premise почти всегда стоят ощутимо дешевле cloud-based реализаций - начиная от "васянова домашнего медиасервера", заканчивая высоконагруженными кластерами банков и прочих РЖД. В практическом опыте ни разу не встретил выгоды от перехода на облачные хранилища - SaaS - чуть другая тема - тут "облачная почта" и даже "облачная система бухгалтерского учёта" запросто могут оказаться оправданными... а могут и не оказаться.
Если вы крупная компания, ваши расходы - это не только железо, но и человеко-часы, то конечно s3 вам обойдется дешевле выделенного сервера, т.к. s3 упрощает очень многие административные задачи, т.е. платить программистам придётся намного меньше.
В моем проекте сотни миллионов файлов, терабайты данных, и выделенный сервер оказался дешевле. Но там только я один, конечно пришлось хорошо "попрограммировать", что бы хранить это всё эффективно, но время не жалко, ведь это хобби, которое приносит деньги.
Такие дела...
Если вы работаете один, то та крупная компания, о которой я рассказывал, была в три раза больше вас.
Поддержу. Сам был частью поцесса миграции с 2х датаценторв в AWS. И деже те, кто это затеял говорили, что оно не будет дешевле в AWS, но будет сильно меньше геморроя с людьми.
Держать штат админов
Обновлять зоопарк операционок новыми версиями
Следить за сертификатами
Нанимать/уволтнять, добавлять тимлидов чтобы с сотней админов управится
Уметь настраивать 150 разных сервисов и обновлять их! 10 версий оракла, 4 mySQL, 2 версии Spark, и т.д.
Самое, на мой взгляд, главное в облаках ( о чем мы как инженеры мало задумываемся, а бизнес сильно) это нереально быстрое прототипирование и запуск новых решений.
Захотел поставить redis перед приложением - 5 кликов и готово, захотел БД на 3ТВ поставить, чтобы отчетность или бигдату погонять - 15-20 минут курения мануала и готово. Через месяц можно дропнуть если эксперимент не выгорит. И не надо держать парк специалистов под все.
Тут вот какое дело - настроить/заапгрейдить СУБД - раз в дофига времени. Если у вас свой девопс с ансиблом или подобным - вообще автоматически 100500 раз не проблема. А за RDS будете платить денег постоянно. Т.е. - для "обкатать концепт", "надо ненадолго куча ресов" - облако в самый раз. Для "посмотреть, как у профи настроено" - тоже. Но в случае "понятно и предсказуемо" - оно почти всегда дороже, плюс если у вас свое железо - вы можете его сделать "под себя", а не выбирать готовый инстанс в стиле "брюки или широкие и длинные, или короткие и узкие, длинных и узких - нет".
Это чем-то напоминает "развивать бизнес на свои или на кредитные?" - своих может не хватить на нужный темп развития.
Чтобы эти два решения вообще можно было сравнивать, приведи, пожалуйста, SLA для обоих. Ну, чтобы не получилось, например, что к дедикам выставлялась нулевая терпимость к потере данных, а «местный s3 за сохранность ответственности не несет».
Хранить и смотреть - наверное. Но, если вдруг вам понадобятся все эти данные...
Мои опенсорс проекты терабайт десять трафика в месяц создают, и все это бесплатно крутится в «облаках». Просто, удобно, надежно, и бесплатно - а вы что можете предложить взамен? Касаемо AWS, так они давно известны тем, что то ненужные бэкапы делают и берут деньги за хранение, то другими способами денег сдирают, все это при фактическом отсутствии лимитов (которые вроде бы есть, но применяются очень запоздало) может дорого обойтись. Давно удалил там учетную запись, во избежание.
у меня тройка Тб трафика, средняя нагрузка на проц в 70-90% (i5-13600K), ~6ТБ SSD, ~30 ТБ HDD, я даже не хочу знать, сколько бы мне это обошлось в облаке, а сейчас это обходится в 2 провайдера на 2тр/месяц и периодические расходы на аккумуляторы для UPS.
Вы утверждаете, что у вас распределенные по всей планете сотни серверов с резервированием, высокоскоростным интернет каналом и дисками на ~6ТБ SSD, ~30 ТБ HDD каждый стоят в сумме 20 баксов в месяц? Или вы системник с помойки в бабушкиной тумбочке сравниваете с CDN? Будьте любезны привести пруф на такой тарифный план, а то ваша адекватность вызывает сомнения.
Вы утверждаете, что у вас распределенные по всей планете сотни серверов с резервированием, высокоскоростным интернет каналом и дисками на ~6ТБ SSD, ~30 ТБ HDD каждый стоят в сумме 20 баксов в месяц? Или вы системник с помойки в бабушкиной тумбочке сравниваете с CDN?
Нет не утверждаю. Просто для перелива бэкапов бэкапов фотографий меня и моей сраной любимой кошки CDN как бы не особо и нужен.
Если у бизнеса 90% клиентов находится в ДС, его не особо волнует время отклика из префектуры Хиросима
мне кажется, что я отчетливо дал понять, что речь не об облаке, упомянув несерверный проц, 2-х провайдеров с явно некоммерческими тарифами и затраты на UPS и сказав, что и слышать о тарифах в облаке не хочу (по той причине, что возможно что 1 месяц аренды высоконагруженного сервера обойдется мне в полную стоимость оборудования). А распределенные по всей планете сервера - это не частый случай потребности, особенно для частных проектов.
А распределенные по всей планете сервера - это не частый случай потребности, особенно для частных проектов.
Это как раз типовый случай, что подтверждают миллионы (или уже сотни миллионов?) репозиториев на гитхабе (в облаке). А как у вас в тумбочке диски хранить это однопользовательская задача, которая, возможно, и вовсе подключения к интернет не требует (а если и требует, пара терабайт в облаке от эппл стоит 600 руб/месяц и у других провайдеров сравнимо, а порой, и намного дешевле, в зависимости от).
3 Тб трафика в месяц это совсем немного. Давайте зайдем на сайт Amazon и посчитаем.
Согласно информации указанной в разделе S3 -> Data Transfer, на момент создания данного комментария первые 10 Тб трафика в месяц в локации us-east-1 стоят $0.09 за Гб. Путем нехитрых арифметических вычислений получаем 3*1024*$0.09 = $276.48 в месяц (и это только за трафик). Вот такой вот "pay for what you use".
О чем действительно страшно подумать так это о том, сколько согласно этим тарифам должен был бы платить тот же Github. Хотя, наверняка к ним прикреплен свой личный менеджер по VIP-клиентам с членством в местном гольф-клубе. Да и уверен, что маркетинговая повесточка для Amazon тоже роляет.
upd. Хотя нет, только что проверил - Github уже свинтил обратно на бренную землю.
Ах, да, классическая Denial of Wallet атака.
Т.е. получается, что зная имя чьего-то существующего бакета я могу тупо его заддосить и подставить владельца на серьёзные траты?
Б - безопасность.
Б - безопасность.
Ну для Амазона никакой опасности и нет, а париться о безопасности клиентов — не их забота.
Забавный факт №2 - получается что те компании которые неправильно настроили stress load и нанесли 1300$ ущерба они не виноваты, у них лапки.
Но при этом если ты откроешь возможность записи и попытаешься монетизировать то что они туда пишут то это уже уголовная статья, по версии автора.
Автор оригинального поста так же сообщает, что команда S3 уведомлена о проблеме и работает над её исправлением.
Т.е. теперь можно написать ПО, которое вместо 200 будет отдавать 3хх/4хх и вообще все запросы (даже ваши собственные) станут бесплатными?
Более того, амазон уже давно пофиксил это, почти год назад https://aws.amazon.com/ru/about-aws/whats-new/2024/05/amazon-s3-no-charge-http-error-codes/
Посмотрел документацию Yandex Cloud Object Storage:
Примечание
Операции GET, HEAD, OPTIONS, PATCH, POST и PUT, закончившиеся с ошибками 403 или 404, тарифицируются. При расчете стоимости применяются тарифы для стандартного хранилища.
Страшно жить!
Так любой ддос тарифицируется, работа то сделана. Я этого всего уже лет десять боюсь :), ну т.е. боялся, с asw пришлось съехать на vpsы и как-то даже "выдохнул".
Еще хуже с email. Если у вас есть любая форма подтверждения подписки скажем, то если спамить в неё чужие адреса, то жертвам приходит письмо типа "подтвердите что это вы регистрируетесь там то" и они начинают это все помечать спамом для гугла итп. И как эту коллизию разрешить совершенно непонятно.
Понятно, что у них есть основания тарифицировать этот трафик. Но это ведёт к тому, что он может использоваться для атак. И с одной стороны владельцу сервиса как бы всё равно, он деньги получит, даже избыточные. Но это и привлекательности для клиентов угрожает. Наверное, лучше эти запросы не тарифицировать, а компенсировать их стоимость чуть более высокой стоимостью остальных запросов. Тогда не будет стимула использовать их для атак на кошелёк клиентов сервиса. Тогда появляется возможность атаки на сам сервис. Но у них и возможности для борьбы с этим больше, чем у клиентов.
Капча на такие операции (отправка емейла на произвольный адрес) должна потенциально снижать риски. Как минимум будет выше стоимость атаки.
Форма восстановления пароля!
Двойной эффект: если угадал с адресом, то у пользователя растёт тревожность и опосредованно недоверие к сервису. Не угадал - просто раздражение и в каком-то проценте случаев пометка спама.
И как эту коллизию разрешить совершенно непонятно.
Да, именно так. Вся надежда на то, что всякие гуглы таки обучаются в процессе отличать злоумышленников, даже таких, которые маскируются за "нормальными" пользаками.
А так - лет 10 назад или около того случай был: mail.ru блокировал почтовый траффик с одной электронной торговой площадки, который она была обязана рассылать по 44-ФЗ (уведомления всякие). И никакие обращения в суппорт не действовали - "вы шлёте слишком много". Чуть ли не до Усманова тогда дошли.
Посмотрел на своем хостинге, s3 стал недавно тарифицироваться по гб трафику. Спасибо за статью, пока сделал лимит по трафику у себя.
Статья говорит о том чего нет. Уде не берут денег за не авторизованные запросы https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorCodeBilling.html
Годы идут, а косяки остаются. Мне где-то в 2018 или 2019 году AWS выкатило счет за S3, стал смотреть, активного хранилища нет, было когда-то, когда сделал один раз бекап сервера. Потом сервер был удален, бекап тоже. Но где-то в недрах S3 остался. В ответе пишут, у вас есть живое S3 хранилище, там бекап лежит. За это деньги просим. Я в ответ - а где в моей панели управления этот бекап? В лучших традициях райкинского "грузите апельсины бочками" две недели общался, пока тикет не попал видать куда-то выше. И о чудо, долг исчез. И тикет сам закрылся.
У меня было аналогично с бэкапом каких-то давно не существующих данных, который нигде не отображался, кроме биллинга. И даже после удаления всех русурсов во всех регионах AWS, деньги продолжали списываться. Помогло только закрытие аккаунта.
Увы... Закрытие аккаунта не гарантия остановки списывания денег, AWS явно об этом предупреждает. Надо все ресурсы вычищать
Пользуйтесь пэйпалом и предоплатными дебетовыми картами. Палка не спишется, если удалить клиента из автоплатежа, а карта не уйдёт в овердрафт.
Вычистить как раз не мог, не было доступа из консоли управления. Удаление аккаунта прекратило все безобразия. Странные вы вещи говорите - на каком вообще основании они могут списывать оплату с не-клиентов?
возможно версионность. Кажется она из панельки не видна.
Как-то вы припозднились с переводом. Оригинал вышел в конце апреля 2024 года, а спустя две недели Amazon перестали брать плату за обращения к S3, на которые ответ HTTP 403
https://aws.amazon.com/about-aws/whats-new/2024/05/amazon-s3-no-charge-http-error-codes/
У них этот "порядок исключения" действует буквально для всех при определенных обстоятельствах
добавление случайного суффикса к именам корзин
Обычно всё-таки префикса, и это делается примерно всеми и всегда.
И это явно указано в best praсtices, покуда у бакетов пространство глобальное имён.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html
Choose a bucket naming scheme that's unlikely to cause naming conflicts
Там явно написано, что это следует делать, если ваш софт сам создаёт бакеты, чтобы избежать конфликта имён. Если ты создаёшь фиксированные бакеты, это не является необходимым. Это не делается, чтобы скрыть имя бакета.
Если на клиенте используются подписанные короткоживущие ссылки для получения или загрузки файлов, то кто угодно может узнать из таких ссылок имя бакета.
чтобы избежать конфликта имён
Могу лишь ещё раз повторить широко известный факт: бакеты находятся в глобальном пространстве имён. То есть, два клиента AWS не могут создать бакет с одинаковым именем. Поэтому, чтобы не налетать на конфликты, все сколь-либо опытные известные мне люди работают с префиксами. Часто вида "<company_name>-<env_name>-"
И проблема, описанная в посте, произошла ровно по причине попытки создать бакет с именем, которое кто-то мог переиспользовать. Если бы там был префикс с именем компании/проекта, вероятность такого исхода была бы куда ниже.
В общем виде эта проблема существовала ещё задолго то появления AWS и S3-совместимых хранилищ. Кто-то завязывает свой софт на доменное имя, которое перестают поддерживать, а потом его кто-то посторонний регистрирует заново и получает много обращений. Иногда с заведомо злыми намерениями.
Недавно на hacker news обсуждали эту проблему в контексте Google Workspaces и их работы с OAuth2/OIDC: https://news.ycombinator.com/item?id=42699099
Я помню историю, когда где-то в Америке чувак решил повыделываться и заказал себе автомобильный номер "Номер не определен" - и ему автоматом пришли все штрафы, в которых был не определен номер нарушителя)
Там был NULL, насколько я помню.
То ли дело коварный "Prawo Jazdy", который бесцеремонно и серийно нарушает ПДД в Ирландии https://medium.com/@aydin.j.zubair/the-curious-case-of-prawo-jazdy-irelands-elusive-serial-traffic-offender-4c63f1150ac7
Чёт я не пойму, а white-list по ip к бакету? Или как это работает?
Если не ошибаюсь. S3 в Амазоне - глобальный сервис, он живет вне virtual private cloud, в котором ты мог бы сам настраивать сетевые правила и файрволл. В s3 ты можешь регулировать доступ через ACL в том числе по айпи, но ACL работают на уровне самого S3 и в описанной истории они как раз тарифицировались.
ИМХО достаточно очевидно, что банкеты на aws надо называть в духе human-readable-name-XXXXX. Если не из неочевидной экономии, то хотя бы из соображений безопасности. Публично доступный интерфейс же.
Правило номер 1 - если вы примерно представляете нагрузку и она тянется на одном барметале - то взять два барметала и натянуть на них HA, и это гарантирует вам что вы а) не придете к вендорлоку б) не получите ВНЕЗАПНО (с) счетов на сотни и тысячи баксов.
Облако должно быть приватным, либо с фиксированным прайсом не зависящим от нагрузки.
А цена "per request" включающая неаутентифицированные запросы это примерно то же, что платные входящие звонки.
Для глобальных проектов пара серверов это так себе идея, межрегиональный трафик стоит немало и задержки существенные. А локальные проекты типа интранета компании можно и вовсе в интернет не выставлять, vpn давно придумали.
d) будете платить НЕВНЕЗАПНО эти самые тысячи баксов адмиину/девопсу, который это всё поддерживает e) будете лежать на выходных и в праздники и немного по ночам, потому что админ/девопс у вас один и некому кроме него нажать на кнопку reboot, когда что-то зависнет
будете платить НЕВНЕЗАПНО эти самые тысячи баксов адмиину/девопсу, который это всё поддерживает
Вы, конечно, "забыли" что этот админ/девопс уже есть, поскольку раздеплоить типичную нынешнюю развесистую лапшу из сервисов и поддерживать ее в публичном облаке все равно кто-то должен.
удете лежать на выходных и в праздники и немного по ночам, потому что админ/девопс у вас один и некому кроме него нажать на кнопку reboot, когда что-то зависнет
Если ваша реализация такова, что у вас нет фейловера и вам нужно нажимать кнопку reboot когда что-то зависнет, то у меня для вас плохие новости...
"забыли" что этот админ/девопс уже есть, поскольку раздеплоить типичную нынешнюю развесистую лапшу
Чем больше инфраструктурного управления берёт на себя команда, тем больше придётся трудозатрат вкладывать для достижения заданных показателей надёжности и скорости разработки. И лапша самоуправляемого кубернетеса с двумя десятками компонент будет куда больше, чем описание аналогичных облачных ресурсов в терраформе.
Как человек, который делает и то и другое, я, конечно, буду всегда рекомендовать начинать с максимально высокоуровневых абстракций и брать максимально serverless зависимости, насколько это возможно для заданного проекта и опускаться на нижние уровни абстракции только имея конкретные соображения и расчёты.
Проблема в том, что мало кто умеет хорошо расчитывать непрямые расходы на инфраструктуру. Вот как раз в виде дополнительных человекочасов, рисков и замедления цикла разработки. Отсюда часто возникают мысли, что публичные облака -- это дорого, когда только вершина айсберга видна.
Как человек, который делает и то и другое, я, конечно, буду всегда рекомендовать начинать с максимально высокоуровневых абстракций и брать максимально serverless зависимости
Тут опытные стартаперы воспользовались серверлессом, поделились так сказать опытом - https://www.electropages.com/blog/2021/01/how-start-received-75000-bill-2-hours-google-cloud-services
А на кого-то и серверную стойку роняли при перетаскивании между этажами, это для вас доказывает необходимость отказа от датацентров?:)
Безопасность тех, кто таскает стойки в зону моей ответственности не входит.
А производительность и затраты ресурсов сервиса - очень даже.
Потому как если об этом не подумать, то потом получаются публикации типа "у нас было все правильно и серверлессно а потом мы выкинули свои же новомодные сервисы, сделали по-старперски - и неожиданно увидели, что затраты на инфраструктуру снизились в 10 раз" - https://habr.com/ru/articles/733780/
Ну покажите же нам, как мои нулевые расходы на сборку сотен докер образов в месяц на гитхабе, раздачу десятка терабайт трафика на клаудфларе, запуск десятков тысяч гугл колаб ноутбуков и многое другое вы сделаете вдесятеро меньше с собственным выделенным железом в десятках датацентров по всему миру и резервированием. Вы вообще сами понимаете, что говорите?
Тоже широко известная история. Сотрудники Amazon соптимизировали свои процессы внутри AWS и остались на нём же. Какие можно выводы сделать?
Что пихаемый во все щели сервелесс многократно оверпрайснут и малопроизводителен?
Странный вывод на основе статьи, где даже автор явно пишет в ретроспективе
which was a good choice for building the service quickly
Ну а сторонних рассуждений по теме вроде
https://www.linkedin.com/pulse/scaling-up-prime-video-audiovideo-monitoring-service-reducing-larry/ или https://www.infrastructureposts.com/p/e7-thoughts-on-scaling-up-the-prime
слишком много, чтобы в 100-ый раз это обсуждать.
В публичных облаках есть много разных способов решить одну задачу. Со своими плюсами и минусами.
Если какой-то подход всегда уступает другим, соответствующие сервисы теряют пользователей и просто закрываются.
Это широко известная в среде облачных инженеров история. Только вот эти стартаперы совсем не опытные, о чём они сами пишут в изначальном посте. И рекомендую почитать, что дальше произошло для полноты картины. GCP простил им этот долг.
Ну и ситуаций подобных описанной у меня не происходило, покуда я всегда держу в голове такой аспект и обвешиваю всё автобюджетированием, детекторами аномалий, ограничениями масштабирования и другими стандартными инструментами укрощения серверлесса.
А что, если я скажу, что я "воспользовался серверлессом" и выбил грантов на $700k "за красивые глаза" для стартапа от трёх крупнейших платформ, и все эти гранты удалось утилизировать на благо развития продуктов? Что у меня везде масштабирование с нуля настроено и утилизация ресурсов недостижимая для тех, кто сидит на своём железе? Не говоря уже про эластичность, гибкость и простоту прохождения любого рода аудитов и compliance процессов.
В итоге, конечно, рыночек рассудит -- я только за. Особенно, если посмотреть на числа и тенденции рынка. Что растёт и с какой скоростью. Какие компании куда миграции чаще делают.
Во времена первых «опсосов» (операторов сотовой связи) все делалось «из говна и палок» и ЧП были практически непрерывными. Да, дешево, но какой ценой для тех, кто все это поддерживал. Прошло примерно десятилетие и были потрачены огромные деньги, чтобы от этого уйти. И вот очередные новички, кто годами все это круглосуточно не поддерживал, зовут нас туда же, хотя я более чем уверен, ни один из них к tty порту линукс сервера по модему не способен подключиться и решить типовые проблемы типа рухнувшей файловой системы.
и выбил грантов на $700k "за красивые глаза" для стартапа от трёх крупнейших платформ, и все эти гранты удалось утилизировать на благо развития продуктов
А ну норм тема, освоить бонусы и деньги инвесторов и показать положитьный баланс (с учетом бонусов). А стартап назвать и показатели выручки конечно не позволяет NDA?
Наброс же был "злой гугл коварно выставил счёт на $75k". Вот я просто показываю, что бывает ровно наоборот.
Причем тут "освоить деньги инвесторов" - гугл, амазон и прочие предлагают гранты в виде оплаты определенного объема потребления их облачных услуг, а деньгами получить нельзя ни копейки. Можете и вы запросить такой грант, все открыто и доступно, но если денег на своем проекте заработать не сможете - вам такой грант ничем не поможет.
Ну вот вы сами и сказали то, что разрывает уютный манямирок юных стартаперов - есть только цифры: расходы, выручка и привлеченные средства. Если технологии Х дороже чем Y, то никакие гранты (привлеченные средства) не изменят того, что проект убыточен
А все эти «pay as you go» и «per-request price» означают линейный рост потребления и затрат, прямо пропорциональный клиентской базе и нагрузке - поэтому схема «у нас станет больше пользователей, выручка вырастет в два раза а затраты на 20% и мы выйдем в прибыль» тут не работает. И дыра в бюджете будет только увеличиваться.
А значит стартап будет закрыт как только по какой-то причине следующий раунд «привлечения внешних средств» зафейлится.
Облако должно быть приватным, либо с фиксированным прайсом не зависящим от нагрузки
В таком случае облако без нагрузки будет стоить те же пару килобаксов в месяц, что и облако с большой нагрузкой... Вы так весь смысл облаков перечеркнули)
Если вам нужно "поиграться" - это с лихвой перекроет минимальная виртуалка за копейки с фиксированной ценой, и вы не увидите прайса в $1300 как в статье. Если у вас есть продуктив - то скорее всего, ваша нагрузка уже достигла того уровня, когда дедикейты экономически выгодней, просто потому что те же ресурсы в облаке двукратно дороже.
Ну и внимание, вопрос - если посмотреть на то, как поступают маркетплейсы и вообще любые не-наколеночные проекты, то выясняется, что у них у всех есть свои ресурсовы с запасом (а порой и с двух-трехкратным) - и они считают, что это выгодней чем любое чужое облако (и часто пилят своё). Как вы предполагаете, у них какая-то тайная арифметика - или они все же что-то посчитали и поняли, что создать или даже вести разработатку своего облака оправданнее, чем использовать чужое?
Маркетплейсы это амазон что ли?:) Так они в облаке. Алиэкспресс тоже в облаке(алибаба клауд). НАСА пробовали свои датацентры и в итоге ушли на AWS, хотя у них объемы данных и трафик безумные. Они посчитали, хоть и постфактум.
Маркетплейсы это амазон что ли?:) Так они в облаке
Есть такой анекдот - амазон использует S3, EC2 и прочее, и вы используете S3, EC2 и прочее - но есть один нюанс.
Амазон себе денег не платит, а вы амазону платите. Поэтому бюджет амазона переживет ошибку которая приведет к миллиарду запросов и отскалирует сервис стократно. А в способностях пережить такое у вашего бюджета есть сомнение.
Отсутствие реалтайм лимитов на расходы у амазона отнюдь не проблема облаков как таковых, а просто бизнес-модель амазона (кто жалуется - тем обычно списывают "долг", но жалуются не все и не всегда). В гугл клауд совсем иначе сделано и безопаснее для пользователя, у клаудфларе еще лучше, на гитхабе и докерхабе вообще бесплатно (и можно делать уйму вещей, которые на амазоне изрядно стоят).
Маркетплейсы это амазон что ли?:) Так они в облаке. Алиэкспресс тоже в облаке(алибаба клауд). НАСА пробовали свои датацентры и в итоге ушли на AWS, хотя у них объемы данных и трафик безумные. Они посчитали, хоть и постфактум.
Если вам нужно "поиграться" - это с лихвой перекроет минимальная виртуалка за копейки с фиксированной ценой,
Это не облако же, а виртуалка. Облако как раз когда оно "резиновое", и ты платишь за то, что потребил, и не нужно париться с "ой, нагрузка подросла и всё упало". Ну или за воздух, если как обсуждаемой статье, плата взимается за провал авторизации.
Строго говоря, в описанной ситуации никакого вендорлока нет - довольно легко перейти с aws s3 на тот же s3 от другого провайдера
Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года.
Сегодня только вторник, а я прочитал ВысокоЧастотная АЛКОторговля...
Пойду планировать пятничный досуг 😁
«Несколько недель назад я начал работу над прототипом системы индексирования документов для моего клиента.»
Поднять в докере минио минут 15 делов.
Не так давно AWS перестал брать деньги за 403:
https://aws.amazon.com/about-aws/whats-new/2024/05/amazon-s3-no-charge-http-error-codes/
По статье возникло 3 вопроса автору:
1) вы выбрали какое-то простое имя бакета типа backup или example или что-то подобное, почему его никто ещё не занял до вас?
2) почему никто ещё не провёл такую атаку с регистрацией всех бакетов из словаря ?
3) как вы перехватили бекапы каких-то чужих приложений без авторизации с которой шли системы бекапа?
Годы идут, а статьи по уже пофикшенным проблемам продолжают выходить.
Как пустой S3 бакет может вас обанкротить