Comments 11
Николай, а в чем отличия того, что вы называете Persistent Fabric, от того, что Gartner называет Data Fabric? Как бы вы размежевались?
P.S. «Но это все маркетинговый bullshit, а мы будем строить digital twin» — звучит забавно, конечно.
Николай, а концепция Polyglot Persistence легендарного Мартина Фаулера, 2011 — в голову не приходила? было упомянуто тут martinfowler.com/bliki/CQRS.html Тоже в парадигме MDM 5 Level/ Data-as-Service — но вопросы онтологии решает по-моему интереснее. На представленных схемах — Вы, походу в реляционной модели крутитесь, а в Polyglot Persistence допускается сущности в различных представлениях онтологически обьединять. Если на бытовом примере — то у вас может быть и скан паспорта как изображение, и паспорт в виде структурированного текста, и паспорт в виде обогащенного и проверенного во всяких базах ФМС профиля клиента. И все это в одном мульти-облаке, но по факту в разных представлениях в СУБД разного типа — key-value, graph, doc-oriented, Non-SQL, OORDBMS и пр. Приложение само определяет — в каком представлении ему нужен обьект
Вот смешно получилось, неужели у меня фраза Polyglot Persistence ни разу в тексте не прозвучала?… проверил, похоже действительно нет.
Дело в том, что эта статья продолжает предыдущую, где эта фраза есть: habr.com/ru/company/avito/blog/426101
Базы микросервисов Авито строятся согласно Polyglot Persistence. По предыдущей статье можно понять, что среди этих баз есть и key-value, есть и document-based… чего там только нет. И помнящая ткань — это не про само хранение, а про структурирование метаданных о хранении.
Дело в том, что эта статья продолжает предыдущую, где эта фраза есть: habr.com/ru/company/avito/blog/426101
Базы микросервисов Авито строятся согласно Polyglot Persistence. По предыдущей статье можно понять, что среди этих баз есть и key-value, есть и document-based… чего там только нет. И помнящая ткань — это не про само хранение, а про структурирование метаданных о хранении.
мне кажется вы переизобрели ServiceNow Configuration Management Database и ServiceNow Workflows
Было бы излишне самоуверенно считать, что я изобрел что-то действительно новое, о новом пишут не на хабре, а в рамках научной публикации :)
Описанное в статье — это не полностью новое, это творческое переосмысление различных инструментов, позволяющее им сосуществовать вместе.
Я бы скорее сказал, что Configuration Management Database и ServiceNow Workflows являются хорошими кандидатами на роль источника данных для определенных слоев.
Описанное в статье — это не полностью новое, это творческое переосмысление различных инструментов, позволяющее им сосуществовать вместе.
Я бы скорее сказал, что Configuration Management Database и ServiceNow Workflows являются хорошими кандидатами на роль источника данных для определенных слоев.
мое понимание, что это больше относится к ITIL и ITSM.
неважно микросервисы у вас или монолиты, но должен быть золотой источник данных для всех ИТ активов и элементов конфигурации (особенно в продакшене). А любые изменения в этом источнике данных проходят через бизнес-процесс, который можно выразить в виде направленного ациклического графа действий (ручных или автоматизированных/роботизированных).
Также есть варианты дополнять золотой источник данных через сканирование/autodiscovery
неважно микросервисы у вас или монолиты, но должен быть золотой источник данных для всех ИТ активов и элементов конфигурации (особенно в продакшене). А любые изменения в этом источнике данных проходят через бизнес-процесс, который можно выразить в виде направленного ациклического графа действий (ручных или автоматизированных/роботизированных).
Также есть варианты дополнять золотой источник данных через сканирование/autodiscovery
Вот теперь понятнее стало.
Описанный в статье подход — про дополнение через сканирование и autodiscovery.
Т.к. экосистема Авито — это десятки кросфункциональных команд, маленьких стартапов, каждый из которых запускает/развивает/выводит сервисы независимо, сам выбирает и меняет бызы. И таких сервисов с базами много сотен, каждый день что-то меняется.
Описанный в статье подход — про дополнение через сканирование и autodiscovery.
Т.к. экосистема Авито — это десятки кросфункциональных команд, маленьких стартапов, каждый из которых запускает/развивает/выводит сервисы независимо, сам выбирает и меняет бызы. И таких сервисов с базами много сотен, каждый день что-то меняется.
интересно, можете раскрыть тему безопасности тогда?
у вас внедренные безопасники в каждую команду или централизованная система?
как выполняется сканирование на уязвимости, накатывание патчей, endpoint защита, всякие правила фаероволов, доступы, аккакунты и т.д. — как вы защищаете инфраструктуру от внешних угроз, но еще и внутрених угроз
у вас внедренные безопасники в каждую команду или централизованная система?
как выполняется сканирование на уязвимости, накатывание патчей, endpoint защита, всякие правила фаероволов, доступы, аккакунты и т.д. — как вы защищаете инфраструктуру от внешних угроз, но еще и внутрених угроз
Sign up to leave a comment.
Концепция персистентной ткани для контроля IT-инфраструктуры