- повышение автономности команд
- сокращение TTM (time-to-market)
- эффективное масштабирование
- повышение отказоустойчивости
- поддержка роста компании
- внедрение новой технологии
❗️Губительным же для проекта перехода автор считает как отсутствие цели, так и желание достичь множество целей одновременно. По этому поводу автор высказывается:
Однако в реальности люди часто пытаются изменить не одну вещь, а сразу много. Это приводит к путанице приоритетов, быстро увеличивается объем работ, задерживая получение каких-либо выгод.
К примеру, мы решаем, что изменение архитектуры приложения позволит справляться с ростом трафика: "Ну, если беремся за микро-сервисы, то одновременно с этим можем сделать команды автономнее! И это дает нам отличный шанс попробовать Kotlin в качестве языка программирования!"
Прежде чем вы придете в себя у вас уже будет масштабная инициатива внедрения множества новшеств, которые накинули к плану работ "для верности".
В такой ситуации микро-сервисы становятся запертыми как подход!
Важно отделить мотивирующий стержневой мотив от любых второстепенных выгод, которые вы также хотели бы получить. В описанном примере масштабирование системы - самый важный мотив. Остальные работы, не направленные на достижение главной цели, должны отойти на задний план.
Продолжим пример: мы целимся в масштабирование. А оно достигается за счет перераспределения нагрузки на выделенные сервисы.
По заветам автора, держа в уме одну главную цель, составляем простой план:
- сначала выделяем сервис "как есть" с минимально необходимыми изменениями. Чтобы достичь результата (перераспределить нагрузку) - нужно срезать углы, а любой оверхед не допустим (поэтому никаких изменений)
- дальше в рамках автономного развития сервиса фокусно проводим оптимизации и другие улучшения.
Кажется все просто, но на деле появляется ряд второстепенных требований, которые, не будучи основным мотивом, кратно увеличивают сроки проекта из-за возрастающей когнитивной нагрузки:
- перейти на другой стек: к примеру декомпозируем Ruby-монолит в сервисы на Golang. Для выноса сервиса необходимо разобраться в текущей реализации, локализовать ее и перенести код. У рубистов дополнительная когнитивная нагрузка появится в последнем пункте, у голанг-разработчиков - сразу в первом.
- исправить в процессе переезда ошибки и уязвимости. Изменение в поведении системы ведут к невозможности сравнить обе реализации (монолитную, как эталон, и новую сервисную). Приходится держать в уме эту "разницу". А если фиксов много?
- улучшить перформанс или кардинально поменять бизнес-процесс, и как следствие обоих пунктов, - сделать новую систему, идеально заточенную под актуальные требования. Проблема проявится при интеграции "нового подхода" со старым, и прийдется временно адаптировать новое под старое.
В качестве тулинга по выстраиванию и удержанию приоритетов Ньюман предлагает систему "ползунков":
- выписать цели и расставить их приоритеты на текущий момент (это нормально, если позже приоритеты изменятся) в формате ползунков указывая вес (к примеру, от 0 до 10)
- выбрать главную цель, следовать ей
- постоянно использовать диаграмму для принятия и агрументации технических и организационных решений
Последний пункт не очевидный, но в разы ценней первого: регулярное обращение к приоритетам - помогает избежать расфокуса, не потерять понимание, и не упустить смысл в процессе.