Анита Ихуман, специалист по работе с разработчиками компании MetalBear, рассказывает на портале The New Stack о ключевых компромиссах между локальными, персональными удаленными и совместными облачными средами разработки.

По мере того как команды разработчиков переходят к созданию нативных облачных приложений, потребность в оптимизированных рабочих процессах разработки резко возрастает. Согласно Statista, в 2022 г. 93% организаций работали преимущественно в облаке. Но вот в чем загвоздка: переход к нативной облачной разработке с ее лабиринтом распределенных контейнеров и микросервисов — это не так уж радужно. Этот переход порождает новые проблемы: необходимо отыскать баланс между масштабируемостью, гибкостью и удобством для разработчиков.

Разработчики часто чувствуют себя перегруженными, жонглируя многочисленными интерфейсами, логикой и рабочими процессами. Чтобы по-настоящему использовать возможности нативного облака, организациям нужна не только облачная инфраструктура, но и рабочий процесс разработки, который будет работать на них и соответствовать их потребностям. Это означает инвестирование в правильные инструменты, построение продуманных процессов и создание надежных систем, которые облегчают жизнь командам разработчиков.

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

Что такое эргономика разработки в облаке?

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

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

Оптимизация эргономики облачной разработки — это минимизация операционных издержек и предоставление разработчикам возможности взаимодействовать с облачными ресурсами так же легко, как и с локальными средами. Это означает:

  1. Легкая настройка среды. Разработчики должны иметь возможность приступить к написанию кода без сложного конфигурирования и длительных процессов настройки. Непринужденная настройка позволяет уделять больше внимания разработке, а не инструментарию.
  2. Реалистичные тестовые среды. Надежное тестирование требует доступа к производственно-подобным средам, включая базы данных и файловые системы, без необходимости их ручного создания и обслуживания.
  3. Сотрудничество с другими разработчиками. Независимо от того, работают ли разработчики в одном офисе или в разных часовых поясах, им нужны интуитивно понятные способы обмена кодом, просмотра изменений и выполнения тестов в режиме реального времени.
  4. Эффективные отладка и тестирование. Современные облачные архитектуры отличаются сложностью. Разработчики должны иметь доступ к инструментам, которые позволят им быстро устранять неполадки и исправлять проблемы даже в сложных облачных системах.

Сравнение рабочих процессов разработки

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

  • Только локальная разработка. Разработчики работают на своих локальных машинах с установленными инструментами, приложениями и зависимостями. Часто используются такие инструменты, как Skaffold, Tilt или Docker Compose.
  • Удаленные персональные среды. Разработчики могут получать доступ к персональным, постоянным или эфемерным облачным средам. Такие инструменты, как Okteto, Release и Bunnyshell, помогают настроить эти среды.
  • Удаленная общая среда. При таком подходе разработчики совместно работают в общей производственной среде, которая содержит все ресурсы (сторонние сервисы, базы данных, микросервисы) вашего приложения в идеальном тестовом окружении. В эту категорию попадают такие инструменты, как Telepresence, CodeZero и mirrord.
Только локальная разработка Удаленные персональные среды разработки Удаленные общие среды разработки
Расположение среды Локальные машины Облачная среда, изолированная для каждого разработчика Локальная машина с доступом к общей облачной среде
Согласованность Подвержена несогласованности из-за дрейфа зависимостей и несоответствия локальных настроек Изолирована с высокой вероятностью дрейфа конфигурации между средами Высокая согласованность между командами
Распределение вычислений Высокое потребление локальных ресурсов Ресурсы выделяются по требованию для каждого разработчика Общие облачные ресурсы
Скорость итераций Быстрые итерации, но зависящие от производительности и конфигурации локальной машины Медленнее из-за полного запуска среды Быстрее, общий доступ к живым сервисам
Адаптация и доступ Простая, привычная настройка Крутая кривая обучения при независимом доступе Минимальная настройка, общий доступ

Какой подход подойдет вашей организации

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

Размер команды

Локальная разработка — практичный выбор для небольших команд (1-10 разработчиков), работающих над легкими приложениями, благодаря своей простоте и низкой стоимости. Однако по мере расширения команды поддерживать совместную работу и согласованную среду становится все сложнее. Для средних команд (10-50 разработчиков), занимающихся более сложными проектами или нуждающихся в доступе к специализированным ресурсам, сбалансированным решением являются удаленные персональные среды.

В свою очередь, удаленные общие среды лучше подходят для больших команд (50+ разработчиков), управляющих сложными инфраструктурами или выполняющих ресурсоемкие сборки и тесты. Такие системы позволяют автоматически масштабироваться для работы с различными рабочими нагрузками без дополнительных инвестиций в оборудование.

Бюджет

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

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

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

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

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

Поиск компромиссов в облачной разработке

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

  • Опыт сложной разработки. Традиционная локальная разработка часто требует от разработчиков моделирования или имитации сложных управляемых сервисов, что приводит к несоответствиям и ненадежным результатам. С помощью удаленной разделяемой среды разработчики могут взаимодействовать с реальной службой в производственной среде, обеспечивая бóльшую согласованность и надежность без создания громоздких локальных копий.
  • Потребление ресурсов. Локальные среды разработки требуют значительных вычислительных мощностей, они нагружают оборудование и пропускную способность сети. Удаленные персональные среды переносят это бремя в облако, но часто требуют полноценных конфигураций для каждого разработчика. Удаленные общие среды оптимизируют использование ресурсов, сохраняя переменные окружения и базы данных в удаленной среде, запуская локально только необходимую часть, что снижает накладные расходы на инфраструктуру и снимает ограничения локальных машин.
  • Совместная работа. Удаленные персональные среды изолируют каждого разработчика, ограничивая совместную работу в режиме реального времени. Удаленная совместная разработка позволяет нескольким разработчикам одновременно работать над одним и тем же облачным сервисом, сохраняя при этом раздельное взаимодействие. Разработчики также могут подключаться к разным удаленным подам для выполнения параллельных задач, что повышает эффективность рабочего процесса без сбоев в работе.
  • Итерационные циклы. Настройка среды разработки или контекстное переключение задач в удаленной персональной среде — это трудоемкий процесс, который часто приводит к задержкам и неэффективности рабочего процесса. Исследование, проведенное в 2023 г. компанией TideLift, показало, что более 50% времени разработчиков уходит на обслуживание, сложную настройку и операционные задачи. В то же время в удаленной разделяемой среде запуск занимает около 15 секунд, поэтому разработчики не тратят время на ожидание выполнения цикла «нажать-дождаться-увидеть», как при использовании интерфейса командной строки (CLI), так и расширений IDE.
  • Затраты на облако. Использование облачных инфраструктур и ресурсов может потребовать значительных затрат. Организации, использующие удаленные персональные среды, сталкиваются с существенными расходами, поскольку они инвестируют в кластеры Kubernetes и создают отдельные среды для каждого члена команды. Однако при использовании удаленных общих сред разработчики и организации могут пользоваться общими средами и платить меньше облачным провайдерам.
  • Безопасность. Облачные разработки часто сопряжены с проблемами с безопасностью, особенно если речь идет о конфиденциальных данных. Чтобы решить эти проблемы, организации могут использовать гибридный подход, при котором разработчики работают локально, но получают безопасный доступ к ресурсам кластера с помощью политик. Это гарантирует, что команды будут иметь разрешение на взаимодействие только с определенными частями рабочего процесса.

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