Inner Source и микросервисы: как получить больше плюсов, чем минусов

InnerSourcing и микросервисы дополняют друг друга и одновременно повышают порог вхождения новичков в эту тему. Я расскажу с точки зрения IT-архитектора и организатора процесса разработки:
1. В чем конкретно можно выиграть при использовании InnerSourcing.
2. Какие инструменты и паттерны нужны для достижения успеха, и что будет, если их не использовать.
3. С какими проблемами сталкиваются компании, где мы настраивали связку InnerSourcing+микросервисы, даже если делали всё максимально хорошо.

Статья на эту тему и видео запись доклада на ArchDays https://blog.byndyu.ru/2019/12/inner-source.html

Transcript

1. Inner Source и
   микросервисы
   Как получить больше плюсов,
   чем минусов?
   

   View Slide

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

   View Slide

3. Нас включают в компанию заказчика
   для разработки продуктов и
   внедрения продуктовых практик и
   технических новинок, например,
   микросервисов и Inner Source.
   

   View Slide

4. Как протолкнуть
   свою задачу в
   соседнюю команду?
   Совещания, убеждения,
   доказательства и, в итоге, ожидание
   в очереди до покраснения
   приоритета.
   

   View Slide

5. Inner Source
   Реализация подхода Open
   Source в границах компании
   

   View Slide

6. 1. Исходники всех проектов
   доступны для всех сотрудников
   Inner Source
   

   View Slide

7. 2. Любой может стать
   контрибьютером с помощью
   pull request’а
   Inner Source
   

   View Slide

8. 3. Core Team принимает изменения
   извне и следит за целостностью
   Inner Source
   

   View Slide

9. 1. Управление приоритетами в бэклоге
   2. Выяснение требований по новой фиче
   3. Согласование плана работ между
   командами
   4. Разработка фичи
   5. Сбор обратной связи “а то ли мы
   сделали?”
   Работа по задаче без Inner Source
   Владелец продукта Команда
   Критичный ресурс
   

   View Slide

10. 1. Анализ pull request от внешней
    команды
    2. Добавление кода pull request в
    свой код
    ★ Нет спора за приоритеты
    ★ Нет обсуждения требований
    ★ Нет программирования
    ★ Нет сдачи фичи заказчику
    Владелец
    продукта
    Команда
    Работа по задаче через Inner Source
    

    View Slide

11. Поиск нужного
    репозитория
    описание
    репозитория,
    архитектура,
    инструмент
    коллоборации
    Запуск проекта
    локально
    контейнеры, IaC,
    инструменты
    разработки
    Куда внести
    изменения?
    документация,
    внутреннее
    качество, низкий
    тех. долг, тесты,
    инструменты
    разработки,
    архитектура,
    понятный и
    определенный API
    Сделать pull
    request и релиз
    инструмент
    коллаборации,
    continuous delivery,
    управление релизами
    Проверить нет
    ли поломок
    тесты, внутреннее
    качество, низкий
    тех. долг
    Секрет успеха Inner Source – 5 шагов без барьеров
    

    View Slide

12. Если у вас микросервисная архитектура,
    то часть барьеров к Inner Source уже
    устранены
    

    View Slide

13. В микросервисах:
    ● Continuous Delivery
    ● Тотальная
    автоматизация
    Контрибьютору не надо
    читать сложные инструкции,
    всё работает само под
    капотом
    

    View Slide

14. ● IaC
    ● Контейнеры
    Контрибьютор может быстро
    развернуть сервис на своем
    компьютере
    В микросервисах:
    

    View Slide

15. ● Мониторинг
    ● Трассировка запросов
    ● Логирование
    Core Team не страшно
    принимать pull request’ы
    В микросервисах:
    

    View Slide

16. ● Чистый API
    ● Компилируемые
    контракты (proto)
    ● Swagger
    Чтобы было понять как и где
    API поменять и на кого это
    повлияет
    В микросервисах:
    

    View Slide

17. ● Паттерны проектирования
    кода и взаимодействия
    сервисов: CircuitBreaker,
    TolerantReader,
    GracefulDegradation...
    Чтобы было легче
    разобраться, какой сервис за
    что отвечает и не бояться
    поломать всё вокруг
    В микросервисах:
    

    View Slide

18. Поиск нужного
    репозитория
    описание
    репозитория,
    архитектура,
    инструмент
    коллоборации
    Запуск проекта
    локально
    контейнеры, IaC,
    инструменты
    разработки
    Куда внести
    изменения?
    документация,
    внутреннее
    качество, низкий
    тех. долг, тесты,
    инструменты
    разработки,
    архитектура,
    понятный и
    определенный API
    Сделать pull
    request и релиз
    инструмент
    коллаборации,
    continuous delivery,
    управление релизами
    Проверить нет
    ли поломок
    тесты, внутреннее
    качество, низкий
    тех. долг
    

    View Slide

19. Поиск нужного
    репозитория
    описание
    репозитория,
    архитектура,
    инструмент
    коллоборации
    Запуск проекта
    локально
    контейнеры, IaC,
    инструменты
    разработки
    Куда внести
    изменения?
    документация,
    внутреннее
    качество, низкий
    тех. долг, тесты,
    инструменты
    разработки,
    архитектура,
    понятный и
    определенный API
    Сделать pull
    request и релиз
    инструмент
    коллаборации,
    continuous delivery,
    управление релизами
    Проверить нет
    ли поломок
    тесты, внутреннее
    качество, низкий
    тех. долг
    

    View Slide

20. Основные сложности
    в Inner Source –
    организационные и
    культурные
    

    View Slide

21. Если у сотрудников есть бонусы
    за фичи, то личные интересы
    противоречат Inner Source
    1. Изменить мотивацию
    сотрудников
    Сложности и проблемы Подход к решению
    

    View Slide

22. Если баги нашли три месяца
    спустя, кто поправит? Вернем
    контрибьютора?
    1. Договориться внутри
    компании об
    ответственности за
    создание PR и его апрув
    Сложности и проблемы Подход к решению
    

    View Slide

23. Слабым разработчикам закрыта
    возможность делать PR или они
    не хотят открывать свои
    репозитории
    1. Повышать инженерный
    уровень
    2. Интеграция с CI, чтобы
    на этапе предложения PR
    получать отказ по сборке
    или метрикам
    3. Решать кадровые
    вопросы
    Сложности и проблемы Подход к решению
    

    View Slide

24. Неявные изменения,
    зацикленные изменения и
    зависимые релизы
    1. Открыть доски с задами
    2. Создавать задачу на
    доске, если делаешь PR
    Сложности и проблемы Подход к решению
    

    View Slide

25. Сотрудники должны поменять
    привычку жаловаться на баги и
    начать делать PR
    1. Удобная система
    коллаборации,
    например, Github
    2. Целенаправленное
    обучение Inner Source
    3. Конкурсы лучших
    контрибьюторов
    Сложности и проблемы Подход к решению
    

    View Slide

26. Не много ли проблем?
    

    View Slide

27. Зачем Inner Source команде
    продукта?
    Вместо написания всего своими силами, можно
    заниматься только продуктом, а внешние запросы
    принимать в виде готового кода.
    Зачем Inner Source потребителям
    продукта?
    Вместо ожидания в очереди, можно послать pull request
    

    View Slide

28. Agile
    Небольшие кросс-функциональных
    команды сфокусированные на
    целях продукта.
    Выигрыш: скорость.
    Быстрая проверка гипотез, эффективное
    достижение бизнес-целей продукта.
    Проигрыш: масштабируемость.
    При большом количестве продуктов в
    компании рабочий день состоит из
    совещаний по “синхронизации”
    

    View Slide

29. Agile
    Небольшие кросс-функциональных
    команды сфокусированные на
    целях продукта.
    Выигрыш: скорость.
    Быстрая проверка гипотез, эффективное
    достижение бизнес-целей.
    Проигрыш: масштабируемость.
    При большом количестве продуктов
    рабочий день состоит из
    “синхронизаций”
    OSS (Inner Source)
    Совместная работа с открытыми
    репозиториями для всех продуктов
    всей компанией.
    Выигрыш: масштабируемость.
    Без совещаний каждый эффективно
    устраняет барьеры для достижения
    целей своего продукта.
    Проигрыш: скорость.
    Распределенная команда продукта не
    может двигаться также быстро, как
    выделенная команда продукта.
    

    View Slide

30. Agile
    Подходит для компаний с
    небольшим количеством
    продуктов или стартапам.
    OSS (Inner Source)
    Подходит для крупных компаний с
    большим количеством продуктов
    и/или распределенными
    командами.
    

    View Slide

31. Чеклист запуска Inner Source
    ❏ Работающая микросервисная архитектура
    ❏ Система работы с пулреквестами, например, github
    ❏ Эталонный репозиторий
    ❏ Открытые досок с задачами
    ❏ Мотивация сотрудников не противоречит Inner Source
    Kick off, обучение, рейтинги контрибьюторов
    ❏ Измеряем успех
    

    View Slide

32. https://github.com/dicortazar/mana
    ging-inner-source-projects/blob/ma
    ster/measuring/metrics.md#allow-i
    nnovation-in-detail
    

    View Slide

33. Прогноз популярности Inner Source
    1. Внедрение Inner Source облегчается
    DevOps-инструментами, которые
    постоянно улучшаются, и упрощением
    работы с микросервисами.
    2. Если у конкурентов получилось
    внедрить Inner Source, то они окажутся
    впереди, поэтому неизбежно эту
    практику будут применять всё чаще.
    

    View Slide

34. Полезные ссылки
    1. Исследование по сравнению Inner Source и Open Source
    http://www.cs.rug.nl/paris/papers/IST11.pdf
    2. Paypal подводит итоги работы в стиле Inner Source
    https://www.oreilly.com/programming/free/files/getting-started-with-innersource.pdf
    3. Модель оценки зрелости Inner Source
    https://speakerdeck.com/bitergia/a-maturity-model-for-innersource
    4. Collaborate through social coding
    https://www.ibm.com/garage/method/practices/culture/practice_social_coding/overview
    5. Паттерны https://github.com/InnerSourceCommons/InnerSourcePatterns
    6. Сообщество, статьи, learning path и slack https://innersourcecommons.org/
    

    View Slide

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

    View Slide