Создание микросервисов

Джон Ивс (Jon Eaves) из Австралии на сайте RealEstate.com.au охарактеризовал микросервисы как некий код, который может быть переписан за две недели, что имело вполне определенный смысл в качестве основного правила конкретно в его контексте.

Собирайте вместе все, что изменяется по одной и той же причине, и разделяйте все, что изменяется по разным причинам».

У меня слишком часто возникает ощущение, что уже существующие и вполне понятные стандарты и технологии игнорируют в угоду новым стандартам, которые можно реализовать только с помощью совершенно новой технологии, любезно предоставляемой теми же самыми компаниями, которые в первую очередь содействуют разработке новых стандартов!

Пре­ждевременная декомпозиция системы на микросервисы может обойтись весьма дорого, особенно если область вам плохо известна.

подробности реализации всегда изменяются быстрее, чем положенные в их основу размышления

Иногда намеренно допускается замедление работы каких-либо компонентов, чтобы взамен получить какие-то другие преимущества, особенно если такое замедление вполне приемлемо.

Подумайте о нашем монолите как о куске мрамора. Мы могли бы сразу взорвать его, но это редко заканчивается хорошо. Намного разумнее обтесывать кусок постепенно.

Код должен представлять организацию, поэтому пакеты, представляющие ограниченные контенты, в организации должны взаимодействовать точно так же, как взаимодействуют между собой настоящие подразделения организации в данной области бизнеса.

Принятие решений при конструировании систем — это путь компромиссов, и архитектуры микросервисов буквально сотканы из решений, принятых на их основе!

Если объем совместно используемого будет слишком велик, потребляемые сервисы станут завязываться на внутренние представления. Это снизит автономность, поскольку при внесении изменений потребует дополнительного согласования с потребителями.