Раньше я считал, что публичные облака дорогие, и как я заблуждался! Да что говорить, многие мои знакомые так и считают. Но я попробую объяснить, почему это совсем не так и я изменил свое мнение!
Cразу сделаю оговорку — все очень сильно зависит от вашего проекта. Но постановку вопроса это не меняет - так как облака, как правило, дорогие для тех проектов, где они не нужны. А какая разница, сколько стоит продукт, который вам не нужен! Но стоит вам начать реализовывать сложный проект, как раз в этот момент облачные сервисы и оказываются полезны.
Раскрытие информации: я основатель облака Amvera, в котором можно развернуть проект через git push, введя три команды в терминале. Потому я могу быть предвзят в этом вопросе и рассмотрю кейс, не относящийся к нашему облаку.
Давайте представим такой проект. SaaS-сервис. У вас 20 — 25 микросервисов. Некоторые из них масштабируются горизонтально, количеством инстансов. Основная база данных - PostgreSQL. Проект — прод, вам нельзя эту базу данных потерять. Плюс, вы пишете логи в Elastic, запускаете приложения в Kubernetes и используете брокер очередей сообщений Kafka. Да, это не монолит, который можно на VPS/железном сервере запустить, но и не космический корабль c несколькими зонами доступности и тысячами приложений.
А теперь посчитаем, где и за сколько это можно развернуть. Допустим, проект потребляет 100 vCPU, 400 Гб ОЗУ и 2 Тб SSD. Вернее, потребляет он меньше, но нужно брать с запасом.
Если взять любое публичное облако, получим очень примерно 70 000 руб. за CPU, 80 000 руб. за ОЗУ и 20 000 руб. за диск. Добавим еще 10 000 руб. на бэкапы и 50 000 руб. на managed PostgreSQL, Kafka, Kubernetes и OpenSearch. Итого получилось 230 т.р./месяц. Кажется, что это очень много.
А теперь попробуем это сделать на своем железе. Старый ноутбук или одноплатник с алиэкспресса тут не подойдут.
Если вам нужен новый (а смысл брать старый нет) сервер со 100 vCPU, 400 Гб ОЗУ и 2 Тб SSD это вам выйдет в 1,2-1,5 млн. руб. Хорошо, хорошо, вы нашли дешевле и взяли за 700 000 руб.
Решили развернуть на нем все сразу. И сразу столкнулись с тем, что Kubernetes нужно ставить на 3 ноды минимум. Это значит, вам надо либо на вашей железке поднять несколько виртуальных машин, либо использовать что-то вроде minikube, который можно и на одной запустить.
Железку нужно где-то ставить. Арендуем колокейшн на 2U за 10 000 -15 000 руб./месяц.
Ставим Elastiс и понимаем, что мощности не хватает. Плюс еще нужен стейджинг. Идем и покупаем еще один сервер за 700 000 руб.
Но вы получили не отказоустойчивое решение. Любой сбой и все пропало. Особенно это касается дисков.
Тогда вы идете и докупаете еще пару серверов за 700 000 руб. Нарезаете виртуалки, настраиваете сеть, поднимаете Ceph …
И вот, наконец, у вас спустя пол года и 2,8 млн. рублей почти отказоустойчивая инфраструктура. Если учесть, что года через 3-4 (возможно, через 6-10) вы их спишите, то стоимость владения с учетом инфляции будет около 60 000 руб. в месяц.
И за колокейшн вы платите каких-то "жалких" 60 000 руб. в месяц.
Но есть нюанс. За железными серверами надо следить. Вдруг диск полетит, надо заменить, да и много что может случиться. И для этого вы выделяете половину времени одного из членов команды. Зарплаты бывают разными. Но мы же экономим, поэтому заложим “всего” 75 т.р. в месяц.
Итог — мы получили сумму, аналогичную публичному облаку.
Но давайте будем честны, самостоятельно развернуть Kubernetes, Ceph, Kafka, PostgreSQL c бэкапами и т.д. проблематично. Вам понадобится пару инфраструктурных/DevOps инженеров. Хорошо, один “сын маминой подруги” за 300 000 руб/месяц.
Это я не говорю, что услуги по сопровождению и построению инфраструктуры могут и 1 млн. руб. в месяц стоить.
Но даже если брать по минимуму, мы получим 495 000 руб/мес против 230 000 руб/мес за публичное облако.
Тогда может брать сервера в аренду?
Сразу скажу, что получится еще дороже. Сейчас стоимость аренды примерно равна стоимости публичного облака.
Из плюсов своих серверов вы получите
Запас по вычислительной мощности.
DevOps в штате. Есть вероятность, что специалист будет вам полезен и при использовании публичного облака.
А из минусов
Неэластичность. Докинуть железный сервер в кластер, не то же, что виртуалку у провайдера.
Вы маловероятно настроите инфраструктуру также хорошо, как провайдеры с сотнями клиентов на которых они набили шишки. И все обязательно упадет, возможно, просто еще время не пришло…
В облаке вы получаете множество скрытых преимуществ из разряда защиты от DDoS, пулов IP, геораспределенности, нормальных бэкапов и много другого, что очень сложно реализовать самостоятельно.
Но не работают же облака в минус? Нет, конечно. Просто самые большие затраты это администрирование и построение общей инфраструктуры. А эти затраты теряются на масштабах провайдеров. Для них себестоимость чуть выше стоимости владения железом. Но «что позволено Юпитеру, не позволено быку», поэтому, пока ваш бюджет на инфраструктуру не миллиард в месяц, баланс затрат себестоимости будет не в вашу пользу если вы решите сделать что-то подобное самостоятельно.
Но давайте вернемся к вопросу - а вам облако реально нужно?
Если у вас небольшой сайт, и вы редко вносите в него изменения, проще воспользоваться простым хостингом. Хостинг в несколько раз дешевле виртуалки у PaaS облачного провайдера.
Если нагруженный сайт, но шаблонный, и вы не вносите много изменений, ваш выбор — хостинг или аренда железного сервера плюс настройка бэкапа в другое место.
Если вы банк, вам безопасники не дадут в облаке развернуться.
Если у вас стартап с частыми изменениями и вам нужно легко все развертывать из коробки и каждый день доставлять обновления, воспользуйтесь Heroku, или нашим сервисом Amvera;) Это даст вам сразу CI/CD, бэкапы, алерты и максимально абстрагирует от инфраструктуры.
И вот только если у вас сложный сервис, который должен работать в разных регионах или использовать сложную, нагруженную инфраструктуру, вам путь в классические, публичные облака.
Публичные облачные провайдеры берут деньги за то, что снимают с вас тяжесть развертывания и администрирования сложных инфраструктурных сервисов, разделяя эти издержки на множество клиентов. Если вы решите все делать самостоятельно, делить эти издержки будет не с кем. И на самом деле на выходе вы получаете относительно "дешевый" продукт. А сравнивать облако просто со стоимостью покупки железного сервера, это как сравнивать стоимость автомобиля со стоимостью металла, из которого он сделан. Но выбор, где разворачивать сервисы, за вами.
Комментарии (44)
n2dt4qd2wg9b
15.12.2024 16:21Не вижу в расчёте графу: заплатить за трафф между двумя сущностями в облаке...
kirillkosolapov Автор
15.12.2024 16:21Обычно трафик внутри одной зоны доступности бесплатный. Веселье начинается, если вам надо гонять трафик вовне...
kirillkosolapov Автор
15.12.2024 16:21Но у разных провайдеров по разному бывает
kirillkosolapov Автор
15.12.2024 16:21Только тут не понял за что минусы?)
Thomas_Hanniball
15.12.2024 16:21Видимо, потому что люди не согласны с вами. Трафик в облаках платный, иногда "неожиданно платный".
Неадекватная стоимость исходящего трафика у некоторых облачных провайдеров. https://habr.com/ru/companies/ruvds/articles/806689
В облаках платное всё: трафик, балансировка нагрузки, бэкапы, мониторинг, защита от DDOS и прочее.
kirillkosolapov Автор
15.12.2024 16:21Насколько мне известно, информация по ссылке немного устарела. Azure и AWS сейчас изменили правила для исходящего трафика (вот новость https://incrussia.ru/news/posle-aws-i-google-microsoft-zayavila-chto-otmenit-platu-za-peredachu-ishodyashhih-dannyh-azure-no-s-vazhnoj-ogovorkoj/). Но да, много подводных камней в тарификации (обращения к S3 как пример) и почти все платно
n2dt4qd2wg9b
15.12.2024 16:21Была история, в 2018м году собрал супермикру с двумя дисками по 8ТБ и она на домашнем интернете делала 20ТБ исходящего трафика в месяц.
Работал в AWS и коллега в шутку сказал: а почему не купишь инстанс?
Посчитал EBS тогда на 16ТБ +инстанс и исходящий трафф, и это дело мне обошлось бы в месяц в эквивалентную сумму стоимости супермикры.
Dmitri-D
15.12.2024 16:21Вы свое время и знания по поддержке железа и поддержке доступности сети, питания и пр. оцениваете в ноль?
Пример, может быть, не очень очевидный. А если ваш бизнас пойдет хорошо и вам потребуется 100 инстансов? А как собирать будете, где бежать будет pipeline, как проверять коснситетность, систему мониторинга делать? Облака экономят ваши деньги на том, что там загрузка инженеров равномерна - клиентов много. А вы наймете 10 инженеров, которые сегодня трудятся над релизом, а завтра их занять нечем, потом снова нагрука 120% - получится неравномерно. Инженеры - дорогой товар, особенно качественные иженеры.n2dt4qd2wg9b
15.12.2024 16:21Да, я просто показал простой edge-case, где месячная стоимость облака равнялась стоимости своей инфраструктуры. При этом я даже не брал во внимание стоимость инженеров ни в первой ни во втором случае.
Забавно и другое, я не считал стоимость трафика "для въезда в облако" и для последующего "выезда" из облака. А он был бы с х2, так как тогда AWS тарифицировала трафик от инстанса до EBS практически по той же цене, что и Интернет.
В 2016м мне пришлось работать в месте, где хостил свои личные сервера Shazam, кстати. Теперь уже не уверен, где они? Всё ещё на своих или пошли в облака.
vitaly_il1
15.12.2024 16:21нет, плата за egress осталась - отменили одноразовую плату за траффик когда уходишь из облака
ky0
15.12.2024 16:21Рассуждения, основанные на кейсе "у нас из ниоткуда взялся сложный высоконагруженный проект" - это такое.
Облака хороши в случаях, когда:
Вам надо очень быстро (и ненадолго) развернуть сервисы с приемлемой производительностью.
У вас паттерн нагрузки изменяется в очень широких пределах и пики занимают относительно небольшую часть времени - так, что в "среднем" положении инстансы жрут не очень много денег, а иногда их можно скукожить вообще почти до нуля.
Вы ведёте бизнес в стране, где не очень хорошо с поставками серверного и сетевого оборудования (и особенно с поддержкой оного), а большая часть квалифицированного персонала куда-то делась.
Во всех прочих случаях (особенно, когда нужна гибкость не в производительности, а в инфраструктуре) своё железо и свой отдел эксплуатации становится выгоднее на вполне приемлемых отрезках времени.
MarkovM
15.12.2024 16:21Ключевое слово - свой отдел эксплуатации. И свои DevOps. Если эти два отдела есть, жизнь становится проще. Но не многие могут себе позволить эти два отдела. Об этом и статья
ky0
15.12.2024 16:21Начать можно с одного отдела - эксплуатации. Потому что девопс-практики в значительной степени находятся внутри кружочка "Ops", и в особенности - на первых порах, пока основная цель, чтобы сервис просто надёжно работал. Обмазать остальным можно позже, если взлетит.
Areso
15.12.2024 16:21Полтора года работал с AWS. Отдел эксплуатации и отдел DevOps'ов никуда не делись. И даже DBA (хотя казалось бы...).
n2dt4qd2wg9b
15.12.2024 16:21Более того, днём с огнём дешевых облачных девопсов в Северной Америке не найти.
mentin
15.12.2024 16:21Мой вариант где облако выгоднее - интерактивное использование SaaS. Чем-то похоже на пункт 1. Аналитические интерактивные запросы можно исполнять на одной машине полчаса, или на тысяче пару секунд. В результате либо покупаешь тысячу машин, и они простаивают 99% времени, потеря денег. Либо аналитики ждут полчаса - и вы теряете ещё больше, потому что простаивают аналитики. Либо идете в облако, которое автоматически выделяет 1000 машин на пару секунд, платите копейки, и получаете отличную производительность.
mst_72
15.12.2024 16:21Можно по-подробнее про выделение 1000 машин на пару секунд для аналитиков (мы ведь про Спарк, а не про лямбды, не так ли?). Причем желательно именно про пару секунд, а не про, скажем, минут 15 спаркового кластера в каком-нибудь датабриксе
mentin
15.12.2024 16:21Мой случай не про Спарк, а про Google BigQuery. Там выделяются слоты на уже бегущих процессах (у них multitenant, и не надо каждому давать новый процесс или хуже того VM). Поэтому могут выделять (кусочки) тысяч машин даже не на секунды, а на миллисекунды, эффективно распараллеливая даже очень короткие запросы. Для интерактивной аналитики - самое оно.
DaneSoul
15.12.2024 16:21Посмотрел тарифы на сайте и не понял два момента по тарификации:
1) Если контейнер создан, но в данный момент не запущен - тарификация вообще не идет? Есть ли какая-то минимальная в месяц в таком случае? Например бывают тестовые проекты которые нужно изредка на пару часов запускать для работы.
2) Тариф считается на каждый контейнер отдельно или в рамках одного можно несколько не требовательных к ресурсам запускать?
kirillkosolapov Автор
15.12.2024 16:21Да, только за запущенные. Если остановить - тарификация отключается. 2. На каждый проект. Но проект это одно приложение, либо несколько, в режиме многопоточности. Т.е. много сервисов в одном проекте сложно запустить
mst_72
15.12.2024 16:21И хранение контейнера ничего не стоит?
kirillkosolapov Автор
15.12.2024 16:21Если вы не превысили лимит тарифа на хранилище (он не очень большой), то ничего. Если лимит тарифа превышен, буде тарифицироваться диск сверх лимита
Thomas_Hanniball
15.12.2024 16:21Если учесть, что года через 3-4 вы их спишите, то стоимость владения с учетом инфляции будет около 60 000 руб. в месяц.
Никто сервер через 3-4 года не списывает. Срок жизни сервера 5-7 лет. В некоторых случаях - 10 лет. Даже Microsoft, Google и Amazone эксплуатируют свои серверы в течение шести лет. https://servernews.ru/1081397
За железными серверами надо следить. Вдруг диск полетит, надо заменить, да и много что может случиться. И для этого вы выделяете половину времени одного из членов команды.
Чтобы обслуживать 3 сервера и менять там диски не нужно 0,5 человека (50% времени одного человека). Достаточно будет 3-4 часа в месяц, т.е. 0,025 человека (2,5% времени одного человека).
И за колокейшн вы платите каких-то "жалких" 60 000 руб. в месяц.
Зачем покупать свои серверы, если они всё равно поедут в ЦОД. Может лучше сразу арендовать выделенные серверы у хостера? Тогда и вся головная боль по обслуживанию железа ляжет на плечи хостера, а не вас.
Тогда вы идете и докупаете еще пару серверов за 700 000 руб. Нарезаете виртуалки, настраиваете сеть, поднимаете Ceph …
Нет, просто докупаем у хостера немного мощностей в другом датацентре, чтобы была гео распределённость.
MarkovM
15.12.2024 16:21Даже если взять ваши цифры, основная стоимость упирается не в железо, а в DevOps. Т.е. результат расчета принципиально не изменится. Облака вас избавляют от необходимости самостоятельного развертывания Kubernetes, настройки бэкапов (и так, чтобы он был рабочий) и т.д. Плюс, многие вещи (условная распределенная СУБД с синхронизацией по атомным часам у AWS) вы самостоятельно просто не сможете сделать
artptr86
15.12.2024 16:21Серьёзному проекту в облаках всё равно потребуется специалист для настройки и конфигурирования всех сервисов, а также для настроки инфраструктуры devops.
Areso
15.12.2024 16:21Плюс, многие вещи (условная распределенная СУБД с синхронизацией по атомным часам у AWS) вы самостоятельно просто не сможете сделать
А оно надо? Большинству проектов достаточно обычного мастера + реплики.
generalx
15.12.2024 16:21Вообще есть тема у оксген с стойкой в твоём помещение «edge cloud»
Все как обычно зависит от задач
ekhaskel
15.12.2024 16:21Принципиальная ошибка автора заключается в том, что он исходит из предположения что системы в облаках работают сами, без собственных девопс инженеров и других специалистов по инфраструктуре у пользователя. Я бы даже сказал классическая ошибка. В небольших проектах возможно так и есть. И полтора программиста, которые пишут код в таких проектах, заодно в оставшееся время могут и поднимать контейнеры и рулить базами данных/кубернетесом/кафкой. Но в реальных больших системах собственные сисадмины/девопс инженеры всё равно нужны. Сотрудники облачного провайдера отвечают только за общую инфраструктуру облака. И никак не отвечают и не могут отвечать за ваш проект. И поэтому вся арифметика меняется. На входе действительно проще, быстрей и дешевле поднять систему в облаке. Особенно если система не должна работать 24/7 и ВМ/контейнеры можно поднимать для тестов и отладки на пару часов в день. Но при реальной эксплуатации надо хорошо считать. То что дешевле и проще в первый месяц, далеко не всегда дешевле и проще в перспективе 5-и лет. И в этом я полностью согласен с @ky0 выше.
Плюс отсутствие доступа к инфраструктуре может сыграть и очень плохую шутку при неудачном стечении обстоятельств. Реальный пример случился с нами буквально на днях, когда рухнула часть облачной инфраструктуры Яндекса. И это по закону подлости был как раз день, когда мы показывали проект большому госзаказчику. Если бы это были наши собственные сервера, мы бы уже метнулись кабанчиком в ЦОД/серверную и подняли дополнительный сервер с копией системы. А так ждали у моря погоду, что-то придумывали/изобретали и пытались сделать хорошую мину при плохой игре...
Уже написал свой пост, а потом обратил внимание что это рекламная статья товарища из компании, которая предлагает облачные услуги. Не знаю, может у них хорошее облако, не проверял. Но не верю в сказки что большие сложные проекты будут хорошо работать сами по себе, без специалистов по инфраструктуре, которые ими непосредственно занимаются.
И, кстати @kirillkosolapov - а как у вас в облаке с 152-ФЗ?kirillkosolapov Автор
15.12.2024 16:21Попробую ответить на ваши вопросы. Да, вы правы, в крупных проектах есть свои DevOps, даже в облаках, но в облаках на них меньше нагрузка как правило (все конечно индивидуально). 2. Инцидент в Яндексе про который вы пишете описан вот в этом отчете - https://status.yandex.cloud/ru/incidents/1009?retpath=%2Fru%2Freports#report Он нас тоже затронул. Если кратко, у коллег упала сеть. Не на одном сервере, а глобально. Если бы в вашем ЦОДе условный "экскаватор судьбы" перекопал сразу все кабели, поднятие дополнительного сервака бы не помогло. Это я к тому, что инциденты разные бывают. Плюс, что вам мешало поднять копию системы в другом месте? На том же вашем сервере или в другом облаке. Кажется, это не сложнее чем установить дополнительный физический сервер и поднять с нуля на нем. А если глобально - у вас либо отказоустойчивое решение, когда вы выдерживаете падение сервера или целого ЦОДа, либо нет. А облако это или выделенные сервера дело второе. 3. К вопросу о рекламности. Я конечно не упускаю возможность упомянуть наш сервис, но статья к нему вообще не относится. У нас не классическое облако проект как в примере в статье у нас проблематично развернуть. Мы на другой сегмент работаем. Наши клиенты это индивидуальные разработчики, а не клиенты условного AWS. Т.е. наш основной конкурент это Heroku, а это совсем другая история не относящаяся к проблематике сложных проектов с DevOps. Я писал эту статью как раз как потребитель публичных облаков и железных серверов, а не как их продавец 4. Про 152 вопрос требует уточнения. У нас вся инфраструктура в РФ, перс данные для регистрации не нужны и т.д.
Резюмируя - вы отчасти правы, но если бы публичные облака были так "невыгодны", не пользовалось бы ими подавляющее большинство компаний из целевых сегментов
ekhaskel
15.12.2024 16:21Спасибо за столь подробный ответ.
По поводу инцидента в Яндекс - к сожалению, я очень хорошо знаю что там произошло. Проблема там была не физическая а логическая. И кстати, сбой в был внутри зоны, в связности именно между компонентами, снаружи всё (то что было живо 8-) отзывалось без проблем. И именно в такой ситуации можно было всё быстро поднять на другом физическом сервере/ах в том же ЦОД. Ну да это не принципиально. Отвечая на ваш вопрос - помешало поднять в другом месте то, что по ряду причин всё заточено именно под яндекс и именно под эту упавшую зону. А решение наше пока еще не географически распределённое потому, что облака это дорого, чертовски дорого...
Мы хорошо это знаем, каждый месяц переводя в Яндекс шестизначную сумму, уже очень близко приблизившуюся к семизначной, и пока не можем позволить себе её увеличить.
Выгодность/невыгодность надо хорошо считать. Я знаю компании, которые ушли в облака потому что это модно. Знаю те, которым неважно сколько это стоит, а важно что бы было кого засудить за сбой системы. Но знаю и тех, кто считал арифметику. Мы вот думали что всё посчитали и пошли как раз в облако. Но сейчас понимаем, что арендовав четыре года назад два шкафа в двух ЦОД сейчас были бы в плюсе..
Для индивидуального разработчика, который хочет поднять условный пет проект, не очень задумываясь что такое сегментация системы, разграничение доступа к данным, требования регулятора, которому нужно пару-тройку ядер, и который не знает и не хочет знать, что такое RDMA, маска подсети и Layer 7, но умеет писать yaml файлы - ваше решение однозначно может оказаться удобным и выгодным. Ни в коем случае не хочу никого задеть или обидеть, прошу не понять меня неправильно. Но для каждой конкретной задачи скорей всего понадобится свой определённый инструмент.
И, повторюсь, облака это удобно и дёшево для малонагруженного простого проекта и очень-очень недёшево для большой системы.
ekhaskel
15.12.2024 16:21Вы уж простите что прицепился, просто только что как раз сделали очередной платёж за облако и меня завёл ваш кликбейтный заголовок. 8-)
Наверное зря. 8-))
raznoe
15.12.2024 16:21Если вам надо возить одного человека раз в день нерегулярно - то такси самое то.
Если вам надо возить 100 человек каждый день по определенным маршрутам каждый день - то такси будет не самое то ( и в управляемости, и в деньгах)
Ну и еще куча разных промежуточных вариантов.
inkvizitor68sl
15.12.2024 16:21
Что-то вы странное насчитали, вряд ли Селектел себе в убыток на 30 тысяч работает с хоста -)
kirillkosolapov Автор
15.12.2024 16:21Почему? В статье у меня очень приблизительный расчет, и получалось, что стоимость владения таким сервером, плюс стоимость колокейшн около 35 т.р. если самим покупать. На скрине аренда - 90 т.р. Как видно провайдер точно в минус не работает) Это "почти" сравнимо со стоимостью облака если учесть что диски нужно сетевые делать и т.д.
heejew
15.12.2024 16:21Ловкая манипуляция, однако. ;)
И инженеры нам в облаке не нужны, и сравниваем мы виртуализацию в облаке с железом, лишь невзначай упоминая, что можно виртуалки, и сервера мы то и дело списываем и только новые покупаем, и да, именно покупаем сами и ставим в колокейшн.
Хорошо, мы в onpremise для отказоустойчивости ресурсы посчитали, умножили количество железа, а для облака ну как-то так и забылось, или куда эти расчеты делись? Не, понятно, что часть требований по ресурсам срезаются за счет managed сервисов, но не совсем же в ноль ведь.
В остальном тут и без меня подметили "небольшие несоответствия"
Alex-Freeman
Во первых "Если вам нужен новый (а смысл брать старый нет)", а зачем)? Если я поднимаю HA/FT то в принципе подойдет любое железо которое пройдет по совместимости. Никто не мешает поднять все что вы перечислили на 5 HP360G8 которые можно взять за шапку сухарей. По поводу надежности у меня уже лет 10 -15 работает стойка подобных, за это время никто не сдох.
И кстати совсем не факт, что в облаке я не возьму нечто подобное, но дороже)
kirillkosolapov Автор
Для некоторых кейсов так и есть