Мифы вокруг ПАК: что мешает технологической независимости

В эпоху цифровой трансформации программно-аппаратные комплексы (ПАК) становятся неотъемлемой частью ИТ-инфраструктуры современных предприятий. Известно, что ПАК — это передовая архитектура, которая широко и успешно применяется в мире: за счет глубокой интеграции программной и аппаратной частей такие решения обеспечивают высокую производительность, предсказуемость работы и управляемость, что напрямую влияет на экономику ИТ — снижает совокупную стоимость владения, ускоряет вывод сервисов в продуктив и повышает отдачу от инфраструктурных инвестиций. Тем не менее вокруг ПАК сложилось множество мифов, вера в которые может приводить к неверным управленческим решениям и тормозить путь к технологической независимости. В этой статье Михаил Гилязов, директор по развитию бизнеса Скала^р (Группа Rubytech), разбирает основные заблуждения и рассказывает, как обстоят дела на самом деле.

Миф 1. ПАК — это просто сервер в красивой коробке

Путаница возникает из-за определения, что такое ПАК. Здесь нужно четко разделять, имеется в виду специализированное программно-аппаратное решение или полноценный ПАК. В первом случае — это, действительно, один сервер с предустановленным ПО. Он предназначен для узких, строго сегментированных задач, чаще всего в сфере информационной безопасности (например, NGFW от Positive Technologies или от "Континент").

Полноценный же ПАК — это инженерно спроектированная инфраструктурная платформа, в которой вычислительные узлы, системы хранения, сетевая фабрика, средства виртуализации, управления и мониторинга подобраны, настроены и протестированы как единое целое. Именно такая инженерия дает предсказуемую производительность, отказоустойчивость и единый цикл поддержки — то, что невозможно получить, просто собрав стойку из компонентов разных вендоров.

За счёт этого ПАК закрывает широкий спектр общеинфраструктурных задач, таких как: платформа для построение частных и гибридных облаков, виртуализация серверов и рабочих мест (VDI), работа высоконагруженных СУБД и платформ обработки данных, контейнерные среды, системы резервного копирования и катастрофоустойчивости, платформы для аналитики, ИИ и машинного обучения, а также консолидация критичных бизнес-приложений уровня ERP и биллинга. По сути, ПАК становится фундаментом, на котором предприятие строит и развивает свои цифровые сервисы.

Пока жёсткого ГОСТа на этот класс решений нет, но отрасль уже пришла к общему пониманию: ПАК — это сложная инфраструктурная платформа, а не "сервер в красивой коробке" и не набор железа со скриптами поверх.

Миф 2. Проекты с использованием ПАК — это долго и сложно

Внедрение ПАК само по себе не может быть целью проекта, и выполняется в рамках решения какой-то задачи. Обычно цель проекта — это построение, обновление или перенос инфраструктуры, запуск продуктивной информационной системы(систем), например, банковской или корпоративной. Независимо от того, какие методы выбраны, решение любой задачи потребует времени на проектирование, закупку и внедрение программного и аппаратного обеспечения в имеющуюся инфраструктуру.

И здесь использование ПАК сокращает сроки по сравнению с другими путями реализации проекта. Вы не тратите время на поиск, проверку совместимости компонентов и подбор интеграторов. ПАК поставляется и работает "из коробки". Это экономит время на всех трех этапах, тогда как самостоятельная сборка обычно растягивает процесс.

Миф 3. ПАК — это дорого

Корректно сравнивать совокупную стоимость владения (TCO), а не только начальные инвестиции. Как показывает практика, в перспективе 3–5 лет ПАК оказывается выгоднее других решений. В стоимость ПАК уже включены техническая поддержка, обновления и гарантийное обслуживание. Существенная экономия достигается за счет отсутствия затрат на интеграцию компонентов и снижения рисков простоя из-за проблем совместимости.

Даже если сравнивать цену "на входе", то ПАК нередко может оказаться выгоднее покупки отдельных решений и самостоятельной сборки. К примеру, практически весь набор составляющих, который используется в ПАК Скала^р — это линейные компоненты, доступные на открытом рынке. При сравнении стоимость оказывается вполне сопоставимой.

Именно поэтому крупные корпорации покупают готовые ПАК. Не потому, что не могут сделать сами, а потому что делать самим — это дорого. Заплатить вендору ПАК за долю его R&D и поддержку выгоднее, чем полностью финансировать разработку за свой счет. Заказчик ПАК разделяет затраты на разработку и сопровождение с другими покупателями — это заложено в стоимость не одного, а десятков и сотен комплексов, которые приобретают разные компании. Если же пытаться собрать все самостоятельно, вы несете все издержки целиком: и исследовательские, и операционные, и на поддержку жизненного цикла.

Миф 4. Отечественные ПАК не тянут критичные нагрузки старых систем на Oracle/IBM

Наша практика показывает, что при правильном подходе к проектированию на текущий момент практически нет задач и ситуаций, когда нельзя было бы перестроить инфраструктуру так, чтобы она выполняла задачу с нужным уровнем критичности и производительности. Конечно, нельзя вытащить полстойки Oracle Exadata и просто поставить вместо нее такую же по объему отечественную сборку — это невозможно. Но если переосмыслить задачу и правильно подобрать решение, то результат превосходит ожидания.

ПАК Oracle соединяет в себе три типа нагрузки: транзакционную, аналитическую, гибридную. Соответственно, есть возможность правильно скомбинировать отечественные ПАК и сделать архитектурное проектирование. Тогда эти задачи можно решить даже с большей эффективностью. Яркий пример — перевод АБС Газпромбанка с импортного технологического стека на отечественные ПАК Скала^р. Скорость подготовки отчетности (в том числе годовой) выросла более чем в три раза. Производительность не просто не упала — она кратно выросла.

Полный текст читайте на сайте ComNews.ru