GK
Стремление SOA к максимизации Reuse и оркестрации приводит к выстраиванию технических границ, а не бизнесовых
Size: a a a
2017 May 23
GK
Microservices более точно отвечает на вопрос, как достичь SOA Strategic goals: Increased organizational agility и Increased business and technology alignment
E
Microservices более точно отвечает на вопрос, как достичь SOA Strategic goals: Increased organizational agility и Increased business and technology alignment
Скорее, даёт возможность
GK
Скорее, даёт возможность
Всё же и SOA позволяет, в теории, достичь свои целей. Но в Microservices происходит переосмысление, как лучше это делать
E
Я имел ввиду, что микросервисы не отвечают более точно, а дают возможность ответить более точно. Но часто такой возможностью не пользуются в обоих случаях, следуя только очевидным внешним признакам
OT
https://xebialabs.com/resources/whitepapers/exploring-microservices-14-questions-answered-by-experts/#.WSM2T4E-Bu4.telegram
Exploring Microservices: 14 Questions Answered By Experts
Exploring Microservices: 14 Questions Answered By Experts
Бросьте файл в чат, кто скачал?
GK
Я имел ввиду, что микросервисы не отвечают более точно, а дают возможность ответить более точно. Но часто такой возможностью не пользуются в обоих случаях, следуя только очевидным внешним признакам
Евгений, понял твою мысль, согласен.
ДЛ
Бросьте файл в чат, кто скачал?
AS
Microservices более точно отвечает на вопрос, как достичь SOA Strategic goals: Increased organizational agility и Increased business and technology alignment
Мне нравится именно такая четкая формулировка, вместо расплывчатой "дает возможность". Концепция SOA изначально была слишком выхолощенной что-ли, в результате чего превратилась в этакую дубину для Enterprise Architect с помощью которой он загоняет всех в будущее "никогда".
MS
Всем привет! К ближайшему вебинару я презентацию нарисую сам, а вот к следующему уже не буду. Разделю заготовку на [микро]тезисы и выложу в наш чатик для обсуждения :-)
MS
А самая большая проблема при подготовке - где взять оппонентов для предварительного обсуждения ))
MS
А самая большая проблема при подготовке - где взять оппонентов для предварительного обсуждения ))
а какой позиции надо оппонировать?)
GK
А самая большая проблема при подготовке - где взять оппонентов для предварительного обсуждения ))
Готов помочь с оппонированием )
MS
Ну, кстати, на мой взгляд самое неочевидное свойство из Фаулера - 6. Decentralized Data Management. Очень часто народ реализует в виде микросервисов обработчики сообщений, а данные продолжает хранить в централизованной банке
GK
Мне нравится именно такая четкая формулировка, вместо расплывчатой "дает возможность". Концепция SOA изначально была слишком выхолощенной что-ли, в результате чего превратилась в этакую дубину для Enterprise Architect с помощью которой он загоняет всех в будущее "никогда".
SOA заложила фундамент для Service Based архитектур, но оказалась слишком сложной и не достаточно конкретной в важных вопросах. Взять хотя бы таксономию сервисов, она слишком сложная в SOA и не выглядит естественной.
MS
Я сделаю презентацию в виде _микротезисов_ 😇, чтоб каждый из них отдельно можно было потом здесь пообсуждать
E
... и одну большую статью сначала, потому что "Monolith first" ;)
GK
Ну, кстати, на мой взгляд самое неочевидное свойство из Фаулера - 6. Decentralized Data Management. Очень часто народ реализует в виде микросервисов обработчики сообщений, а данные продолжает хранить в централизованной банке
На это есть ответ в SOA: Service Autonomy :) Каждый сервис должен монопольно владеть своими ресурсами, в том числе данными. Данные должны быть инкапсулированы в сервисах. Если говорить о MonolithFirst, то на начальном этапе данные разных сервисов могут жить в одной базе, но решение нужно дизайнить так, чтобы данные можно было быстро засплитить и перенести вместе с сервисом. Я сам так делал.
MS
... и одну большую статью сначала, потому что "Monolith first" ;)
Вот-вот :)