С как компромис А и В (не говоря о Е и Д) уже сложнее просто суммы частного случая для А и частного (очень похожего) случая для Б.
Не всем очевидна эта истина.
Если мы начинаем вносить правки в функционал блока C в зависимости от «хотелок» зависимых систем — уже что-то пошло не так! Тем более, если эти правки специфичны.
Дык вот реальность во многих коммандах именно такая. Плохо или с недостатком опыта обдуманное (см. ссылку на «Что видишь, то и есть») выделение "общего кода"…
Причем на моей памяти именно аргумент DRY, который не так легко паррировать в тех же самых кругах ;)
Вместо конфига, описывающего всё, лучше использовать дефолты, которые при желании можно переопределять в конфиге.
Я боюсь это как минимум не точно.
Дело не в дефолтах, а в подходе с созданием конвенций и спецификаций которые впринципе делают конфигурацию ненужной. В этом сила брат.
Вы не должны ничего копипастить.
Вам предлогают принцип DRY не рассматривать как принцып "Don’t Repeat Anything" или "Copy and Paste is bad"
Если вы так это понимаете то вы конечно не один. Я тоже долго так думал, пока не стал решать прблемы в системе с микросервисами и смотреть что думет люди по этому поводу…
Оказалось, что принцип то о knowledge:
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
От того, что мы не опишем контракты между сервисами, они вдруг пропадут? Ничего подобного, просто эти интерфейсы сделаются неявными.
Контракт описан не библиотекой. И описан конечно же явно. Я привел REST сервис в пример, контракт REST сервиса очень явный…
Допустим вы написали Сервис User, которы умеет прочитаь и создать юзера. Но решили создать библитеку которая представлят обьект этого самого юзера напримэр на яве… Вы конечно же эту библиотеку обязаны испольтовать везде где этот User учавствует… в 100 сервисах…
и конечно же апдейтить все 100 сервисов ели в узере что-то пересмотрелось… Ну покрайней мере вам надо перепроверить везде… Удачи и держитесь там ;)
П.С. Кстати что если вы захотите написать новый сервис на Golang? Жесткое следование неправильного пятого DRY тоже может препятствовать это-му стремлению, библиотеки то на яве ;) Но это не основной аргумент, просто пища для размышления.
Упрощали? Боже упаси… Чем же все эти SOAP/WSDL упрощали… Это было достаточно жесткое соединение… Системы были достаточно не поворотливые… Вы писали все эти WSDLины? Версионировали? Это же застрел ;) Меня больше не заставите ;)
BPM
Да это хорошая тема но независима от SOAP/WSDL/ESB.
И те Ентерпрайзные дорогущие и абсолютно баговые (Oracle BPM Suite) ситемы которые работали (иногда исключительно ) через ESB вымирают! Слава богу кстати!
С появлением и развитием нормального BPMN и например Camunda (которая опен/сорс, комюнити дривен) BPM стала соотвествовать и принесла те фишки про которые в книжках ещем может и 15 лет назад писали, но которые реальные проекты из бизнеса редко приносили (по многим причинам)
П.С. возможно у меня специфический взгляд на это. Я со всем этим в Германии столкнулся.
Валидные все замечания… Под всеми подпишусь…
Вот только тут автор не до-раскрыл…
Чего только люди ни придумают, лишь бы копипастить не бросать.
Библиотеки "не нужны" которые 1) общие 2) описывают интерфейс между сервисами… Лучше копипастить пару строк, но быть абсолютно независимым в релиз-цыклах отдельных сервисов… Если вы сможете это с бибилиотеками, то без проблем.
Как пример: к простому REST сервису не надо писать спиальную клиентску библиотеку. Возможно затрыты на апдейт и синхронизацию этой библиотеки слишком привяжут развитие сервиса, к релиз-цыклам этой либы.
Это о том что необдуманыне зависимости, в долгосрочном цыкле системы, легко становятся опаснее чем любой копи-пастинг.
SOA может и похожа определением (словестным) на MSA, но ИМХО речь о другом и статья это не плохо показывает.
Я свою проф. деятельность начинал в Концерне и потом консалтил еще во времена популярности SOA.
И мне кажется бизнес в свое время понял SOA так:
сервисы уровня фирмы (я начал с очень крупной, постепенно уменьшая :) ),
интеграция через монстрезный ESB
громоские протоколы
фокус на интеграцию (и орхестрацию) существующих в предприятии ситем. Дальше подключили процессы и BPM (на самом деле это самое интересное)
Работают "Архитекторы" ;)
В Микросервисной архитектуре скорее надо применить "zoom". Тоесть речь идет о более технических сущностях конечно же в контексте современных представлений (или догм):
каждый сервис это отдельный процесс.
делить рервисы можно не только по бизнес фичам но и "как угодно", например по техническим предпочтениям скалируемости одних или других сущностей.
В мире реально существовавшего SOA, попадавшегося мне на глаза, делили по бизес фичам (capability). А часто вопрос и не задавался как делить, потому что
закон Конвея (“Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”), что есть на то и пишут заглушки.
Каждый сервис, можно/нужно разрабатывать, тестировать и деплоить в продукцию отдельно от остальных!
Набор МИКРО сервисов могут запртосто быть заменой одного лишь монолит-сервиса класса SOA 10 летней давности. Видел и такое.
Влияние современности: DevOps, Agile Teams, Cloud, Containers, Eventualy Consistency
Работают Девелоперы, ДевОпсы и если остались Архитекторы.
Что-то в этом роде.
П.С. заранее прошу прощение, за возможные странности моего русского языка .
В чем таки достоинства Reactive forms в сравнении с Template-driven?
Template-driven вариант мне кажется более интуитивным и простым. Может быть это связано с тем что я не видел каких-то особых ситуаций ( Я во фронтэнде только набегами, раз в пятилетку, на ангуляре первый серьезный проект)? Мог-бы кто-то пролить свет на это?
Не умалая полезности статьи, было бы интересно узнать не только о том что падает, но общее впечатление:
Как выглядит ваш кластер?
Как перформанс?
И что совместимостью с драйвером PostgreSQL?
Дело в том что этот проект вроде как OpenSource эквивалент гугловскому Spanner. Ну по по "духу" покрайнейм мере, что делает его крайне интересным!
Но как-то отпугивает теперь такая вот сыроватость.
Конечно…
Статья вообще о отсутствии стратегии "Докер Инк". а тулы изначально Open Source и в тыкву точно не превротится ничего.
"Переживания" о стратегии фирмы были давно и (под давлением общественности) разрабы позоботились о нормальном состоянии компонентов.
Попили их на сомостоянельные части как отдельные проекты с отдельным цыклом и АПИ между ними стандартизировали. Об этом были на Хабре статъи..
А зачем вам альтернатива...?
Что не работает?
Все же в Моби распилили на модули и опенсорснули…
Хорошие части никуда не денутся а плохим придет альтернатива…
Скорее в статье мне не хватает еще одной вещи…
С как компромис А и В (не говоря о Е и Д) уже сложнее просто суммы частного случая для А и частного (очень похожего) случая для Б.
Не всем очевидна эта истина.
Дык вот реальность во многих коммандах именно такая. Плохо или с недостатком опыта обдуманное (см. ссылку на «Что видишь, то и есть») выделение "общего кода"…
Причем на моей памяти именно аргумент DRY, который не так легко паррировать в тех же самых кругах ;)
Похожий опыт с ECS и Terraform. Терраформ в отличии от ECS очень нравится кстати...
Ну и конечно ждем это, но пока никаких дат не озвучено кроме 2018. Надеюсь не Q4
Я боюсь это как минимум не точно.
Дело не в дефолтах, а в подходе с созданием конвенций и спецификаций которые впринципе делают конфигурацию ненужной. В этом сила брат.
Конечно, но на огромные суммы у небольшой группы людей.
да. + не нужен ESB, нарушал он принцип dump pipe.
P.S. дух временени Хабр: Разбор доклада Ивана Круглова «Строим свой Service Mesh»
Вы не должны ничего копипастить.
Вам предлогают принцип DRY не рассматривать как принцып "Don’t Repeat Anything" или "Copy and Paste is bad"
Если вы так это понимаете то вы конечно не один. Я тоже долго так думал, пока не стал решать прблемы в системе с микросервисами и смотреть что думет люди по этому поводу…
Оказалось, что принцип то о knowledge:
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
Контракт описан не библиотекой. И описан конечно же явно. Я привел REST сервис в пример, контракт REST сервиса очень явный…
Допустим вы написали Сервис User, которы умеет прочитаь и создать юзера. Но решили создать библитеку которая представлят обьект этого самого юзера напримэр на яве… Вы конечно же эту библиотеку обязаны испольтовать везде где этот User учавствует… в 100 сервисах…
и конечно же апдейтить все 100 сервисов ели в узере что-то пересмотрелось… Ну покрайней мере вам надо перепроверить везде… Удачи и держитесь там ;)
П.С. Кстати что если вы захотите написать новый сервис на Golang? Жесткое следование неправильного пятого DRY тоже может препятствовать это-му стремлению, библиотеки то на яве ;) Но это не основной аргумент, просто пища для размышления.
Упрощали? Боже упаси… Чем же все эти SOAP/WSDL упрощали… Это было достаточно жесткое соединение… Системы были достаточно не поворотливые… Вы писали все эти WSDLины? Версионировали? Это же застрел ;) Меня больше не заставите ;)
Да это хорошая тема но независима от SOAP/WSDL/ESB.
И те Ентерпрайзные дорогущие и абсолютно баговые (Oracle BPM Suite) ситемы которые работали (иногда исключительно ) через ESB вымирают! Слава богу кстати!
С появлением и развитием нормального BPMN и например Camunda (которая опен/сорс, комюнити дривен) BPM стала соотвествовать и принесла те фишки про которые в книжках ещем может и 15 лет назад писали, но которые реальные проекты из бизнеса редко приносили (по многим причинам)
П.С. возможно у меня специфический взгляд на это. Я со всем этим в Германии столкнулся.
Валидные все замечания… Под всеми подпишусь…
Вот только тут автор не до-раскрыл…
Библиотеки "не нужны" которые 1) общие 2) описывают интерфейс между сервисами… Лучше копипастить пару строк, но быть абсолютно независимым в релиз-цыклах отдельных сервисов… Если вы сможете это с бибилиотеками, то без проблем.
Как пример: к простому REST сервису не надо писать спиальную клиентску библиотеку. Возможно затрыты на апдейт и синхронизацию этой библиотеки слишком привяжут развитие сервиса, к релиз-цыклам этой либы.
Это о том что необдуманыне зависимости, в долгосрочном цыкле системы, легко становятся опаснее чем любой копи-пастинг.
Например?
Опять же, может это просто не входит в определение, но никто вам не мешает включить все плюшки ;)
SOA может и похожа определением (словестным) на MSA, но ИМХО речь о другом и статья это не плохо показывает.
Я свою проф. деятельность начинал в Концерне и потом консалтил еще во времена популярности SOA.
И мне кажется бизнес в свое время понял SOA так:
В Микросервисной архитектуре скорее надо применить "zoom". Тоесть речь идет о более технических сущностях конечно же в контексте современных представлений (или догм):
В мире реально существовавшего SOA, попадавшегося мне на глаза, делили по бизес фичам (capability). А часто вопрос и не задавался как делить, потому что
закон Конвея (“Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”), что есть на то и пишут заглушки.
Что-то в этом роде.
П.С. заранее прошу прощение, за возможные странности моего русского языка .
Теперь ясно. Спасибо.
Тут по подробнее пожалуйста...
В чем таки достоинства Reactive forms в сравнении с Template-driven?
Template-driven вариант мне кажется более интуитивным и простым. Может быть это связано с тем что я не видел каких-то особых ситуаций ( Я во фронтэнде только набегами, раз в пятилетку, на ангуляре первый серьезный проект)? Мог-бы кто-то пролить свет на это?
спасибо!
Не умалая полезности статьи, было бы интересно узнать не только о том что падает, но общее впечатление:
Как выглядит ваш кластер?
Как перформанс?
И что совместимостью с драйвером PostgreSQL?
Дело в том что этот проект вроде как OpenSource эквивалент гугловскому Spanner. Ну по по "духу" покрайнейм мере, что делает его крайне интересным!
Но как-то отпугивает теперь такая вот сыроватость.
Простите, спешил. Русской клавы нет. Я знаю тут это не прощают :((
Позор уже не отмыть.
Конечно…
Статья вообще о отсутствии стратегии "Докер Инк". а тулы изначально Open Source и в тыкву точно не превротится ничего.
"Переживания" о стратегии фирмы были давно и (под давлением общественности) разрабы позоботились о нормальном состоянии компонентов.
Попили их на сомостоянельные части как отдельные проекты с отдельным цыклом и АПИ между ними стандартизировали. Об этом были на Хабре статъи..
А зачем вам альтернатива...?
Что не работает?
Все же в Моби распилили на модули и опенсорснули…
Хорошие части никуда не денутся а плохим придет альтернатива…
Спасибо. Надо пробовать!