Свои серверы против облака: большинство компаний получают и то, и другое
Дискуссия между сохранением серверов в собственном ЦОД и переносом всего в облако редко заканчивается чистым ответом. Разбор того, что реальная гибридная инфраструктура на самом деле предполагает.
В последние несколько лет разговор о переходе в облако преподносится как бинарный выбор. Либо вы переходите в облако (прогрессивно, современно), либо остаётесь на собственных серверах (легаси, отстаёте). Реальность в большинстве компаний среднего размера, с которыми я работаю, не такая. Это гибрид, который никто полностью не планировал.
Часть нагрузки ушла в облако, потому что поставщик потребовал, или проектная команда выбрала AWS без централизованной политики. Часть осталась на собственных серверах, потому что данные чувствительные, интеграция сложная, или кто-то решил, что экономика не сходится. Результат - два окружения с разными моделями эксплуатации, допущениями безопасности и структурой затрат, которые управляются как одно.
Почему дискуссия остаётся неразрешённой
Чистое облако и чистый on-premise - оба имеют смысл как позиции. Бессмысленно приходить к гибриду случайно и потом эксплуатировать его, не признавая, что это гибрид.
Аргументы за облако реальны: управляемые сервисы снижают операционную нагрузку, масштабирование проще, а переход от капитальных затрат к операционным помогает многим бизнес-моделям. Аргументы за собственные серверы тоже реальны: для стабильных, предсказуемых нагрузок экономика часто говорит в пользу собственной инфраструктуры, а требования к суверенитету данных или задержкам иногда делают облако неподходящим.
Проблема в том, что ни одна сторона этого спора не права всегда, и большинство компаний так и не проделывают расчёт по своим реальным нагрузкам.
Как выглядит осознанный гибрид
Осознанный гибрид начинается с классификации нагрузок. По каждой значимой нагрузке вы отвечаете: это вычислительно интенсивная и переменная нагрузка? Она обрабатывает персональные данные с требованиями к резидентству? Это стандартная функция, где управляемый сервис устраняет операционные издержки? Профиль нагрузки достаточно стабилен, чтобы зарезервированные мощности оказались выгоднее эластичного биллинга?
На основе этого вы принимаете явные решения о размещении, а не наследуете их от того, кто первым настраивал систему.
Операционная проблема, о которой не говорят
Сложная часть гибрида - не куда ставить нагрузки. А как эксплуатировать два окружения согласованно. Управление идентификацией и доступом в обоих. Мониторинг с единой картиной. Политика безопасности, последовательная на обоих периметрах. Резервное копирование и восстановление, охватывающее оба.
У большинства компаний, работающих в гибридном режиме, этого нет. Есть две раздельные модели эксплуатации, нередко принадлежащие разным командам, с негласным предположением, что они «в конце концов объединятся». Этот день редко наступает.
Практический подход к следующему решению
Когда возникнет следующее инфраструктурное решение, прежде чем размещать нагрузку, потратьте час на три вопроса. Первый: каков ожидаемый профиль нагрузки в течение трёх лет - переменный или стабильный? Второй: есть ли ограничения по резидентству данных или задержкам, которые ограничивают размещение? Третий: существует ли управляемый облачный аналог, который снимает значимую операционную нагрузку, и при какой доплате?
Ответы не всегда будут указывать в одну сторону. Это нормально. Важно принимать решение осознанно, а не по умолчанию, и документировать логику - чтобы следующая команда, принявшая эту систему, понимала, почему она там, где она есть.
Об экономике
Переход в облако с целью снижения затрат обычно работает только тогда, когда вы также меняете операционную модель - переходите на управляемые сервисы, сокращаете операционный персонал, обслуживавший физическую инфраструктуру, и активно управляете облачными расходами. Если вы переносите нагрузку «как есть» и оставляете ту же команду управлять ею, вы нередко платите больше за то же самое. Экономика облака требует полного пакета, а не просто переноса инфраструктуры.