Методология AppOps (операции с приложениями) стандартизирует развертывание и управление приложениями независимо от плоскости управления, полностью отделяя нюансы конкретной инфраструктуры от приложений, утверждает на портале TechBeacon Рави Лахман, технический директор поставщика нативной облачной платформы «приложение как код» Shipa.

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

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

Полноценное внедрение Kubernetes и GitOps — это долгосрочные цели дорожной карты для последних. Тем временем, развертывание приложений на различных технологиях означает, что разработчикам приходится работать с несколькими конвейерами CI/CD, а также с таким же количеством манифестов Kubernetes и конфигураций инфраструктуры как кода (infrastructure-as-code, IaC). Не менее сложной задачей является поддержка приложений после развертывания.

Для разработчиков последствия всей этой сложности и ограниченного контроля приложений проявляются по нескольким направлениям. Скорость разработки замедляется. Страдают возможности поддержки приложений. Разработчики и операционные команды испытывают повышенное трение. Эти проблемы и сложности только усугубляются по мере расширения групп разработчиков, приложений и сред.

Бесконечное добавление инструментов и инвестирование в ресурсы ведет к неустойчивости

Организации часто пытаются идти в ногу с растущей сложностью среды приложений, добавляя новые дорогостоящие инструменты автоматизации и привлекая еще более дорогостоящий персонал. По мере того, как компании продолжают автоматизировать инфраструктуру и предоставление услуг с помощью таких технологий, как Kubernetes и GitOps, команды DevOps внедряют новые конвейеры и средства контроля безопасности для поддержки этих платформ. Однако подобное увеличение числа конвейеров приводит к тому, что разработчики сталкиваются с еще большим количеством разрозненных инструментов и средств управления приложениями, а также испытывают еще большее недовольство по поводу того, что платформы DevOps увеличивают накладные расходы на процесс разработки.

Дорогостоящие и бесплодные попытки организаций управлять сложными конвейерами лучше всего иллюстрируют внутренние платформы разработчиков (internal developer platforms, IDP). В теории IDP абстрагируют управление инфраструктурой и ускоряют доставку и поддержку приложений. Но, как выясняется, IDP не могут кардинально уменьшить растущую сложность, с которой сталкиваются разработчики. Основной их недостаток заключается в том, что это в основном нестандартные решения, они негибкие и их трудно привести в соответствие с отраслевыми стандартами, такими как канареечное развертывание.

Типичная IDP также ориентирована на цели на уровне управления, например, заполнения внутренних тикетов, которые на самом деле увеличивают накладные расходы разработчиков, а не оптимизируют их работу. В то же время, IDP пытаются помочь организациям предложить своим клиентам какую-либо прямую и очевидную бизнес-ценность. По этим причинам они могут стать заброшенными проектами, зачастую из-за многолетних периодических простоев, пробелов в безопасности, огромных расходов и разочарования разработчиков.

AppOps: другой вариант развития

Использование модели AppOps, которая стандартизирует развертывание и управление приложениями независимо от плоскости управления, помогает обеспечить эффективность разработчиков, к которой стремятся организации. Благодаря AppOps, DevOps может использовать любую плоскость управления, от виртуальных машин до Kubernetes и далее, а разработчики могут продолжать свою деятельность, то есть действовать без оглядки на инфраструктуру.

Полностью отделяя нюансы конкретной инфраструктуры от приложений, AppOps обеспечивает абстрагирование на уровне приложений, которого не может достичь ни одна IDP. Например, разработчики, поддерживаемые AppOps, могут плавно перевести приложение с виртуальных машин на Kubernetes, не сталкиваясь со сложным списком манифестов и объектов Kubernetes, с которыми пришлось бы разбираться разработчикам, использующим IDP.

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

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

Примеры конвейеров приложений, оптимизированных с помощью AppOps. Источник: Shipa

Потенциал AppOps

Перспективы AppOps заключаются в том, что конкретная инфраструктура, конвейер CI и плоскость управления, на которых создаются приложения, становятся неважными, по крайней мере, с точки зрения разработчика. Таким образом, AppOps делает исчезновение слоя Kubernetes, предсказанное некоторыми рыночными наблюдателями, вполне правдоподобным. Как ожидается, зрелый AppOps увеличит темпы разработки и, наконец, выполнит обещание автоматизации полностью убрать инфраструктуру с глаз долой и из головы разработчиков.