Signadot спонсировал этот пост.
«Мы теряем около полумиллиона долларов ежемесячно из -за нашего сломанного процесса тестирования». Это отрезвляющее заявление было получено из вице -президента по проектированию платформы во время недавней дискуссии об их проблемах тестирования микросервисов. Что сделало это особенно касающимся, так это то, что это не было оценкой — это было результатом тщательного измерения.
Их организация выросла до более чем 200 разработчиков, работающих на десятках микросервисов, каждый инженер представляет в среднем 15 запросов на притяжение ежемесячно. То, что казалось на поверхности как процветающая инженерная организация, было сокрыть значительную утечку производительности: их интеграционные тестирование было полностью отключено от процесса обзора PR.
«Наши разработчики на самом деле не ждут интеграционных тестов перед слиянием», — пояснил вице -президент. «Они запускают базовые модульные тесты, получают одобрение и слияние проверки кода. Тогда начинаются реальные проблемы ».
Их интеграция после Merge и сквозные тестирование часто выявлялись проблемы, которые не были пойманы модульными тестами. Когда произошли сбои — что происходило регулярно — инженеры должны были переключаться к коду, из которого они умственно перешли, диагностируют сложные задачи интеграции и снова запустили весь PR -цикл.
«Каждый цикл отладки может потреблять от одного до двух часов целенаправленного инженерного времени»,-продолжил вице-президент. «Поскольку инженеры регулярно попадают в эти сбои интеграции, мы наблюдаем около 20 часов на одного разработчика в месяц, потерянных в этом фрагментированном рабочем процессе».
Математика была отрезвляющей: 200 инженеров × 20 часов теряются ежемесячно × 100 долларов в час = 400 000 долларов в виде инженерной производительности, исчезая каждый месяц.
Когда я предложил традиционное решение, чтобы раскрутить больше средств, чтобы облегчить узкое место, вице -президент покачал головой. «Мы неоднократно запускаем эти цифры. Затраты на инфраструктуру для дублирующих средств будут подходить к нашим текущим потерям, без решения фундаментальной проблемы ».
Этот разговор олицетворяет дилемму, которую создали современные архитектуры микросервиса для инженерных команд. Организации применяют микросервисы для масштабируемости и автономии команды, только чтобы оказаться в клиентах между затратами на монтаж инфраструктуры и снижением производительности разработчиков.
Внутренняя петля против внешней петли
Чтобы понять, почему эта проблема настолько распространена, мы должны изучить, что инженеры называют «внутренней петлей» и «внешней петлей» разработки.
Внутренний цикл — написание кода, выполнение модульных тестов и внесение локальных изменений — обычно быстро. Инженеры получают немедленную обратную связь за считанные минуты. Этот быстрый цикл — это то, где разработчики процветают, поддерживая состояние потока и высокую производительность.
Но с микросервисами внешний цикл — интеграция изменений с другими службами, выполнение полных системных тестов и развертывания — становится резко медленнее, часто в 10 раз или более.
Давайте разберемся, почему эта внешняя петля становится убийцей производительности:
Совокупное воздействие ошеломляет. Типичный цикл отладки FIX-тестирования во внешней петле может потреблять от двух до трех часов по сравнению с двумя-три минуты во внутренней петле. Поскольку инженеры несколько раз еженедельно попадают в эти циклы, компании обычно теряют восемь -10 часов на разработчика в неделю на этот фрагментированный рабочий процесс.
Традиционные подходы не масштабируются
Почему мы не можем решить это с большим количеством среды? Обычный подход «Система в коробке», где каждый разработчик разжигает всю систему в своем собственном изолированном облачном экземпляре, быстро становится чрезмерно дорогим в масштабе.
Давайте сделаем математику:
Для системы с 50 микросервисами разработчику нужен экземпляр AWS EC2 M6A.8Xlarge (32 VCPU, 128 GIB Memory), который стоит приблизительно 1,30 долл. В час. Управление этим 24/7 за месяц стоит 936 долларов, или 11 232 долл. сша в год для одной среды разработчика. Чтобы предоставить выделенную среду для команды из 50 разработчиков, ежегодные затраты на 561 600 долларов сша — и это просто для вычисления, не включая хранение, передачу данных или управляемые услуги.
Вот почему многие команды соглашаются на ограниченное количество общих сред, создавая узкие места и производительность.
Современный подход: Основанная на аренде Среда
Песочники, инкапсулирующие локальные и GIT, версии услуг.
Современные архитектуры сетки обслуживания меняют это уравнение:
Вместо дублирования инфраструктуры вы можете создавать среды мгновенного тестирования, изолируя на уровне запроса, используя технологию сервисной сетки. Каждый разработчик получает свою собственную песочницу через интеллектуальную маршрутизацию запросов.
Вот где трансформация становится количественной:
- Затраты на инфраструктуру: Снижение на 90% по сравнению с дублирующими средами, что делает его экономически возможной для предоставления изолированных тестирования для каждого PR
- Тестирование масштаб: От селективного тестирования (из -за ограничений ресурсов) до комплексного тестирования для каждого изменения кода
- Скорость интеграционного тестирования: От пост-Мерж (часы) до предварительного получения (минуты)
- Итерации разработчика: От одного или двух в день до 10 до 15 в день
- Среднее время для разрешения: От двух до трех часов до 15 до 20 минут
- Скорость побега дефекта: Снижено на 70% (проблемы до слияния)
Наиболее драматичное влияние наносит значительное снижение стоимости эфемерных сред. Когда тестирование становится доступным в масштабе, организации могут перейти от нормирования ресурсов тестирования к предоставлению среде по требованию для каждого запроса на привлечение. Эта демократизация тестирования трансформирует как производительность разработчиков, так и качество программного обеспечения, не нарушая бюджет инфраструктуры.
Ответ вице -президента: «Значит, мы можем дать каждому разработчику мгновенные среды и снизить затраты?»
Да, точно!
Как это работает?
Ключевым пониманием является то, что дублирование полной среды не нужна для тестирования микросервисов. Благодаря изоляции приложений и маршрутизации интеллектуальных запросов вы можете поделиться базовой инфраструктурой при сохранении изоляции.
Когда разработчик хочет проверить изменение, система создает песочницу, которая включает в себя модифицированные только услуги. Запросы динамически направляются на эти услуги на песочке на основе заголовков запросов, используя общую среду для всего остального.
Решение проблемы изоляции данных
Одним из важнейших аспектов этого подхода является то, как обрабатывать изоляцию данных. Когда инженеры впервые услышат о маршрутизации на основе запросов, они сразу же выражают обеспокоенность по поводу уровня данных: «Если мы делимся инфраструктурой, не будут одновременно не мешать данным друг друга?»
Это достоверная проблема с несколькими решениями в зависимости от требований к тестированию:
Для большинства сценариев тестирования общие базы данных работают удивительно хорошо. Ключ — это использование моделей множества, которые часто уже встроены в архитектуры микросервиса. Благодаря разделению тестовых данных с использованием существующих идентификаторов модели домена (userId, Orgid, TenantId), каждый тест может работать в своем собственном логическом пространстве в общей базе данных.
Для более интенсивных потребностей в тестировании, таких как миграция схемы или операции по производству данных, временные экземпляры базы данных могут быть предоставлены по требованию. Эти эфемерные базы данных раскачиваются только при необходимости и заканчиваются при завершении тестирования, обеспечивая полную изоляцию без накладных расходов поддержания постоянной дубликатной инфраструктуры.
Наиболее сложные системы предлагают гибридный подход, автоматически определяющий, когда общие ресурсы достаточны и когда требуются изолированные ресурсы. Это дает разработчикам лучшее из обоих миров: скорость и эффективность общих ресурсов с безопасностью изоляции при необходимости.
Проверено в производстве
Этот подход не только теоретический; Это уже дает результаты в масштабе. Ведущие технологические компании внедрили вариации этой модели с впечатляющими результатами:
- Uber построил Slate для маршрутизации тестового трафика на основе запросов.
- Lyft создал плоскость управления для своей общей среды разработки.
- Airbnb внедрила маршрутизацию запросов, которая значительно снизила затраты на тестирование.
Эти организации используют облачные нативные технологии и возможности сервисной сетки для преобразования тестирования без дублирования инфраструктуры. Наиболее продвинутые реализации используют инфраструктуру в качестве кода (IAC) для предоставления эфемерных средах за считанные минуты — не только для тестирования, но и для прототипирования и экспериментальной разработки.
Влияние на бизнес измеряется как с помощью технических показателей (например, DORA Framework), так и разработчиков. Компании, как правило, видят более быстрое время на рынке, более качественные выпуски и значительно снижают затраты на инфраструктуру, обеспечивая редкую комбинацию лучшей, более низкой и более дешевой разработки программного обеспечения.
От узкого места до прорыва
Традиционный подход к тестированию интеграции пост-Мерге создает ненужное узкое место в разработке микросервисов. Смечая слева интеграционные тесты — перемещая их от медленной внешней петли в быстрый внутренний цикл — организации могут фундаментально изменить свой процесс разработки.
Инженеры проверяют изменения в отношении реальных зависимостей перед слиянием, выявляя проблемы с интеграцией, когда они все еще свежи и недорого, чтобы исправить. Современные нативные технологии облака, такие как сетки услуг и маршрутизацию запроса, делают этот подход все более доступным, не требуя массовых инвестиций в инфраструктуру.
Для организаций, борющихся с тестированием микросервисов, это преобразование обеспечивает четкое конкурентное преимущество: более качественное программное обеспечение, более быстрое циклы доставки и более эффективное использование ресурсов-при этом улучшая опыт разработчика.
Signadot-это платформа для тестирования Kubernetes для микросервисов. Используя Signadot, инженерные команды «сдвигаются налево», чтобы выяснить проблемы раньше и повысить доверие. Узнайте больше новейших из Signadot Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Арджун Айер, генеральный директор Signadot, является опытным экспертом в облачной местной области с глубокой страстью к улучшению опыта разработчика. У Арджуна хвастается более чем 25-летним опытом работы в отрасли, есть богатая история разработки программного обеспечения для интернет-масштаба и … Подробнее от Arjun Iyer
