Скрытая стоимость миграции в облако: что упускают
Aidar O.8 мин чтения
В 2021 году Andreessen Horowitz подсчитали, что публичное облако обходится топ-50 софтверных компаний примерно в $100 млрд упущенной капитализации — цифра, которую они назвали «парадоксом на триллион долларов». Пять лет спустя парадокс расширился от гипермасштабных софтверных компаний до каждого предприятия, мигрировавшего в облако ради обещанной экономии. Презентации, обосновавшие эти миграции, стабильно упускали одни и те же пять статей расходов.
ROI-расчёты миграции в облако занижают реальную стоимость на 30–50 процентов, потому что моделируют инфраструктурные статьи, но упускают операционные, кадровые, архитектурные и комплаенс-долги, всплывающие через полтора года — и этот разрыв структурный, а не случайный.
Egress и налог на гравитацию данных
Первый сюрприз почти в каждом корпоративном облачном счёте — сетевые расходы. Ingress бесплатен. Egress — выгрузка данных из облака, между регионами или между сервисами разных провайдеров — нет. Терабайт из AWS S3 на on-premises стоит $80–90. Умножьте это на часовые аналитические выгрузки, еженедельные бэкапы, межрегиональную репликацию для disaster recovery и межсервисный трафик в микросервисной архитектуре — и месячная строка за сеть становится существенной долей счёта. Flexera в отчёте State of the Cloud 2024 показала, что расходы на передачу данных стали крупнейшим источником неожиданных перерасходов для 41 процента корпоративных респондентов. Исходная бизнес-модель почти никогда не включала egress в реалистичных объёмах. Более глубокая проблема стратегическая: как только объём данных превышает определённый порог, egress-стоимость ухода становится рвом, который провайдер может бесконечно монетизировать. Именно это a16z называли гравитацией данных — и она заложена в долгосрочную модель каждого облачного вендора.
Премия за кадры и разрыв в FinOps
Облачные инженеры стоят на 30–50 процентов дороже своих on-premises коллег на каждом региональном рынке, который мы отслеживаем, включая Казахстан. Бизнес-модель трактует это как разовую стоимость перехода — переобучить существующий штат, нанять нескольких специалистов, готово. На практике облачная инженерия — отдельная дисциплина, требующая непрерывного апскиллинга, потому что темп релизов провайдера обгоняет внутренние циклы обучения. Затем — разрыв в FinOps. FinOps как операционная модель, распределяющая облачные затраты по бизнес-юнитам, обеспечивающая дисциплину тегирования, rightsizing нагрузок и переговоры по commitments, в большинстве предприятий на старте миграции отсутствует. Он появляется через 18–24 месяца, после первого перерасхода бюджета, когда CFO требует ответственности. По отчёту FinOps Foundation State of FinOps 2024, 49 процентов организаций характеризуют свою FinOps-практику как «идущую», а не «бегущую». Без зрелой FinOps-функции облачные расходы растут быстрее нагрузки — потому что никто не владеет затратами.
Lift-and-shift не раскрывает того, что обещала презентация
Большинство корпоративных миграций — lift-and-shift по необходимости, а не по замыслу. Бизнес-модель предполагает перепроектированные, cloud-native нагрузки, автоматически масштабирующиеся, потребляющие compute только при необходимости и использующие managed-сервисы. Реальность — продиктованная сроками и рисками переписывания продакшн-систем — такова, что монолиты переезжают на облачные виртуальные машины с минимальными изменениями. Когда монолитное приложение работает на постоянном облачном инстансе, размеренном под пиковую нагрузку, предприятие платит розничную облачную цену за инфраструктуру, которую эффективнее разместило бы on-premises. Gartner отмечает, что 70–80 процентов корпоративных облачных миграций всё ещё стартуют как lift-and-shift, и что обещанная эластичность требует re-architecture работы, редко финансируемой как часть исходной миграции. ROI-презентация предполагала эластичное конечное состояние. Счёт отражает статичное промежуточное состояние — которое часто становится постоянным.
Reserved instances и лок-ин, которого должно было не быть
Ценовые скидки, делающие облако экономически конкурентным — reserved instances, savings plans, корпоративные программы скидок, committed-use контракты — все требуют многолетних обязательств перед конкретным провайдером, семейством инстансов, а иногда и регионом. Скидки реальны: 30–70 процентов от on-demand цены обычны. Но это обязательство воспроизводит ровно тот вендорский лок-ин, от которого облако должно было избавить. Хуже того, оно фиксирует предприятие в архитектурных решениях провайдера: если нагрузке нужно перейти на другой тип инстанса, в другой регион или к другому провайдеру, committed spend становится sunk cost, искажающим следующее решение. Бизнес-модель представляет эти скидки как экономию; она редко моделирует их как стратегический долг. Для предприятия, которому нужна архитектурная гибкость — а любому предприятию, работающему в десятилетнем горизонте, она нужна — структура committed spend становится тихим ограничением на каждое будущее решение.
Резидентность данных и архитектурный долг, бьющий по Казахстану сильнее всего
Закон Казахстана о персональных данных требует хранения и обработки определённых категорий персональных данных в пределах национальных границ. Внутри Казахстана нет регионов AWS, Azure или GCP. Практическое следствие: любое предприятие с регулируемыми данными — а это большинство предприятий — не может работать на чисто публично-облачной архитектуре. Решение всегда гибридное: регулируемые данные в локальных дата-центрах или комплаентных локальных облачных провайдерах, нерегулируемые нагрузки в международных облачных регионах, защищённая связность между ними. Гибридная архитектура — не бесплатное дополнение. Она добавляет стоимость VPN или выделенных линий, две control plane в эксплуатации, две модели безопасности в поддержке и латентность для любого workflow, пересекающего границу. Ближайшие крупные облачные регионы — Франкфурт, Дублин, Мумбаи, Сингапур — находятся в 80–200 миллисекундах, что меняет список возможного для приложений, чувствительных к латентности. Ничего из этого не появляется в ROI-презентации, обычно построенной по западному шаблону, предполагавшему локальный hyperscale-регион и отсутствие ограничений по резидентности.
Контраргумент
Стандартный ответ: это решаемые проблемы, а не структурные — egress можно минимизировать, дисциплину FinOps можно выстроить, за lift-and-shift может последовать re-architecture, гибридные архитектуры можно хорошо спроектировать.
Но «решаемость» этих проблем неоднородна. Расходы на egress можно снизить на 30–50 процентов архитектурной дисциплиной, но не обнулить. Зрелость FinOps формируется три-пять лет в большинстве предприятий, и это обучение оплачивается из перерасходов бюджета в течение этого окна. Re-architecture — это вторая миграция, часто крупнее первой, на которую у немногих организаций хватает политического капитала после объявления о «завершении» первой. Лок-ин committed spend математически неизбежен, если вы хотите скидку. А резидентность данных в Казахстане — регуляторный факт, а не архитектурное предпочтение. Сумма этих ограничений — не набор багов, которые нужно починить. Это форма облачной экономики в корпоративном масштабе.
Что это значит
Руководители, подписывающие бизнес-модели облачной миграции, должны требовать четыре вещи, которых стандартные ROI-презентации почти не содержат. Первое — трёхлетнюю TCO-модель, включающую egress в реалистичных объёмах, стоимость гибридной связности, инструменты и штат FinOps, а также обязательства по reserved instances, смоделированные и как экономия, и как стратегический долг. Второе — операционную модель FinOps, определённую до начала миграции: кто владеет распределением затрат, как обеспечивается тегирование, какая месячная каденция оптимизации, какой бизнес-юнит покрывает перерасходы. Третье — workload-appropriate стратегию миграции, явно называющую, какие нагрузки будут lift-and-shift, какие re-platform, какие re-architecture, а какие останутся on-premises — с финансированием работ по re-architecture в той же бизнес-модели, а не отложенными на потом.
Четвёртое, и именно для Казахстана, — архитектурное решение по резидентности данных, принятое сразу: какие данные должны остаться локально, какие могут размещаться в международных облачных регионах, как обеспечивается граница, и как выглядят латентность и операционные расходы итоговой гибридной конструкции. Эти четыре пункта не делают облачную миграцию менее привлекательной. Они делают бизнес-модель честной. Честные бизнес-модели выживают на отметке восемнадцати месяцев — когда разрыв между презентацией и счётом превращается в разговор о том, на что на самом деле подписалась команда руководителей. Облако по-прежнему правильный ответ для большинства корпоративных нагрузок. ROI-презентация, которая его продала, обычно нет.
Часто задаваемые вопросы
Gartner и Flexera стабильно сообщают, что предприятия превышают облачные бюджеты на 20–40 процентов в первый год после миграции, а по некоторым категориям нагрузок — более чем на 50 процентов. Основные драйверы — несмоделированные расходы на egress, oversized инстансы, унаследованные от lift-and-shift, и отсутствие FinOps-дисциплины для обеспечения тегирования, rightsizing и управления commitments. Пик перерасхода обычно приходится на девятый-восемнадцатый месяц, когда медовый месяц стабильных нагрузок заканчивается, а зрелость FinOps ещё не догоняет.
Flexera в отчёте State of the Cloud 2024 оценивает, что примерно 32 процента корпоративных облачных расходов тратятся впустую — простаивающий compute, oversized инстансы, «осиротевшие» хранилища и обязательства, не совпадающие с реальными паттернами потребления. Цифра потерь остаётся удивительно стабильной на протяжении нескольких лет данных Flexera, что указывает на структурную особенность облачной экономики, а не временную проблему. Зрелые FinOps-практики снижают показатель до 15–20 процентов, но не обнуляют его.
Закон Казахстана о персональных данных требует хранения и обработки определённых категорий персональных данных в пределах национальных границ. Поскольку ни один крупный hyperscaler не имеет региона внутри Казахстана, комплаенс требует либо локального облачного провайдера, либо гибридной архитектуры, удерживающей регулируемые данные в локальных дата-центрах. Оба пути добавляют стоимость, не заложенную в стандартную ROI-презентацию: локальные облачные провайдеры берут премию относительно международных hyperscaler, а гибридные архитектуры добавляют связность, эксплуатацию двух control plane и латентность. Реалистичная ROI-модель для Казахстана должна добавлять 15–25 процентов к инфраструктурной строке и включать эксплуатационный overhead гибрида с первого дня.
Нет. Структурные проблемы, которые мы описываем, — не повод избегать облачной миграции, а повод строить честную бизнес-модель и зрелую операционную модель вокруг неё. Облако по-прежнему даёт реальные выгоды: эластичность для переменных нагрузок, доступ к managed-сервисам, быструю провизию и непрерывно улучшающийся каталог сервисов, который on-premises-инфраструктура не может обеспечить. Аргумент этого анализа не против миграции. Он против ROI-презентаций, занижающих реальную стоимость и оставляющих команду руководителей неподготовленной к счёту, приходящему через восемнадцать месяцев.
Корпоративная миграция в облако в Казахстане несёт ограничения, которые западные ROI-шаблоны не моделируют — резидентность данных, гибридная сложность, латентность и кривая зрелости FinOps, которую большинство организаций недооценивают. opengate проводил корпоративных клиентов через трёхлетние TCO-модели, выживающие при столкновении со счётом, включая статьи, которые стандартные презентации пропускают. Если вы оцениваете бизнес-модель миграции или аудитируете ту, что уже восемнадцать месяцев в работе, мы можем пройтись по статьям, которые с наибольшей вероятностью отсутствуют.
Хотите работать вместе? Свяжитесь с нами