Облачные сервисы вышли из стадии экспериментов. Amazon EC2 и S3 работают в продакшене, появляются предложения от хостинг-провайдеров с почасовой тарификацией, и финансовый директор задаёт правильный вопрос: зачем покупать стойку серверов под пиковую нагрузку, если её можно арендовать на три дня в квартал. Но переносить всё в облако никто не собирается. Учётные системы, базы с персональными данными, ведомственные реестры остаются на собственных серверах – по соображениям закона, безопасности и просто здравого смысла. Реальность ближайших лет – гибрид: часть нагрузки внутри периметра, часть снаружи. Задача архитектора – связать эти две половины так, чтобы они работали как одна система.

Где проходит граница

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

Между этими зонами нужна чёткая линия и шлюз на ней. Не стоит размывать границу ради удобства разработчиков – каждый канал наружу должен быть описан, согласован со службой безопасности и поддаваться аудиту. Управлять облачной частью при этом удобнее через инструменты провайдера; мы уже разбирали, как устроена консоль управления AWS и какие операции она закрывает без обращения к API.

Чем связывать половины

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

Три принципа, которые экономят месяцы:

  • Асинхронность. Канал до облака не должен блокировать внутренние процессы. Очередь сообщений переживёт обрыв связи и доставит данные, когда канал восстановится.
  • Единый формат и версионирование контрактов. Облачный сервис и внутренняя система меняются с разной скоростью. Версия контракта развязывает их релизы.
  • Шифрование канала и аутентификация на обеих сторонах. Трафик через интернет защищаем VPN или TLS, доступ – по сертификатам, а не по паре «логин-пароль».

Отдельный вопрос – отчётность поверх распределённых данных. Когда источники разнесены между своим ЦОДом и облаком, собирать аналитику запросами вживую нельзя: вы упрётесь в латентность и нагрузите боевые системы. Здесь работает выделенный слой данных – мы описывали этот подход в материале об архитектуре отчётности и слое данных. Данные стягиваются в единое хранилище по расписанию, и отчёты строятся уже по нему.

Своя инфраструктура тоже становится гибкой

Гибрид – это не только «своё плюс чужое облако». Внутренний контур тоже стоит сделать эластичным, иначе разрыв в гибкости между половинами будет слишком заметен. Виртуализация даёт ту же логику – пул ресурсов вместо привязки к железу – но под полным контролем организации. Свежий VMware vSphere 4 позволяет собрать внутреннее «частное облако» с живой миграцией и распределением нагрузки, и тогда перенос задачи между своим ЦОДом и публичным провайдером перестаёт быть переездом и становится решением о размещении.

Вывод

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