Signadot спонсировал этот пост.
Я много лет разговаривал с инженерными лидерами о проблемах тестирования микросервисов, и один разговор продолжает повторяться. Обычно это начинается с чего -то вроде: «Мы создали эту удивительную архитектуру микросервисов, но тестирование стало кошмаром».
Проблема интеграционного тестирования
Обещание микросервисов является убедительным — более быстрые циклы разработки, лучшая автономия команды и улучшенная масштабируемость. Но этот архитектурный подход представляет значительную проблему тестирования, которую многие команды не полностью ценят, пока они не по колену в нем.
Реальность такова, что локальное тестирование с высмеиваемыми зависимостями не обеспечивает достаточной уверенности. Эти издевательства со временем со временем уходят от реальности, что приводит к страшному синдрому «Работа на моей машине». Интеграционные ошибки часто остаются неизвестными, пока код не достигнет общей среды с реальными зависимостями, обычно постановкой.
Это создает болезненное узкое место. Как сказал мне один вице -президент по технике недавно: «Наша стационарная среда похожа на переполненный ночной клуб: все хотят, емкость ограничена, а борьба регулярно разворачивается из -за того, кто получает доступ».
Решение эфемерной окружающей среды
Чтобы решить эти узкие места, многие организации обратились к эфемерной среде-по требованию, недолговечны реплики производства, где разработчики могут проверить изменения против реальных зависимостей перед слиянием кода.
Типичная реализация включает в себя либо создание отдельных пространств имен Kubernetes, так и целых кластеров Kubernetes, которые содержат все сервисы, базы данных, очереди сообщений и другие зависимости. Каждый разработчик получает свою собственную изолированную игровую площадку.
Это решает проблему раздора. Но по какой цене?
Математика традиционных эфемерных средств
Давайте запустим немного математики салфетки на то, что на самом деле стоят эти среды. Используя ли вы изоляцию пространства имен или отдельные кластеры, требования к ресурсам остаются одинаковыми, поскольку вы дублируете все компоненты в обеих моделях. Я использую довольно консервативные предположения:
- Размер команды: 100 разработчиков, каждый из которых нуждается в одной среде
- Сложность архитектуры: 50 микросервисов
- Требования к ресурсам: Каждому микросервису нужно 2 VCPU и 4 ГБ ОЗУ
- Шаблон использования: Среда активна восемь часов в день только в будние дни
На AWS экземпляр T3.large (2 VCPU, 8 ГБ) стоит примерно 0,08 долл. сша в час. Будучи консервативным и предполагающим отличное количество бин, нам понадобится не менее 50 таких случаев на окружающую среду.
Годовой расчет выглядит следующим образом: 0,08 долл. сша/час.
Да, вы правильно прочитали. Более 800 000 долларов ежегодно только в расчетах. Даже с более консервативными оценками и дисконтными ценами мы все еще говорим миллионы.
Оперативное бремя поддержания сотен эфемерных среда огромна. Дрифт конфигурации, сетевые проблемы и ограничения ресурсов создают постоянные головные боли для команд платформ. Когда что -то ломается, все развитие затихает.
Эфемерная среда на основе песочницы
Существует принципиально иной подход к этой проблеме, который значительно снижает как затраты, так и оперативную сложность: настраиваемое изоляцию посредством маршрутизации запросов в эфемерных средах на основе песочницы.
При использовании Kubernetes с сервисной сеткой, такой как Istio или Linkerd, вы можете создать общую базовую среду с динамическим маршрутизацией запросов. Когда разработчику необходимо проверить изменения, они развертывают только те службы, которые они изменили в песочнице. Запросы направляются на эти услуги на основе заголовков запросов, в то время как неизменные услуги совместно используются во всех песочницах.
Источник: Signadot
Давайте пересмотрим затраты с этим подходом:
Годовые затраты: (0,08 долл. сша/час × 50 Услуги × 1 Базовая линия × 24 часа × 365 дней) + (0,08 долл. сша/час × 2 Услуги × 100 разработчиков × 8 часов × 5 дней × 52 недели) = 35 040 долл. сша + 33 280 долл. сша = 68 320 долл. сша.
Это снижение затрат на 92% по сравнению с традиционными эфемерными средами!
Источник: Signadot
Отсутствующий фактор: оперативная сложность
Благодаря традиционной эфемерной среде (как пространство имен, так и на основе кластеров) ваша платформа станет ответственной за поддержание сотен реплик всего вашего стека. Каждое изменение конфигурации, каждая миграция базы данных, каждая новая служба должна распространяться во всех средах. Это создает огромное бремя обслуживания, которое линейно растет с количеством разработчиков.
Напротив, с подходом на основе песочницы вы поддерживаете только одну базовую среду. Эта среда может постоянно обновляться через ваш существующий трубопровод CI/CD, гарантируя, что она всегда отражает текущее состояние вашей основной ветви. Операционная нагрузка остается почти постоянной, независимо от того, сколько разработчиков вы добавляете.
Реальное воздействие
Недавно я поговорил с вице -президентом по проектированию платформы в компании Fintech, которая рассчитала стоимость традиционных эфемерных среды на сумму более 5 миллионов долларов в год. После перехода к подходу на основе песочницы компания сократила затраты на инфраструктуру более чем на 85% и переориентировала свою команду платформы на создание лучшего опыта разработчиков и инструментов, а не просто поддержания среды.
Другой клиент, крупное программное обеспечение в качестве поставщика услуг (SAAS), планирует полностью отказаться от собственных центров обработки данных, причем одним из ключевых факторов является ликвидация дорогих дублирующих средств тестирования через эфемерные среды на основе песочницы.
Помимо экономии затрат, эти компании увидели значительные улучшения в производительности разработчиков. Циклы тестирования сократились от часов до минут, позволяя разработчикам немедленно проверять изменения, а не ждать тестов интеграции после Merge.
Заключение
По мере того, как архитектуры микросервиса продолжают расти в сложности, стоимость традиционных подходов к тестированию растет неустойчиво. Эфемерные среды на основе песочницы предлагают более эффективную альтернативу, которая обеспечивает преимущества реального интеграционного тестирования без каких-либо затрат на инфраструктуру и операционного бремени.
Для многих организаций речь идет не только о экономии денег, а о том, является ли комплексное интеграционное тестирование вообще вообще жизнеспособным. Когда традиционные подходы стоят миллионы, многие команды вынуждены сокращать углы при тестировании, что приводит к проблемам качества и инцидентам производства.
Если вы заинтересованы в том, чтобы увидеть эти концепции в действии, ознакомьтесь с нашим тематическим исследованием с помощью Brex, что снизило затраты на инфраструктуру на 99% после реализации эфемерных сред. Его инженерная команда может, наконец, масштабировать тестирование для всех разработчиков, не нарушая банк.
Чтобы углубиться в детали технической реализации того, как сетки службы включают эфемерные среды на основе песочницы, прочитайте «Использование ISTIO или Linkerd для разблокировки эфемерных сред» для более глубокого погружения в подход.
Signadot-это платформа для тестирования Kubernetes для микросервисов. Используя Signadot, инженерные команды «сдвигаются налево», чтобы выяснить проблемы раньше и повысить доверие. Узнайте больше новейших из Signadot Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Арджун Айер, генеральный директор Signadot, является опытным экспертом в облачной местной области с глубокой страстью к улучшению опыта разработчика. У Арджуна хвастается более чем 25-летним опытом работы в отрасли, есть богатая история разработки программного обеспечения для интернет-масштаба и … Подробнее от Arjun Iyer
