Нужно ли разделение системы на сервисы, за которые отвечает в полной мере минимум один человек?

Question

[Vitaliy]

Ссылаюсь больше на сервис-ориентированную архитектуру, где отдельная часть (выделенная согласно подцелям бизнеса, а не технологически) является в большей степени независимой как на серверной стороне, так и на клиентской.

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

Назревает такая идея: положить ответственность за каждый сервис на одного человека (как минимум).

Как по мне, это имеет следующие преимущества:

• в роли фронтендера разработчик не должен заботиться о бизнес задаче, которую решают другие сервисы.
  
• нет частых коммуникаций между фронтендером и бэкендером (так как это один и тот же человек)
  
• исключено перекладывание ответственности на фронтендера/бэкендера (проще сделать минимальное API и предложить фронтендеру преобразовывать данные на клиенте так, как ему нужно, но это усложняет ему работу и ухудшает быстродействие приложения)
  
• можно писать код в своем стиле (особенно касается клиентской части, где можно похоливарить о kebab-case против camelCase для имен классов стилей)
  

Недостатки:

• необходимы навыки full track
  
• сложно продолжить поддержку сервиса, если с него ушел (временно или насовсем) единственный разработчик, так как кроме него мало кто имеет понятие как работает сервис внутри
  
  

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

Answer 1

[Иван Шумов]

Во-первых FullStack для сервисной архитектуры это полная задница, уж простите. Необходимо иметь раздельно людей на фронт и бэк. Проблема о которой вы еще не знаете в том что люди имеют свойство меняться и в таком ключе вы можете потерять очень значимую единицу. Бэк должен иметь четкую спецификацию и соответствовать логике работы микросервиса/ сервиса (по секрету - они только размером отличаются ).

Микросервис и их интеграция появляется в системе с разной скоростью и строятся они абсолютно по-разному. Более того в таком подходе вам обязательно нужен тот кто проектирует все это вместе и по отдельности. Обычно это архитектор

Comments

[Максим Федоров]

тестирование -- еще отдельная веточка во всем этом деле :)

[Иван Шумов]

Максим Федоров, оно везде должно быть) вне зависимости от подхода

[Максим Федоров]

Иван Шумов, :)
я про то, как сложно во-первых качественно и там и там код покрыть (фуллстекер должен быть очень крутым, чтобы знать как и на JS написать и на бекенде), потом функционал покрыть, а потом еще и с особенностью архитектуры сервисы затестирвоать, их совместную работу :)

[Иван Шумов]

Максим Федоров, о да

Answer 2

[Saboteur]

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

Comments

[Vitaliy]

Разбитие на микросервисы делается не для того, чтобы за микросервис отвечал один человек

одно не исключает другое, как по мне.

для этого есть ООП

можно подробнее? Как ООП защищает от внесения изменений в одну часть приложения посторонним разработчиком (который изначаль не имплементил эту фичу)?

По остальному, речь идет о сугуьо разработке, а не инфраструктуре и развертыванию

[Saboteur]

Виталий Столяров, Если правильно писать ООП, то объект - самодостаточен и достаточно невелик, чтобы влезть в голову разработчика. То есть софт можно разбить на проекты и каждому отдельному разработчику можно поручить писать свой объект,. Если разработчики умеют писать в принципе - они напишут.
Так можно распарралеливать процесс разработки ПО, увеличивая скорость.

Ну а если разработчик неспособен понять что написано, чтобы изменить фичу, то наверное вы наняли не того человека.

Answer 3

[Александр Михайленко]

Делюсь личным опытом)
Будучи в компании единым бэкенд разрабом, я являюсь и архитектором БД и проектирую архитектуру самого приложения (в моем случае это REST API, и пришлось проектировать структура фронта на Angular 6 ).
Так вот - все это полная ерунда, один человек не может делать все качественно (если он на 15+ лет уже в этой сфере)
На сейчас у меня стоит задача проектировать систему,которая похожа на микросервисную архитектуру, и я уже второй день здесь задаю вопросы у знающих людей и ищу советы, так как раньше такого не делал)
Поэтому чисто по своему опыту говорю - если бизнес задача и нагрузки не требуют сервисов(микросервисов) лучше не проектировать её так.
Если вы один, то потом получите просто уйму обязанностей, это и автоматический деплой систем, их тестирование, их администрирование.
Мне повезло пообщаться с senior разработчиком, так он сказал - чем дольше у вас все на монолите тем вам лучше, иначе потом будете отгребать по полной