август    2026

Пн	Вт	Ср	Чт	Пт	Сб	Вс
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

показать все 

13.08.2026

Эксперт «Группы Астра» Эдуард Тихомиров отметил 5 главных трендов в разработке ПО и программировании

Читать далее 

20.07.2026

ИИ-директор «Группы Астра» Владимир Нелюб: Очередной инцидент с доступом к ChatGPT возвращает нас к вопросу о национальных моделях

Читать далее 

20.07.2026

Главное ИТ-событие года состоится в Москве в октябре

Читать далее 

20.07.2026

К2 НейроТех запустил калькулятор ИИ-зрелости для оценки инфраструктурной готовности бизнеса

Читать далее 

20.07.2026

ИИ в корпоративном обучении пока остается инструментом, а не заменой человека

Читать далее 

показать все 

26.07.2026

Почему компании возвращаются с облаков на свои серверы? Как считать экономику переезда?

Читать далее 

26.07.2026

Аутсорс разработки: как не потерять контроль над кодом и сэкономить 30% бюджета

Читать далее 

20.07.2026

Ключевая задача для технологического бизнеса — адаптация к новым правилам

Читать далее 

21.06.2026

Коллаборации с конкурентами: необходимость или рискованная ставка?

Читать далее 

21.06.2026

Как вы обеспечиваете непрерывность разработки без зарубежных облаков?

Читать далее 

20.06.2026

Сергей Ергопуло: «Информационное моделирование становится частью единой цифровой вертикали предприятия»

Читать далее 

29.07.2025

Точность до метра и сантиметра: как применяют технологии позиционирования

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

22.09.2023

Эпоха российской ориентации на Запад в сфере программного обеспечения завершилась

Читать далее 

22.09.2023

Сладкая жизнь

Читать далее 

показать все 

Главная / Статьи / Опросы / Почему компании возвращаются с облаков на свои серверы? Как считать экономику переезда?

Почему компании возвращаются с облаков на свои серверы? Как считать экономику переезда?

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

1. Вы перевели инфраструктуру в облако, а через год-два вернули обратно на свои серверы. Что стало триггером? Это были деньги, безопасность, производительность, контроль или что-то другое? Расскажите историю решения.
2. Когда вы считали TCO (совокупную стоимость владения) для облака vs своего железа, какие скрытые затраты вы не учли в первоначальных расчетах?
3. Сколько реально стоил переезд из облака обратно на свою инфраструктуру? Включите не только железо и лицензии, но и время команды, простой сервисов, переделку архитектуры, обучение. Окупился ли переезд и за какой срок?
4. Вы оставили часть инфраструктуры в облаке, а часть вернули на свои серверы. По какому принципу делили? Что осталось в облаке и почему? Что вернули и почему? Как теперь работаете с гибридной моделью?
5. Расскажите о случае, когда облачный провайдер изменил условия (поднял цены, ограничил функционал, изменил SLA), и это стало причиной возврата. Как вы защищались от таких рисков? Что бы сделали иначе?
6. Если бы вы сейчас стояли перед выбором «облако или свое железо» — что бы выбрали и почему? Какие данные или метрики стали для вас решающими?
7. Какой один совет вы бы дали ИТ-директору, который сейчас думает о возврате из облака? Не «считайте TCO» (это очевидно), нужна конкретика: на что смотреть, каких ошибок избегать, с чего начать?

На вопросы «БИТа» отвечают эксперты компаний

Сергей Халяпин,
директор по развитию новых рынков и технологических партнеров Termidesk (ООО «Увеон-облачные технологии», входит в «Группу Астра»)

«Переезд окупается тогда, когда нагрузка стабильна, горизонт планирования понятен, а компания готова инвестировать в собственную эксплуатацию»

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

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

Особенно это заметно в VDI-сценариях: если рабочие места постоянно включены, требуют стабильной производительности и обслуживают большое число пользователей, то экономика облака может перестать сходиться. Если в ЦОД компании невключенная машина, это просто невыключенная машина пользователя, то в облаке это затраты — компания оплачивает любые включенные ВМ.

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

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

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

Также не нужно забывать, что современные приложения — многозвенные, и для корректной и быстрой работы эти звенья должны размещаться близко друг к другу. Перенос только части приложения в облако, может привести к снижению комфорта работы пользователей, так как их запросы к приложению в облаке будут обрабатываться быстро, а вот дальнейший запрос от приложения к БД или middleware будет вынужден возвращаться по WAN-каналам в ЦОД компании.

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

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

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

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

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

Для VDI это может выглядеть так: основные рабочие места и чувствительные данные находятся в собственной инфраструктуре, а временные фонды, пилоты, тестовые группы или резервные мощности — в облаке. Главное, чтобы пользовательский сценарий оставался единым, а администрирование — централизованным.

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

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

Защита от такого риска — не только договор. Нужна архитектурная переносимость: независимость от уникальных сервисов одного провайдера, документированные процедуры миграции, регулярные тесты восстановления и/или переноса инфраструктуры, резервные копии в контролируемом контуре и понимание, сколько времени займет перенос нагрузки.

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

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

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

7. Не начинайте с закупки серверов. Начните с построения карты рабочих нагрузок и сценариев работы пользователей.

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

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

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

Алексей Какунин,
генеральный директор ЕМДЕВ

«В бюджете переезда сопоставимыми оказались не серверы и лицензии, а работа команды»

1. Мы хотим поделиться кейсом миграции с облачного Microsoft SharePoint на on prem корпоративный портал Инкоманд, который команда ЕМДЕВ реализовала для машиностроительного холдинга ~5000 сотрудников.

Ключевой триггер — отключение сервисов Microsoft Sharepoint для российских клиентов. Однако и до принятого Microsoft решения заказчик хотел убрать критичные сервисы из зарубежного облака, вернуть контроль над ИБ и архитектурой. И при этом не потерять удобство и гибкость low code решения, к которой привык в SharePoint.

Решение принимали поэтапно. Команда проводила аудит рисков, оценку роста совокупной стоимости подписок, ограничения интеграций с локальными системами. В итоге выбор пал на on prem корпоративный портал Инкоманд, который полноценно замещает SharePoint сценарии.

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

Во-первых, интеграции — стыковка портала с существующими СЭД, ERP, HR и ИТ сервисами, доработка API, обеспечение отказоустойчивости связок.

Во-вторых, ИБ и сеть — защищенные каналы, VPN, сегментация, дополнительные средства мониторинга и аудита.

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

3. В бюджете переезда сопоставимыми оказались не серверы и лицензии, а работа команды, то есть проектирование новой архитектуры, миграция контента и прав, настройка интеграций, обучение редакторов и ИТ службы. Для холдинга с 5000 сотрудников окупаемость наступила примерно за 2,5–3 года за счет отказа от подписок, снижения ТСО (отсутствие пользовательских лицензий) и ИБ рисков (эксплуатация в собственном полностью контролируемом контуре), а также ускорения вывода новых сервисов на портале Инкоманд.

4. В данном проекте все сервисы, реализованные на облачном Sharepoint Online, были перенесены on-prem. Однако в случае необходимости мы рекомендуем оставлять в облаке внешние витрины и часть неперсонализированных сервисов, где важна глобальная доступность и эластичность ресурсов.

Во внутренний же контур обязательно перенести корпоративный портал, документы, сервисы для сотрудников, ИТ и HR приложения — все, что связано с персональными данными и ключевыми процессами. Гибридная модель строится вокруг корпоративного портала как «точки входа». Он объединяет on prem системы и при необходимости дает ссылки/виджеты на облачные сервисы.

6. При запуске новых интеграционных и/или портальных решений мы рекомендуем выбирать модель «on prem first, а SaaS — по необходимости», опираясь на метрики нагрузки, требований к локализации данных и прогнозируемой стоимости владения на горизонте 3–5 лет.

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

7. Смоделируйте и подробно опишите целевую архитектуру «после возврата» до старта миграции — с перечнем сервисов, стеков, ответственностей и ограничений. Затем проведите пилотный вынос одного из ключевых контуров (в нашем случае, например, интеграционной шины или портала) на собственную инфраструктуру, чтобы на реальных данных увидеть расходы и риски. Это позволит избежать «обратной» привязки к облаку, лучше спланировать бюджеты и выстроить гибридную модель, если она окажется оптимальной.

Максим Захаренко,
СЕО «Облакотека»

«Часто проблема не в самом облаке, а в том, что его используют как арендованный сервер, без оптимизации»

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

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

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

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

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

На практике самый здоровый вариант — гибридная модель. В облаке часто оставляют то, где важны гибкость, быстрый запуск, резервные площадки, dev/test-среды, сезонные пики, бэкапы и аварийное восстановление. На свое железо могут возвращать стабильные, прогнозируемые нагрузки с высокой загрузкой, особенно если у компании уже есть сильная инфраструктурная команда.

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

Мой совет ИТ-директору: начните не с решения уходить из облака, а с инвентаризации нагрузок. Разделите их на стабильные, переменные и критичные. По каждой посчитайте полный жизненный цикл на 3–5 лет и стоимость риска. И обязательно проверьте, можно ли сначала оптимизировать текущее облако: убрать лишние ресурсы, настроить политики хранения, пересмотреть архитектуру. Бывает, после такой оценки идея вернуть все обратно теряет экономический смысл. А иногда, наоборот, становится понятно, что часть нагрузки рациональнее держать у себя.

Илья Глейкин,
независимый бизнес-консультант в области ИТ-менеджмента

«Главный триггер обычно смешанный: экономика плюс контроль»

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

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

Главный триггер обычно смешанный: экономика плюс контроль. В первоначальном TCO часто недооценивают не стоимость виртуальной машины, а «хвосты»: каналы связи между площадками, лицензии на СУБД и виртуализацию, рост требований к ИБ.

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

Реальная экономика обратной миграции считается не как «купили серверы вместо счета за облако». Надо заложить CAPEX на серверы, СХД, сеть, резервную площадку, лицензии, электроэнергию/стойки, поддержку, ЗИП, мониторинг, а также работу команды: аудит зависимостей, перенос данных, переписывание IaC, тесты отказоустойчивости, ночные окна миграции, параллельную оплату облака и новой инфраструктуры на переходный период.

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

Гибридная модель выглядит так: в облаке остаются тестовые среды, пиковые кампании, CDN, резервное копирование, DR, аналитика/ML на GPU, сервисы с переменной нагрузкой. На свои мощности возвращают то, что стабильно загружено, критично к задержкам, содержит чувствительные данные или требует нестандартной ИБ-архитектуры.

Ошибка — переносить все одним проектом. Начинать нужно с карты потребления: 20 самых дорогих сервисов, профиль CPU/RAM/IOPS/трафика, RTO/RPO, требования 152-ФЗ и отраслевых регуляторов. После этого выбрать один контур, перенести пилотом и сравнить факт за два биллинговых периода.

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

Иван Иванов,
генеральный директор ООО «Апрель Инновации»

«Гибридная модель требует чуть больше усилий для ее сопровождения, но все это закрывается довольно легко путем использования CI/CD- автоматизаций»

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

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

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

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

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

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

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

1) Есть ли жесткие требования по сохранности персональных данных, используемых в предоставляемых вашей компанией сервисах?

2) Насколько SLA облачного провайдера соответствует уровню SLA, который вы предоставляете своим клиентам?

3) Готовы ли вы держать в штате достаточное число devops специалистов, обслуживающих вашу инфраструктуру; возможна ли частичная или полная автоматизация devops операций?

4) Что будет с вашими сервисами и клиентами в случае отказа облачного провайдера или оборудования в вашей инфраструктуре?

5) Способны ли вы обеспечить собственную инфраструктуру запасными компонентами и осуществлять ее обслуживание в условиях санкционного давления на Россию?

Юлия Камалова,
старший преподаватель кафедры информационных технологий Финансового университета при Правительстве РФ

«Начните с аудита. Возьмите счета от провайдера и выпишите все сопутствующие статьи расходов»

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

Начиная сотрудничество с облачным провайдером, компании привлекает модель оплаты по факту потребления (pay-as-you-go). Однако спустя год выясняется, что для круглосуточно работающих систем с предсказуемой нагрузкой эта гибкость оборачивается финансовой ловушкой. Счета за облачные услуги растут из года в год, не принося соразмерной выгоды для бизнеса. Особенно болезненной статьей расходов становится плата за вывод данных из облака — затраты, которые часто не учитываются при первоначальных расчетах.

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

В итоге классический подход «lift and shift» (простой перенос виртуальных машин из собственного дата-центра в облако без переработки архитектуры) не дает обещанных преимуществ, а лишь создает дополнительные сложности с управлением расходами.

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

Прежде всего, это прямые расходы на новое оборудование и лицензии. Но неожиданностью становятся и косвенные издержки. Компании тратят месяцы на инвентаризацию: оказывается, что в облаке «живут» десятки забытых сервисов, взаимосвязи которых никем не задокументированы. Приходится переписывать часть архитектуры, отказываться от управляемых сервисов (например, RDS или очередей сообщений) и настраивать их аналоги на собственных серверах.

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

В итоге многие приходят к гибридной модели, и это единственное разумное решение. Компании возвращают на собственные серверы критически важные для задержки (latency-sensitive) базы данных и тяжелые корпоративные системы, а также среды разработки и тестирования, поскольку там важны предсказуемая производительность и быстрый доступ к данным.

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

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

При выборе между облаком и собственным оборудованием стоит исходить из правила: облако подходит для динамических, непредсказуемых или кратковременных нагрузок, а собственное оборудование — для всего, что работает в режиме 24/7 с высокой и стабильной утилизацией ресурсов.

Ключевыми показателями являются не только почасовая стоимость, но и совокупная стоимость владения (TCO) на горизонте 3–5 лет с учетом затрат на исходящий трафик, администрирование и переработку архитектуры. Критически важны также нормативные требования и вопросы суверенитета данных: для финансового и государственного секторов это часто становится непреодолимым препятствием для использования публичного облака.

Главный совет ИТ-директору, задумавшемуся о возврате инфраструктуры «домой»: не начинайте с покупки серверов. Начните с аудита. Возьмите счета от провайдера и выпишите не только стоимость виртуальных машин, но и все сопутствующие статьи расходов: трафик, дисковые операции, управляемые сервисы, поддержку.

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

Далее выберите один-два пилотных сервиса с наиболее предсказуемой нагрузкой и попробуйте развернуть их на арендованных серверах или в рамках услуги колокации (размещения оборудования в дата-центре). Так вы получите реальные данные о производительности, сложности администрирования и затратах, а не теоретические расчеты.

И помните: возвращение — это не признак поражения, а признак зрелости. Это переход от стратегии «cloud-first» (облако — прежде всего) к стратегии «cloud-smart» (разумное использование облака), когда для каждой рабочей нагрузки вы выбираете оптимальное место размещения.

Ключевые слова: облако, миграция, инфраструктура, репатриация, гибридная модель, cloud-smart, сервисы, инвестиции, архитектура, нагрузки, эксплуатация

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи