Анирудх Раманатан, технический директор Signadot, рассказывает на портале The New Stack, почему фрагментация убивает опыт разработчиков (DevEx) и — что еще важнее — как это исправить.

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

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

Это и есть проблема микросервисных сред: фрагментация по умолчанию.

Как мы к этому пришли

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

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

Это противоречие между сложностью, скоростью и реалистичностью сформировало ту разросшуюся среду, с которой мы живем сегодня:

  • CI слишком медленный? Добавьте моки.
  • Стейджинговая среда слишком неустойчивая? Сделайте более легкую.
  • Девы заблокированы на локальном уровне? Взломайте его с помощью скриптов и заглушек.

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

Почему это начинает причинять боль

Фрагментированные среды создают трения повсюду:

  • Баги выявляются поздно или только на стадии стейджинга.
  • Тесты проходят в CI, но проваливаются в продакшене.
  • Локальные среды разработчиков становятся медленными и ненадежными.

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

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

Хорошие новости: уровень инфраструктуры вырос

Вот что отличает этот момент: мы больше не застреваем.

Kubernetes предоставляет общую платформу оркестрации, а сервисные сетки, такие как Istio и Linkerd, добавляют недостающий элемент: тонкий контроль трафика на уровне запросов. Эти инструменты позволяют разработчикам запускать несколько изолированных версий сервисов в одном общем кластере без конфликтов.

Это означает, что вы можете:

  • Маршрутизировать трафик по запросам, а не только по сервисам.
  • Развертывать изолированные версии микросервисов без репликации всего стека.
  • Безопасно использовать общую среду для разработки, тестирования, стейджинга и проверки.
  • Быстро развернуть и свернуть эфемерные среды с высокой степенью достоверности.

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

Строительные блоки уже есть. Теперь дело за тем, чтобы сшить их вместе правильным образом

Лучший путь вперед

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

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

Признаки перемен

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

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