Стратегии размещения систем: что держать у себя, а что в облаке?

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

• Стратегия № 1: все критичное — на своих мощностях, остальное — в облаке. Многие крупные игроки идут именно этим путём. Например, банк или страховая компания держит business-critical и особенно mission-critical системы (основные транзакционные системы, базы данных, платежные шлюзы) в своих ЦОДах — для гарантии контроля и доступности, а вспомогательные приложения — почта, тестовые среды, аналитика big data — выносят во внешнее облако.

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

Выгода: баланс между надежностью своих ресурсов и гибкостью облака.

Риски: нужно интегрировать облако и свой ЦОД, обеспечить сеть между ними (чтобы облачная CRM быстро стучалась к локальной базе, например). В моём случае мы оставили основной складской и финансовый софт на своей «железке», а систему электронного обучения персонала — в SaaS, и спим спокойно.

• Стратегия № 2: гибридное облако для критичных систем. Казалось бы, критичные вещи — только on-prem. Но есть тренд: использовать гибридные облака даже для ключевых нагрузок. Это когда часть мощности — в собственном приватном облаке или ЦОДе, а часть — у публичного провайдера, связанных в единую инфраструктуру.

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

Выгода: экономия — не нужно строить «двойной» ЦОД ради редких пиков, облако подхватит.

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

• Стратегия № 3: геораспределённые собственные ЦОДы (geo-redundancy). Для тех, кто не доверяет чужим облакам вовсе, но хочет отказоустойчивости: строятся два и более собственных ЦОДа в разных регионах. Критичные системы работают с репликацией между ними (актив-актив или актив-пассив — об этом далее), что защищает от катастроф. Например, компания может иметь основной ЦОД в Москве, резервный — в Новосибирске.

Плюсы: полный контроль над обоими площадками, данные не уходят третьим лицам.

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

• Стратегия № 4: всё в публичном облаке, а локально — только «кеш» и канал. Хотя тема материала — свой ЦОД, нельзя не упомянуть противоположный подход, популярный у цифровых компаний: cloud-first, максимум сервисов в облаке (IaaS/PaaS/SaaS), а на своих площадках разве что небольшие узлы для кэширования или интеграции. В ритейле и e-commerce этот подход встречается: мол, зачем нам строить серверные, если Amazon/Azure/Яндекс накроют наши онлайн-сервисы инфраструктурой.

Плюсы: минимальные капзатраты, время вывода новых проектов — минуты (развернуть VM или контейнер в облаке).

Минусы: зависимость от интернета и провайдера, счета за облако растут со временем (многие через пару лет «внезапно» узнают, что OPEX на облако превысил все ожидания). Часто на практике компании, ринувшиеся «всё в облако», потом частично возвращаются on-prem (это явление даже получило название — cloud repatriation).

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

Разумеется, стратегий больше (например, колокейшн: когда не строишь свой ЦОД, а размещаешься в чужом дата-центре целиком, арендуя стойки — это между своим и облаком вариант). Я фокусируюсь на том, когда свой ЦОД уже решено строить, и нужно решить — что там будет крутиться. В моём случае после анализа мы выбрали комбинацию: критичные бизнес-системы — в своем новом ЦОДе + геокопия в резерве, второстепенные системы — частично в коммерческом облаке. Это дало и контроль, и гибкость.

Больше полезной информации и реальных примеров в моем Telegram-канале: https://t.me/gleykin_it