Компромиссы микросервисов

[afiskon]

Благодарю за перевод.

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

[igor_suhorukov]

Распределенность — чаще дейсвительно минус. Хотя модульность кода, например OSGI, позволяет деплоить сервисы как в одном процессе, так и в нескольких процессах на нескольких узлах DOSGI. Так что, в большом проекте, подход разделения на микросервисы может быть оправдан. Но и порождает новые сложности

[vaniaPooh]

Были недавно на конференции RootConf в Москве, так вот там один товарищ из Spotify как раз рассказывал, что у них все на микросервисах построено.

[googol]

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

[dim_s]

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

sdtimes.com/martin-fowler-monolithic-apps-first-microservices-later

[potan]

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