Самостоятельный хостинг vs подписка у вендора: когда это окупается

Какую проблему вы на самом деле решаете

Начните с конкретной вещи, которую хотите запустить. "Нам нужно всё хостить у себя" — слишком расплывчато, чтобы это оценить. База данных, GitLab, Sentry, чат, файловое хранилище и инструмент для биллинга создают совсем разный объем работы.

Начните с одной простой фразы: "Мы хотим запускать X у себя, потому что Y мешает сегодня." Если вы не можете закончить эту фразу ясно, вы еще не готовы к переходу.

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

Боль из-за цены звучит так: "Наш счет вырос с $800 до $2,400, а использование почти не изменилось." Боль из-за контроля звучит так: "Нам нужен более долгий срок хранения логов, свои правила доступа или настройка, которая соответствует нашему процессу." Запишите, что важнее всего. Если важны оба пункта, расставьте их по порядку.

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

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

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

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

Когда самостоятельный хостинг обычно выигрывает

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

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

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

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

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

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

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

Когда план у вендора безопаснее

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

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

Поддержка — еще одна причина остаться у вендора. Запуски продуктов, праздничные продажи и инциденты в выходные редко случаются в удобное время. Облачный тариф может дать вам реальный путь к поддержке, когда что-то ломается во время кампании.

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

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

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

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

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

Считайте полную стоимость, а не только счет

Цена на наклейке обычно обманывает. Сервер за $200 может превратиться в куда более высокую ежемесячную стоимость, если добавить рутинную работу, которая делает систему безопасной и удобной.

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

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

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

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

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

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

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

Используйте простой путь принятия решения

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

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

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

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

До начала работы назначьте дату отката. Поставьте дедлайн, определите, как выглядит провал, и решите, кто принимает решение вернуться назад.

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

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

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

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

Реалистичный пример маленькой команды

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

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

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

Их грубые цифры выглядят так:

• Подписка у вендора: $1,900 в месяц
• Небольшой облачный сервер, база данных и хранилище: около $260 в месяц
• Дополнительные резервные копии и мониторинг: около $70 в месяц
• Настройка и перенос: примерно 45 часов инженера на старте

Эта работа по настройке важна. Команда тратит неделю на перенос данных, проверку прав доступа и написание простой процедуры обновления. Первые пару месяцев самостоятельный хостинг обходится дороже, потому что время на миграцию — это реальная стоимость, даже если в счете ее не видно.

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

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

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

Ошибки, которые создают лишнюю боль

Большинство неверных решений начинается с полуправды: ежемесячный счет кажется слишком высоким, значит, запускать инструмент у себя обязательно дешевле. Но счет — только часть стоимости. Кому-то все равно нужно ставить обновления, проверять резервные копии, чинить странные сбои и отвечать на вопрос: "почему сегодня все медленно?"

Эта работа недолго остается маленькой. Инструмент, который экономит $400 в месяц, легко может съедать вдвое больше в рабочем времени, если команда тратит на обслуживание несколько лишних часов каждую неделю. Цена важна, но именно труд обычно решает, останется ли самостоятельный хостинг дешевым или тихо превратится в обузу.

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

Обновления тоже создают много лишней боли. Люди откладывают патчи, потому что все и так работает, а потом прыгают сразу через три-четыре версии и надеются на лучшее. Именно так небольшое обслуживание превращается в простой на выходные. Назначьте окно для патчей, сначала проверяйте обновления на копии и записывайте, кто после изменений проверяет логи, интеграции и резервные копии.

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

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

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

Быстрые проверки перед решением

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

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

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

Можете ли вы объяснить полную ежемесячную стоимость на одной странице? Включите хостинг, хранилище, мониторинг, платные дополнения и часы сотрудников. Если итог меняется по причинам, которые никто не может объяснить, система менее предсказуема, чем кажется.

Могут ли этим управлять два человека? Один эксперт — это не план. Отпуска, больничные и смена работы случаются.

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

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

Если хотя бы одна из этих проверок не проходит, сделайте паузу. Часто лучший вариант — тот, который остается спокойным, когда что-то ломается в случайный вторник.

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

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

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

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

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

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

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

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

Если картина все еще неоднозначна, возьмите второе мнение, прежде чем идти дальше. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями по вопросам инфраструктуры, архитектуры ПО и решений в формате Fractional CTO, так что внешняя оценка может показать, подходит ли самостоятельный хостинг вашей команде или просто добавит лишнюю рутину.

Если тест сработал, расширяйтесь постепенно. Если нет, откатывайтесь, сохраните выводы и двигайтесь дальше.