Комментарии 48
Во первых "Если вам нужен новый (а смысл брать старый нет)", а зачем)? Если я поднимаю HA/FT то в принципе подойдет любое железо которое пройдет по совместимости. Никто не мешает поднять все что вы перечислили на 5 HP360G8 которые можно взять за шапку сухарей. По поводу надежности у меня уже лет 10 -15 работает стойка подобных, за это время никто не сдох.
И кстати совсем не факт, что в облаке я не возьму нечто подобное, но дороже)
Не вижу в расчёте графу: заплатить за трафф между двумя сущностями в облаке...
Обычно трафик внутри одной зоны доступности бесплатный. Веселье начинается, если вам надо гонять трафик вовне...
Но у разных провайдеров по разному бывает
Только тут не понял за что минусы?)
Видимо, потому что люди не согласны с вами. Трафик в облаках платный, иногда "неожиданно платный".
Неадекватная стоимость исходящего трафика у некоторых облачных провайдеров. https://habr.com/ru/companies/ruvds/articles/806689
В облаках платное всё: трафик, балансировка нагрузки, бэкапы, мониторинг, защита от DDOS и прочее.
Насколько мне известно, информация по ссылке немного устарела. 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 как пример) и почти все платно
Была история, в 2018м году собрал супермикру с двумя дисками по 8ТБ и она на домашнем интернете делала 20ТБ исходящего трафика в месяц.
Работал в AWS и коллега в шутку сказал: а почему не купишь инстанс?
Посчитал EBS тогда на 16ТБ +инстанс и исходящий трафф, и это дело мне обошлось бы в месяц в эквивалентную сумму стоимости супермикры.
Вы свое время и знания по поддержке железа и поддержке доступности сети, питания и пр. оцениваете в ноль?
Пример, может быть, не очень очевидный. А если ваш бизнас пойдет хорошо и вам потребуется 100 инстансов? А как собирать будете, где бежать будет pipeline, как проверять коснситетность, систему мониторинга делать? Облака экономят ваши деньги на том, что там загрузка инженеров равномерна - клиентов много. А вы наймете 10 инженеров, которые сегодня трудятся над релизом, а завтра их занять нечем, потом снова нагрука 120% - получится неравномерно. Инженеры - дорогой товар, особенно качественные иженеры.
Да, я просто показал простой edge-case, где месячная стоимость облака равнялась стоимости своей инфраструктуры. При этом я даже не брал во внимание стоимость инженеров ни в первой ни во втором случае.
Забавно и другое, я не считал стоимость трафика "для въезда в облако" и для последующего "выезда" из облака. А он был бы с х2, так как тогда AWS тарифицировала трафик от инстанса до EBS практически по той же цене, что и Интернет.
В 2016м мне пришлось работать в месте, где хостил свои личные сервера Shazam, кстати. Теперь уже не уверен, где они? Всё ещё на своих или пошли в облака.
нет, плата за egress осталась - отменили одноразовую плату за траффик когда уходишь из облака
Рассуждения, основанные на кейсе "у нас из ниоткуда взялся сложный высоконагруженный проект" - это такое.
Облака хороши в случаях, когда:
Вам надо очень быстро (и ненадолго) развернуть сервисы с приемлемой производительностью.
У вас паттерн нагрузки изменяется в очень широких пределах и пики занимают относительно небольшую часть времени - так, что в "среднем" положении инстансы жрут не очень много денег, а иногда их можно скукожить вообще почти до нуля.
Вы ведёте бизнес в стране, где не очень хорошо с поставками серверного и сетевого оборудования (и особенно с поддержкой оного), а большая часть квалифицированного персонала куда-то делась.
Во всех прочих случаях (особенно, когда нужна гибкость не в производительности, а в инфраструктуре) своё железо и свой отдел эксплуатации становится выгоднее на вполне приемлемых отрезках времени.
Ключевое слово - свой отдел эксплуатации. И свои DevOps. Если эти два отдела есть, жизнь становится проще. Но не многие могут себе позволить эти два отдела. Об этом и статья
Сейчас все крупные корпорации в США уже в облаках. Это факт.
Начать можно с одного отдела - эксплуатации. Потому что девопс-практики в значительной степени находятся внутри кружочка "Ops", и в особенности - на первых порах, пока основная цель, чтобы сервис просто надёжно работал. Обмазать остальным можно позже, если взлетит.
Полтора года работал с AWS. Отдел эксплуатации и отдел DevOps'ов никуда не делись. И даже DBA (хотя казалось бы...).
Но не многие могут себе позволить эти два отдела
Автор лукавит, облако само по себе их не заменит.
Мой вариант где облако выгоднее - интерактивное использование SaaS. Чем-то похоже на пункт 1. Аналитические интерактивные запросы можно исполнять на одной машине полчаса, или на тысяче пару секунд. В результате либо покупаешь тысячу машин, и они простаивают 99% времени, потеря денег. Либо аналитики ждут полчаса - и вы теряете ещё больше, потому что простаивают аналитики. Либо идете в облако, которое автоматически выделяет 1000 машин на пару секунд, платите копейки, и получаете отличную производительность.
Можно по-подробнее про выделение 1000 машин на пару секунд для аналитиков (мы ведь про Спарк, а не про лямбды, не так ли?). Причем желательно именно про пару секунд, а не про, скажем, минут 15 спаркового кластера в каком-нибудь датабриксе
Мой случай не про Спарк, а про Google BigQuery. Там выделяются слоты на уже бегущих процессах (у них multitenant, и не надо каждому давать новый процесс или хуже того VM). Поэтому могут выделять (кусочки) тысяч машин даже не на секунды, а на миллисекунды, эффективно распараллеливая даже очень короткие запросы. Для интерактивной аналитики - самое оно.
Во всех прочих случаях (особенно, когда нужна гибкость не в производительности, а в инфраструктуре) своё железо и свой отдел эксплуатации становится выгоднее на вполне приемлемых отрезках времени.
да вроде как наоборот, когда нужна гибкость - то облака более удобные. Ну например
Сейчас нам надо поднять 100 серверов на arm. На один час
Завтра нам надо 50 серверов в южной америке и 50 в австралии для тестов
После завтра нам нужно 30 серверов с gpu ускорителями поиграться с ML
А теперь мы хотим провести тест нашего ha кластера и нам надо собрать гео распределенный кластер со стораджем на пару петабайт
А теперь мы услышали про хайп AI и нам нужны сервера с ускорителями для АI, на пару недель для поиграться
А еще мы не хотим разбираться почему начала глючить прошивка рейд контроллера после обновления ядра и т.п. прелести из мира железа
И мы не хотим следить и обновлять весь хардварный софт
и так далее и тому подобное. Что то мне подсказывает, что ваш условный отдел эксплуатации не сможет вам это дать, ну либо сроки и стоимость будут неадекватными
Посмотрел тарифы на сайте и не понял два момента по тарификации:
1) Если контейнер создан, но в данный момент не запущен - тарификация вообще не идет? Есть ли какая-то минимальная в месяц в таком случае? Например бывают тестовые проекты которые нужно изредка на пару часов запускать для работы.
2) Тариф считается на каждый контейнер отдельно или в рамках одного можно несколько не требовательных к ресурсам запускать?
Если учесть, что года через 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 …
Нет, просто докупаем у хостера немного мощностей в другом датацентре, чтобы была гео распределённость.
Даже если взять ваши цифры, основная стоимость упирается не в железо, а в DevOps. Т.е. результат расчета принципиально не изменится. Облака вас избавляют от необходимости самостоятельного развертывания Kubernetes, настройки бэкапов (и так, чтобы он был рабочий) и т.д. Плюс, многие вещи (условная распределенная СУБД с синхронизацией по атомным часам у AWS) вы самостоятельно просто не сможете сделать
Серьёзному проекту в облаках всё равно потребуется специалист для настройки и конфигурирования всех сервисов, а также для настроки инфраструктуры devops.
Плюс, многие вещи (условная распределенная СУБД с синхронизацией по атомным часам у AWS) вы самостоятельно просто не сможете сделать
А оно надо? Большинству проектов достаточно обычного мастера + реплики.
Вообще есть тема у оксген с стойкой в твоём помещение «edge cloud»
Все как обычно зависит от задач
Принципиальная ошибка автора заключается в том, что он исходит из предположения что системы в облаках работают сами, без собственных девопс инженеров и других специалистов по инфраструктуре у пользователя. Я бы даже сказал классическая ошибка. В небольших проектах возможно так и есть. И полтора программиста, которые пишут код в таких проектах, заодно в оставшееся время могут и поднимать контейнеры и рулить базами данных/кубернетесом/кафкой. Но в реальных больших системах собственные сисадмины/девопс инженеры всё равно нужны. Сотрудники облачного провайдера отвечают только за общую инфраструктуру облака. И никак не отвечают и не могут отвечать за ваш проект. И поэтому вся арифметика меняется. На входе действительно проще, быстрей и дешевле поднять систему в облаке. Особенно если система не должна работать 24/7 и ВМ/контейнеры можно поднимать для тестов и отладки на пару часов в день. Но при реальной эксплуатации надо хорошо считать. То что дешевле и проще в первый месяц, далеко не всегда дешевле и проще в перспективе 5-и лет. И в этом я полностью согласен с @ky0 выше.
Плюс отсутствие доступа к инфраструктуре может сыграть и очень плохую шутку при неудачном стечении обстоятельств. Реальный пример случился с нами буквально на днях, когда рухнула часть облачной инфраструктуры Яндекса. И это по закону подлости был как раз день, когда мы показывали проект большому госзаказчику. Если бы это были наши собственные сервера, мы бы уже метнулись кабанчиком в ЦОД/серверную и подняли дополнительный сервер с копией системы. А так ждали у моря погоду, что-то придумывали/изобретали и пытались сделать хорошую мину при плохой игре...
Уже написал свой пост, а потом обратил внимание что это рекламная статья товарища из компании, которая предлагает облачные услуги. Не знаю, может у них хорошее облако, не проверял. Но не верю в сказки что большие сложные проекты будут хорошо работать сами по себе, без специалистов по инфраструктуре, которые ими непосредственно занимаются.
И, кстати @kirillkosolapov - а как у вас в облаке с 152-ФЗ?
Попробую ответить на ваши вопросы. Да, вы правы, в крупных проектах есть свои DevOps, даже в облаках, но в облаках на них меньше нагрузка как правило (все конечно индивидуально). 2. Инцидент в Яндексе про который вы пишете описан вот в этом отчете - https://status.yandex.cloud/ru/incidents/1009?retpath=%2Fru%2Freports#report Он нас тоже затронул. Если кратко, у коллег упала сеть. Не на одном сервере, а глобально. Если бы в вашем ЦОДе условный "экскаватор судьбы" перекопал сразу все кабели, поднятие дополнительного сервака бы не помогло. Это я к тому, что инциденты разные бывают. Плюс, что вам мешало поднять копию системы в другом месте? На том же вашем сервере или в другом облаке. Кажется, это не сложнее чем установить дополнительный физический сервер и поднять с нуля на нем. А если глобально - у вас либо отказоустойчивое решение, когда вы выдерживаете падение сервера или целого ЦОДа, либо нет. А облако это или выделенные сервера дело второе. 3. К вопросу о рекламности. Я конечно не упускаю возможность упомянуть наш сервис, но статья к нему вообще не относится. У нас не классическое облако проект как в примере в статье у нас проблематично развернуть. Мы на другой сегмент работаем. Наши клиенты это индивидуальные разработчики, а не клиенты условного AWS. Т.е. наш основной конкурент это Heroku, а это совсем другая история не относящаяся к проблематике сложных проектов с DevOps. Я писал эту статью как раз как потребитель публичных облаков и железных серверов, а не как их продавец 4. Про 152 вопрос требует уточнения. У нас вся инфраструктура в РФ, перс данные для регистрации не нужны и т.д.
Резюмируя - вы отчасти правы, но если бы публичные облака были так "невыгодны", не пользовалось бы ими подавляющее большинство компаний из целевых сегментов
Спасибо за столь подробный ответ.
По поводу инцидента в Яндекс - к сожалению, я очень хорошо знаю что там произошло. Проблема там была не физическая а логическая. И кстати, сбой в был внутри зоны, в связности именно между компонентами, снаружи всё (то что было живо 8-) отзывалось без проблем. И именно в такой ситуации можно было всё быстро поднять на другом физическом сервере/ах в том же ЦОД. Ну да это не принципиально. Отвечая на ваш вопрос - помешало поднять в другом месте то, что по ряду причин всё заточено именно под яндекс и именно под эту упавшую зону. А решение наше пока еще не географически распределённое потому, что облака это дорого, чертовски дорого...
Мы хорошо это знаем, каждый месяц переводя в Яндекс шестизначную сумму, уже очень близко приблизившуюся к семизначной, и пока не можем позволить себе её увеличить.
Выгодность/невыгодность надо хорошо считать. Я знаю компании, которые ушли в облака потому что это модно. Знаю те, которым неважно сколько это стоит, а важно что бы было кого засудить за сбой системы. Но знаю и тех, кто считал арифметику. Мы вот думали что всё посчитали и пошли как раз в облако. Но сейчас понимаем, что арендовав четыре года назад два шкафа в двух ЦОД сейчас были бы в плюсе..
Для индивидуального разработчика, который хочет поднять условный пет проект, не очень задумываясь что такое сегментация системы, разграничение доступа к данным, требования регулятора, которому нужно пару-тройку ядер, и который не знает и не хочет знать, что такое RDMA, маска подсети и Layer 7, но умеет писать yaml файлы - ваше решение однозначно может оказаться удобным и выгодным. Ни в коем случае не хочу никого задеть или обидеть, прошу не понять меня неправильно. Но для каждой конкретной задачи скорей всего понадобится свой определённый инструмент.
И, повторюсь, облака это удобно и дёшево для малонагруженного простого проекта и очень-очень недёшево для большой системы.
Плюс отсутствие доступа к инфраструктуре может сыграть и очень плохую шутку при неудачном стечении обстоятельств. Реальный пример случился с нами буквально на днях, когда рухнула часть облачной инфраструктуры Яндекса. И это по закону подлости был как раз день, когда мы показывали проект большому госзаказчику. Если бы это были наши собственные сервера, мы бы уже метнулись кабанчиком в ЦОД/серверную и подняли дополнительный сервер с копией системы. А так ждали у моря погоду, что-то придумывали/изобретали и пытались сделать хорошую мину при плохой игре...
если при этом не работают апстрим провайдеры у ЦОД, то толку от вашего метания кабанчиком чуть больше, чем никакого
Вы уж простите что прицепился, просто только что как раз сделали очередной платёж за облако и меня завёл ваш кликбейтный заголовок. 8-)
Наверное зря. 8-))
Если вам надо возить одного человека раз в день нерегулярно - то такси самое то.
Если вам надо возить 100 человек каждый день по определенным маршрутам каждый день - то такси будет не самое то ( и в управляемости, и в деньгах)
Ну и еще куча разных промежуточных вариантов.
Что-то вы странное насчитали, вряд ли Селектел себе в убыток на 30 тысяч работает с хоста -)
Почему? В статье у меня очень приблизительный расчет, и получалось, что стоимость владения таким сервером, плюс стоимость колокейшн около 35 т.р. если самим покупать. На скрине аренда - 90 т.р. Как видно провайдер точно в минус не работает) Это "почти" сравнимо со стоимостью облака если учесть что диски нужно сетевые делать и т.д.
Ловкая манипуляция, однако. ;)
И инженеры нам в облаке не нужны, и сравниваем мы виртуализацию в облаке с железом, лишь невзначай упоминая, что можно виртуалки, и сервера мы то и дело списываем и только новые покупаем, и да, именно покупаем сами и ставим в колокейшн.
Хорошо, мы в onpremise для отказоустойчивости ресурсы посчитали, умножили количество железа, а для облака ну как-то так и забылось, или куда эти расчеты делись? Не, понятно, что часть требований по ресурсам срезаются за счет managed сервисов, но не совсем же в ноль ведь.
В остальном тут и без меня подметили "небольшие несоответствия"
Почему облака — это дёшево, чертовски дешево