Комментарии 26
А оно само не должно отскейлиться по появлению replicas=N деплоймента? Вроде же, все приличные хостеры куба уже давно автоскейл сделали. И даунскейл, для приличия же.
Модель не скелит кластер. Цель - найти минимальный по цене кластер в который влезет наша нагрузка, не создавая сам кластер :). При ее росте, физически кластер отскейлится конечно. Но в нашем случае мы ищем минимальный размер по минимальной цене, чтобы сказать заказчику что-то навроде: если вы хотите это сделать, минимальная цена вопроса будет в районе X. При скейле она будет только расти.
Некоторые заказчики в этот момент говорят, типа, что-то дорогой, этот ваш кубернетис. А еще его и поддерживать надо, так совсем ой.
Я понял, это для эстимейтов цены. Разумно, да.
(Хотя это не отменяет того, что куб на виртуалках кратно дороже эквивалентного baremetal).
У bare metal настолько много минусов, что при любой возможности его не использовать, не используйте.
И далеко не во всех случая совокупная стоимость владения bare metal ниже cloud и ни о каких "кратно дороже" и речи быть не может, просто вы не умеете в FinOps.
При использовании определенных техник возможно значительно(!) снизить расходы на облако: если подписываться брать у них машины в течении года/нескольких лет + spot instances + такие сервисы как https://spot.io/ + использование VPC endpoints + всякие https://www.infracost.io/ и ещё много что. Знаю многих, кто сходу тратил кучу денег в облаках не умея это правильно просчитать и не умея использовать правильные технологии.
А ещё, например, стартапный план Амазона (если у любого серьёзного облака) позволяет получить бюджет в 100 тысяч долларов, чего для начала хватит очень многим.
Смотрите - чем меньше контора, тем больше у неё пользы от облаков. Если у вас утилизация ресурсов плавает от 1 до 10% (с пиками до 30%) одного сервера - вы, очевидно, заплатив 300 баксов в месяц за all inclusive, экономите.
А вот если у вас baseline в несколько тысяч ядер, то как бы вы не крутили, есть "базовая цена сервера", "наценка за клауд" и всё. Чем меньше deployment events в единицу времени (месяц?), тем менее выгоден cloud, потому что нагрузка стационарна.
Если огромное количество кейсов, когда облака также более выгодны и для small и для medium и для large компаний. Взять и описать всё в двух предложениях, как пытаетесь вы, невозможно, каждый кейс индивидуален и переменных влияющих на итоговую цифру много (включая расходы на персонал)
Чаще всего компании, которые боятся облаков и говорят, что там дорого просто не умеют правильно проектировать и использовать то, что я перечислил в предыдущем сообщении.
Единственное что никак не побороть в AWS/GCP/Azure это цена трафика, что не для всех компаний критично. Для кого очень очень критично часть нагрузок таки держат в каком-нибудь DO.
Эм... Противопоставлять DO и AWS - это так себе затея. equinix vs aws - вот это уже больше похоже на сравнение.
"каком-нибудь DO" = хостинг вроде DO второго третьего и т.д. порядка не из первой тройки.
Я именно про это и говорил. DO = дисконтер. Есть серьёзные конторы (IBM'овский softlayer), которые дают очень хороший baremetal через API. И оно всё равно дешевле aws'а, хоть IBM никогда скромными запросами не отличалась.
Есть причины по которым AWS дороже.
IBM может быть сколько угодно серьезной компанией, но в этом бизнесе им до AWS как до луны, поэтому у IBM bare metal и дешевле AWS bare metal.
Некоторые из причин, почему AWS в чём-то дороже условного IBM/Oracle & etc:
прогнозируемая, испытанная, проверенная и проверяемая годами надёжность
богатая несравнимая ни с одной другой экосистема. У них есть managed практически что угодно и это позволяет не тратить разного рода ресурсы. Например вместо HA Patroni Postgres берёте RDS (которым тоже естественно нужно уметь правильно пользоваться)
наличие отличных top tier дц во многих зонах по миру. Не говорим про Россию т.к. с финансовой точки зрения этот рынок, к сожалению, не интересен
очень качественное api и наличие нескольких хорошо поддерживаемых инструментов для него
очень хорошая техническая поддержка
commit to upstream including Kubernetes, Elasticsearch/OpenSearch & etc
При всем вышеперечисленным настаиваю на том, что в большинстве случаев при правильном подходе к оптимизации и планированию расходов их можно держать на уровне если не ниже, то вполне сравнимом с другими провайдерами/хостингами.
В каком бизнесе ibm далеко? В клаудах? Посмотрите, у кого выручка от клаудов самая большая в мире.
IBM cloud безусловно далеко до AWS, хотя вы можете найти какие-то статьи, где IBM cloud где-то в чём-то впереди. Генеральным директором всего Amazon не зря стал бывший генеральный директор AWS.
Добавьте ко всему мной сказанному то, что для создания/поддержки инфраструктуры на AWS очень легко найти очень качественную команду инженеров с десятилетиями опыта, чего точно нельзя сказать про IBM cloud, а это расходы и расходы также не маленькие.
Последний квадрант Гартнера по публичным облакам утверждает, что IBM Cloud далеко позади AWS.
Вы видимо берёте и сравниваете "в лоб" некую базовую цену сервера, которая, например в AWS в случае использования трехгодичной подписки + spot instances + других техник совершенно не та, что on demand.
При чём тут вообще количество неких deployment events я не понял? Хоть каждую минуту деплойте и инфру и приложения, цена от этого не поменяется :)
нет, я не сравниваю "в лоб". Я видел достаточно деплойментов разного типа, чтобы говорить про это.
Насчёт deployment events. Смотрите, представьте себе cloud, в котором у каждого ресурса был один deployment event и с тех пор конфигурация не менялась годами. Что выгоднее - cloud или бареметал? Очевидно, бареметал. Потому что по raw performance эквивалент будет дешевле.
Теперь посмотрим на другой сценарий - инстансы/лямбды/whatever появляются и исчезают, под временный стенд для тестов, под внезапный 10х всплеск нагрузки, etc. В этой ситуации может оказаться, что клауд с baseline 1x и пиками 10x, плюс постоянной ротацией ephimerial фигни при тестах - кратно выгоднее, чем заказанные и простаивающие 10x ресурсы, плюс примерно столько же на стейджинги.
В чём между ними разница? В числе deployment events. Экономия от "клауда" происходит в тот момент, когда кто-то что-то не использует и за это либо не берут деньги (лямбда), либо удаляют (инстансы). Если deplyment (в оба направления - на создание и удаление) не происходит достаточно часто, то экономического смысла клауды не имеют.
(Это не отменяет де-факто аутсорс части обслуживания инфраструктуры, что совершенно отдельный вопрос).
Не знаю что вы видели, я работаю с большим количеством компаний разного размера и вижу это каждый день.
Очевидно я рассматриваю кейсы с каким-либо трафиком/с каким либо взаимодействием с пользователем, а не сферического коня в вакууме, которого не трогают годами. Там ещё тоже смотря как не трогают. Если вызывают изредка, то может и лямбдой и тп можно заменить :) Нагрузка же в случаях наличия пользовательского трафика априори не константа, а значит имеет смысл масштабировать инфраструктуру под нагрузку.
Вопрос аутсорса обслуживания части инфраструктуры в облаках это конечно вопрос о дельный, но его точно стоит учитывать и добавлять к общей стоимости на инфраструктуру и в этом облако сильно впереди bare metal. Есть топовые компании с достаточно большой инфраструктурой которую обслуживает очень мало людей.
В этом треде я сам для себя эту идею сформулировал - чем более динамичная среда, тем выше финансовая польза от облаков. Грубо говоря, если 90% константны, то оставшиеся 10% погоды не сделают. Если 90% динамические, то экономия на 90% ресурсов в моменты простоя кратно перевешивает финансовый оверхед.
Хотя, на самом деле, в разработке и прототипировании клаудный подход (возможность заказать ресурс asap, а не ждать месяц) - это бесценно. Но какой именно ресурс - это интерсный вопрос. Тот же scaleway и equinix выдают бареметал с почасовой оплатой за единицы минут, что мало отличается от времени запуска виртуалки в GCP, а производительность у условного Ryzen с nvme такая, что GCP'шный эквивалент будет стоить как оба крыла самолёта.
Вы пытаетесь переизобрести FinOps? Не нужно, он уже существует. Очень и очень много параметров влияют на итого. И это далеко не только константность/динамичность нагрузок на сервера. Не стоит недооценивать неумение неспециалиста в вопросе без специально заточенных под это инструментов и десятилетий опыта (а сейчас уже такое накопилось да) просчитать всю картину в целом. В серьезных компаниях для оценки таких миграций нанимаются специально обученные люди + косты режутся на регулярной основе, а не один раз.
Интересно было бы использовать инструмент из статьи для гораздо более сложных кейсов и добавить туда разные хостинги и т.д. посмотреть на вывод.
И далеко не во всех случая совокупная стоимость владения bare metal ниже cloud и ни о каких "кратно дороже" и речи быть не может, просто вы не умеете в FinOps.
Из практики:
Переехали в yandex cloud из hetzner. Теперь платим в 4 раза дороже (вместо 4K евро, платим 16-18K долларов)
Прерываемая виртуалка в яндекс облаке, стоит больше обычной вирталки в hetzner. Обычная виртуалка в яндекс облаке естественно еще дороже. С bare-metal даже сравнивать нет смысла.
Надежность никак не поменялась. Возможно даже в облаке сеть моргает чаще чем моргала в hetzner. Не говоря уже о других проблемах, недавно например лег DNS на ощутимое время.
Ценник в основном за инстансы с кластерами БД, managed БД стоят еще дороже, и не факт, что дадут какие-то плюшки, которые это окупят.
Как было два девопса на той же зарплате, так и осталось. Только теперь в облаке требуется тратить дополнительные ресурсы на оптимизацию затрат и экономию. И в виду сложности, для экономии в облаке нужно потратить больше ресурсов чем в hetzner.
Как научиться в FinOps чтобы платить меньше? Прерываемые/spot машины не станут чудесно дешевле, обычные инстансы тоже. На чем тогда экономить? На готовых сервисах? Ну у нас автоматизация для настройки пару типов кластеров бд и кластеров kubernetes не супер дорого вышла и вполне устраивает. Особенно учитывая, что один кластер managed БД по стоймости равен 50% зп одного девопса, а таких кластеров несколько. Да и managed решение далеко не идеальны, особенно по гибкости конфигурации. Например многие вещи в managed кубе яндекса, мы хотели бы сделать по другому (не использовать kube-proxy, вместо iptables для сервисов использовали бы ipvs, а в cilium хотели бы использовать native routing вместо тунелинга, хотели бы иметь возможность включить pod security policy и так далее и тому подобное). У меня если честно нет идей, но если вы что-то посоветуете, то я буду вам сильно благодарен. С облаками опыта имею не много.
P.S. Переезд был обусловлен 152-ФЗ
Не знаю про яндекс клауд, но хочу узнать. По опыту ажуры скажу что единственный способ делать дешевле это уплотнять, и использовать всякий серверлесс и манажед сервисы, не смотря на то что они не идеальны. Не надо выдумывать велосипед. Само по себе оно будет только расти в цене. Девелоперы будут создавать больше и больше ресурсов бесконтрольно. Скейлить их куда не надо и так далее.
Как бы цынично это не звучало, манажед сервисы уменьшают потребность в персонале. По сути вы перемещаете стоимость персонала в шареный сервис, частично. И "девопсы" становятся не нужны в таком количестве.
Как бы цынично это не звучало, манажед сервисы уменьшают потребность в персонале. По сути вы перемещаете стоимость персонала в шареный сервис, частично. И "девопсы" становятся не нужны в таком количестве.
Но в моем кейсе это ведь не так. managed решение покрывает всего 1% задач. Возьмем для примера тот же куб, managed решает проблему обслуживания control-plain и обновления, но это ведь мизерная часть того, что обычно надо делать. Есть еще уйма задач связанных с кубом, которые вообще никак managed решением не покрывается. И как же "девопсы" будут не нужны, а кто node-local-dns развернет? Кто напишет gatekeeper политики на rego? Логирование, мониторинг, ingress-controller, istio, cert-manager, т.д. Кто будет это обслуживать, исправлять проблемы, дорабатывать?
P.S. На самом деле мы используем managed куб, поскольку он считай бесплатный. Но это никак не избавляет от того, что нужны компетентные люди, которые будут обслуживать его.
С managed mysql мы покрываем задачи настройки отказоустойчивого кластера и бэкапов. Но на обслуживание этого, сейчас у нас уходит максимум 8 часов в месяц. Каждый managed mysql сейчас нам обойдется в лучшем случае на 1170$ дороже, таких кластеров у нас 6 (6*1170 = 7020). 7K$ чтобы покрыть 8 часов работы в месяц.
Ну то есть окей мы возьмем managed решение, и закроем какой-то мелкий пласт задач по обслуживанию, но есть же большое количество задач для "девопсов", банально даже поддерживать terreaform код для развертки всего этого в облаке. Не совсем понятно, как это избавит от надобности в у словных "девопсах" и сократит персонал. В нашем кейсе работы например меньше не стало, местами стало даже больше. Как было два девопса так и осталось.
Про серверлесс тоже непонятно, ну вот у нас есть 20-30 приложений, от 100 до 10000 rps, обычные бэкендики, что-то пишут в базу. Как серверлесс поможет сэкономить?
Про Яндекс cloud ничего не знаю от слова совсем.
Если будет возможность/желание рассмотреть топ 3 облаков, то обращайтесь, а так даже и прокомментировать не особо могу.
Я могу только одно тут сказать. Облако, оно точно не дешевле bare metal. На счет дороже или нет утверждать не буду. Его плюс - гибкость и уровень вхождения. Для построения более-менее нормальной HA инфрструктуры вам не нужны спецы по железу или какие-то хитрые варианты построенные на железе. Все накликивается в портале по инструкциям. Но стоит все это врядли меньше.
Я ещё раз повторюсь: всё очень сильно зависит от кейса. Не утверждаю, что в 100% случаев облака дешевле даже при FinOps подходе, но он сильно меняет картину.
Серьёзную инфраструктуру в облаках никто не "накликивает" , (хотя конечно в отдельных случаях бывает и с таким боремся. Называем это ClickOps :) , а раскатывают Terraform'ом и это достаточно серьезный отдельный инструмент, которым нужно владеть. Вокруг него есть целая экосистема разных прибамбасов вроде Infracost, driftctl, terraformer, кучи community модулей, terragrunt и т.д. и т п.
Ну вот банальный кейс который я приводил выше.
Вот сейчас я смотрю на детализацию и вижу что у меня только за трафик выходит 4000$. У меня на bare-metal вся инфра стоила столько =).
А это не статика, а именно бэкенд трафик. Статику у нас CDN отдельно раздает. Отдельно за это платим.
@eosfor
манажед сервисы уменьшают потребность в персонале
Кого нам уволить, чтобы окупить цену за трафик? На bare-metal нам этот трафик бесплатно обходился и никакие люди его отдельно не обслуживали. А цена только за этот трафик равна цене всей нашей инфраструктуре которая была на bare-metal.
Спасибо за статью.
Интересный инструмент!
Kubernetes и моделирование на minizinc