Signadot спонсировал этот пост.
Постановка всегда была неизбежным злом. Новые подходы к изоляции и песочницам по требованию наконец-то сделали это просто злом.
На протяжении десятилетий промежуточная среда была неотъемлемой частью разработки программного обеспечения. И так же долго его ненавидели разработчики во всем мире. Это пресловутая пробка, в которой каждый разработчик вынужден стоять только для того, чтобы проверить свою работу.
Однако в постановке больше нет необходимости; его время пришло и ушло. Новые методы изоляции позволяют разработчикам безопасно тестировать в реальных средах, обеспечивая быструю и высококачественную обратную связь, чего невозможно достичь в промежуточной среде.
Пришло время убить вашу промежуточную среду.
Проблема, которую мы все знаем
Теоретически промежуточные среды имеют смысл. Мы должны протестировать код в среде, похожей на производственную, прежде чем отправить его в производство. Все остальное было бы безумием.
Но лекарство стало отдельной болезнью. В любой организации, в которой имеется более нескольких микросервисов, промежуточная среда неизбежно превращается в пустошь, наполненную страданиями разработчиков и сожженными деньгами.
- Это узкое место: Когда 50 разработчиков объединяют код, промежуточный этап становится общей очередью. Тесты проваливаются не из-за плохого кода, а из-за того, что другой разработчик внедрил конфликтующее изменение.
- Это не производство: Мы называем это «производственным», но у него никогда не бывает одинакового масштаба данных, шаблонов трафика или политик управления идентификацией и доступом (IAM). Именно в этом разрыве точности и скрываются опасные ошибки.
- Это убивает скорость: Зафиксируйте код, дождитесь CI, дождитесь слота развертывания, запустите 40-минутный набор тестов. Этот многочасовой цикл разрушает состояние потока.
- Никто этого не поддерживает: Команды рассматривают его как свалку нестабильных сборок, что еще больше отклоняется от производства.
Мы мирились с этим нарушенным рабочим процессом в течение 20 лет. Мы верили, что это единственный путь.
От изоляции окружающей среды к запросу на изоляцию
Постановка существует из-за предположения, что тестирование должно быть изолировано на уровне среды. Чтобы протестировать новую версию платежного сервиса, необходимо развернуть его в среде, которая также содержит сервис корзины, пользовательский сервис и сервис аутентификации.
Это предположение устарело и устарело.
Новая модель — изоляция на уровне запроса. Вместо клонирования всей среды вы запускаете только ту службу, которую меняете. Эта модель поддерживается собственными платформами Kubernetes, которые предоставляют песочницы по требованию для каждого запроса.
Вот как это работает:
- Новая версия сервиса разворачивается в изолированной «песочнице» по требованию.
- Когда отправляется тестовый запрос (с тегом уникального заголовка), он направляется в изолированную службу.
- Когда эта служба вызывает свои зависимости, эти вызовы перенаправляются обратно в стабильные базовые службы в рабочей среде.
- Тестовый запрос остается изолированным во время прохождения через стек, в то время как весь остальной трафик проходит нормально.
При таком подходе вы получаете высокоточное тестирование (реальные зависимости, реальные сетевые политики) без недостатков общих сред (отсутствие коллизий, отсутствие очередей, значительно более низкие затраты).
Изоляция на уровне запросов может быть реализована в традиционном локальном > промежуточном > производственном процессе развертывания, чтобы улучшить его, устранить конфликты и долгое ожидание конвейера CI. Но его реальная сила заключается в том, что он полностью устраняет необходимость в подготовке и позволяет проводить тестирование в производстве.
Модель безопасности
Тестирование в производстве звучит опасно. Это не тогда, когда у вас есть правильные ограждения.
- Строгая изоляция данных имеет решающее значение. Наибольшее беспокойство вызывает то, что изолированная служба может повредить данные в других службах. Решение простое. Тот же заголовок маршрутизации, который изолирует тестовый трафик, также направляет операции базы данных в отдельные тестовые базы данных. Например, когда тестовый запрос проходит через систему, каждая служба распознает тестовый контекст и направляет все записи в базу данных в изолированные хранилища тестовых данных, полностью отделенные от производственных баз данных. Тестовые пользователи взаимодействуют только с тестовыми данными. Данные о производстве остаются нетронутыми.
- Мультиарендность обеспечивает основу. Ограничения виртуальной частной сети (VPN) гарантируют, что тестовый трафик исходит только из авторизованных внутренних сетей. Журналы аудита отслеживают каждый сеанс песочницы на предмет соответствия требованиям.
- Маршрутизация запросов обеспечивает контроль радиуса взрыва. Ваша песочница изолирована на уровне запроса. На работе ваших коллег это не повлияет. Производственный трафик протекает нормально.
- Постепенный развертывание по-прежнему имеет важное значение. Песочницы выполняют предварительную проверку, но вы по-прежнему используете канареечные развертывания, флаги функций и возможность наблюдения для безопасного развертывания для реальных пользователей.
Отвечаем на трудные вопросы
Тестирование в производстве — это логическая эволюция движения за сдвиг тестирования влево. Но внесение такого фундаментального изменения в ваш конвейер CI/CD, естественно, поднимает некоторые важные вопросы:
- «Как вы можете гарантировать, что тестовый трафик не испортит производственные данные?» Тестовые записи изолированы. Заголовок изоляции перенаправляет все операции записи в базу данных в эфемерные, непроизводственные хранилища данных, которые уничтожаются после теста. Производственные данные никогда не трогаются.
- «А как насчет радиуса взрыва? Как предотвратить плохой тест от DDoS-атак нижестоящей службы?» Песочницы — это «теневые» развертывания, построенные с использованием таких защитных средств, как автоматические выключатели и сетевые политики. Тест с ошибками и неконтролируемыми сетевыми запросами автоматически ограничивается и ограничивается, не позволяя ему перегружать базовые службы или влиять на других пользователей.
- «Это звучит хорошо для простых API, но как насчет Kafka или gRPC?» Модель изоляции не зависит от протокола. Заголовок изоляции распространяется через gRPC или как заголовок сообщения Kafka. Например, изолированный потребитель читает основную тему, но обрабатывает сообщения только со своим уникальным идентификатором песочницы.
- «А как насчет требований соответствия и аудита?» Эта модель более проверяема. Каждая песочница привязана к конкретному пользователю и сеансу запроса на включение/разработки. Весь тестовый трафик явно помечается идентификатором песочницы и идентификатором пользователя, что создает детальный журнал аудита, который намного превосходит общую промежуточную среду.
Решение этих проблем и переход к промышленному тестированию неизбежно потребуют некоторых первоначальных инженерных инвестиций. Однако окупаемость инвестиций в эту работу — это не просто экономия от устранения прямых затрат на инфраструктуру вашей постановки. Это также лучший опыт разработки, более быстрая доставка продуктов и меньше возможностей, упущенных конкурентами, которые могут выполнять итерации и поставлять быстрее, чем вы.
Пришло время отпустить
Устранение промежуточного тестирования может показаться несбыточной мечтой, но несколько известных облачных команд, таких как DoorDash и Uber, уже перешли к тестированию в производстве. Благодаря своим очень сложным стекам микросервисов и необходимости повышения точности тестирования они также реализуют огромную экономию затрат на инфраструктуру.
Подобные команды, отказывающиеся от своих промежуточных сред для тестирования в производстве, представляют собой более широкую тенденцию: отказ от приближений в пользу реальности. Промежуточные среды — это артефакты эпохи, когда дублирование инфраструктуры было более сложной проблемой, чем координация действий людей вокруг общих ресурсов.
Эта эпоха заканчивается.
Будущее не за созданием более качественных моделей производства или оптимизацией вашего конвейера CI. Речь идет о принятии совершенно новой парадигмы. Команды, идущие на этот шаг, не просто двигаются быстрее и сокращают расходы. Они также поставляют более надежный код.
Пришло время убить вашу промежуточную среду.
Signadot — это собственная платформа Kubernetes для тестирования микросервисов. Используя Signadot, команды разработчиков «смещают влево» тестирование, чтобы выявить проблемы раньше и повысить уверенность в выпуске. Узнайте больше Последние новости от Signadot ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Арджун Айер, генеральный директор Signadot, — опытный эксперт в области облачных технологий, страстно желающий улучшить опыт разработчиков. Обладая более чем 25-летним опытом работы в отрасли, Арджун имеет богатую историю разработки программного обеспечения для Интернет-масштабов и… Подробнее от Арджуна Айера
