Service mesh

Service mesh в Узбекистане: зачем эта надстройка над Kubernetes

Микросервисная архитектура в Узбекистане перестала быть экспериментом одной-двух компаний: банки, финтех-стартапы и резиденты IT Park Uzbekistan — а их уже почти 2 900 — держат десятки сервисов в Kubernetes-кластерах. Когда сервисов становится больше десятка, ручное управление трафиком, шифрованием и повторными попытками между ними превращается в хаос из скриптов и костылей. Service mesh — Istio, Linkerd, Envoy — забирает эту рутину на уровень инфраструктуры: маршрутизация, mTLS, circuit breaking и трассировка запросов настраиваются один раз, а не пишутся заново в коде каждого сервиса.

Кто в Узбекистане реально этим занимается

Service mesh — не отдельная профессия, а специализация внутри DevOps и SRE. Такие задачи появляются там, где Kubernetes уже работает: в банках с иностранным капиталом, у экспортоориентированных IT-компаний Ташкента и в продуктовых командах, которые обслуживают нагрузку сразу из нескольких стран. Небольшому стартапу с парой сервисов service mesh чаще всего не нужен вовсе — а вот команда с десятками микросервисов без него быстро тонет в логах, таймаутах и непонятно откуда взявшихся 500-х ошибках.

Спрос и зарплаты

По итогам 2025 года, согласно данным hh.uz, DevOps-инженер — одна из самых высокооплачиваемых технических ролей в Узбекистане: медианное предложение — около 10,89 млн сум в месяц, доля от всех IT-вакансий — 2%, а годовой прирост — 12,8%. Для сравнения: системный администратор получает медианно около 7,77 млн сум (доля 5,6%, рост 8,5%), а более узкая роль системного инженера — около 9,34 млн сум, и эта позиция за год потеряла 17,5% вакансий — рынок явно смещается от классического администрирования к cloud native. Отдельной строки «Service mesh» в статистике hh.uz нет — это не вакансия, а специализация внутри DevOps, но именно она чаще всего отличает middle-инженера от senior на техническом интервью в банке или экспортной IT-компании.

Чему учат на курсах

• Istio — sidecar-прокси на базе Envoy, VirtualService и DestinationRule, канареечные релизы, fault injection
• mTLS и политики безопасности между сервисами без изменения кода приложений
• Linkerd и Cilium — более лёгкие альтернативы Istio для команд, которым не нужна вся его сложность
• Observability: трассировка через Jaeger, метрики в Prometheus и дашборды в Grafana

Для кого этот навык, а для кого пока рано

Курсы по service mesh рассчитаны на DevOps-инженеров, SRE и бэкенд-разработчиков, которые уже разворачивали Kubernetes самостоятельно хотя бы полгода. Если вы пока не создавали Deployment и Service своими руками, начинать со service mesh рано: половина терминов курса окажется непонятной без этой базы. Есть и обратная ситуация — если инфраструктура компании состоит из двух-трёх монолитных сервисов без оркестрации, изучать Istio сейчас смысла нет, разве что заранее, на перспективу роста.

Нюанс, о котором редко говорят на курсах

Service mesh решает не все проблемы микросервисов — он добавляет собственный слой сложности и расходует ресурсы кластера на sidecar-прокси в каждом поде. Поэтому в небольших командах Ташкента и Самарканда чаще выбирают облегчённый Linkerd или обходятся обычным API-шлюзом, а полноценный Istio разворачивают там, где счёт сервисов идёт на десятки и есть отдельная платформенная команда. Это стоит держать в голове до того, как вы вложите пару месяцев в изучение самого тяжеловесного инструмента экосистемы.

Начинать с нуля сразу с Istio не нужно — сначала база Kubernetes, потом уже mesh. Но если эта база уже есть, пары недель плотной практики с sidecar-прокси и mTLS хватает, чтобы претендовать на middle-senior DevOps-роль в банке или экспортной IT-компании. Спрос на этот навык узкий, зато и конкуренция за такие позиции заметно ниже, чем среди обычных бэкенд-разработчиков.