Signadot спонсировал этот пост.
В типичной организации, создающих микросервисы, жизненный цикл разработки программного обеспечения (SDLC) протекает через лоскутное одеяло из отключенных сред. Код перемещается от локальной разработки, часто на Docker Compose или одноздовом кластере Kubernetes, в трубопроводы непрерывной интеграции (CI), заполненные макетами, в настройки препарата, которые являются лишь частично реалистичными, а иногда через дополнительные этапы, такие как тестирование принятия пользователя (UAT). Каждый шаг вводит дрейф, накладные расходы на техническое обслуживание и большее расстояние от реальной производственной среды.
Каждый из этих этапов вводит свою собственную среду, с собственным бременем обслуживания, рисками и режимами отказа. Команды платформы остаются их всем, хотя ни один из них не является полностью последовательным. Результатом является постоянное наращивание долга трений, дивергенции и обслуживания.
Это проблема среды микросервиса: фрагментация по умолчанию.
Как мы сюда попали
Мы не попали сюда, потому что мы были небрежны. Мы попали сюда решить реальные, жесткие проблемы с инструментами, которые у нас были. Реальность заключалась в том, что мы должны были совершать компромиссы между скоростью и верностью.
Предоставление каждому разработчику полную копию производства не была практичной, особенно после того, как компании начали управлять 20, 30 или более микросервисами. Местные установки стали слишком тяжелыми, слишком медленными и слишком хрупкими. С другой стороны, делать все с макетами означало более быструю обратную связь, но ценой реализма, и настоящие ошибки все еще проскользнули в производство.
Это напряжение между сложностью, скоростью и реализмом сформировало разрастание окружающей среды, с которой мы живем сегодня:
- CI слишком медленно? Добавить макет.
- Постановка слишком хрупкая? Сделайте легче.
- Разработчики заблокированы на местном? Взломать его сценариями и заглушками.
Каждый шаг имел смысл в то время. Но со временем мы получили разбросанный беспорядок окружающих средств, которые не совсем разговаривают друг с другом, и определенно не соответствуют производству. И теперь большая часть нашей энергии уходит в поддержание работы этой структуры, а не улучшать ее значимыми способами.
Почему это начинает больно
Фрагментированные среды создают трение везде:
- Ошибки появляются поздно или только в постановке.
- Тесты проходят в CI, но терпят неудачу в производстве.
- Локальные настройки разработчиков становятся медленными и ненадежными.
Большая проблема — продолжающийся труд. Команды платформы заканчивают тем, что объединяют несколько настройки среды, дренирование времени, которое можно потратить на улучшение девекса, абстрагируя сложность и обеспечивая более быструю доставку. Вместо того, чтобы продвигать организацию вперед, они застряли в боевой инфраструктуре.
Каждый патч, больше макетов и более тяжелых сценариев добавляют только бремя.
Хорошая новость: Инфра выровнялась
Вот что отличает этот момент: мы больше не застряли.
Kubernetes предоставляет общую платформу для оркестровки, а сервисные сетки, такие как Istio и Linkerd, добавляют критическую недостающую часть: мелкозернистого управления трафиком на уровне запросов. Эти инструменты позволяют разработчикам запускать несколько изолированных версий услуг внутри одного и того же общего кластера, без столкновения.
Это означает, что вы можете:
- Маршрут трафик на зависимости от проведения, а не только на услуги.
- Развернуть изолированные версии микросервисов без воспроизведения всего стека.
- Безопасно разделить общую среду через разработку, тестирование, постановку и валидацию.
- Включите эфемерные, высокие условия, которые можно быстро развернуть и быстро снести.
Как я писал ранее, эти возможности инфраструктуры, наконец, делают его реалистичным объединять окружающую среду по всему SDLC. Вместо того, чтобы поддерживать множество различных хрупких настройки, вы можете составить одну сильную, многократно используемой основы, которая поддерживает все.
Строительные блоки здесь. Теперь речь идет о том, чтобы сшить их вместе правильно.
Лучший путь вперед
Вместо того, чтобы поддерживать пять отдельных сред, лучшим путем является создание унифицированной, подобной производственной среде, которая поддерживает разработку, тестирование, обеспечение качества (QA) и сквозной валидации. Сделав эту среду многопользовательской и динамичной, команды могут избежать воссоздания и исправления реальности на каждом шаге.
Это объединение значительно упрощает бремя инженерии платформы. Вместо того, чтобы решать одни и те же проблемы окружающей среды, много разных способов, команды платформы могут сосредоточиться на более высоком уровне: улучшение опыта разработчиков, ужесточение петель обратной связи и ускорение доставки.
Признаки перемен
Многие организации движутся в направлении модели унифицированной среды: единственной производственной базы, общей между разработкой, тестированием и за его пределами.
Брекс, например, сделал этот сдвиг и увидел значительное улучшение удовлетворенности разработчиков и снижение затрат на инфраструктуру более чем на 90%, одновременно масштабируя тестирование для сотен инженеров. Сильная окружающая среда помогает всему, что выше, движется быстрее и чувствует себя легче.
В Signadot мы построили размещенную платформу, которая позволяет легко принять эту модель в ваших собственных кластерах Kubernetes. Если вы чувствуете вес фрагментированной среды, вы не одиноки. Есть лучший способ в пределах досягаемости.
Signadot-это платформа для тестирования Kubernetes для микросервисов. Используя Signadot, инженерные команды «сдвигаются налево», чтобы выяснить проблемы раньше и повысить доверие. Узнайте больше новейших из Signadot Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Анируд Раманатан является техническим директором Signadot, где он фокусируется на развитии нативного облака. До этого он работал в Google, сосредоточившись на базовых контроллерах Kubernetes и расширяемости. Он также является комитетом в проекте Apache Spark с акцентом на … Подробнее от Anirudh Ramanathan
