Развитие разработки облачных микросервисов

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

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

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

Развитие культуры, ориентированной на развертывание

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

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

- «Завершение историй»

- «Будьте в курсе последних обновлений технологического стека»

- «Обеспечение соответствия компонентов стандартам безопасности»

- «Написание детальных тестов»

Большинство предоставленных ответов демонстрируют приверженность этому процессу, и это хорошо. Однако какова цель? Целью SDLC является создание программного обеспечения и его развертывание. Будь то внутреннее приложение или приложение SaaS, развертывание программного обеспечения помогает организации достичь цели. Услышав заявление о том, что целью SDLC является поставка и развертывание программного обеспечения, практически любой, кто участвует в этом процессе, скажет: «Ну, конечно, это так». Команды часто упускают из виду эту «очевидную» директиву, поскольку она далека от реального процесса развертывания. Стратегические инвестиции в этот процесс могут закрыть этот разрыв.

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

Различные команды SDLC могут относиться к «Kubernetes Everywhere» со скептицизмом. Работа, проделанная над Kubernetes по уменьшению занимаемой площади для таких систем, как периферийные устройства, сделала запуск Kubernetes на рабочей станции очень управляемым. Знакомство команд с Kubernetes посредством автоматизации позволяет им итеративно осваивать платформу. Самое главное — создать культуру, ориентированную на развертывание .

Планируйте артефакты развертывания

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

Процесс сборки

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

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

Для новых проектов начните с разработки процесса сборки рабочей станции. Затем процесс сборки можно добавить в конвейер CI/CD. Процессы локальной сборки и сборки CI/CD должны стремиться к совместному использованию как можно большего количества кода. Это позволит всей команде быть в курсе того, как создается и развертывается приложение.

Создание артефактов

Основными результатами процесса сборки являются артефакты сборки. Для облачных приложений сюда входят образы контейнеров (например, образы Docker) и пакеты развертывания (например, диаграммы Helm). Когда инженер выполняет процесс сборки на своей рабочей станции, артефакты, скорее всего, потребуется опубликовать в репозитории, например в реестре контейнеров или репозитории диаграмм.

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

Параметризация

Центральным моментом всего этого процесса является то, что ключевые компоненты определения процесса сборки и развертывания не могут быть дублированы в зависимости от среды выполнения. Например, если образ контейнера создается и публикуется одним способом на локальной рабочей станции, а другим — в конвейере CI/CD. Через сколько времени они разойдутся?

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

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

Рисунок 1. Кластер местного развития

Разработка облачных микросервисов в действии

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

Облегчение процесса разработки командам разработчиков

Изменение культуры заключается в привлечении команд к принятию нового способа выполнения чего-либо. Следующий шаг – исполнение. Сдвиг влево требует, чтобы инженеры-программисты перешли от проектирования и написания кода приложения к тому, чтобы стать неотъемлемой частью проектирования и реализации всего процесса сборки и развертывания. Это означает изучение новых инструментов и изучение областей, в которых у них может не быть большого опыта. Человеческая природа склонна сопротивляться переменам. Инженеры-программисты могут посмотреть на весь этот процесс и подумать: «Как я могу освоить этот новый процесс и эти новые инструменты, пытаясь при этом соблюдать график?» Это правильный вопрос. Однако инженеры-программисты, как правило, не против внедрения нового инструмента или процесса разработки, который поможет им и команде, не нарушая радикально их повседневную жизнь.

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

Контейнеры разработки

Спецификация Development Containers — это относительно новое достижение, основанное на существующей концепции поддержки сред разработки. Многие команды инженеров используют системы инфраструктуры виртуальных рабочих столов (VDI), в которых рабочая станция разработчика размещается в виртуализированной инфраструктуре. Компаниям, внедряющим среды VDI, нравится централизованное управление средами, а разработчикам программного обеспечения нравится идея предварительно упакованной среды, содержащей все компоненты, необходимые для разработки, отладки и создания приложения.

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

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

Рисунок 2. Контейнер разработки микросервисов, настроенный с помощью контейнеров разработки.

Синергетическая эволюция облачной разработки продолжается

Существует синергия между левым сдвигом, разработкой облачных технологий и микросервисов. Они представляют собой образец разработки приложений, который может быть принят командами любого размера. Инструментарий продолжает развиваться, делая практическое использование технологий, используемых в облачных средах, доступным для всех, кто участвует в процессе доставки приложений. Это изменение культуры, которое влечет за собой изменение мышления при изучении новых процессов и технологий. Важно, чтобы команды не были обременены набором ручных процессов, из-за которых они чувствуют, что их продуктивность теряется. Автоматизация помогает командам легко освоить шаблоны и технологии.

Как и при любых других организационных изменениях, по мнению разработчиков DST Global,важно предварительное планирование и подготовка. Не менее важно вовлечение команд в план. Когда люди имеют право голоса в изменении, владение и усыновление становятся естественным результатом.