Service Mesh – технология, которая призвана обеспечить гибкое, стабильное и надежное общение сервисов. Технология, призванная упростить эксплуатацию сетевого взаимодействия. Но сделает ли она систему проще?

За последние пять лет в Авито мы прошли путь от реализации собственного Service Mesh до внедрения Open Source решения Istio. И нам есть чем поделиться:

- Причины выбора собственной реализации и почему в итоге ушли на Istio?

- Организация локальности трафика при деплое в несколько датацентров

- Особенности внедрения безопасного общения (mTLS): откуда ждать сопротивление?

- Процесс внедрения массовых изменений в Service Mesh

- Как Service Mesh помогает ускорить разработку и тестирование за счет изолированных окружений?

- Так ли прост Service Mesh и стоит ли его внедрять?

Поговорим и про организацию процессов, и про техническое устройство Service Mesh на масштабе более двух тысяч сервисов и миллионов запросов в секунду.

Целевая аудитория:

- DevOps- и SRE-инженеры, поддерживающие сетевую инфраструктуру в компании

- лидеры, оценивающие целесообразность внедрения Service Mesh и платформенного подхода

Давайте сегодня перенесемся в то время когда трава была зеленее, а kubernetes еще не было и пройдем путь становления DevOps методологии как стандарта, попутно разбирая как делать надо, а как делать не надо. В докладе разберу основные паттерны и антипаттерны построения конвейера CI/СD, а также попробую ответить на вопрос каким должен быть идеальный pipeline!

- Анализ пожеланий клиентов по созданию эффективного аналога зарубежных BI-инструментов: Microsoft PowerBI и Google Looker Studio.

- Проектирование прототипа решения на базе opensource-технологий: Apache Superset (python) и своего плагина на java к Trino.

- Создание работающего BI-решения за 2 недели с активным использованием технологий контейнеризации Docker и Docker Compose.

- Масштабирование BI-решения с использованием Kubernetes.

- Работа BI-решения под нагрузкой в 25 000 компаний-клиентов - подводные камни и секреты.

- Организация процесса внутреннего обучения системных администраторов и разработчиков технологиям контейнеризации - как придти к цели кратчайшим путем.

- Организация процесса использования контейнеризации в разработке и эксплуатации для устойчивого дальнейшего развития "BI-конструктора".

А так-же: рассмотрим наиболее частые ошибки и подумаем, как их избежать.

Работа с базами данных в Kubernetes отличается от работы с stateless микросервисами. При этом, если учитывать особенности работы Kubernetes со stateful-приложениями, мы можем получить хорошую автоматику для запуска тысяч баз данных. Наша платформа DBaaS на базе Kubernetes имеет ряд особенностей и требований к предоставляемым кластерам, в связи с этим есть достаточно большой простор для проблем при вводе в эксплуатацию нового кластера. В рамках доклада обсудим, какие задачи мы решили при эксплуатации баз данных в Kubernetes, из чего состоит DBaaS Kubernetes кластер, как происходит его настройка, и что мы придумали, чтобы сделать приемку кластера легче.

При разработке каждого продукта есть свои особенности и это нормально.

А что если мы скажем, что сюда добавляются требования к развёртыванию от заказчиков, требования регуляторов, при этом мы хотим сохранять качество нашего продукта, как быть?

Сегодня я попробую рассказть о том, как может выглядеть процесс разработки и поставки продукта для заказчиков, у которых полностью изолированный контур до уровня физического доступа для развёртывания. В рассказ будут входить описание работы с инцидентами и линии поддержки, особенности проектирования архитектуры подобных решений, а так же специфику разработки скриптов развёртывания на такие контура заказчиков.