Comments 127
Напомнило историю про кудесника, который продал фальшивомонетчикам машинку по печатанью баксов. Купюры были настолько хороши, что проходили все проверки. Кудесник продал машинку за 100к баксов и исчез. Машинка проработала пару дней и прекратила. Ее разобрали, оказалось что создатель загрузил туда 10к баксов настоящих купюр, бумага, которую туда подавали для якобы печатанья складывалась во внутренний бункер, а машинка просто отдавала настоящие купюры. Пока не кончились.
Я даже нашел, где это впервые описано в литературе:
Интересный музей, ничего не скажешь. Больше всего мне машина понравилась, которая деньги делала. Ее студенты МВТУ сработали и грузинам за 10 000 рублей продали: нам настоящие деньги нужны, а фальшивую машину мы еще одну сделаем. Показали студенты, куда краску лить, куда бумагу вкладывать, куда спирт заливать. Делала машина великолепные хрустящие десятки, которые ни один эксперт от настоящих отличить не мог. Предупредили студенты грузин: не увлекайтесь – жадность фраера губит! Не перегревайте машину – рисунок расплывчатым станет. Уехали грузины в Грузию. Знай себе по вечерам денежки печатают. Но встала машина. Пришлось в шайку механика вербовать. Вскрыл механик ту машину, присвистнул. Обманули вас, говорит. Не может эта машина денег фальшивых делать. В ней сто настоящих десяток было вставлено. Крутанешь ручку – новенькая десятка и выскочит. Было их только сто. Все выскочили. Больше ничего не выскочит. Грузины в милицию. Студентов поймали – по три года тюрьмы за мошенничество. А грузинам – по десять. За попытку и решимость производить фальшивые деньги. Оно и правильно: студенты только грузин обманули, а грузины хотели рабоче-крестьянское государство обманывать.
(с) Аквариум. Виктор Суворов.
Это было сильно раньше описано, в какой-то детской книжке, еще бы название вспомнить ...
О, нашел - "Тельняшка - моряцкая рубашка", Ефетов Марк Семенович
https://m.tululu.org/bread_12309_22.xhtml
Как часто бывает с подобными авторами, история ворованная. Байка про деньгопечатную машину ещё дореволюционная.
Я даже нашел, где это впервые описано в литературе
del
Хотел ответить, но увидел ниже - уже ответили. Это было описано раньше в детской книжке.
del
А мне напомнило историю, как дачник попросил газовиков, прокладывающих недалеко газопровод высокого давления, подключить ему газ по дешевке, ему подключили, а через время газ перестал идти. Мужик вызвал газовиков, те стали копать по трубе и выкопали газовый баллон.
У нас похожая история была в городе когда микрорайон сдавали, разве что это было не мошенничество, а очковтирательство и потемкинские деревни
ленточка, губернатор, мэр, оркестр, открытие новых домов, газовое отопление, плиты, фотки включенной газовой плиты, фотки радостных новых жильцов (получивших дома по социалке)
проблема в том что газ до микрорайоне дотянули только через полгода (к осени), а чтобы сделать торжественное открытие, к газопроводу на вводе прицепили баллон с газом
Не ну 40 000 то сэкономил всё равно. Даже больше, если пару месяцев, то 130 000.
Как бы это не аукнулось. С тем же успехом можно нанять анонима для рисования логотипа в 3 раза дешевле, он его откуда-нибудь сопрет и исчезнет. А прилетит за неправомерное использование если что - компании. GCP наверняка имеет условия запрещающие его так использовать, со штрафами и компенсациями.
Тогда смысл статьи прояснился: через объявление ищут чувака, чтобы тот им ещё 1М акков залил. В конце должна быть приписка: "Чувак, вернись, я всё прощу! (твой директор)"
Если через полгода только затраты взлетели обратно, то этот товарищ сэкономил конторе полмиллиона примерно.
GCP же без привязки карты не позволит создавать проекты. Неужто тот надыбал миллион аккаунтов, к каждому из которых была привязана реальная карта?
Одна карта может быть привязана к нескольким аккаунтам, поэтому задача в целом сводится только к количеству аккаунтов.
А может там и база карденных номеров была ? А товарищ исчез, после того как органы его разработку начали.
Всего-то надо поставить в подвале компании десяток железных серверов по 40 тысяч каждый и пусть жужжат, модельку считают.
Нет, надо обязательно в облако всё пихать, за сотни килобаксов в месяц.
думается мне, что за 100к в месяц там был далеко не десяток серверов.
мы считали как-то раз стоимость только compute instance без учета затрат на обслуживание-амортизацию-итд - и гугловый клауд по стоимости был эквивалентен примерно 4 годам владения.
а для того, что они там за 100к в месяц арендуют - боюсь, что пришлось бы собственный дц в подвале строить.
а можете поделиться анализом? многим бы было полезно
кроме стоимости владения, железо быстро устраивает, в облаке постоянно обновляется
Если растёт требуемая вычислительная мощность(т.е. "устаревает" железо), то и облачные затраты тоже растут.
Если все правильно спланировать по комплектующим, расходникам, сроку жизни сервера и т.п., а так же найти где скупают Б\У сервера, то выходит дешевле, чем в облаке, НО самый главный минус - ты не знаешь скорость усложнения вычислений. Если эта параметр заранее известен: через какой промежуток времени тебе понадобиться увеличить мощность и насколько - то все легко и просто, а если они неизвестный - лучше облако (ну или стойку выкупить в ДЦ и самому всё, но это не меньший геммор).
Да в общем то. Облачные тарифы так рассчитываются, чтобы это было немного дороже, но не слишком(чтобы достаточная часть клиентов сочла условия приемлемыми).
Это смотря как считать и что сравнивать.
К примеру, если залить на какой-нибудь дедик БД объемом 100Gb и ничего с ней не делать месяц, то у железного хостера это вам обойдется в 40 евро, а в Firestore - 18 баксов.
А если из этой БД начать постоянно что-то считать со скоростью 1000 rps, то у железного хостера это останется 40 евро, а в Firestore станет 1500 баксов.
А если посмотреть в сторону Functions/Lambda, с аналогичным сравнением, то там вообще атас.
Облака требуют куда более скрупулезного подхода к архитектуре и реализации софта и не прощают ошибок :)
Облачные тарифы так рассчитываются, чтобы это было немного дороже, но не слишком
Если считать в 3-10 раз дороже как "немного но не слишком" то в общем то да вы на 100% правы.
Да просто берешь и по терафлопам и памяти считаешь в переводе на топовые видюхи. И да, не считая электричества и обслуживания.
Плюс, не у всех есть такой подвал и не всегда можно найти "подвал" в нужном месте по нужной цене быстро. Кроме того, полгода назад Dell просил делать заказы на полгода-год вперед из-за недостатка комплектующих (может сейчас лучше). Плюс, куча мелочей с содержанием этого всего, обновления безопасности, автоматизация. С хранением данных тоже не все просто, всякие Netapp как космос стоят, если ты не Verizon (у которого скидка 70%). Свой распределенный storage поставить легко, а когда накроется легко все потерять.
Нередко бывает, что еще купятся серверы под проект и пока сетевики настроят (а ведь хочется покруче навернуть в новом ДЦ же, не просто как в прошлый раз), пока на эту новую навороченную сеть научатся как все ставить (автоматизация особенно не любит случайных изменений)... В общем это дело может простоять год-два вообще без использования.
Но частично соглашусь, в облаке можно случайно кучу потратить денег, если никто в мелочи не вникает.
За 100к/мес можно взять два v4-64 TPU инстанса в облаке.
А какая у них цена простоя?
Потому что к десятку железных серверов в подвале надо добавить подвал электричество, кондиционер, бесперебойник, запчасти 2 разных толстых интернет-канала и обеспечить круглосуточное дежурство человека с отвёрткой.
И то вероятность "ой" будет кратно выше чем в AWS.
И всё это непрофильная деятельность для компании, раз они даже для продакшен пайплайна (сбор данных) привлекали внешних консультантов. То есть шишки будут набиты и оплачены.
Другое дело, что на 90 тыс. в месяц можно уже подумать про переезд в облако попроще или на bare metal хостинг. Так сказать есть слона по кускам
Потому что к десятку железных серверов в подвале надо добавить подвал электричество, кондиционер, бесперебойник, запчасти 2 разных толстых интернет-канала и обеспечить круглосуточное дежурство человека с отвёрткой
Есть очень простая математика: если ваша софтина загружает под завязку десяток железных серверов, то перенося её в облако, вы будете оплачивать облачному провайдеру десяток его железных серверов, его электричество, его кондиционер, его бесперебойник, его запчасти, его интернет-каналы, его человека с отвёрткой, амортизацию части его дата-центра, содержание его административного аппарата, его саппорта, его маржу и его налоги.
Поэтому облако дешевле собственных серверов в двух случаях:
а) если ваша нагрузка несущественна, и не догружает под завязку даже один сервер.
б) если ваша нагрузка имеет эпизодический характер, лишь время от времени требуя существенных мощностей.
В остальных кейсах намного дешевле организовать собственную серверную, чем арендовать.
Согласен с вами! Но еще надо учесть длительность владения проектом. А это величина труднопредсказуемая, особенно на начальном этапе.
И может оказаться, что дешевле платить за облако год, чем покупать железо стоимостью как 3-4 года аренды + строить свою инфраструктуру + нанимать админа.
А проект потом окажется не на столько приносящим деньги.
Если через год становится ясно, что оно взлетело и летит стабильно - тогда уже свое железо покупать
Судя по описанию проекта, тут уже можно и задуматься о своих серверах. Но ведь нет ничего более постоянное, чем временное решение?
Ещё есть точки на карте с очень дорогим электричеством, тоже аргумент в пользу облака.
Есть ещё момент с эксплуатационными затратами, надежностью и SLA. Если для пачки серверов надо нанимать сисадмина и платить за жирный канал, становится не все так однозначно. У облаков же как правило эти ресурсы шарятся между всеми остальными серверами. Кроме того, ни для кого не секрет, что облака сдают с переподпиской по физическому ресурсу.
А кто является владельцем данных, загруженных в облако?
А для облаков сисадмины не нужны? Нужны. Но то, что их теперь называют девопсами не делает их дешевле, скорее наоборот.
В облаке всё равно администрирования надо меньше, если используются специализированные сервисы, а не режим VDS-ки.
Скажем, я очень сомневаюсь, что у клиентов облачного Sentry часто возникает проблема с недоступностью из-за того, что Clickhouse отожрал в простое 60 гигабайт памяти (включая весь своп!). Такие вещи решаются админами Sentry, а не девопсами.
Скажем, я очень сомневаюсь, что у клиентов облачного Sentry часто возникает проблема с недоступностью из-за того, что Clickhouse отожрал в простое 60 гигабайт памяти
Ну да, у них просто ресурсы отскейлятся. Синхронно с чеком ;)
Зависит от того, что вы делаете. Если вам нужно много данных хранить и надежно, если баз данных разных и kubernetes, то такое локально поставить может и просто, а вот чтобы работало и не потерялось далеко не элементарно, был свидетелем ни одного примера (большую часть поддерживал именно железные серверы). А когда речь начинается про стеки, message сервисы и т.п., то там уже вообще нужно несколько команд кормить.
если ваша софтина загружает под завязку десяток железных серверов, то перенося её в облако, вы будете оплачивать облачному провайдеру десяток его железных серверов, его электричество, его кондиционер, его бесперебойник, его запчасти, его интернет-каналы, его человека с отвёрткой, амортизацию части его дата-центра, содержание его административного аппарата, его саппорта, его маржу и его налоги.
Только энергоэффективность датацентра будет значительно выше вашей серверной, железо облачный провайдер будет закупать с большой скидкой, а человек с отвёрткой будет обслуживать тысячу серверов, а не десяток и т.д. и т.п. Получится ли серверная в итоге дешевле? Я не знаю, но математика точно не такая уж и простая.
б) если ваша нагрузка имеет эпизодический характер, лишь время от времени требуя существенных мощностей.
У большинства вёб приложений, например, загрузка менятся в зависимости от времени суток, дня недели, праздников и т.д.
У большинства вёб приложений, например, загрузка менятся в зависимости от времени суток, дня недели, праздников и т.д.
Это как раз то, про что многие забывают. У нас в компании есть случаи, когда очень мощное железо включается на 2-3 часа в раз в месяц, или раз в день. И не нужно платить за сервер 24/7 при наличии почасовой тарификации.
Даже в вашей модели, а что если нагрузки на 1.1 сервера? Надо же покупать 2, то есть имеем КПД 55%. На самом деле надо 3, чтобы иметь возможность один выключить для обслуживания.
Согласен, что есть порог по количеству серверов, после которого дешевле нанять людей и сделать самим, а не покупать сервис. Но это явно не 1 и не 10 серверов.
Ещё точнее там много уровней по которым можно двигаться от "лямбда в AWS" до "собственный датацентр". Можно взять сервера в том же AWS, можно взять сервера не у AWS, можно арендовать место в чужом датацентре. Яндекс уже стоит свои датацентры и проектирует свои корпуса, стойки и материнские платы.
Но для каждого шага "вниз" нужно нанимать команду людей, учить их, вкладываться в R&D, что дорого. Всё это оправдано на тысячах и десятках тысяч серверов, если они у вас есть, то вам не нужны советы от комментаторов с Хабра :)
Я работал в банке и там считали риски на гриде из 1000+ железных машин. Так вот утилизация у них недотягивала до 10% (6-7% вроде насколько помню). Но час в день загрузка была под сотню.
Тут я вам могу ответить цитатой одного парня, вы, наверное, его уже читали:
б) если ваша нагрузка имеет эпизодический характер, лишь время от времени требуя существенных мощностей.
Хотя если вы работали в банке размером меньше Credit Suisse, и для расчёта рисков вам нужен был грид из 1000+ серверов, мне сдаётся, там есть непаханное поле для оптимизации сего процесса.
Просто в банках оракл с кубами
Ну мне это ничего не говорит. В кубах же вы не производите расчёты рисков, и вообще никакие расчёты, это data warehouse, а не транзакционная база. Просто бывает, что какую-то мудрёную бизнес-логику вешают на ETL-скрипт, который данные в те кубы льёт, и в итоге оно действительно требует 1000+ тормознутых инстансов, но это то самое непаханное поле для оптимизации.
Так стабильных загрузок почти и нет в природе - есть естественные колебания (в течение дня, недели), всякие регуляции, начало бизнес дня и прочие колебания нагрузки.
Так фишка в том, что и у облака тоже нет настолько стабильных нагрузок, чтобы равномерно раскидать стоимость аренды серверов по всем своим клиентам. Все их клиенты-финансовые организации дружно проводят сеттлмент после окончания банковского дня в своей зоне. А все их клиенты-магазины дружно наваливают транзакции в чёрную пятницу и перед рождественскими/новогодними праздниками. Поэтому облачные ресурсы точно так же часть времени простаивают, часть — в дефиците, а каждый сервер жрёт энергию, обслуживается и амортизируется непрерывно, и это тоже уже включено в стоимость облачных ресурсов. Чудес не бывает.
Неправильно, потому что
а) тот, кто специализируется на чём-то, делает это быстрее, а значит дешевле для себя.
б) облако более гибко в использовании, то есть ваш пик у кого-то спад в нагрузке и можно гибко использовать железо.
в) когда амазон покупает 12 тыс серверов - цена n, а когда вы покупаете 12 серверов - цена 2n, если не 3n за каждый.
г) когда есть готовое решение, масштабирование этого решения на 1000 клиентов намного дешевле, чем когда вы то-же самое решение создаёте только для себя.
в) компетенции Амазона гораздо выше компетенции админа Васи с отверткой, что потенциально может вылиться в простой и финансовые убытки.
в) когда амазон покупает 12 тыс серверов — цена n, а когда вы покупаете 12 серверов — цена 2n, если не 3n за каждый.
Ну эти же цифры сугубо пальцев в небо. Я покупаю свои 12 серверов не поштучно в магазине у дома, я покупаю их у дистрибьютора — конторы, которая покупает 12 тысяч на весь регион примерно по той же цене, что и Амазон. И что, вы где-то видели дистрибьютора, который продаёт их с двухкратной (или тем более, трёхкратной) наценкой? Обычная дистрибьюторская наценка — 30-50%, это позволит и операционные расходы окупить, и прибыль 10-15% поиметь. Ну т.е. разница есть, но не настолько критичная, чтобы существенно поменять экономику.
Плюс, ещё Амазон покупает какие-то типовые конфигурации. И если вам для ваших нужд понадобилось, например, больше дискового пространства, или там вычисления на GPU, вы очень неприятно удивитесь ценам облачных провайдеров.
Добавлю, что многие вещи вы просто не сможете купить на рынке, тк AWS кучу всего реализовал в своем кастомном силиконе, который поддерживает работу их системы виртуализации.
Это, кстати, вообще основной аргумент. Если рассматривать облако просто как хостинг вашего софта, экономика там действительно грустная уже для аренды чего-либо размером с одну стойку. Но если рассматривать облако ещё и как аренду готовых софтовых решений, с этой стороны оно намного привлекательнее. Тут и СУБД на любой вкус, будь-то реляционка, будь-то NoSQL, тут и контейнеры, и очереди сообщений, и мощные тулзы для аналитики и т.д.
то перенося её в облако, вы будете оплачивать облачному провайдеру десяток его железных серверов, его электричество, его кондиционер, его бесперебойник, его запчасти, его интернет-каналы, его человека с отвёрткой, амортизацию части его дата-центра, содержание его административного аппарата, его саппорта, его маржу и его налоги.Вы забыли про
А еще может себе позволить кидать простаивающие сервера на другие задачи\клиентов. Ваша железка так не сможет. По крайней мере так оперативно — точно.
Хочу заметить что чтобы ПП для 20 серверов не будет 20 раз дороже чем для одного то же самое с системой кондиционирования если ни одного сервера вам надо держать комплект запчастей кто-то не значит что вам нужно 20 комплектов до 20 серверов то есть такие вот затраты они размазываются на всех клиентов на все сервера поэтому получается чуть-чуть дешевле
Сейчас еще появился риск того, что вам завтра в облаке просто возьмут и все отключат нахрен из-за санкций, потому что вы в неправильной стране бизнес ведете. И весь ваш бизнес пойдет по бороде, потому что за пару дней серверную в подвале не сделаешь.
Справедливости ради, нужно сказать, что кого-то вовсе убили.
В этом мире всю его историю кого-то убивают.
Типа ок это ? А вот отжать за косвенное участие в этом бизнес не ок ? Тоже можно сказать, всегда кто то теряет, когда больше, когда меньше, чего плакаться то ?
При чем тут ок/не ок? Это реальность, нравится оно нам или нет, это существует и нужно разумно оценивать риски при принятии решений.
А "плакаться" - оно вам как-то поможет? Ну тогда поплачьте. Не поможет - какой в этом смысл?
А «плакаться» — оно вам как-то поможет? Ну тогда поплачьте. Не поможет — какой в этом смысл?А какой смысл плакаться отключению облака? Кого-то от облака отключили, а кого-то разбомбили вместе с тем самым «подвалом» с серверами.
А где вы увидели плачь по облаку? Это вы уже своих тараканов проецируете, зачем-то еще и бомбежки сюда приплели. Если попытаетесь прочитать исходный пост, то он был о том что существует такой риск, его вероятность в нынешней обстановке значительно возросла, и его уже нельзя просто игнорировать как что-то крайне маловероятное, что было еще не так давно.
Бомбежки подвалов с серверами - если говорить о большей части России, о "старых" территориях - это пока еще, слава богу, очень маловероятное событие.
А где вы увидели плачь по облаку?А, то есть, отключат — и ладно?
Это вы уже своих тараканов проецируете, зачем-то еще и бомбежки сюда приплели.Ага, ага, участие страны в военных действиях привели вы, а бомбёжки — это значит, я «приплёл».
Что же до «маловероятное событие», то год (с небольшим) назад украинские IT'шники, думаю, считали такое вообще невероятным.
В целом же, никто вам не мешает пользоваться облаками тех стран, в которых вы и ведёте бизнес. Ну, если вычеркнуть, опять же, вероятность того, что ДЦ облака внезапно окажется ближе вас к зоне боевых действий.
Не понял ваши претензии. Я по моему ясно написал - хочется плакать - ради бога, только это вашему бизнесу вряд-ли поможет в случае отключения. Разумнее заранее взвешивать все риски и понимать что облако на территории "недружественного врага" с большой вероятностью вам могут просто отключить по беспределу, несмотря на все ваше законопослушие.
Насчет бомбежек - сорян, запутался чуток в диалоге, это действительно не ваше было.
Насчет "косвенного участия" проглядел как-то. "А судьи - кто?" "Отжималы", если смотреть с такой точки зрения, во всем этом косвенно еще больше виноваты, чем обычный гражданин России, они весь текущий век спокойно закрывали глаза на многие очень дерьмовые вещи, которые творили их страны, одно перечисление которых займет не одну сотню строк. Или мы тут видим, а тут в упор не замечаем? "Вы не понимаете, это другое!"?
Да блин, не в справедливости дело то вовсе, а в оправдании людоедских привычек. Забудьте вы уже про оглядки, соседей и прочее, ведет твоя страна агрессивную войну не занимайся там бизнесом, каждая копейка заплаченная налогами - чья то смерть. Чувака примерно такого же как ты, который не при чем, тебе облачко отключили, а его убили на твои денежки. Когда падает ценность человеческой жизни, падает и смысл всех этих законов и регуляций, ради чего боялись ковида и масочки носили, те 500к примерно, которых уже переработали на военную колбасу ?
В основном изначально я хотел сказать, что доступа у вас нет не из-за санкций, а из-за действий руководства страны, оно пожертвовало вашими интересами и кое кем лично, для борьбы с гмо комарами и гусями.
Тогда вам вовсе не получится заниматься бизнесом и ни чем другим в принципе, потому что все страны ведут "людоедскую политику".
Я так понимаю вы с Украины - вас не парило что ваша страна восемь лет людей уничтожала на ваших бывших окраинах? А ваши лучшие друзья сколько миллионов людей убили по всей планете только за последние десять лет? Или тут у вас мораль работает, а тут уже "это другое"?
С чего вы вообще решили что я Украинец ? Типа если против убийства то не Русский? Про 8 лет, вы не устали ?
"Устали" это аргумент, конечно! Если людей убивают много лет, то это уже несчитово получается, это уже можно поддерживать налогами, так по вашему получается?
Меня это двумыслие уже даже не злит, забавляет, тут нам разрешено видеть "преступления", а тут мы вообще ничерта не видим, потому что это кого надо преступления.
PS Знаю, что мне тут сейчас карму сольют нахрен за неправильное мнение - да и черт с ней, переживу.
Вы вот вообще не понимаете. Я уже писал, если сосед жрет человечину, это не повод самому этим заниматься.
А по политике, вам больше нравится гейропа или китайский тоталитаризм ? Типа такой сейчас выбор, а не за целостность России, т.к. ее уже продали.
Еще это не повод натягивать сову на глобус. Если вы с оружием в руках защищаетесь от взбесившегося соседа-каннибала, вы не становитесь таким-же как он. Впрочем вам вряд-ли имеет смысл все это объяснять.
Ну тут вы описали мотивацию Украинцев, а на нас то кто напал ? И почему мы "защищаемся" методами которые осуждаем ? А давайте на личности не переходить и фразы "вам врядли имеет смысл объяснять" не использовать. Мне про ваши способности "понимать" тоже есть что сказать.
По мне ситуация простая - кто первым перешел границу другого государства, тот и агрессор. Вот так я примитивно думаю. А тот кто при этом утверждал, что государство это не имеет право на существование и никогда не имело называется фашист.
Если вы с оружием в руках защищаетесь от взбесившегося соседа-каннибала, вы не становитесь таким-же как он
Всё-то верно, но проблема в том, что взбесившийся сосед-каннибал, это не Украина, это мы.
Еще вы забыли, что на это время нужно всё, завтра не получится. Планирование, покупка и установка могут от полгода до года занять в зависимости от проекта и размера.
В одном lift&shift проекте стоимость 10х2 средненьких машин выходила в 150 килобаксов в год. Основная цена была в лицензиях легаси на винду и сиквел. Собрать у себя он-прем было около 60. И плюс 10 в месяц на 24/7 админов. Проект на 10 лет. Угадайте какой вариант победил? Во превых "генеральный мне яйца отрежет, если я затребую сейчас 70к, а 12.5 (150/12) частично влазят в месячный бюджет и надо-то еще часть экстра расходами оформить" и, конечно, "мы уже обещали облако".
Мы для своего клиента как-то запускали тысячи довольно жирных контейнеров в Fargate, считали за несколько часов и гасили до следующего раза. Сколько надо железа притащить в подвал и какова будет его загрузка, если считать надо условно 6 часов но раз в месяц?
Что свои сервера дешевле - это только кажется. Проблема в том, что если вам нужно развернуть отказоустойчивый кластер kubernetes, распределенную СУБД, настроить мониторинг и т.д. для этого нужны узкоспециализированные и дорогие специалисты. И это намного дороже облака где уже все сложное работает "из коробки". Но если у вас "монолит", то да - аренда bare-metal будет сильно дешевле.
Остаётся только один вопрос - а где он брал уникальные номера карт для этих аккаунтов, и каким образом он их валидировал?
У меня триал GCP не принимает даже вполне себе валидный one-time Revolut Virtual - чует, что препейд, и просит "настоящую" карту. А их не напасешься, поэтому даже второй аккаунт не дали создать - пришлось отдавать честно заработанный доллар за поиграться. Миллион же таких аккаунтов, да с верификацией карт - стоит явно дороже запрошенных 50к.
В общем, похоже на байку.
Эта байка уже была здесь. Если не путаю, автор уже признался что он это узнал от "приятеля одного сисадмина, который ...".
короче, не для Хабра, ИМХО.
Есть определенные сомнения в правдивости истории. Если человек смог написать такое расширение для Chrome значит у него очень глубокие знания GCP API. Ведь надо не просто создать аккаунт, а активировать его, создать ресурсы, запустить нагрузку и выгрузить результат. Такой человек вполне легально мог бы оптимизировать затраты компаний на облачную инфраструктуру и зарабатывать шестизначные суммы даже просто автоматизируя работу devops команды. И он врядле бы стал рисковать репутацией ради 50 тысяч.
Напомнило старый анекдот начала 90-ых, могу чуточку переврать:
Автосалон, французы показывают свою новую машину (Пежо) и хвастаются антиугонкой. Подходит невзрачный мужичок средних лет, и говорит, мол, интересно, можно я вашу сигналку протестирую? Французы переглянулись, мол, почему нет. Мужичок сигналку взломал за 2 минуты и говорит: ребята, фуфло ваша сигналка, любой инженер взломает за 3 минуты. Французы переглянулись и спрашивают: а зачем инженерам взламывать сигналки? У них же и без того хорошие зарплаты!
Какую вижу мораль в анекдоте: ситуации в жизни разные бывают, бывают, что и инженеры либо сами взламывают, либо делают инструменты для взлома. Особенно, если у них нет паспорта первого мира.
Может это был бывший(?) сотрудник Google?
Я думаю, что вы приувеличиваете значение репутации. Если имя разработчика не представляет собой личный бренд, то ваша репутация никому не интересна.. ее просто нет, а вы имеете определенный послужной список и достижения.
Личный бренд тут не при чем. Это обычное явление, когда при найме рекрутеры ищут доступную информацию по кандидату. Если они при этом найдут такую информацию, как в статье, то это явно не сыграет в его пользу. Тем более если речь идет о высокооплачиваемой позиции, а не аникейщик в институт стали и сплавов.
Не согласен. Репутация это именно хорошо узнаваемое устоявшееся мнение.
- Кто это ?
- Это@koil
- Тот самый @koil? Он подержал меня за руку.. не буду мыть ее неделю!!!
Собственно репутация для профессионала это почти тоже что что личный бренд. В противном случае, повторюсь, вы хороший специалист, но у вас нет репутации, а есть набор рекомендаций от прошлых работодателей.
Hidden text
Я пришел к этому мнению за просмотром одной из серий Аббатства Даунтон, где одного из слуг увольняют без рекомендаций (придется начать с низов), но не испортив репутации слухами о аморальном поведении.. правда тогда рекомендация - это вещь больше похожая на поручительство, когда предыдущий работодатель поручается за тебя частью своей репутации, но не суть. Аналогия все равно хорошая чтобы понять разницу.
Вы не представляете до какой глубины в узкой нише может докопаться целеустремлённый студент. Но его всё равно никуда не возьмут, потому что у него бумажки нет, и опыта работы тоже.
Почти год назад с директором по ИТ моего клиента связался
фриланс-разработчик, заявивший, что поможет сэкономить 90% от затрат на
облачные сервисы.
Одному мне любопытно откуда фриланс разработчик узнал как и сколько контора тратит денег?
Про AWS могло быть написано в вакансиях или в профилях на Линке текущих пользователей.
Сделать "прикидку" к носу можно исходя из профиля компании и её размеров.
Скорее всего, инсайд таки имел, раз знал, что
а) расширение хрома выполняет важную задачу и может выполнять бизнес логику
б) затраты идут на разовые запуски, для которых некритична потеря данных
Если бы этих пунктов не было, то финт бы не сработал. К примеру, если б они собирали все в кучу в каком-нибудь редшифте, и его силами б считали фичи на всей выборке, и это б составляло хоть 11% затрат, то фокус бы не удался
Если клиент такой жирный, то у него есть AWS Enterprise Support и выделенный TAM (tech account manager) одна из задач которого помогать клиенту снизить затраты на облако, для чего у него есть специальные инструменты и доступ к спецам, которые на этом собаку съели. Имхо история выдуманная.
Так задача-то заключалась в выполнении разовых расчётов в облаке. Вот буквально есть исходные данные (у пользователя, не у фирмы!), если скрипты которые их обрабатывают (эти уже у фирмы), надо эти скрипты где-то запустить, показать пользователю результат и забыть.
Что тут можно принципиально оптимизировать, кроме как поставить своё железо в подвале?
Не, можно конечно же скрипты переписать на что-то более производительное, но этим точно не техподдержка заниматься будет. Да и реверс-инжиниринг скриптов на перле по стоимости легко перегонит покупку железа в подвал...
одна из задач которого помогать клиенту завязаться на AWS покрепче вокруг шеи, чтобы даже мысли о переезде к конкурентам не возникало
Поправила, не благодарите
Inference инстансы могут стоить дорого, но что мешает объединять запросы в батчи, хранить пока не соберется достаточно, и запускать endpoints по мере готовности, а в паузах гасить? Это может легко снизить затраты в разы. Второе, зачем использовать AI aws service, если можно поднимать свои docker контейнеры с +той же+ моделью и существенно дешевле, при такой же мощности?
А мне почему-то при прочтении заголовка вспомнилась шутка про человека, который устроился на работу в компанию, разрабатывающую ПО, исправил один баг и уволился.
Дьявол, как говорится, в деталях.
NDA обычно покрывает не только фигурантов контракта но и предметную область. Т.е. мне трудно представить как в рамках стандартного договора можно писать в твиттере детали проекта.
Выше уже написали, чтобы использовать GCP нужно прикрепить кредитку к биллингу (Кстати, то же самое верно и для других облаков: AWS, Azure, Oracle Cloud итд). Поверить в файл accounts.yaml "содержавший примерно 1 миллион аккаунтов Google" — довольно трудно. На форумах действительно продают пачками аккаунты Google (очевидно для спамеров), но к ним никогда в комплекте не идет кредитка и активная GCP.
Если копнуть чуть глубже в механизм аутентификации GCP, то злоумышленнику наверное нужны были не сами учетки, а т.н. ключи или же по каждой учетке по oauth2 авторизоваться, чтобы добыть ключи. Т.е. даже если у нас есть мифический файл с миллином аккаунтов, на моменте входа в 5-6 аккаунт Google начнет требовать ввод капчи, блокировать ip итд.
Вообще непонятно зачем автору потребовался миллион аккаунтов, когда можно было и на одной (!) учетке сделать тоже самое. Т.е. грубо говоря, купить на хак-форуме одну (!) угнанную учетку GCP, и вот все эти черные дела сделать на одной (!) учетке.
К примеру, у меня был случай года 2 назад — у одного из клиентов в какой-то момент обнаружился в биллинге запросов в Google Maps на 50.000 евро, а у них ни один сервис в Google Maps не использовал. Как потом выяснилось, у глав. разраба украли токен через npm (установил какую-то ересь на рабочий комп из npm и она угнала токен-файл). Обнаружили в биллинге аномалию случайно, могли и год не замечать.
И вот чтобы совсем добить тему миллиона аккаунтов — не буду рекламировать, но точно знаю один рабочий сервис, который предлагает аккаунты AWS с балансом (т.н. кредитом) $100.000 всего за $2.000 — это очень известное предложение, оно рекламируется не на "хак"-форумов, и люди которые занимаются облаками с этим предложемнием прекрасно знакомы. Это противоречит правилам AWS и долго такой аккаунт не живет, но работать работает.
Что касается цены, то обычно когда AWS используют люди которые только-только перешли с on-premise — то они строят на облаках не так эффективно. Поэтому есть куча случаев, когда в проект приглашают какого-нибудь Solutions Architect, который, грубо говоря, настраивает auto scaling groups и делает проекту экономию 30-40%. Когда я прочитал заголовок, то думал что прочту еще одну подобную историю, а не все вот это. Миллион аккаунтов гугл-клауда.
Вообще непонятно зачем автору потребовался миллион аккаунтов, когда можно было и на одной (!) учетке сделать тоже самое.
Я так понимаю, на одной учётке нужны деньги, пусть и чужие. И если начинать воровать их — тут могут и органы возбудиться. Если же использовать бесплатный триал — состав преступления найти труднее, пострадавшая сторона тут только гугл.
Т.е. даже если у нас есть мифический файл с миллином аккаунтов, на моменте входа в 5-6 аккаунт Google начнет требовать ввод капчи, блокировать ip итд.Разве вся соль была не в том, что через дополнение браузера эти механизмы не работали?
Это было возможно только благодаря… расширению Chrome, которое не позволяло сработать проверке безопасности Google и отказать в создании аккаунта.
С другой стороны, если бы эта компания продолжила делать то, что им показал этот чел, т.е. абузить триальные аккаунты GCP и перераспределять нагрузку на них, при этом создавать новые по истечении триала старых, то компания сможет сократить свои расходы навсегда
На самом то деле, на триале доступны микроинстансы с лимитом в 720 часов/месяц только.
При создании триального аккаунта нужно вводить номер карты для того, чтобы нагрузка сверх лимита оплачивалась по результатам потребления.
Т.е. не выйдет создать 100 триальных аккаунтов, т.к. микроинстансы не подойдут для расчета ML/AI.
Ну, с чисто финансовой точки зрения компания все равно в плюсе осталась. С "экономией" 90к/месяц - затраты на "специалиста" они меньше чем за месяц отбили :). Главное теперь иски за использование левых аккаунтов не словить.
Мне кажется во втором абзаце потерялось слово
Это история о том, как благодаря (?) мой клиент снизил свои ежемесячные траты на AWS
Как загадочный разработчик снизил затраты на AWS на 90%, а потом исчез