В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Архитектура ИТ-решений

1588 membersпожаловаться на группу
2019 September 20

PD

Phil Delgyado in Архитектура ИТ-решений
Отдельный сервис не есть повод для архитектора, там хватит сеньор-девелопера, делов-то.
А вот конкретный подход к реализации CQRS (а это уже дорогой архитектурный выбор) без залезания в код не сделать.
источник
12:16пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
Petr Shmotov
Ну. И за 2-3 недели надо и архитектуру сделать, и реализовать.
Для проекта какого масштаба?
источник
12:16пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
Если на проекте ценой в несколько человеко-месяцев есть архитектор, не читающий код, то его проще выгнять )
источник
12:16пожаловаться

PS

Petr Shmotov in Архитектура ИТ-решений
Микросервис априори атомарный, величина проекта роли не играет.
источник
12:17пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
Так микросервис - это не архитектура.
Архитектура - это распределение микросервисов и правила их взаимодействия.
И их жизненный цикл.
источник
12:17пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
А там уже решения за 2-3 недели не принимаются )
источник
12:17пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
Каждый конкретный микросервис не должен требовать участия архитектора, зачем он.
А вот как они взаимодействуют - уже задача архитектора.
источник
12:18пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
Так как между https, grpc, kafka, rmq или dbqueue есть много существнных различий.
источник
12:19пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
И языки для микросервисов сильно зависят от общих подходов к архитектуре системы и их надо знать.
источник
12:19пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
(Да даже при проектировании банального REST API нужно держать в голове ограничения всех языков системы...)
источник
12:19пожаловаться

PS

Petr Shmotov in Архитектура ИТ-решений
Мы куда-то в сторону ушли. Т.е. по вашему надо в начале протестить все брокеры, выбрать один, и на нем клепать интеграцию для всех микросервисы, независимо от внутренних условий, ограничений и целей?
источник
12:21пожаловаться

PS

Petr Shmotov in Архитектура ИТ-решений
Phil Delgyado
Так как между https, grpc, kafka, rmq или dbqueue есть много существнных различий.
Ну, и я про то же. Каждый сервис требует отдельного внимания, как минимум со стороны интеграции.
источник
12:22пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
Petr Shmotov
Мы куда-то в сторону ушли. Т.е. по вашему надо в начале протестить все брокеры, выбрать один, и на нем клепать интеграцию для всех микросервисы, независимо от внутренних условий, ограничений и целей?
Брокер - это не про конкретный сервис, это про взаимодействие сервисов. И да, нужно выбрать метод взаимодействия сервисов до того, как их писать. Так как изменение транспорта между сервисами очень дорого стоит и не всегда возможно, а от этого транспорта принципиально зависит то, как писать эти самые сервисы. И смена rmq на кафку приводит к переписыванию всех сервисов и всей их логики.
источник
12:23пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
Как и смена https на grpc
источник
12:24пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
Но чтобы это понимать - нужно код читать и писать.
источник
12:24пожаловаться

PS

Petr Shmotov in Архитектура ИТ-решений
Phil Delgyado
Брокер - это не про конкретный сервис, это про взаимодействие сервисов. И да, нужно выбрать метод взаимодействия сервисов до того, как их писать. Так как изменение транспорта между сервисами очень дорого стоит и не всегда возможно, а от этого транспорта принципиально зависит то, как писать эти самые сервисы. И смена rmq на кафку приводит к переписыванию всех сервисов и всей их логики.
Ну. И я про то же. Т.е. всё-таки архитектура нужна? Или можешь интеграции отдается на откуп разработчика - как он захочет, так и запилит?
источник
12:25пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
При чем тут интеграция? Взаимодействие микросервисов внутри системы - это не интеграция одного продукта в чужой ландшафт.
источник
12:27пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
И при проектировании системы проговаривать правила взаимодействия сервисов - нужно. А для этого нужно таки протестировать кучу разных брокеров и фреймворков, залезть в их код и выбрать конкретный узкий список. Так как поддерживать несколько зачастую вообще не реально (так как гарантии разные)
источник
12:28пожаловаться

PD

Phil Delgyado in Архитектура ИТ-решений
И если архитектор заранее не описывает процессы взаимодействия - то нафиг он вообще нужен...
Да, с точностью до настроек конкретных брокеров (так как они принципиальны)
источник
12:29пожаловаться

PS

Petr Shmotov in Архитектура ИТ-решений
Ещё раз по шагам. Взаимодействие сервисов - это про архитектуру? Вроде да. Теперь вопрос - когда по вашему стоит проработать взаимодействие - в начале глобально и для всех, или для каждого микросервиса стоит рассматривать индивидуально?
источник
12:30пожаловаться