Настоящая проблема микросервисов
Сегодня увидел новую статью с разоблачением хайпа вокруг микросеовисной архитектуры. Это было понятно ещё на заре её популярности, что рано или поздно хайп сменится трезвыми оценками, а спад будет обозначен разоблачениями. Как до этого было много раз с другими подходами и технологиями (где сейчас монады, Кафка, голанг?)
Удивительно, но архитектурная проблема с монолитами/микросервисами/SOA (и иже) лежит совсем не в их плоскости. Она глубже и серьёзней.
Если бы сейчас ко мне подошли и спросили: "как бы ты построил новое распределённом приложение Х, если бы был не ограничен ресурсами?" Я бы уверенно ответил: "ни одним из этих способов".
Во всём IT фундаментальны и нередуцируемы только две сущности: процесс и данные. Процессы связываются друг с другом в сложные конвейеры, разделённые общими протоколами данных и слоями трансляции.
Существенная логика приложения (которую ещё называют "бизнес-логикой") — это как раз набор таких процессов, которые, в свою очередь, полагаются на процессы нижележащие и инфраструктурные.
Так вот: выбор между монолитом или микросервисами (или чем угодно ещё) — это не выбор архитектуры бизнес-логики, это выбор инфраструктуры, хостинга, для бизнес-логики и к самой бизнес-логике не должен иметь никакого отношения. Это всё равно, что каждый раз проектировать свой диспетчер ОС или свой Kubernetes, выбирая архитектуру для транзакции зачисления денег на счёт клиента.
Бизнес-логике должно быть абсолютно всё равно, в каком процессе или на какой виртуальной машине она запущена. То, что действительно нужно — общая среда исполнения, которая бы забрала на себя этот бойлерплейт распределённых систем, а программисты и архитекторы могли бы сосредоточится на конкретной задаче, не занимаясь каждый раз вопросами инфраструктуры и сетевых взаимодействий.
Так что если бы у меня было достаточно ресурсов, я бы привёл инфраструктурный слой в порядок: что бы бизнес процессы не заботились о своём хостинге, а выбор между монолитом и микросервисами ушёл в прошлое как нерелевантный.