Bare metal против облака для стабильных нагрузок: что дешевле?

Почему этот выбор путает

Решение становится сложным, потому что одно и то же приложение может хорошо работать на двух очень разных вариантах и приводить к сильно отличающимся счетам.

Сначала облако часто кажется дешевле: вы арендуете небольшие части по мере необходимости. Выделенный сервер или купленное железо выглядят дороже в начале. Но если нагрузка остаётся стабильной месяцами, фиксированная стоимость может выйти ниже.

Форма трафика меняет всё. Если приложение получает резкие всплески при релизах, рекламных кампаниях или распродажах, облако проще оправдать: можно добавить ресурсы на короткое окно и потом свернуть. Если нагрузка почти не меняется из недели в неделю, вы можете платить облачную надбавку за гибкость, которой редко пользуетесь.

Стиль выставления счётов тоже скрывает реальное сравнение. Облачные счета обычно приходят в виде множества мелких строк: вычисления, хранилище, трафик, бэкапы, логи, базы данных и балансировщики. Каждая позиция сама по себе кажется невинной. Счёт за сервер часто выглядит как одно аккуратное число. Команды сравнивают простую строку с длинным счётом и пропускают, куда на самом деле уходит деньги.

Для стабильных нагрузок победитель чаще зависит не от технологии, а от того, насколько «скучен» у вас трафик на самом деле. Одна команда хочет мгновенного масштабирования, потому что рост непредсказуем. Другая уже знает, что трафик примерно одинаков каждый день, и заботится больше о плоском счёте.

Ежемесячная цена — только часть решения. Вы ещё выбираете, сколько работы возьмёт на себя команда, как быстро восстановиться после аппаратной проблемы и насколько вы комфортно относитесь к контрактам, усилиям по миграции и планированию ёмкости. Дешёвые серверы не будут дешёвыми, если никому не хочется их поддерживать. Удобство облака перестаёт казаться удобством, когда счёт растёт каждый квартал.

Чаще всего это решение про стоимость, усилия и риск. Названия брендов важны меньше, чем пропускная способность, рост хранилища, бэкапы и то, как часто вам действительно нужно менять ёмкость.

Как выглядят стабильные нагрузки

Стабильная нагрузка выполняет примерно одинаковое количество работы почти каждый день. Трафик немного колеблется, но паттерн легко предсказать. Утро понедельника может быть загруженнее, чем ночь воскресенья, но ничего не прыгает в 10 раз без предупреждения.

Множество бизнес‑приложений работают именно так. Внутренние инструменты, панели SaaS, используемые в рабочие часы, и системы, которые обрабатывают заказы или счета по фиксированному расписанию, обычно следуют рутине. Количество пользователей и их поведение остаются близки к привычным.

Представьте компанию с 120 сотрудниками. Большинство входит в систему с 8 до 10 утра, работает в приложении весь день, а активность падает после 18:00. Это всё ещё считается стабильным трафиком: есть дневные пики, но они повторяются достаточно регулярно, чтобы их можно было планировать.

Это сильно отличается от событийного трафика. Распродажа, запуск продукта, упоминание в СМИ или платная кампания могут поднять спрос далеко выше обычного. Даже если система большую часть месяца тихая, такие всплески меняют решение по хостингу, потому что заставляют держать резерв.

Сезонные бизнесы занимают среднюю позицию. Налоговый сервис может быть спокойным месяцами, а затем заполняться перед дедлайнами. Платформа школы может простаивать летом и наполняться в начале семестра. Это не то же самое, что нагрузка, почти идентичная каждую неделю.

Стабильное использование упрощает планирование: вы можете с меньшей погрешностью оценить CPU, память, хранилище и потребности в поддержке. Поэтому хостинг с предсказуемым трафиком легче оценивать по цене, чем системы с постоянными сюрпризами.

Тем не менее стабильный трафик не снимает риск отказов. Серверы умирают. Диски ломаются. Базы замедляются. Плохой релиз может сломать спокойную систему так же быстро, как и загруженную. Стабильная нагрузка проще подбирается по размеру, но не значит, что ею можно пренебрегать.

Где растут облачные счета

Облачное ценообразование поначалу кажется простым. Вы запускаете сервер, выбираете базу данных и идёте дальше. Сюрприз приходит через месяц, когда счёт включает гораздо больше, чем главный сервер.

Типичный счёт растёт слоями. Сначала платите за серверы приложения и фоновые задачи, затем за базу данных и её хранение, снимки, бэкапы, исходящий трафик, мониторинг, логи и несколько управляемых сервисов, которые казались незначительными при включении.

Каждая строка кажется разумной сама по себе. Управляемая база кажется нормальной. Так же и снимки, балансировщик и длинное хранение логов. Соберите всё вместе — и конфигурация, которая в первый день выглядела дешёвой, может стоить вдвое или втрое дороже, чем вы ожидали.

Это чаще всего происходит, когда использование остаётся высоким весь месяц. Если приложение работает занято без «тихих часов», вы платите за арендованную ёмкость каждый час, каждый день — независимо от того, шумный это день или нет.

Облако также упрощает добавление подстраховок. Команды выбирают более крупные инстансы, чем нужно, держат резервные машины работающими и оставляют тестовые окружения в сети, потому что выключать их — неудобно. По отдельности это не выглядит критично, но вместе быстро поднимает счёт.

Особого внимания заслуживают сетевые расходы. Продукты, которые отдают много файлов, API‑ответов или бэкапов, могут платить болезненно большую сумму просто за вывод данных из облака. Для стабильного трафика эта статья часто ускользает при первой оценке.

Это не значит, что облако — плохая сделка. Если команде нужен рабочий стек на этой неделе, ожидаются частые архитектурные изменения или проекты часто поднимают и сворачивают, облако может сэкономить реальное время. Вы платите больше за гибкость, но иногда скорость важнее экономии каждого доллара на инфраструктуре.

Когда имеет смысл bare metal

Bare metal начинает выглядеть привлекательно, когда нагрузка очень мало меняется изо дня в день. Если трафик едва колеблется, фиксированная месячная стоимость легче укладывается в бюджет, чем облачный счёт, который плавает в зависимости от вычислений, хранилища, трафика и дополнительных сервисов. Вы знаете, сколько стоит сервер, и это убирает много шума.

Это особенно заметно для систем, которые долгое время остаются загруженными. Портал клиентов с ровным ежедневным использованием, API с одинаковым объёмом запросов каждый час или внутренняя система, работающая круглосуточно, — всё это может соответствовать шаблону. Если вы арендуете одинаковую облачную ёмкость месяц за месяцем, аренда полного сервера часто становится проще и дешевле.

Во многих долгосрочных сценариях bare metal даёт больше CPU, RAM и дискового пространства за те же деньги. Облако получает премию, когда спрос резко растёт или падает. Если вы держите инстансы 24/7 при высокой загрузке, эта премия перестаёт приносить пользу. Вы платите лишнее за гибкость, которой редко пользуетесь.

Но есть существенный недостаток: команде придётся больше работать. На bare metal кто‑то должен заниматься настройкой, патчами, мониторингом, бэкапами, планами переключения и упражнениями по восстановлению. Облачные провайдеры тоже требуют управления, но они скрывают больше «трубы». На bare metal часть этих обязанностей возвращается к вам.

Поэтому важнее не только цена на табличке, но и степень загрузки. Bare metal имеет смысл, когда сервер загружен достаточно, чтобы низкая месячная цена окупила дополнительные операционные усилия.

Обычно это подходит, когда CPU и память активны большую часть дня, трафик меняется плавно, а не резкими рывками, рост хранилища прогнозируем и команда умеет управлять инфраструктурой без сильного стресса. Также это выгодно, когда риск простоя низок и его можно покрыть планом восстановления, а не дорогостоящим решением высокой доступности.

Вот в чём суть решения. Если спрос спокойный, постоянный и всегда включён, выделенные сервера могут быть более аккуратным вариантом. Если нагрузка постоянно наполовину простаивает или меняется каждую неделю, облако по‑прежнему оправдывает более высокую цену.

Как сравнивать варианты

Большинство плохих инфраструктурных решений начинаются с поверхностного сравнения. Кто‑то смотрит на месячную цену одной облачной инстанции и одного арендованного сервера и выбирает более дешёвую строку. При этом половина реальной стоимости остаётся за кадром.

Честное сравнение начинается с вашего использования на следующие 12 месяцев. Выпишите среднюю нагрузку, обычный пик и ожидаемый рост. Если трафик стабилен и приложение не прыгает сильно изо дня в день, фиксированная ёмкость часто выглядит лучше, чем на первый взгляд.

Используйте одну и ту же таблицу для обоих вариантов. Отслеживайте средний и пик CPU, RAM, хранилище и пропускную способность. Включите полные ежемесячные расходы, не только вычисления: бэкапы, мониторинг, дополнительные диски, сетевые сборы, резервная ёмкость и поддержка. Затем посчитайте время команды на настройку, патчи, обновления, бэкапы, мониторинг и реагирование на инциденты.

Эта строка с учётом времени людей важнее, чем многие основатели предполагают. Облачный счёт может выглядеть аккуратно на бумаге, но управляемые сервисы, снимки, сетевые сборы и покупки «из удобства» быстро накапливаются. Bare metal может выглядеть дешёвым, но превратиться в дорогое, если команда тратит слишком много часов на ручную работу.

Дайте число этим часам. Если инженер тратит шесть часов в месяц на патчи, проверки бэкапов и редкие проблемы, посчитайте это. Если облако сокращает эти часы до двух — это важно. Если хорошо спланированный выделенный стек экономит сотни долларов в месяц, это тоже важно.

Затем протестируйте один плохой месяц. Предположите, что сервер выходит из строя, диск заполняется или трафик скачет на 30 %. Сколько вы платите, как быстро восстанавливаетесь и кто просыпается в три ночи? Маленькие команды часто обнаруживают, что простая облачная конфигурация выигрывает здесь. Команды с стабильным трафиком и более сильными операционными практиками чаще выигрывают с bare metal.

Если после всего этого цифры остаются близки — выберите тот вариант, который команда сможет спокойно обслуживать в 2 a.m. Дешевая инфраструктура перестаёт быть дешёвой, когда любой инцидент превращается в паническую гонку.

Простой пример с предсказуемым трафиком

Представьте B2B SaaS‑приложение, которое используют офисные команды с 8:00 до 18:00 по будням. Трафик почти одинаков каждую неделю, а ночи и выходные тихие.

Такой паттерн меняет математику. Вы не платите часто за неожиданные пики, поэтому дополнительная гибкость облака большую часть времени простаивает.

В облаке команда держит три инстанса приложения, одну управляемую базу, балансировщик, блочное хранилище, ежедневные снимки, мониторинг, хранение логов и один резервный инстанс на случай отказа. За год сервера приложения и резервная ёмкость могут стоить около $17,000. Управляемая база и хранилище — ещё $13,000. Бэкапы, логи, мониторинг и передача данных — $8,000, а поддержка или внешняя помощь — $4,000. Итого около $42,000 в год.

Теперь поместите ту же нагрузку на арендованные выделенные сервера. Два выделенных сервера для приложения, один более мощный сервер для базы, хранилище для бэкапов, мониторинг и один небольшой резервный сервер могут покрыть её. Аренда серверов и резервов — примерно $24,000 в год. Бэкапы, мониторинг и удалённое хранение — ещё $3,500. Услуги «remote hands» и инструменты поддержки — $2,500, а внешняя помощь для патчей и проверок — $6,000. В сумме около $36,000 в год.

Если компания покупает сервера, а не арендует, средняя трёхлетняя стоимость может снизиться ещё больше, хотя в первый год удар по бюджету будет сильнее из‑за единовременной покупки железа.

Здесь выбор превращается в простую бюджетную задачу. Когда нагрузка предсказуема, платить облачные ставки за мгновенное масштабирование может казаться расточительным.

Тем не менее более дешёвый вариант может быстро проиграть, если команда не способна его безопасно поддерживать. Если некому делать обновления Linux, менять диски, тестировать восстановление и закрывать уязвимости, один серьёзный простой может съесть сэкономленные деньги. Четырёхчасовой простой во вторник днём может стоить больше, чем годовая разница.

Дешевая инфраструктура остаётся дешёвой, только если команда умеет её держать стабильной.

Ошибки, которые искажают решение

Многие команды начинают с месячной цены сервера и на этом останавливаются. Это самый быстрый способ ошибиться с математикой.

Арендованный сервер может выглядеть дешёвым, но кто‑то всё равно должен его патчить, смотреть, менять сломанные диски и реагировать, если в 2 a.m. сломается задача бэкапа. Облако скрывает часть этой работы в управляемых сервисах. Bare metal может выиграть по стоимости, но только если команда умеет его обслуживать так, чтобы мелкие проблемы не превращались в пожар.

Оценки облака часто ошибаются в противоположную сторону. Приложению нужно всего пару базовых частей, а счёт набирает дополнительные базы, премиум‑типы хранилища, лишние балансировщики, простые снимки и логи, которые никто не читает. Для стабильного трафика эти «допы» могут стоить дороже, чем сами вычисления.

Рост хранилища тоже вводит в заблуждение. Трафик кажется стабильным месяцы, а потом загрузки медиа удваиваются. Хранение бэкапов растёт с 7 дней до 90, затем до года, потому что никому не хочется ничего удалять. Реалистичное сравнение требует учёта роста с течением времени, а не только текущего месяца.

Покупка слишком большого количества железа — ещё одна частая ошибка. Нагрузка может казаться стабильной, потому что прошлый квартал был аномально сильным, или из‑за одного клиента. Если вы покупаете сервера под временный пик, вы замораживаете деньги в простаивающей ёмкости и зовёте это планированием.

Лучше разделять спрос на две корзины: базовый уровень, который вы видите чаще всего, и пики, которые можно объяснить. Если пики приходят от релиза, праздника или одной кампании продаж, не принимайте их за норму.

Работу по восстановлению тоже часто игнорируют, когда нагрузка спокойна. Команды пропускают тесты восстановления, потому что приложение долго не падало. Потом база портится или сервер умирает, и никто не знает, полные ли бэкапы и сколько займёт восстановление. Спокойная система может долго скрывать слабые практики восстановления.

Перед выбором выпишите полную стоимость простыми словами: время людей в месяц, рост трафика и хранилища, период хранения бэкапов, время восстановления, резервная ёмкость для отказов или обслуживания и любые облачные дополнения, без которых приложение может обойтись. Когда вы честно всё это посчитаете, ответ обычно станет яснее.

Вопросы, которые стоит задать перед решением

Плохое инфраструктурное решение часто начинается с плохой оценки. Команды догадываются о трафике, предполагают рост и цепляются за конфигурацию, которая выходит слишком дорогой или трудной в поддержке.

Пять вопросов снимают большую часть шума.

Во‑первых, знаете ли вы настоящий базовый уровень, а не усреднённое значение за месяц? Посмотрите на нормальный CPU, RAM, хранилище, трафик и истинные пики. Пик на 20 минут в день — совсем другое дело, чем давление, которое длится весь день.

Во‑вторых, справится ли ваша команда с обновлениями, мониторингом, бэкапами и восстановлением спокойно? Bare metal может стоить меньше, но только если кто‑то поддерживает его без превращения каждого обслуживания в ночную аварию.

В‑третьих, сколько вы реально будете экономить в месяц и достаточно ли этого, чтобы оправдать дополнительные усилия? Небольшая экономия быстро исчезает, когда учитываешь время на настройку, дежурства, резерв и миграцию.

В‑четвёртых, ожидаете ли вы резкого роста трафика или крупных продуктовых экспериментов в следующем году? Если вам нужно быстро масштабироваться, облако часто упрощает жизнь, даже если счёт выше.

В‑пятых, с каким видом «лок‑ина» вы готовы мириться? Облачный лок‑ин проявляется в управляемых сервисах и изменениях цен. Аппаратный лок‑ин проявляется, когда вы покупаете или арендуете сервера под текущую нагрузку и затем её перерастаете.

Честный ответ на один из этих вопросов может изменить всё решение. Если использование плоское, стек прост и команда уже умеет управлять серверами, bare metal часто выигрывает по стоимости. Если спрос колеблется, приложение меняется быстро или команда маленькая, платить за облачную гибкость может быть дешевле в сумме.

Если цифры близки — приостановитесь. Обычно это значит, что решение больше зависит от операционной части, чем от цен хостинга.

Что делать дальше

Принимайте решение на основе проверяемых цифр. Оценки по памяти обычно хуже, чем один‑два месяца реального трафика, CPU, RAM, хранилища и данных по сети.

Начните с вытягивания реального использования из логов, биллинга и мониторинга. Если трафик держится примерно на одном уровне каждый день, у вас уже есть нужный базовый уровень. Если он плавает — измерьте, как часто происходят всплески и как долго они длятся.

Держите план практичным. Соберите недавние данные и запишите нормальную нагрузку, пиковую, рост хранилища и сетевое использование. Выберите путь на ближайшие 12 месяцев, а не навсегда. Задайте чёткий триггер для смены: например, облачные расходы превысили предел или сервер близок к заполнению. Потом через несколько биллинговых циклов пересмотрите решение и проиграйте один инцидент — отказ железа или внезапный всплеск трафика.

Рамка в 12 месяцев помогает. Команды застревают, когда считают хостинг частью постоянной идентичности, а не практическим выбором. Можно арендовать сейчас и переехать позже. Можно купить сейчас выделенную ёмкость и позже вернуть часть стека в облако.

Перед тем как слишком уверенно решать, проведите один тест инцидента. Перезапустите сервис, смоделируйте отказ диска или проверьте, как быстро можно восстановиться из бэкапа. Конфигурация, которая выглядит дешёвой на бумаге, становится дорогой, если восстановление медленное и никто не знает, что делать.

Если цифры близки, второй взгляд эксперта помогает сэкономить время и деньги. Oleg Sotnikov на oleg.is консультирует стартапы и малый бизнес по инфраструктурным компромиссам, архитектуре продукта и операционным усилиям — как раз в тех областях, где это решение обычно оказывается сложнее, чем кажется. Такой обзор особенно полезен, когда трафик стабильный, окно планирования — около года, и нет места для ошибки.