Микросервисы в ERP

[mau]

Когда говорят о микросервисах возникает одно ощущение — мешанина.
Начиная от определения, например Фаулера: архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP.
Мешанина туманной концепции (небольшие сервисы) и конкретной реализации.

Теперь к нашим баранам, сиречь повару.
Независимость повара и микроволновки, производителя микроволновки, команды микроволновки и установки микроволновки определяемтя не микросервисной архитектурой (использованием отдельного процесса, отдельного источнока данных и протокола HTTP), а компонентной архитектурой. Вспомним приснопамятную RAD-архитектуру и наборы компонентов для Delphi, покупаемых на Горбушке. Без микроскрвисов.

Динамическое обслуживание кучи микроволновок - архитектура main/worker процессов. Пример - Apache, PostgreSQL (что знаю). Без микросервисов.

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

И особенно доставляет слушать доклады с всевозможных конференция о историях успеха внедрения микросервисной архитектуры (или особенно какой-нибудь Event-Driven Microservice Architecture) в крупных гигантах. Ребята все делают правильно, а получают неуправляемый ворох сервисов и перекосы в системе хранения данных.
Но это неважно, ведь используются самые передовые технологии, правдв?

[axm2017]

Цитата:

Сообщение от mau

Когда говорят о микросервисах возникает одно ощущение — мешанина.
...
Динамическое обслуживание кучи микроволновок - архитектура main/worker процессов. Пример - Apache, PostgreSQL (что знаю). Без микросервисов.

Микроволновка вполне себе работает как самостоятельная вещь с вполне конкретной целью - греет. Пихай яблоки и прочее и грей на выходе получишь какую то обработанную пищу. Микросервис.

Цитата:

Сообщение от mau

Единственное применение микросервисов - использование другой технологии (скорее всего, языка программирования).

Откуда такое мнение?
Естественно как у любой архитектуры есть + и - и бездумно применять не стоит

ps домохозяйкам на заметку
https://habr.com/ru/post/249183/
Не фан микросервисов (мне например не нравятся слухи об invoice машинах и прочем внутри MS как отдельных сервисах так как беглый опрос показывает что MS ники видят это как black boxes со всеми вытекающими) но имеет место быть.

[belugin]

Цитата:

Сообщение от mau

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

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

В случае микросервиса, хранение и администрирование лежит на команде, которая поддерживает микросервис, она может даже сменить вид хранилища по желанию.

Цитата:

Сообщение от mau

Динамическое обслуживание кучи микроволновок - архитектура main/worker процессов. Пример - Apache, PostgreSQL (что знаю). Без микросервисов.

Да, процессам теперь придется взаимодействовать через IPC, если хочется горизонтального масштабирования (добавлением дополнительных VM) придется учится межсетевому взаимодействию. Если не хочется тащить в worker процессы код и данные, которые в них не используются, придется запускать не копии одного приложения, а отдельные приложения для разных видов задач. Что-то это напоминает.

Цитата:

Сообщение от mau

Единственное применение микросервисов - использование другой технологии (скорее всего, языка программирования).

Еще хранилище, например.

Цитата:

Сообщение от mau

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

Все верно. Если не думать о стоимости. (вон фейсбук свой PHP написал) Языки связаны с технологиями. Сборка мусора на .NET, JS, Python и GO устроена по-разному. На objective C неудобно писать под Android и так далее, для DataScience много либ и материалов под питон.

Цитата:

Сообщение от mau

И особенно доставляет слушать доклады с всевозможных конференция о историях успеха внедрения микросервисной архитектуры (или особенно какой-нибудь Event-Driven Microservice Architecture) в крупных гигантах. Ребята все делают правильно, а получают неуправляемый ворох сервисов и перекосы в системе хранения данных.
Но это неважно, ведь используются самые передовые технологии, правдв?

Можно сослаться на примеры, пожалуйста? Что за доклады? Кто получил неуправляемый ворох?

[mau]

Цитата:

Сообщение от belugin

Можно сослаться на примеры, пожалуйста? Что за доклады? Кто получил неуправляемый ворох?

Например, тут
Понятно, что никто не выйдет и не скажет "Ребята, мы обделались". Все будут говорить о проблемах и их решении.
Но послушайте, с какими проблемами они столкнулись на пустом месте. Именно из-за того, что у них куча отдельных микросервисов с собственными источниками данных.

[mau]

И опять мы скатываемся в "технологийщину", я же хотел бы вернуться в "концептуальщину" (простите за грубое слово). Ведь организовать взаимодействие с внешним процессом можно по-разному - этому занятию лет 30 (а то и 50).

На сколько мне известно, термин "микро" был применен из-за того, что при проектировании сервисов стремились максимально упростить его функциональность за счет сужения контекста использования. Упростить настолько, что полная реализация его становилась очевидной и обозреваемой одним разработчиком, чтобы избежать ошибок.

Но по факту получается что выделенная в микросервис часть отчуждается из основной системы и в системе остается только её API. Т.е. выделенный кусок должен быть целостным, из него не должно торчать куча необходимых внешних связей (прежде всего логических), которые необходимо реализовывать техническим кардебалетом.

Много ли таких частей в средней ERP, низведенных до масштаба "микро"? Мне кажется нет. В основном, это те самые приблудные псы на заднем дворе кухни, у которых от звяканья микроволновки начинают течь слюни. Да они нужны, они создают информационную инфраструктуру. Но существуют за рамками понятия ERP.

[belugin]

Цитата:

Сообщение от mau

И опять мы скатываемся в "технологийщину", я же хотел бы вернуться в "концептуальщину" (простите за грубое слово). Ведь организовать взаимодействие с внешним процессом можно по-разному - этому занятию лет 30 (а то и 50).

Микросервис это и есть "технологийщина", концептуальщина это как на них разбивать?
Некоторые рекумендуют взять DDD и бить по bounded context.

Цитата:

Сообщение от mau

На сколько мне известно, термин "микро" был применен из-за того, что при проектировании сервисов стремились максимально упростить его функциональность за счет сужения контекста использования. Упростить настолько, что полная реализация его становилась очевидной и обозреваемой одним разработчиком, чтобы избежать ошибок.

How big is a microservice?
Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services.

This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn't be lumped under one microservices label. At the moment we think it's better to group them together, but it's certainly possible that we'll change our mind as we explore this style further.

Цитата:

Сообщение от mau

Много ли таких частей в средней ERP, низведенных до масштаба "микро"?

Так как у "микро" нет абсолютно строгого определения, то см. выше. Ориентировочно там написано "no more than a dozen people".