Зачем изобретать велосипед: или как Группа «М.Видео-Эльдорадо» развивает собственную микросервисную архитектуру

[Triproductivity]

Нет вероятности, что рано или поздно придется слезать с собственного велосипеда обратно? Какой экономической или иной эффект в итоге? Может не увидел?

[mvideo]

Если внимательно прочитать, то в тексте достаточно много про полученные эффекты. Вот, например:

Для примера сегодня полный прогон (со всеми видами тестирования юнитов, контрактные, интеграционные) CI\CD Pipeline для работающего продуктивного бизнес-приложения ─ а это около 12-15 микросервисов связанных между собой) составляет около 31 минуты что на 7-8 минут меньше показателей начала 2020 года.

[pin2t]

К сожалению Oracle безнадежно прошляпил популяризацию контейнеров и облаков. И не смог развернуть Java в эту сторону. Java со своей тяжелой JVM годами затачивалась под выполнение серверов приложений типа Tomcat и IBM <что-то там> и продолжает развиваться в том же направлении. JVM эффективно работает когда выполняется на железной машине и целиком владеет всеми ресурсами.

Java прекрасный эзык, но для микросервисов и kubernetes не приспособлен.

Товарищи из Graal что-то делают, но там как-то у них все ещё куча ограничений, баги и очень медленная компиляция. И в целом поскольку они немного в другую сторону от Java-way идут, поэтому это направление скорее всего бесперспективно.

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

[sapl]

По своему опыту: Go выигрывает у Java только в случаях необходимости реализации простых, но нагруженных микро-сервисов /Хотя при желании можно и Spring-boot приложение затюнить, например заменив tomcat на netty (если вообще нужен веб-сервер в нем).

Для задач ентерпрайза с кучей бизнес логики — как раз таки Go меньше подходит, приходится писать велосипеды и кучу сложно-теструемого кода, когда как Java именно под такие задачи заточена.

ИМХО — симбиоз вполне возможен, на то это и микросервисы.

[sapl]

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

[mvideo]

Для описание и документирование используем автосдокментирование через open-api.
Для взаимосвязей и описание меж сервисного взаимодействия пока никакой автоматизации нет, но планируем заняться этим вопросом после внедрения и перевода полностью микросервисного взаимоjдействия на Service Mesh на базе Istio + (Admiral).

[sapl]

да, я имел ввиду именно как описать меж-сервисные зависимости —
какие сервисы зависят от текущего, от каких он зависит, в каком домене/проекте, кто отвечает и т.д…
+ взаимодействие может быть не только через REST API (через очереди, базы и другие протоколы)

[TechNoBase]

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