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

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

Почему бизнес откладывает миграцию: мифы об облаке

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

Огромный пул работ над приложением

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

Непродуманная архитектура

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

Увеличение расходов

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

Технологическая зависимость

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

Нет экспертизы у сотрудников

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

Низкая скорость работы

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

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

Какие факторы подталкивают к облаку: бизнес-эффект от миграции

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

Отказоустойчивость 

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

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

Также очевидным преимуществом является модель оплаты pay-as-you-go — оплата за потребленные ресурсы, которую поддерживают облака. Если компании не нужна активная репликация инфраструктуры 24/7/365, она может экономить на ресурсах. 

Подробнее о характеристиках Disaster Recovery →

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

Безопасность

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

Например, облако Selectel соответствует 152-ФЗ до первого уровня защищенности, а также имеет лицензию ФСТЭК, сертификат PCI DSS и другие. Это значит, что вы можете хранить персональные данные пользователей и соответствовать требованиям российского законодательства.

Оптимизация расходов

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

Большим преимуществом являются система постоплаты и гибкая тарификация ресурсов. Также можно на время отключить облачные серверы в период простоя или сэкономить до 70% с помощью прерываемых виртуальных машин.

Гибкость и масштабирование

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

Простота в использовании

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

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

Панель управления Selectel работает по такой же механике. В ней можно создать виртуальную машину, а также арендовать PaaS-сервисы — например, облачные базы данных или Managed Kubernetes.

Развитие бизнеса

Сегодня компаниям нужно развиваться так быстро, как этого требует рынок. Внедрение AI-технологий — еще один драйвер миграции в облако. Для работы с ними нужны производительные GPU для сложных вычислений — например, NVIDIA® Tesla® A100, A30 и RTX™ 6000 ADA.

При этом самостоятельная закупка процессоров — нецелесообразное действие. Один ускоритель может стоить более миллиона рублей. А кроме самой покупки придется наладить логистику и доставку оборудования до вашего сервера. Гораздо выгоднее почасово арендовать GPU-мощности у провайдера для решения конкретной задачи.

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

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

Андрей Сутягин

Директор по продажам, ITSumma

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

Антон Баранов

Менеджер облачной платформы, Selectel

Роли и зоны ответственности

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

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

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

Эталонная миграция: 8 шагов

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

Шаг 1. План и требования

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

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

Шаг 2. Аудит и документация

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

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

ITSumma. Также аудит позволяет оценить текущее состояние проекта. У нас был клиент с запросом на миграцию в Managed Kubernetes, однако в момент аудита мы осознали, что инфраструктура буквально разваливается под руками. 

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

Шаг 3. Техническое задание

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

Особое внимание стоит уделить сетевой связности, схеме сети и сопоставлению требований с возможностями новой инфраструктуры. Чаще всего миграция не происходит по принципу простого lift and shift. 

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

Шаг 4. Разработка новой инфраструктуры

При разработке новой инфраструктуры не стоит пренебрегать использованием Infrastructure as Code (IaC). Этот подход значительно упрощает переразвертывание уже мигрированной инфраструктуры — например, если потребуется добавить ресурсы или перенести виртуальную машину между регионами и зонами доступности. Специфические настройки облака, такие как секьюрити группы, можно задавать через API провайдера, CLI или с помощью инструментов вроде Terraform.

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

Шаг 5. Предварительная подготовка

Компаниям необходимо подготовить сценарий аварийного восстановления (Disaster Recovery). Он состоит из регулярного создания бэкапов и четкого плана отката на случай непредвиденных ситуаций во время миграции.

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

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

Шаг 6. Миграция

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

В случае с контейнеризированными приложениями часто сначала переносят CI/CD пайплайны, затем — стейдж-среду и только после этого продакшен. Для классических сценариев с виртуальными машинами могут использоваться временные прокси и VPN-маршруты, которые помогают снизить время простоя и обеспечить бесперебойную работу сервисов в процессе миграции.

Эталонный пример, когда переезжали сначала процессы, а затем приложения, — кейс Тануки.

Кроме того, Selectel начисляет до 1 000 000 бонусов на два месяца при переезде с инфраструктуры других провайдеров или собственной инфраструктуры on-premise. Также поддерживает на всех этапах переезда: от организации встречи с архитектором, который ответит на вопросы, до миграции силами опытных DevOps-инженеров. 

Шаг 7. Приемо-сдаточные испытания

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

Если все проверки прошли успешно, фиксируются результаты и обновляется документация: схема инфраструктуры, состав виртуальных машин и сервисов, параметры резервного копирования, сетевые настройки и настройки управления доступом (IAM).

Параллельно с испытаниями можно настроить системы мониторинга, алертинг и финальную валидацию SLA (выполнения всех соглашений об уровне сервиса).

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

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

Шаг 8. Переключение и введение в эксплуатацию

После успешного завершения испытаний начинается процесс переключения трафика на новую инфраструктуру. Если архитектура это позволяет, рекомендуем использовать поэтапное включение — методы canary или blue/green. Особенно при переходе с on-premise на облако.

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

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

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

Александр Сбитнев

Тимлид DevOps-команды, ITSumma

Когда можно доверять инфраструктуре

Разберем основные признаки, когда можно доверять инфраструктуре провайдера.

1. Провайдер обеспечивает отказоустойчивость. Дата-центры Selectel соответствуют международным стандартам Tier III. Все инженерные системы многократно зарезервированы, чтобы во время плановых работ сервисы функционировали в привычном режиме. 

Кроме того, есть несколько дата-центров в Москве и Санкт-Петербурге, что позволяет клиентам размещать свои ресурсы в разных локациях для обеспечения отказоустойчивости и резервирования. Это повышает уровень доступности до 99,99%. 

2. Инфраструктура соответствует требованиям безопасности. У Selectel есть инфраструктура, для которой проведена не только оценка эффективности, но и аттестация по 17 приказу ФСТЭК. Это значит, что клиент может размещать системы, которые выполняют требования безопасности.

Ознакомиться с сертификатами и заключениями можно на странице безопасности Selectel.

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

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

Андрей Давид

Руководитель отдела продуктов клиентской безопасности, Selectel

Бесплатная миграция в Selectel

До 1 000 000 бонусов на два месяца. Инженеры подготовят план и поддержат на всех этапах миграции. 

Подробнее →