03.06.2021, 08:38 | #21 |
Участник
|
И опять мы скатываемся в "технологийщину", я же хотел бы вернуться в "концептуальщину" (простите за грубое слово). Ведь организовать взаимодействие с внешним процессом можно по-разному - этому занятию лет 30 (а то и 50).
На сколько мне известно, термин "микро" был применен из-за того, что при проектировании сервисов стремились максимально упростить его функциональность за счет сужения контекста использования. Упростить настолько, что полная реализация его становилась очевидной и обозреваемой одним разработчиком, чтобы избежать ошибок. Но по факту получается что выделенная в микросервис часть отчуждается из основной системы и в системе остается только её API. Т.е. выделенный кусок должен быть целостным, из него не должно торчать куча необходимых внешних связей (прежде всего логических), которые необходимо реализовывать техническим кардебалетом. Много ли таких частей в средней ERP, низведенных до масштаба "микро"? Мне кажется нет. В основном, это те самые приблудные псы на заднем дворе кухни, у которых от звяканья микроволновки начинают течь слюни. Да они нужны, они создают информационную инфраструктуру. Но существуют за рамками понятия ERP. |
|
03.06.2021, 16:42 | #22 |
Участник
|
Вот хороший пример в тему с SAP, но думаю если б была АХ то было бы тоже самое. Процесс расчета календарей работал на SAP 9ч, переписали за полгода на микросервисы, теперь работает 10 минут
https://habr.com/ru/company/mvideo/blog/560726/ |
|
03.06.2021, 18:45 | #23 |
MCTS
|
А причем тут микросервисы? Просто переписали с нуля отдельно взятый алгоритм.
__________________
I could tell you, but then I would have to bill you. |
|
|
За это сообщение автора поблагодарили: Ivanhoe (2). |
03.06.2021, 20:51 | #24 |
Участник
|
Цитата:
Но как обычно может быть куча нюансов. Типа как с облаком от мс: формально все красиво а по слухам для акс таки необходимо физически, чтобы сервера были рядом, иначе жёсткие тормоза. |
|
04.06.2021, 18:10 | #25 |
Участник
|
Цитата:
Некоторые рекумендуют взять DDD и бить по bounded context. Цитата:
Сообщение от mau
На сколько мне известно, термин "микро" был применен из-за того, что при проектировании сервисов стремились максимально упростить его функциональность за счет сужения контекста использования. Упростить настолько, что полная реализация его становилась очевидной и обозреваемой одним разработчиком, чтобы избежать ошибок.
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. Так как у "микро" нет абсолютно строгого определения, то см. выше. Ориентировочно там написано "no more than a dozen people". |
|
|
За это сообщение автора поблагодарили: mau (1). |
07.06.2021, 12:22 | #26 |
Участник
|
Если по пиццам, то это я и мой коллега как двумя пиццами накормить 12 разработчиков?
__________________
Ivanhoe as is.. |
|
08.06.2021, 14:11 | #27 |
северный Будда
|
Цитата:
Там даже в явном виде написано Цитата:
Это решение довольно давно было поставлено “костылем” в SAP ERP
__________________
С уважением, Вячеслав |
|