Новые инструменты автоматизации инфраструктуры всегда служили одной цели — ускорения создание приложений, но это часто оборачивалось сложностями с управлением. Вивек Пандей, вице-президент по инженерным вопросам поставщика нативной облачной платформы «приложение как код» (AaC) Shipa, рассказывает на портале The New Stack о модели AppOps, которая позволяет разработчикам развертывать и одинаково управлять своими приложениями.
Когда-то установка нового сервера означала ожидание поставки физического оборудования, что могло занять несколько недель, а далее в течение еще нескольких дней приходилось настраивать и устанавливать ОС. Виртуальные машины (ВМ) стали позволять запускать серверы за считанные минуты, что способствовало повышению эффективности. Затем появились такие инструменты, как Ansible, Puppet и Chef, предназначенные для автоматизации инфраструктуры. Появление облачных вычислений впоследствии потребовало нового поколения инфраструктурных инструментов, таких как Terraform и Docker. Совсем недавно переход к микросервисам и Kubernetes стимулировал появление таких инструментов, как Crossplane и Pulumi. На каждом этапе этой непрерывной эволюции новые инструменты автоматизации инфраструктуры служили одной конечной цели: ускорить процесс создания приложений.
Но одной из самых больших проблем для разработчиков в настоящее время является отнимающая много времени сложность автоматизации развертывания приложений на нескольких инфраструктурных платформах и связанных с ними инструментах. В то время как новые, «рожденные» в облаке компании используют облачные технологии и рабочие процессы с самого начала, большинство уже существующих компаний все еще далеки от полной трансформации и внедрения таких передовых подходов, как Kubernetes или GitOps. Вместо этого большинство по-прежнему задействует для запуска приложений локальные или облачные ВМ. Это требует от разработчиков развертывания приложений для работы с несколькими конвейерами непрерывной интеграции (CI) и множеством Terraform или пользовательских скриптов. Поддержка приложений после развертывания не менее сложна.
Сложность и недостаточный контроль приложений замедляют скорость разработки, ограничивают их поддержку и приводят к трениям между командами разработчиков и ИТ-операций. По мере развития среды организации — увеличения количества команд разработчиков и приложений — проблемы нарастают как снежный ком, и их решение становится все более сложным.
Новая перспектива: фокусировка на уровне приложений
Обычно организации фокусируются на плоскостях управления, которые автоматизируют обеспечение инфраструктуры и сервисов, а команды DevOps адаптируют инструменты автоматизации для развертывания приложений. Например, организациям, внедряющим Kubernetes и GitOps, необходимо создавать новые конвейеры, средства контроля безопасности и т. д. Эти усилия быстро приводят к разрастанию инструментария, разобщенности в средствах управления приложениями и разногласиям между разработчиками с их платформами и командами DevOps.
Чтобы справиться с этой проблемой, многие организации бросают на нее большие ресурсы, а именно дополнительные дорогостоящие инструменты и расширенный штат сотрудников. Ярким примером является создание внутренних платформ для разработчиков (internal developer platforms, IDP). Замысел IDP состоит в том, чтобы абстрагировать инфраструктуру и дать разработчикам возможность быстрее выпускать и поддерживать приложения. Однако на практике дашборд разработчиков не решает сложных задач и не обеспечивает основную бизнес-ценность для клиентов. После многих лет инвестиций IDP часто остаются невостребованными, не обеспечивают достаточный уровень безопасности или простаивают по другим причинам.
Лучший подход — сосредоточиться на уровне самих приложений, для чего требуется построить общую операционную модель приложений.
Модель AppOps позволяет разработчикам развертывать и управлять своими приложениями одинаково, независимо от плоскости управления (будь то Kubernetes, ВМ и т. д.) и поддерживает их проекты и конвейеры. Таким образом, DevOps может менять плоскости управления по мере необходимости без какого-либо влияния на деятельность разработчиков. Организации получают возможность подключить любую платформу из существующего стека к операционной модели приложения, превратив ее в стандартизированное решение.
DevOps с помощью этого централизованного уровня управления может определять безопасность и средства контроля, автоматически применяя их в каждом развернутом приложении и снимая это бремя с разработчиков. Наконец, общая модель управления приложениями должна использовать доступную инфраструктуру для автоматического создания всех ресурсов, необходимых приложениям.
AppOps — новая категория управления инфраструктурой
AppOps — автоматизированная инфраструктура и уровень приложений для ускорения разработки приложений. Ее следует рассматривать как категорию, а не как отдельный инструмент. Подобно волнам автоматизации, возникшим с появлением ВМ, облачных вычислений и микросервисов, AppOps может стать катализатором новых преобразующих решений. Примыкая к CI, управлению производительностью приложений, безопасности приложений и другим категориям, AppOps должна обеспечить скорость, безопасность и контроль в единой операционной модели, призванной стимулировать разработку приложений.
О возможностях AppOps говорит прогноз о том, что благодаря ей Kubernetes превратится в прозрачный инструмент, который больше не будет обременять разработчиков своей сложностью. Разработчикам, занимающимся развертыванием, управлением, поддержкой и защитой приложений, AppOps позволяет абстрагироваться от базовой инфраструктуры, конвейера CI и плоскости управления, сделав их невидимыми. По мере развития такого подхода AppOps обещает устранить основные инфраструктурные отвлекающие факторы, которые ограничивают производительность разработчиков, дав им возможность полностью сосредоточиться на разработке, к чему давно стремится отрасль.
