Сокращение высокой стоимости тестирования микросервисов

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

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

Высокие затраты на дублирование окружающей среды

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

Проблема, однако, возникает в реальной реализации.

Например, крупная компания Fintech, как сообщается, тратила более 2 миллионов долларов в год только на облачные затраты. Компания развернула многие среды для предварительного просмотра изменений и для того, чтобы разработчики проверяли их, каждая из них отражает свою производственную установку. Затраты включали обеспечение сервера, хранения и конфигураций сети, которые значительно добавили. Каждая команда нуждалась в своей собственной копии, и они ожидали, что она будет доступна большую часть времени. Кроме того, они не хотели ждать долгого времени запуска, поэтому в конце концов все эти среды работали 24/7, и все время затрачивало хостинг.

Проблемы синхронизации

Проблемы синхронизации - это одна из проблем, которая поднимает свою голову при попытке реализовать реплицированные среды тестирования в масштабе. По сути, для всех внутренних услуг, насколько мы уверены в том, что каждая реплицированная среда запускает наиболее обновленную версию каждой службы? Это звучит как краевая корпус или небольшая забота, пока мы не помним, что весь смысл этой установки состоял в том, чтобы сделать тестирование очень точным. Выяснение только при продвижении к производству, что недавние обновления для обслуживания C нарушили мои изменения в обслуживании B, более чем разочаровывает; Это ставит под сомнение весь процесс.

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

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

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

Техническое обслуживание накладных расходов

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

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

Проблемы масштабируемости

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

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

Альтернативные стратегии

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

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

Заключение: стоимость, которая не масштабируется

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