Service mesh [Слёрм] [Александр Лукьянченко, Георг Гаал]

Service mesh Вы поймёте service mesh, поработаете руками с технологией, выполнив практические задания. Все это поможет понять необходимость внедрения и подготовиться к нему без костылей в архитектуре. Бизнес-кейсы, которые будем решать Проблема #1. Мониторинга нет, или он слабо развит. Система периодически тормозит, но непонятно, в каких местах. Проблема #2. Клиенты жалуются, что сервисы иногда отдают ошибки. Из мониторинга видно, что падения кратковременные, но частые. Менять что-то в приложении можно, но дорого — много разных стеков. Проблема #3. Нужно выкатить новую фичу, но нет уверенности, что все пойдет как надо. Времени на всеобъемлющее тестирование нет, нужно выкатывать. Проблема #4. В системе появляется новый компонент который отвечает за процессинг кредитных карт. Появляются требования к безопасности системы всей системы. Проблема #5. Приложение разрослось. Клиенты жалуются на долгое время ответа. На серверной стороне все ок. Похоже проблема с удаленными геолокациями. Зачем нужен service mesh Оbservability — прозрачный мониторинг API вызовов в системе, позволяет значительно сократить время на поиск и устранение проблем. Унифицированные политики прокси Envoy упрощают взаимодействие между любым количеством микросервисов, написанных на любых языках — все приводится к общему знаменателю. Service mesh обеспечивает прозрачное управление входящим и исходящим трафиком в едином месте, систему можно гибко тюнить, добавляя или удаляя правила. Задания построены вокруг учебного приложения – онлайн-кинотеатра, состоящего из нескольких микросервисов. Для понимания особенностей работы service mesh в условиях гетерогенных систем сайт написан на двух языках: Python и Ruby. Практикуемся в Istio, но изучаем не интерфейс, а концепцию работы: так участники смогут применить полученный опыт на любом service mesh решении, реализованном на основе Envoy Proxy.