HotWaterMusic Jul 3 2015 at 17:19

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

16 min

33K

Website development *System Analysis and Design *Designing and refactoring *Microservices *

Translation

+22

Comments 7

afiskon Jul 3 2015 at 18:14

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

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

igor_suhorukov Jul 3 2015 at 23:02

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

vaniaPooh Jul 3 2015 at 21:13

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

UFO just landed and posted this here

googol Jul 4 2015 at 10:44

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

dim_s Jul 4 2015 at 10:38

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

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

potan Jul 4 2015 at 15:34

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