Доклад основан на кейсе по разработке Enterprise-grade-приложения, состоящего из десятков приложений, слабо связанных друг с другом, разрабатываемых разными командами, с разными моделями релиза и т.д. Суммарно размер такого решения может составлять несколько сотен различных юнитов, преимущественно микросервисов. Между этими юнитами нужно построить управляемое взаимодействие, учитывая множество специфических ограничений и условий, таких как:
• распределенность микросервисов по различным дата-центрам,
• поддержка "session stickiness",
• поддержка canary- и blue-green-модели,
• для входящих потоков нужно чётко разделять — какие API публикуются из приложения для каких клиентов
• multitenancy,
• и этот список можно продолжать.

На помощь приходит такая концепция, как Service Mesh и идея применить "микросервисную модель" и к структуре Service Mesh. В результате был разработан Non Uniform Service Mesh (NUM), который представляет собой продукт и набор паттернов его применения.

В докладе я на примере крупного приложения разберу типовые паттерны применения NUM:
• интеграция разнородных приложений в единый service mesh и управление связями,
• реализация application security (authentication, M2M),
• условная маршрутизация запросов в зависимости от бизнес-параметра,
• "stickiness" между микросервисом (kubernetes pod) и запросом (ордером, пользователем, HTTP-сессией),
• выкатывание обновлений по canary-модели,
• multitenancy с применением модели instance per tenant и shared multitenant instance,
• кастомизация логики гейтвея,
• интеграция с 3rd party-системами (серверная, южная).