У микросервисов есть несомненные преимущества. Однако, как когда-то Scrum, микросервисы поддаются все большей компрометации от бездумного внедрения.
Например, кто-то услышал, что микросервисы - это автономные команды, автономная поставка. Это, действительно, так, однако беда случается тогда, когда решение перейти на микросервисы становится политическим, а не продиктованным потребностью бизнеса с четкой оценкой все требуемых изменений в архитектуре, орг. структуре, процессах, инфраструктуре.
И тут начинается самое интересное. Оказывается, что отсутствует хотя бы гигиенический минимум инженерных практик и процессов, все тестирование ручное, все развертывание ручное, разработчики работают по четкому тз и не особо погружены в предметную область...ну то есть все как-то работает и даже вроде неплохо, и фичи выпускаются «быстро» и продукт зарабатывает.
Только почему-то в совершенно не инженерной области все больше проблем. Программисты уходят к конкурентам (и не одни, а со своими знаниями), высокая скорость поддерживается героизмом по вечерам и выходным, все больше дефектов, да и затраты на кофе в компании выросли кратно.
Но задачи выполняются. И в таком «типа скраме» звучит «нам нужны микрсоервисы».
Нет. Не нужны.
Для начала нужны простые вещи:
1. Визуализация потока создания технологической ценности (то, что станет delivery pipeline)
2. Выявление потерь в этом потоке
3. Готовность к устранению этих потерь (это может привести и к политике работы с help desk и процессам взаимодействия с безой и инвестициям в обучение/автоматизацию тестирования)
4. Обложить все что можно телеметрией. Иначе мы даже эффект от перехода на микросервисы не оценим.
5. Сделать систему разработки предсказуемой и надежной. Так, чтобы планировать было можно и выполнять работу без постоянных переработок. Для этого существует исчерпывающий набор практик на сокращение объемов незапланированной работы (в том числе вносящей серьезный вклад в неопределенность).
Параллельно можно провести Event Storming для создания стратегического дизайна, выделения модулей, целевого рефакторинга в сторону слабо связанных модулей.
И вот, когда разработчики перестанут уходить, когда все поймут, что это не потогонка в погоне на индивидуальным KPI на внедрение микросервисов, тогда можно переходить.
Интересно, что к этому моменту скилы прокачиваются так, что в целом нередко потребность в микросервисах отпадает. Так и хорошо, если мы можем обеспечить бизнес-результат, не добавляя сложность в продукт.
Например, кто-то услышал, что микросервисы - это автономные команды, автономная поставка. Это, действительно, так, однако беда случается тогда, когда решение перейти на микросервисы становится политическим, а не продиктованным потребностью бизнеса с четкой оценкой все требуемых изменений в архитектуре, орг. структуре, процессах, инфраструктуре.
И тут начинается самое интересное. Оказывается, что отсутствует хотя бы гигиенический минимум инженерных практик и процессов, все тестирование ручное, все развертывание ручное, разработчики работают по четкому тз и не особо погружены в предметную область...ну то есть все как-то работает и даже вроде неплохо, и фичи выпускаются «быстро» и продукт зарабатывает.
Только почему-то в совершенно не инженерной области все больше проблем. Программисты уходят к конкурентам (и не одни, а со своими знаниями), высокая скорость поддерживается героизмом по вечерам и выходным, все больше дефектов, да и затраты на кофе в компании выросли кратно.
Но задачи выполняются. И в таком «типа скраме» звучит «нам нужны микрсоервисы».
Нет. Не нужны.
Для начала нужны простые вещи:
1. Визуализация потока создания технологической ценности (то, что станет delivery pipeline)
2. Выявление потерь в этом потоке
3. Готовность к устранению этих потерь (это может привести и к политике работы с help desk и процессам взаимодействия с безой и инвестициям в обучение/автоматизацию тестирования)
4. Обложить все что можно телеметрией. Иначе мы даже эффект от перехода на микросервисы не оценим.
5. Сделать систему разработки предсказуемой и надежной. Так, чтобы планировать было можно и выполнять работу без постоянных переработок. Для этого существует исчерпывающий набор практик на сокращение объемов незапланированной работы (в том числе вносящей серьезный вклад в неопределенность).
Параллельно можно провести Event Storming для создания стратегического дизайна, выделения модулей, целевого рефакторинга в сторону слабо связанных модулей.
И вот, когда разработчики перестанут уходить, когда все поймут, что это не потогонка в погоне на индивидуальным KPI на внедрение микросервисов, тогда можно переходить.
Интересно, что к этому моменту скилы прокачиваются так, что в целом нередко потребность в микросервисах отпадает. Так и хорошо, если мы можем обеспечить бизнес-результат, не добавляя сложность в продукт.