Скрытые расходы при переходе на микросервисы Бындю Александр 

IT-архитектор в http://byndyusoft.com Byndyusoft – это заказная разработка с продуктовым подходом. В прошлом: • Тренер в ScrumTrek • Вожатый на AgileCamp • IT-директор • .NET/Java/Javascript программист Александр Бындю Эксперт в Agile и Lean · IT-архитектор 

Создание новой системы на микросервисной архитектуре 1. https://microservices.io 2. Бизнес-гибкость через микросервисную архитектуру 3. Useful Tools for Managing Complexity of Microservice Architecture Работа с унаследованным кодом 1. https://www.amazon.com/s?k= legacy+code 2. Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы Специфика перехода от монолита к микросервисам в проектах: 1. важных для бизнеса, 2. уже работающих 

Цель 1. Создавать адекватный план перехода с учетом всех 10 факторов. 2. Точнее считать бюджет перехода на микросервисы. 3. Реалистично оценить, надо ли вам делать переход. 

№1 Затраты Изменение подхода к работе с мастер- данными. Учесть в оценке Анализ мастер-данных монолита и разработку архитектуры управления мастер-данными в микросервисах. Проактивные действия Выбрать стратегию работы с мастер- данными (Управление мастер-данными в микросервисной архитектуре). 

№2 Затраты Не получится бесплатно переиспользовать исходный код монолита. Учесть в оценке Почти весь код придется написать с нуля: 1. для разделения ответственностей по микросервисам, 2. для перехода на новые технологии и инфраструктуру. Проактивные действия Подготовить команду монолита к тому, что проявятся проблемы, которые монолит “прощал”. Выделить их время на ответы на вопросы по принятым в коде решениям. 

№3 Затраты Заново перепроектировать систему. Учесть в оценке Анализ потребностей бизнеса для правильной “нарезки” на микросервисы. Проактивные действия 1. Запланировать время архитектора, аналитика и стейкхолдеров на анализ бизнес-требований. 2. Запланировать время на проектирование API. 

№4 Затраты Создание нового подхода к управлению инфраструктурой, а не переиспользование существующего. Учесть в оценке 1. Управление API: анализ вызовов, система прав, публикация (например, Apigee). 2. IaC и контейнеризацию. 3. Тотальное логирование и мониторинг. Проактивные действия Изучить инструменты, чтобы не попасть в ситуацию, когда создан микросервисный монолит. 

№5 Затраты Измерение и проверка SLA каждого микросервиса. Учесть в оценке При разделении монолита SLA становятся явными, поэтому их надо описать, протестировать и мониторить. Проактивные действия 1. Настройка мониторинга выполнения SLA. 2. Интеграционное тестирование с учетом SLA. 

№6 Затраты Микросервисы добавят на порядок больше точек отказа. Учесть в оценке Вклад в fault tolerance на всех уровнях: проектирование архитектуры, разработка и тестирование. Проактивные действия 1. Нагрузочное, отключение сервисов/систем/хостов, тестирование на восстановление, применение chaos engineering. 2. Применение шаблонов проектирования, таких как Circuit Breaker и Tolerant Reader. 3. Настройка инфраструктуры: service discovery, health-check,... 

№7 Затраты Реорганизация команд. Учесть в оценке Создание кросс-функциональных команд (build-and-run team) под микросервисы. Проактивные действия 1. Выбрать распределение ответственности команд между микросервисами, например, Service per team. 2. Попробовать применить InnerSource, чтобы разгрузить команды от входящих запросов. 3. Выбрать стратегию работы с исходным кодом: монорепа, репозиторий под продукт, репозиторий под микросервис. 4. Выбрать способ управления общими пакетами. 

No content

№8 Затраты Обратная совместимость с монолитом требует дополнительной разработки в микросервисах и наоборот. Учесть в оценке 1. Доработки в микросервисах и монолите. 2. Процесс тестирования обеих систем в связке. Проактивные действия Заранее выяснить, что войдет в работы по сохранению обратной совместимости, и заложить эти работы в план обеих команд. 

№9 Затраты Интеграция служб поддержки. Учесть в оценке 1. Выстраивание процесса техподдержки двух систем одновременно. 2. Обслуживание инструментов служб поддержки в новой системе. 3. Обучение работе техподдержки в новой архитектуре. Проактивные действия 1. Выяснить текущий подход к организации техподдержки всех уровней. 2. Заложить в оценку интеграцию с системами техподдержки. 

№10 Затраты Догоняющий поток фич от бизнеса в период, когда работают обе системы. Учесть в оценке 1. Координацию команд новой и старой систем по работе над новыми фичами. 2. Работы по сохранению обратной совместимости. Проактивные действия 1. Заранее договориться с командой, разрабатывающей монолит о совместных работах. 2. Договориться с бизнесом о процессе внесения новых фич в период жизни обеих систем. 

Создание новой системы на микросервисной архитектуре Работа с унаследованным кодом Специфика перехода от монолита к микросервисам Сумма затрат при переходе от монолита к микросервисам + + 

Создать систему на микросервисной архитектуре Догоняющий поток изменений, работа с мастер-данными, перестроение команд... $ 

Чеклист оценки 1. Мастер-данные 2. Написание кода по-новому 3. Проектирование IT-продукта заново 4. Создание новой инфраструктуры 5. Измерение и проверка SLA 6. Вклад в fault tolerance на всех уровнях 7. Реорганизация команд 8. Работы по обратной совместимости 9. Интеграция служб поддержки 10. Догоняющий поток фич 

Ссылки для погружения в тему 1. The Death of Microservice Madness in 2018, Dave Kerr 2. The hidden costs of microservices, Wayne Geils, Mike Hostetler 3. Microservice Trade-Offs, Martin Fowler 4. Pattern: Microservice Architecture, Chris Richardson 5. The Hidden Costs of Microservices, Justin Leitgeb 6. Challenges and benefits of the microservice architectural style Part 1 + Part 2, André Fachat 

Вопросы? https://byndyu.ru https://t.me/byndyufeed