От железа к облаку и обратно - кейсы миграции

Автор: Иван Богданов, Технический писатель / Technical Writer компании HOSTKEY

Мы прошли путь от облачных VPS за тысячу рублей до выделенного сервера за 4500₽, разобрали гибридную архитектуру с автоскейлингом, и теперь теория понятна, конфигурации настроены, тесты показывают хорошие результаты. Остается вопрос: а что на практике делают компании, которые уже прошли этот путь? Мигрируют ли они из облака или, наоборот, в облако, или же используют сочетание технологий? И самое главное — сколько это стоит в реальных деньгах?

Миграции происходят в обе стороны, причем массово. Dropbox вывел петабайты данных из AWS на собственное железо и сэкономил $74,6 миллиона, Stack Overflow в том же 2025 году переезжает из собственного дата-центра в облако (продолжение здесь). 37signals громко объявил: «Мы покинули облако», а российские компании активно мигрируют в Yandex.Cloud и VK Cloud. Кто прав? Все правы — для своих задач и обстоятельств, в которых эти задачи достигаются.

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

Куда движется индустрия

Прежде чем погружаться в конкретные кейсы, посмотрим на общую картину. Согласно прогнозу Gartner от ноября 2024 года, мировые расходы на публичное облако в 2025 году достигнут 723.4 миллиарда долларов. Это огромные деньги, и затраты продолжают расти год к году. IDC в своих прогнозах указывает на рост расходов на облачную инфраструктуру на 33.3% в 2025 году по сравнению с 2024.

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

Почему компании мигрируют? Причин очень много, выберем несколько:

• Экономика — при стабильных предсказуемых нагрузках выделенный сервер часто дешевле;
• Производительность — выделенное железо дает предсказуемую задержку ответа;
• Регуляторные требования — нужно соответствовать 152-ФЗ в России, GDPR в Европе;
• Контроль — полный доступ к железу.

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

Из облака на собственное железо

Пожалуй, самый известный кейс возврата из облака — Dropbox. В своем проспекте S-1 при выходе на IPO Dropbox публично заявил: компания сократила операционные расходы на $74,6 миллиона за два года после решения о переходе с AWS на собственную инфраструктуру.

Что произошло? В 2015 году Dropbox начал выводить петабайты пользовательских данных из AWS S3 на собственную инфраструктуру. Проект завершился в четвертом квартале 2016 года — на это ушло около двух лет. За 2016 год расходы на AWS снизились на $92,5 миллиона, но инвестиции в собственные дата-центры составили $53 миллиона. Чистая экономия в 2016 составила $39,5 миллиона, в 2017 — еще $35,1 миллиона. При этом Dropbox оставил около 10% данных в AWS — в основном для обслуживания пользователей в Европе и регионах, где у компании нет собственных дата-центров. Это классический пример гибридного подхода, а не полного ухода из облака.

В 2023 году 37signals (Basecamp / HEY) опубликовали громкий пост и подкаст с заголовком «We have left the cloud» («Мы покинули облако»). Компания вывела Basecamp, почтовый сервис HEY и еще пять приложений из AWS на собственное железо. В официальном заявлении говорится: «без найма дополнительных сотрудников».

Миграция не потребовала расширения команды, потому что компетенции по управлению инфраструктурой уже были. Основатель компании Дэвид Хайнемайер Ханссон привел конкретный пример: только на базы данных (RDS) и поиск (Elasticsearch) для HEY уходило больше 500 тысяч долларов в год. При этом нагрузка у 37signals стабильная и предсказуемая — они не гонятся за взрывным ростом, трафик не скачет по многу раз за день.

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

Ahrefs — это немного другой кейс. Они не мигрировали из облака, они просто никогда туда не заходили. В техническом блоге компания опубликовала расчеты. За шесть лет Ahrefs инвестировал $122 миллиона в собственную инфраструктуру. Для сравнения — только в Сингапуре компания развернула 850 серверов, которые в AWS эквиваленте стоили бы около 448 миллионов долларов за 2,5 года работы. Всей инфраструктурой из 3300 серверов управляет команда из 11 человек. В июне 2023 года эта команда обработала 94 аппаратных инцидента — в среднем чуть больше четырех в день.

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

Примеры миграции от собственного железа в облако

Интересный пример обратного направления. В 2025 году Stack Overflow публикует серию постов «Переезд публичных сайтов Stack Overflow в облако» (часть 1, часть 2) о переводе публичных сайтов в облако и выводе техники из физического дата-центра.

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

До этого Stack Overflow уже мигрировал свой продукт Teams в Azure между 2021 и 2023 годами. Эта миграция заняла три попытки за три года и столкнулась с множеством ложных стартов. Команде пришлось распутывать код Teams от остальной кодовой базы, контейнеризировать приложения и переходить с виртуальных машин на Kubernetes. Этот опыт помог при планировании миграции публичной платформы — компания сразу выделила отдельную команду, работающую только на этом проекте, установила четкий дедлайн и запланировала поэтапный подход вместо миграции «большим взрывом».

Другой пример — Baselime — это кейс оптимизации внутри облачной экосистемы, но показательный. Компания мигрировала точки приема данных с AWS Lambda и Kinesis на платформу Cloudflare (Workers и Durable Objects). В результате расходы на AWS Lambda сократились более чем на 85%.

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

Примеры гибридных и специфичных кейсов

Discord — пример компании, которая росла вместе со своей инфраструктурой и принимала решения о приемлемой модели размещения по мере необходимости. В официальном блоге Discord был опубликован пост “How Discord Stores Trillions of Messages” («Как Discord хранит триллионы сообщений») с детальным описанием эволюции системы хранения. В 2017 году система работала на 12 узлах Cassandra. К началу 2022 года выросла до 177 узлов и хранила триллионы сообщений. Это не миграция в классическом смысле, а постепенная эволюция под растущую нагрузку.

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

В технических блогах, обсуждениях на Hacker News и DevOps-сообществах европейские стартапы и представители малого/среднего бизнеса регулярно делятся опытом перехода с AWS на европейских провайдеров вроде Hetzner или OVH, особенно для стабильных предсказуемых нагрузок. Реальные цифры сильно зависят от профиля нагрузки и включают затраты на поддержку, но тренд очевиден: для определенных сценариев европейские провайдеры значительно дешевле AWS, Azure или GCP.

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

Отдельная тема — managed-решения облачных провайдеров. Они удобны, но имеют ограничения. Поддерживаются только последние 2–3 версии ПО, тюнинг системы ограничен настройками провайдера, низкоуровневые метрики могут быть недоступны. Если ваше приложение использует старые версии или требует специфичной настройки ядра, managed-решения могут не подойти. Этот нюанс выясняется на этапе переноса трафика, когда уже поздно что-то менять.

Российский рынок после 2022 года столкнулся с необходимостью массовой миграции по политическим причинам и требованиям 152-ФЗ. Компании переходили с западных облаков на локальных провайдеров — Yandex Cloud, VK Cloud, Selectel, MTS Cloud. Результаты показывают, что это не только про соответствие регуляторике — многие находят реальную экономию.

JivoSite при переносе российского контура из AWS снизил стоимость исходящего

трафика в 6 раз. AI-платформа SWiP сократила издержки на инфраструктуру на 30%

после перехода в Yandex.Cloud. Это уже не добровольная оптимизация, а вынужденная

необходимость, которая для многих обернулась улучшением экономики.

Когда миграция идет не по плану

Стоит также сказать, что и о провальных миграциях написано достаточно много: британский банк TSB потерял 300 миллионов фунтов из-за того, что команда не провела нормальное тестирование перед переключением, а Варшавский университет годами не мог эффективно использовать HPC-систему, загруженную лишь на 20%, и попытка исправить ситуацию через гибридное решение провалилась. Эти кейсы хорошо известны, но интересно посмотреть на другие примеры — они показывают, что проблемы случаются даже у тех, кто в итоге добился нужного результата.

Страховая компания GEICO из империи Уоррена Баффета (Berkshire Hathaway) — это третий по величине автостраховщик в США с выручкой $39,6 миллиарда и прибылью $3,6 миллиарда в 2023 году. В 2013 году компания начала миграцию 600+ приложений в облако. Спустя десять лет результат оказался противоположным ожидаемому. Счета за облако выросли в 2,5 раза, а надежность системы упала. Ребекка Уикли, вице-президент по инфраструктуре GEICO, в октябре 2024 года прямо заявила: «За десять лет пути в облако GEICO так и не перевела туда всё, счета выросли в 2,5 раза, а проблемы с надежностью сильно увеличились».

Что пошло не так? У GEICO огромные объемы данных — как у большинства страховщиков, которые занимаются предиктивной аналитикой рисков и обязаны хранить данные для регуляторов. Выяснилось, что хранение данных в облаке — одна из самых дорогих вещей. Плюс компания использовала подход lift-and-shift, просто перенося legacy-приложения в облако без рефакторинга. Уикли резюмировала: «Просто запускать legacy-приложения в облаке запретительно дорого. Наш кейс это отлично показывает».

Теперь GEICO возвращается обратно в on-premises с OpenStack, Kubernetes и собственной инфраструктурой. Руководство Berkshire Insurance в 2023 году публично признало: «Технологии GEICO требуют гораздо больше работы, чем мы думали. У компании более 600 legacy-систем, которые не взаимодействуют друг с другом». Цель — сократить их до 15–16 систем.

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

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

В 2019 году IHS Markit опубликовала исследование для Fortinet, которое показывает интересный феномен динамичного мульти-облака. 74% из 350 опрошенных предприятий переместили хотя бы одно приложение обратно из облака в собственную инфраструктуру. Причины типичные: проблемы с производительностью (52%), безопасностью (52%), запланированные временные развертывания (40%).

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

• Счета удваиваются. Старая инфраструктура продолжает работать и стоить денег, пока вы запускаете и настраиваете новую. В какой-то момент вы платите в два-три раза больше обычного.
• Нагрузка разваливает систему. Компания переезжала в облако. Функциональные тесты прошли нормально — всё работает. Нагрузочное тестирование решили пропустить. Когда подали реальный трафик, выяснилось, что в облаке есть сетевые задержки, о которых никто не думал. Микросервисы перестали успевать отвечать друг другу, начались таймауты, система посыпалась. Пришлось срочно переключаться обратно, вызывать разработчиков, переписывать логику взаимодействий. Запуск отложили на полгода.
• Команда не справляется. Если ваша команда уже загружена на 100% текущими проектами, миграция неизбежно вытянет людей из бизнес-задач. Time-to-Market замедляется, новые фичи откладываются, бэклог растет. Бизнес начинает давить: «Почему так медленно? Давайте быстрее!» Под давлением тимлид может начать пропускать этапы — «да ладно, тесты потом допишем, разберемся на месте». И в самый ответственный момент, когда уже нельзя отступать, вылезают критичные проблемы.
• Объем данных оказывается недооценен. Перенос 5 Гб незаметен, но когда речь о терабайтах или петабайтах, стоимость исходящего трафика стремительно возрастает. Плюс придется гонять данные несколько раз — кто-то обязательно ошибется при первой попытке. Сложные СУБД с тысячами таблиц и миллиардами строк создают проблемы, которые не решаются простым копированием.

Во всех этих случаях сложность миграции была недооценена. GEICO потратил десять лет и увеличил расходы в 2,5 раза. Многие предприятия возвращали часть инфраструктуры обратно. Миграция требует планирования, тестирования и реалистичных ожиданий. Иначе ожидаемая экономия легко превращается в убытки.

Выводы

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

Что мы узнали из реальных миграций:

• Полная стоимость владения определяет выбор, а не цена сервера. Прямые затраты на инфраструктуру — это только часть картины. Нужно учитывать расходы на команду, скрытые издержки на обучение и миграцию, упущенную выгоду от того, что команда занята инфраструктурой вместо продукта. Компании, которые считают только стоимость виртуальных машин, принимают неверные решения.
• Компетенции команды критичнее размера бюджета. Дешевое железо без специалистов обходится дороже облака. Если у вас нет команды для поддержки собственной инфраструктуры — облако остается разумным выбором, даже если по цифрам выглядит дороже.
• Гибридная архитектура побеждает чистые решения. Индустрия движется к комбинированию технологий, а не к выбору между облаком и железом. Разные типы нагрузок требуют разных подходов — хранение на одной платформе, вычисления на другой, пиковые нагрузки на третьей.
• Контекст и специфика задач важнее трендов. То, что сработало для одной компании, может провалиться для другой. Миграция должна решать конкретную бизнес-задачу с измеримым результатом, а не следовать хайпу или чужим кейсам.
• Миграция — полноценный проект, а не простая техническая операция. Месяцы планирования, выделенная команда, десятки этапов, нагрузочное тестирование. Компании, которые относятся к миграции как к «быстрому переезду», сталкиваются с проблемами производительности, ростом затрат и необходимостью отката.
• Провалы случаются даже при больших бюджетах. Недооценка сложности, пропуск этапов тестирования, lift-and-shift без рефакторинга приводят к росту затрат вместо экономии. 74% компаний возвращали хотя бы одно приложение обратно после миграции.

Главный вывод из всех описанных выше кейсов — не существует правильной инфраструктуры, есть только решения, подходящие для ваших задач прямо сейчас.