Коллеги, а есть ли быстрый способ узнать ценообразование на leanix enterprise architecture suite? На сайте предлагают записаться к ним на демо для этого, а мне бы хоть порядок понимать

Мне кажется, стало понятно:
- монолиты и микросервисы - это миф, есть макароны и модульные решения с низкой связностью модулей (строительных блоков решения)
- есть масса причин, в том числе перечисленные выше, по которым некоторым модулям необходимо придать автономность (сделать их отдельными сервисами)

В общем, муть от микросервисов осела и стало понятно, что нужно просто делать «правильное» проектирование.

При этом в «микросервисной архитектуре» действительно собраны полезные паттерны. И если внимательно на них посмотреть, то станет ясно, что практически ничего нового в них нет (чего бы не было до микросервисов).

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

Всё так. Не надо бездумно дробить до микро/наносервисов, а изоляция - это хорошо.

Перестаем называть доменные сервисы микросервисами )

Я ж не просто так привёл аналогию с переборками в корабле :)

Сам по себе термин «МИКРОсервис» смыла не имеет. Потому напрямую отсылает к размеру. А размер может меняться, сервисы могут «дробиться» и «объединяться» по миллиону разных причин.

имеет смысл, если понимать, про размер чего речь)

Я бы сказал, что граница между просто «макро» сервисами и микросервисами начинается тогда, когда добавление нового сервиса не добавляет работы для Ops’ов. То есть когда программист самостоятельно может как-то в коде (репозитории) описать используемую инфраструктуру, а дальше все завертится без дополнительного вмешательства, отдельного нового разворачивания и прочего.

Так вот нефиг программисту самому сервисы создавать )

Если вспомнить про цель МСА, то эта цель - снижение ТТМ (времени поставки ценности)

Для этого решение должно быть выровнено в бизнесом

Единственный более-менее формальный подход для проектирования выровненного с бизнесом - это DDD

DDD де-факто доминирует в МСА, а на самом деле, в обычных нормальных современных приложенниях.

Но не бывает решений, которые состоят только из доменных сервисов

Добавим «по требованию архитектора» 😈

если дать программисту такой инструмент, вам конец

Думаю, всё сложнее
Мне кажется, что любые рассуждения об отличии нано/микро/гига неизбежно вырождаются в холивар

А вот это уже должна обеспечивать инфраструктура, чтобы конец света не наступил

Почему?

Речь не об отмене архитектурного надзора / контроля. Речь о цене сопутствующих работ

То есть добавление нового сервиса должно быть бесплатно для службы развёртывания / мониторинга и пр.

А если добавление нового сервиса требует исполнения заявок на новое оборудование, просверливание дырок безопасности, ручной Настройки технических метрик мониторинга… до тут ещё пока не «микро», для меня

Добрый день, коллеги! 🖐

Все мы начинали свою карьеру в аналитике или меняли компанию и команду. В новой для себя профессии мы сталкиваемся с новыми для себя терминами. Давайте соберем ИТ понятия, слова, жаргонизмы, сокращения, термины и определения, с которыми вы сталкивались при общении с коллегами и смежниками (другие аналитики, разработчики, тестировщики и т.д.), которые вызывали у вас непонимание, чтобы облегчить жизнь будущих аналитиков, и создадим #словарь_джуна_аналитика 🙂

Пишите все, что было связано с профессиональной ИТ деятельностью: Дэйли, meeting, фича, пинговать, хардкодить, конфлю и т.д.

Пожалуйста, заполните для этого небольшую анкету https://forms.gle/yekMvpRZzk7XmTQy9

Реализуем в рамках https://t.me/BA_SA_Arch_edu

Нет, не все.