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