Компании редко строят ИТ-инфраструктуру с чистого листа. Обычно у бизнеса уже есть серверы, виртуальные машины, устаревшие системы, требования безопасности, бюджетные ограничения и сервисы, которые должны работать без простоев. Поэтому вопрос звучит не «какая модель лучше», а иначе: что оставить локально, что виртуализировать, что перенести в облако и где нужна гибридная архитектура.
Локальная инфраструктура
Локальная инфраструктура долгое время была основой корпоративных ИТ‑систем. В 1990‑е и 2000‑е годы это был единственный зрелый способ обеспечить работу бизнес‑приложений: серверы размещались в собственных дата‑центрах, компании контролировали оборудование, сети, безопасность и резервирование. Такой подход был естественным для своего времени. Бизнес‑приложения были монолитными и требовали тесной привязки к конкретному серверу, сетевые каналы оставались дорогими и медленными, а регуляторика и внутренние стандарты безопасности предполагали физическое хранение данных внутри периметра. Поэтому локальная модель стала базовым способом построения корпоративной инфраструктуры.
Даже сегодня локальная инфраструктура остаётся оправданной для компаний, где критичны предсказуемость нагрузки, низкие задержки и полный контроль над данными. Это характерно для финансовых организаций, промышленных предприятий, медицинских учреждений, операторов связи и компаний, где стоимость простоя высока. В таких сценариях локальная модель обеспечивает стабильность, независимость от внешних провайдеров и возможность соответствовать отраслевым требованиям без компромиссов.
Однако по мере роста требований стало ясно, что локальная модель имеет пределы. Масштабирование занимало недели или месяцы, а обеспечение отказоустойчивости требовало дорогостоящего дублирования. ИТ‑отделы тратили значительную часть времени на обслуживание оборудования: замену дисков, мониторинг температуры, настройку сетей, борьбу с перегревом.
Виртуализация
Когда локальная инфраструктура перестала справляться с ростом количества систем и усложнением бизнес‑процессов, следующим логичным шагом стала виртуализация. Она позволила компаниям уйти от модели «один сервер — одно приложение» и перейти к более эффективному использованию ресурсов. Вместо того чтобы запускать каждую систему на отдельном физическом сервере, компании получили возможность размещать десятки виртуальных машин на одном хосте. Это снизило количество оборудования, упростило эксплуатацию и ускорило запуск новых сервисов.
Переход к виртуализации был вызван вполне практичными причинами. Серверы использовались неэффективно: многие приложения занимали лишь небольшую часть мощности, но требовали отдельного оборудования. Масштабирование инфраструктуры превращалось в долгий и дорогой процесс, а обеспечение отказоустойчивости требовало дублирования серверов и сложных схем резервирования. Бизнесу нужна была скорость — запуск новых сервисов не мог зависеть от поставок оборудования и длительных согласований. Виртуализация позволила решить эти проблемы: ресурсы стали гибче, а управление — централизованным.
Однако виртуализация предъявила новые требования к оборудованию. Если в локальной модели серверы могли быть разнородными и работать с низкой загрузкой, то виртуальная среда требовала высокой плотности и предсказуемой производительности. Процессор стал ключевым ресурсом: виртуализация опиралась на аппаратную поддержку и большое количество ядер, чтобы обеспечить работу множества виртуальных машин.
Память превратилась в главный ограничивающий фактор: виртуальные машины потребляли RAM значительно активнее, чем физические серверы, поэтому хосты оснащались сотнями гигабайт памяти, а её пропускная способность и корректность стали критичными. Дисковая подсистема тоже изменилась. Виртуализация увеличивала нагрузку на хранилище: десятки виртуальных машин создавали конкурирующие запросы, и традиционные HDD перестали справляться. Компании переходили на SSD и NVMe, а затем — на полноценные системы хранения, которые обеспечивали высокую производительность и низкие задержки.
Сеть стала не менее важной: миграция виртуальных машин, доступ к хранилищу и внутренняя коммуникация сервисов требовали высокой пропускной способности и отказоустойчивости. Появилась необходимость в быстрых сетях, разделении трафика и дублировании сетевых путей.
Инженерная инфраструктура тоже усложнилась: высокая плотность нагрузки требовала мощного охлаждения, резервного питания и предсказуемой работы дата‑центра.
Облачная и гибридная модели
Облачная модель ускоряет запуск новых сервисов, а гибридная сочетает разные подходы в одной архитектуре. Но у каждой модели есть ограничения: стоимость масштабирования, требования к оборудованию, зависимость от провайдера, сложность интеграций и риски для безопасности.
Современные компании обрабатывают всё больше данных: транзакции, аналитику, телеметрию, обращения клиентов, логи сервисов. Одновременно бизнес перешёл в режим постоянной доступности: интернет-магазины, личные кабинеты, мобильные приложения и внутренние системы должны работать без простоев. Поэтому инфраструктуре нужны отказоустойчивость, резервирование, мониторинг и возможность обновлять сервисы без остановки.
Недостаточно просто защитить периметр компании: доступы нужно разделять, действия пользователей и сервисов — отслеживать, а критичные данные — хранить и обрабатывать с учётом отраслевых требований. Чем сложнее инфраструктура, тем важнее заранее понимать, какие системы можно выносить за пределы локального контура, а какие должны оставаться внутри компании.
Командам нужны тестовые среды, автоматизация и предсказуемый запуск новых сервисов. Практики CI/CD и IaC помогают выпускать изменения чаще и управлять инфраструктурой по шаблонам, но требуют от ИТ-среды скорости и стандартизации.
Сотрудники работают удалённо, филиалы подключаются из разных регионов, сервисы обмениваются данными между площадками и облаками. Поэтому выросли требования к сетям, стабильности доступа, задержкам и стоимости передачи данных — например, исходящего трафика из облака.
Все эти изменения проявляются в конкретных симптомах: отчёты строятся дольше, базы данных работают на пределе, инциденты происходят чаще, VPN перегружается, а оборудование снимается с поддержки. Это признаки того, что прежняя инфраструктура перестаёт соответствовать требованиям бизнеса и компании нужно пересматривать архитектуру: усиливать локальный контур, развивать виртуализацию, использовать облако или строить гибридную модель.
Если вы хотите узнать больше о том, как выбрать оптимальный форм-фактор сервера, рекомендуем ознакомиться с нашей статьёй Стоечный или башенный: какой форм-фактор сервера выбрать.