MICROSERVICES_ARCH Telegram 474
В продолжение предыдущего поста. Вообще, в нашей индустрии, много проблем, связанных с поверхностным пониманием тех или иных технологий, подходов.

Оно и не мудрено, - индустрия молодая, даже в фундаментальных аспектах эксперты порой расходятся во мнениях.

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

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

Если взять ту же микросервисную архитектуру. Я уже упоминал, что мне здесь немного повезло, был проект почти 20 лет назад, в котором мы реализовали как раз то, что сейчас называется микросервисной архитектурой. В том же проекте был реализован Event Sourcing, хотя я в то время даже слова такого не слышал.

И я такой был 100% не один, уверен, что реализаций были сотни, тысячи. И микросервисный стиль никто не придумывал, он уже был, активно использовался, применялся, этому стилю всего лишь дали имя и попытались описать характеристики.

Термин получился может и не самый удачный для описания сути, но максимально хайповый, тут не отнять. Характеристики тоже попытались описать, получилось как получилось, попробуйте на досуге взять свое архитектурное решение и формализовать его характеристики для того, чтобы его можно было повторно использовать и развивать вокруг него теоретико-практическую базу. Этих характеристик будет практически бесконечное число, так что вам придется взять все существующие стили и выделить:
1. Те, что отличают от других
2. Те, что четко определяют ваш архитектурный стиль в своей совокупности

Я обобщаю и выделяю паттерны из конкретных сессий event storming и это максимально неблагодарное занятие.

Вернемся к описанию архитектурного стиля и вспомним фундаментальные труды по архитектуре. Как там описаны стили? Текстом в свободной форме. Какой-то формализм, конечно, присутствует, но в целом «что вижу - то описываю». Проблема здесь в том, что даже если трое видят одно и то же, описать они это могут совершенно по-разному. А те, кто прочитают, каждый кто прочитает, - могут и понять по-своему и написать по статье на хабре или медиуме со своим понимаем, и вот у нас уже 100500 интерпретаций.

Ситуация ухудшается, когда нечто на хайпе, - статей и интерпретаций становится настолько много, что с ума можно сойти.

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

Например, банальное «изоляция сбоев на уровне отдельных микросервисов». Мало того, что здесь смешаны и технические сбои и бизнес-ориентированные, так тут еще и что такое изоляция, а дальше, - как идентифицировать сбой, как его обработать, различные виды деградации, определение корректирующих действий, мониторинг…. В общем, не все так просто, как кажется на первый взгляд при прочтении нескольких слов, а стандартов описания нет, вот мы и живем каждый в своем контексте, но даже не смотря на это умудряемся строить надежные, эффективные, полезные, быстрые решения :)
👍18🤔3



tgoop.com/microservices_arch/474
Create:
Last Update:

В продолжение предыдущего поста. Вообще, в нашей индустрии, много проблем, связанных с поверхностным пониманием тех или иных технологий, подходов.

Оно и не мудрено, - индустрия молодая, даже в фундаментальных аспектах эксперты порой расходятся во мнениях.

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

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

Если взять ту же микросервисную архитектуру. Я уже упоминал, что мне здесь немного повезло, был проект почти 20 лет назад, в котором мы реализовали как раз то, что сейчас называется микросервисной архитектурой. В том же проекте был реализован Event Sourcing, хотя я в то время даже слова такого не слышал.

И я такой был 100% не один, уверен, что реализаций были сотни, тысячи. И микросервисный стиль никто не придумывал, он уже был, активно использовался, применялся, этому стилю всего лишь дали имя и попытались описать характеристики.

Термин получился может и не самый удачный для описания сути, но максимально хайповый, тут не отнять. Характеристики тоже попытались описать, получилось как получилось, попробуйте на досуге взять свое архитектурное решение и формализовать его характеристики для того, чтобы его можно было повторно использовать и развивать вокруг него теоретико-практическую базу. Этих характеристик будет практически бесконечное число, так что вам придется взять все существующие стили и выделить:
1. Те, что отличают от других
2. Те, что четко определяют ваш архитектурный стиль в своей совокупности

Я обобщаю и выделяю паттерны из конкретных сессий event storming и это максимально неблагодарное занятие.

Вернемся к описанию архитектурного стиля и вспомним фундаментальные труды по архитектуре. Как там описаны стили? Текстом в свободной форме. Какой-то формализм, конечно, присутствует, но в целом «что вижу - то описываю». Проблема здесь в том, что даже если трое видят одно и то же, описать они это могут совершенно по-разному. А те, кто прочитают, каждый кто прочитает, - могут и понять по-своему и написать по статье на хабре или медиуме со своим понимаем, и вот у нас уже 100500 интерпретаций.

Ситуация ухудшается, когда нечто на хайпе, - статей и интерпретаций становится настолько много, что с ума можно сойти.

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

Например, банальное «изоляция сбоев на уровне отдельных микросервисов». Мало того, что здесь смешаны и технические сбои и бизнес-ориентированные, так тут еще и что такое изоляция, а дальше, - как идентифицировать сбой, как его обработать, различные виды деградации, определение корректирующих действий, мониторинг…. В общем, не все так просто, как кажется на первый взгляд при прочтении нескольких слов, а стандартов описания нет, вот мы и живем каждый в своем контексте, но даже не смотря на это умудряемся строить надежные, эффективные, полезные, быстрые решения :)

BY Микросервисы / распределенные системы


Share with your friend now:
tgoop.com/microservices_arch/474

View MORE
Open in Telegram


Telegram News

Date: |

The court said the defendant had also incited people to commit public nuisance, with messages calling on them to take part in rallies and demonstrations including at Hong Kong International Airport, to block roads and to paralyse the public transportation system. Various forms of protest promoted on the messaging platform included general strikes, lunchtime protests and silent sit-ins. The group also hosted discussions on committing arson, Judge Hui said, including setting roadblocks on fire, hurling petrol bombs at police stations and teaching people to make such weapons. The conversation linked to arson went on for two to three months, Hui said. Telegram Channels requirements & features The best encrypted messaging apps So far, more than a dozen different members have contributed to the group, posting voice notes of themselves screaming, yelling, groaning, and wailing in various pitches and rhythms.
from us


Telegram Микросервисы / распределенные системы
FROM American