On-premise и cloud в корпоративной среде: практическое сравнение подходов

Автор: Алексей Воронов, инженер и технический редактор

В корпоративной IT-среде выбор между on-premise и cloud — это не вопрос моды и не формальная строчка в стратегии цифровой трансформации. На практике это решение, которое на годы вперед определяет бюджет, модель эксплуатации, требования к команде, сценарии масштабирования и, что особенно важно, профиль рисков. Я работал с Oracle Database в обоих подходах: сопровождал кластеры на собственном железе в банковской инфраструктуре, а позже участвовал в переносе рабочих нагрузок в OCI. И если говорить без лишней романтики, on-premise действительно дает максимальный контроль, но требует тяжелой дисциплины в эксплуатации. Cloud, в свою очередь, обеспечивает гибкость и скорость, однако быстро поднимает вопросы vendor lock-in, сетевой архитектуры и счетов, которые при неудачной конфигурации растут заметно быстрее, чем ожидалось на этапе пресейла.

Ниже — практический разбор для инженеров, архитекторов, DBA и DevOps-команд. Сравним подходы по ключевым параметрам, посмотрим на реальные сценарии использования, разберем компромиссы и типовые ошибки. Отдельно пройдемся по чек-листам оценки, миграции и гибридным схемам. Задача статьи простая: не пересказать очевидное, а показать, когда on-premise действительно выигрывает, а когда cloud снимает операционную боль и ускоряет развитие платформы.

Что такое on-premise и cloud в корпоративном контексте

On-premise: железо и софт под вашим контролем

On-premise — это модель, в которой вся критичная инфраструктура находится под прямым управлением компании: серверы, системы хранения, сеть, резервирование, средства мониторинга, контуры безопасности и сам прикладной стек. Оборудование может стоять в собственном дата-центре или в colocation, но ответственность за платформу остается у вас. Вы сами закупаете hardware, разворачиваете Oracle Database, WebLogic, интеграционные компоненты, настраиваете RAC-кластеры, резервное копирование, патчинг и процедуры аварийного восстановления.

На бумаге это выглядит как максимальная свобода, и во многом так и есть. Но в реальных enterprise-проектах свобода почти всегда идет в связке с обязательствами: нужен штат, нужны регламенты, нужны окна на обслуживание, нужна зрелая CMDB и понятная модель изменений. Без этого on-premise быстро превращается в набор “исторически сложившихся” решений, к которым страшно прикасаться.

Плюсы на практике:

• Полный доступ к low-level настройкам: можно тонко настраивать kernel, NUMA-политику, storage layout, сетевые параметры, использовать специализированные схемы partitioning и кастомный тюнинг Oracle под конкретную нагрузку.
• Данные физически не покидают периметр организации — это принципиально для банков, госструктур и компаний с жесткими требованиями по локализации и compliance, включая GDPR и ФЗ-152.

Минусы, с которыми я сталкивался в проектах:

• Высокий CapEx на старте: для серьезной отказоустойчивой платформы суммы начинаются не с “одного сервера в стойке”, а с полноценного контура, где 5–10 млн руб. на кластер Oracle Exadata — вполне реалистичный порядок цифр.
• Существенный OPEX на сопровождение: администраторы, DBA, сеть, эксплуатация инженерной инфраструктуры, электричество, охлаждение, поддержка вендоров — в совокупности это легко доходит до 30% годового бюджета платформы.

Характерный пример из практики — проект с резервированием Oracle GoldenGate между primary и replica в on-premise-контуре. По latency все выглядело отлично: менее 1 мс внутри площадки. Но когда мы моделировали failover не на тестовом стенде, а в условиях, близких к боевым, выяснялось, что сама процедура переключения, верификация целостности и возврат сервиса в штатный режим занимают часы. Это типичный урок on-premise: низкая задержка и полный контроль еще не означают простой эксплуатации.

Cloud: от IaaS до SaaS в чужом дата-центре

Cloud — это аренда вычислительных и платформенных ресурсов у провайдера: AWS, Azure, OCI, Yandex Cloud и других. Но в корпоративной среде важно не смешивать все облачные модели в одну корзину. IaaS — это виртуальные машины и сетевые сервисы, то есть в определенном смысле “on-premise без владения железом”. PaaS — уже более высокий уровень абстракции, где значительная часть рутинной эксплуатации передана провайдеру; пример — Oracle Autonomous Database. SaaS — это готовые приложения, где инфраструктурный слой почти полностью скрыт, как в случае с Salesforce.

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

Ключевые типы для enterprise:

• Public cloud: AWS, Google Cloud и аналогичные платформы. Часто это наиболее быстрый путь к запуску, но нужно учитывать multi-tenant-модель, требования к сегментации и контроль сетевого периметра.
• Private cloud: собственная облачная платформа на базе OpenStack, VMware и близких технологий. Формально это тоже cloud-подход, но с полным контролем внутри организации.
• Hybrid: комбинация on-premise и cloud, где часть систем остается в локальном контуре, а часть выносится в облако. Для edge-сценариев показателен пример Oracle Roving Edge.

По состоянию на 2026 год hybrid для enterprise — уже не промежуточный этап, а нормальная рабочая модель. По данным Gartner, 70% компаний из Fortune 500 используют ее для Oracle workloads. И это логично: в реальности организации редко могут одномоментно перевести весь стек в одно облако, особенно если есть legacy-системы, интеграции с внутренними шинами, зависимость от локальных HSM, специфических сетевых политик или регуляторных ограничений.

Сравнение по ключевым метрикам: таблица для быстрого сканирования

Если смотреть на эти метрики глазами архитектора, важно не искать универсального победителя. Смысл в том, чтобы соотнести модель размещения с профилем нагрузки, зрелостью команды и допусками по рискам. По данным моих проектов и отчетов Gartner 2026, TCO в cloud действительно может быть ниже на 30–50% для variable workloads. Но для стабильной, предсказуемой нагрузки с долгим жизненным циклом on-premise часто оказывается экономически и операционно более внятным вариантом.

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

Стоимость владения: как посчитать реальный TCO

Если говорить честно, обсуждение on-premise и cloud почти всегда упирается в деньги — но считать нужно не по маркетинговым калькуляторам “в лоб”, а по полной модели владения. Простая формула TCO выглядит так: hardware + software + люди + энергия + downtime. И вот последний компонент, downtime, компании систематически недооценивают, хотя именно он часто стоит дороже всей экономии на инфраструктуре.

On-premise TCO

• Hardware: серверы Dell/HP, системы хранения, сетевое оборудование, резервные компоненты, плюс лицензии Oracle по модели per core.
• Пример: Oracle Enterprise Edition на 4-node RAC — около 2 млн руб./год на лицензии плюс еще примерно 1 млн руб. на поддержку.
• Скрытые статьи затрат: минимум 2 FTE администратора или DBA, что дает 5–7 млн руб./год, а также PUE 1.5 и затраты на электроэнергию порядка 500 тыс. руб.

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

Чек-лист расчета:

1. Inventarize текущие VM, cores, storage, network throughput и лицензируемые компоненты.
2. Добавьте минимум 20% на redundancy, а для критичных контуров — иногда и больше.
3. Умножьте затраты на 3–5 лет с учетом амортизации, обновления hardware и роста нагрузки.
4. Для Oracle используйте официальный калькулятор лицензирования: oracle.com/licensing.

Из практики: многие организации ошибаются не в цене серверов, а в оценке косвенных расходов. Например, забывают учитывать тестовые и pre-prod среды, резервные площадки, отдельные контуры для обучения, стоимость расширения backup-инфраструктуры и необходимость держать штат с компетенциями именно под конкретный enterprise-стек.

Cloud TCO

• Для OCI примерная отправная точка: Autonomous DB — от $0.14/OCPU-hour.
• Пример: база на 16 OCPU, работающая 24/7, — около 1.2 млн руб./год, при этом auto-scale может быть включен без отдельной закупки железа.
• Типичный источник неприятных сюрпризов: egress traffic, то есть исходящий трафик из облака. В крупных интеграционных схемах он спокойно доходит до 20% счета.

На первый взгляд cloud TCO легче оптимизировать: отключать ресурсы, применять reserved capacity, переносить часть нагрузки на managed-сервисы. Но именно здесь компании чаще всего недооценивают сетевую составляющую, стоимость хранения резервных копий, межзонный трафик, логирование, мониторинг и постоянную работу CI/CD-контуров.

Инструменты: AWS Pricing Calculator или OCI Cost Estimator. В hybrid-сценариях для lift-and-shift Oracle часто используют VMware Cloud on AWS, особенно когда нужно быстро перенести привычную модель эксплуатации без немедленного рефакторинга приложений.

Кейс из практики: при миграции 10 TB Oracle в OCI общий TCO снизился примерно на 40%. Но это не была “идеальная победа” облака: расходы на egress для репликации съедали около 200 тыс. руб. в месяц. Проблема решилась только после перехода на private peering и переразметки сетевой схемы. Это хороший пример того, почему любые расчеты cloud нужно прогонять вместе с сетевыми инженерами, а не только с финансовым отделом.

Производительность и масштабируемость: реальные бенчмарки

Если убрать маркетинг, то on-premise обычно выигрывает там, где важна предсказуемая latency и строгий контроль над путями данных. Внутри собственного DC задержки ниже 1 мс — нормальная, достижимая величина. Cloud отвечает другим преимуществом: эластичностью и возможностью масштабироваться без цикла закупки, поставки и ввода оборудования в эксплуатацию.

Тестируем сами

• Инструмент: HammerDB для Oracle TPC-C — один из удобных способов получить сопоставимые цифры на стенде.
• On-prem Exadata X9: около 1M TPM на узел.
• OCI BM.Standard3: порядка 800k TPM, но с возможностью быстро масштабироваться горизонтально.

Эти цифры сами по себе не дают полного ответа, потому что enterprise-нагрузка редко выглядит как чистый лабораторный тест. Важно не только пиковое количество транзакций, но и характер I/O, работа с redo/undo, латентность между приложением и БД, сетевые задержки при интеграциях, влияние backup/job-окон и поведение при деградации одного из узлов.

Масштабирование:

• On-premise: добавление rack или расширение существующего кластера — это обычно согласования, закупки, логистика, инсталляция и окно на работы. Даже если все спланировано хорошо, downtime 4–8 часов для части операций — не редкость.
• Cloud: Kubernetes плюс OCI Container Engine позволяет выполнять rolling-обновления и расширение без остановки сервиса, если приложение к этому подготовлено архитектурно.

Для Oracle-сред важный практический вариант — использовать Data Guard в hybrid-модели, когда синхронная или асинхронная реплика идет из on-premise в cloud. Такой подход помогает не только с DR-сценарием, но и с поэтапной миграцией, когда прод еще остается в локальном контуре, а часть аналитической или тестовой нагрузки уже вынесена в облако.

Из опыта: проблемы производительности после миграции чаще связаны не с “медленным облаком”, а с тем, что приложение исторически проектировалось под локальную сеть и короткие round-trip. После переноса в cloud внезапно становится видно все, что раньше скрывала близость серверов друг к другу.

Безопасность и compliance: кто отвечает за что?

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

On-premise

• Вы отвечаете за все: физическую защиту, сегментацию сети, шифрование, IAM, журналирование, резервные копии, контроль изменений и расследование инцидентов.
• Сильная сторона модели — возможность строить полностью закрытые или air-gapped-контуры, а также реализовывать zero trust без зависимости от внешнего интернета.

Для Oracle это обычно означает самостоятельную настройку TDE, PKI, Network Encryption, Database Vault, Audit Vault и связанной инфраструктуры. И здесь важно понимать: “данные у нас в ЦОДе” не гарантирует compliance. Регулятору нужен не только факт размещения, но и доказуемость контроля.

Cloud

• Работает shared responsibility model: провайдер отвечает за физический слой и значительную часть базовой инфраструктуры, а вы — за конфигурацию, права доступа, сетевые политики, секреты и защиту самих данных.
• Для OCI доступны compliance-рамки вроде FedRAMP и FIPS 140-2, а также сервисы WAF, KMS и другие встроенные механизмы защиты.

Практика: в одном из финтех-проектов мы построили схему с OCI Private Subnet и VPN-соединением в on-premise-контур. Audit logs стекались в Oracle Audit Vault, где команда получала унифицированный обзор событий по локальной и облачной части. Это хороший рабочий шаблон для гибридной архитектуры: главное не пытаться вести аудит “по отдельности”, иначе в момент инцидента вы получите два неполных мира вместо одной картины.

Риски cloud: основная проблема — misconfiguration. По данным Verizon DBIR 2026, около 90% утечек и компрометаций в облаке связаны именно с ошибками настройки. Не с уязвимостями гипервизора и не с “небезопасностью облака как класса”, а с банальными человеческими ошибками: открытые бакеты, слишком широкие IAM-права, неверно настроенные security lists, отключенное логирование.

Практичное решение — использовать OCI Landing Zones и аналогичные шаблоны, чтобы стандартизировать сетевую и IAM-архитектуру для enterprise. Это снижает риск конфигурационного дрейфа и особенно полезно там, где несколько команд параллельно создают ресурсы в одном облачном тенанте.

Миграция: пошаговый план с примерами Oracle

Миграция — это тот этап, на котором теория особенно быстро сталкивается с реальностью. По данным McKinsey, около 60% миграций проходят с серьезными отклонениями от плана. Обычно причина не в одном большом провале, а в сумме недооцененных факторов: зависимости приложений, сетевые ограничения, лицензирование, качество исходных данных, недотестированные batch-процессы и недооценка окна переключения.

Главное правило: не рубить с плеча. Хорошая миграция — это не “поднять виртуалку в облаке”, а пройти путь от инвентаризации до верифицированного cutover со сценарием отката.

Этапы

1. Assessment: Oracle Data Migration Assessment Tool (DMAT) помогает просканировать схемы, зависимости и спрогнозировать downtime. На этом этапе важно не только собрать факты, но и классифицировать нагрузки: OLTP, batch, интеграции, отчетность, архивы.
2. Lift-and-shift: Zero Downtime Migration (ZDM) для Oracle позволяет выполнять перенос с минимальным простоем, в том числе через physical transportable tablespaces. Это хороший путь, когда задача — быстро сменить площадку без немедленного изменения архитектуры приложения.
3. Refactor: переход на Autonomous DB оправдан, если организация готова принять модель сервиса с автоматическим тюнингом и меньшей ролью ручного DBA-администрирования. Это уже не просто миграция, а изменение эксплуатационной модели.
4. Test: synthetic load в OCI GoldenGate и смежных инструментах нужен не для “галочки”, а чтобы проверить поведение реальных сценариев под нагрузкой: интеграции, nightly jobs, закрытие периода, отчеты, failover и rollback.

Таблица миграций Oracle:

Кейс из практики: перенос Oracle EBS R12 в OCI занял 2 недели и был выполнен без потери данных. Но если смотреть на проект честно, “2 недели” — это только видимая часть. До этого была отдельная фаза подготовки: аудит кастомизаций, проверка интеграций, тестовые прогоны, согласование сетевой связности и проверка процедур восстановления. Именно эти шаги определяют успех, а не только выбранный инструмент миграции.

Самая частая ошибка при миграции Oracle — считать, что если база перенеслась корректно, то проект завершен. На практике критичнее всего ведут себя периферийные компоненты: scheduler jobs, файловые обмены, внешние ETL, старые JDBC-драйверы и латентность между приложением и БД.

Гибридные подходы: когда 1+1=3

В 2026 году hybrid — это уже не компромисс “пока не решили”, а зрелая архитектурная стратегия. По данным IDC, такой подход используют около 80% enterprise-компаний. Причина понятна: в реальной организации почти никогда не существует идеальных условий, чтобы все критичные системы одномоментно разместить либо только on-premise, либо только в public cloud.

Для Oracle особенно показателен вариант Exadata Cloud@Customer: физически железо находится on-premise, но управление и сервисная модель приближаются к облачной. Это хороший пример того, как enterprise-рынок фактически сам сформировал гибрид как рабочую норму.

Сценарии:

• Burst: on-premise остается primary-средой, а cloud используется как DR-контур или площадка для временного расширения мощности.
• Edge: Oracle Roving Edge подходит для отраслей вроде oil&gas, где вычисления и хранение нужны ближе к источнику данных, вплоть до мобильных сценариев “Oracle на truck”.
• Multi-cloud: сочетание OCI и Azure удобно там, где нужно одновременно поддерживать Oracle-нагрузки и тесную интеграцию с Microsoft stack.

Настройка: Oracle Interconnect позволяет организовать быстрый private link между средами. И это не просто удобство, а часто ключ к работоспособности гибридной схемы. Если связность построена “через интернет и надежду”, любой hybrid быстро превращается в постоянный источник сетевых инцидентов и деградаций.

Из практики внедрения гибридных схем: они дают максимальную пользу, когда роли площадок четко разделены. Например, транзакционный контур и чувствительные данные остаются on-premise, а аналитика, dev/test, интеграционный слой или резервный контур уходят в облако. Если же компания просто “размазывает” сервисы между двумя мирами без ясной модели ответственности, то получает удвоение сложности вместо выигрыша.

Когда выбрать что: матрица решений

• On-premise: regulated industry, фиксированная нагрузка на горизонте более 5 лет, критичная low latency, например HFT или другие сценарии, где предсказуемость важнее эластичности.
• Cloud: стартапы, переменный трафик, небольшая команда сопровождения, условно менее 10 DBA или инженеров платформы, когда особенно важны скорость запуска и управляемые сервисы.
• Hybrid: legacy Oracle-системы в сочетании с новыми microservices, поэтапная модернизация, DR в облаке, частичный перенос dev/test и аналитических контуров.

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

FAQ: быстрые ответы на частые вопросы

Стоит ли мигрировать Oracle в cloud в 2026?

Да, если ваш TCO в текущей модели выше хотя бы на 20% и команда сопровождения остается небольшой, например менее 5 человек. В таких условиях OCI выглядит особенно сильным вариантом благодаря нативной поддержке Oracle workloads. Но решение стоит принимать только после расчета сетевой модели, лицензирования и сценариев восстановления, иначе экономия на бумаге может исчезнуть уже в первый квартал эксплуатации.

Как избежать vendor lock-in?

Полностью избежать lock-in в enterprise почти невозможно, но его можно контролировать. Практически это означает: стандартизировать SQL на ANSI там, где это допустимо, выносить инфраструктурные описания в Terraform, не завязывать все интеграции на один проприетарный сервис и сохранять переносимость схем CI/CD. Чем выше доля platform-specific возможностей, тем дороже последующий выход.

Сколько стоит hybrid для 100TB Oracle?

Ориентир — около 3–5 млн руб./год в OCI плюс поддержка on-premise-контура. Но это только базовая рамка: итоговая стоимость очень сильно зависит от уровня резервирования, типа репликации, объема egress-трафика, требований к backup retention и лицензированию. Поэтому считайте через estimator и обязательно отдельно моделируйте DR-сценарии.

Как проверить производительность после миграции?

Используйте TPC-бенчмарки как отправную точку, но не ограничивайтесь ими. Для Oracle гораздо полезнее прогонять real workload replay через Oracle Real Application Testing, потому что он показывает поведение системы на реальном профиле запросов. Именно так чаще всего выявляются узкие места в сети, storage и конфигурации optimizer.

Безопасен ли cloud для ПДн?

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

Эта статья — отправная точка для взвешенного выбора между on-premise, cloud и hybrid-подходом. На реальных проектах побеждает не самая модная модель, а та, которая соответствует вашему профилю нагрузки, зрелости команды и требованиям бизнеса к надежности, скорости изменений и бюджету. Если разбирать тему глубже, то имеет смысл уже смотреть на конкретный стек: Oracle Database, middleware, контейнерную платформу, схему резервирования, лицензии и сетевую топологию. Именно на этом уровне обычно и принимаются правильные архитектурные решения.