Системный сдвиг

Ну конечно, что-то в классификации интеграций я забыл! Например, я думал, куда поместить ETL? Он всё время выпадает — и из классификаций, и из курсов/статей. Спасибо ИИ (точнее — боту Марике, которая живет в группе https://t.me/itsysdes), подсказала ещё несколько различалок: 🔹 по частоте обмена (от обмена в реальном времени, типа вебхуков, вебсокетов и стриминга в gRPC, до ночных ETL-процессов по расписанию. Это не взаимоисключающие способы, их совмещение называется "лямбда-архитектура" ); 🔸 по степени структурированности данных — от зажатых в строгие рамки сообщений в JSON-Schem'ы или бинарного формата protobuf, до произвольных структур NoSQL, документов и медиа (а что если вам придётся передавать между системами видео? Мне вот приходилось; для сырого видео больших объемов самый быстрый способ передачи — записать на переносные диски, набить ими рюкзак и отвезти на метро); 🔹 однонаправленная (издатель-подписчик) и двунаправленная интеграция; 🔸 Впрочем, дадим шанс и статье, которая меня сподвигла на эту серию постов, с их "горизонтальной" и "вертикальной" интеграцией:  такое разделение и в англоязычных источниках есть, впрочем, примерно той же степени адекватности, 'Systems integration is sort of like a wedding' 👀, и с другим наполнением. Но, если подумать, можно и так посмотреть на ситуацию: интегрируем ли мы системы, стоящие на разных этапах технологической цепочки и кормящих друг друга продуктами своей деятельности (для машиностроения и нефтянки даже стандарты есть для интеграции данных о деталях, оборудовании и процессах жизненного цикла непрерывных производств), или мы объединяем однотипные системы, работающие параллельно. Не знаю, откуда они вытащили эту задачу в 2024 году, но лет 20 назад было актуально: объединить в единое пространство системы нескольких магазинов, чтобы сводить остатки (с трудом, но вспоминаю, что посмотреть наличие товара в другом магазине Спортмастера было невозможно — системы не были соединены. Один мой однокурсник ездил с флешкой по сети магазинов одежды и собирал вечером данные о продажах и остатках. Я сам делал несколько таких проектов: для больницы, для сети турагентств и для валютного деска банка — сводил в одной системе результаты торгов разных трейдеров. Очень было актуально в 2000-2006 годах. Сейчас трудно представить такие задачи по горизонтальной интеграции, но, наверное, где-то они ещё встречаются. А может, бойцы вспоминают минувшие дни 🤷‍♂ 🔹 Наконец, экскурс в 2000-е напомнил мне про ещё одну классификацию, в этот раз уровней интеграции данных: физический, логический и семантический. Тогда все говорили про семантический веб, помните? Практика показала, что создание единой семантической модели — скорее утопия, и работать нужно с моделями ограниченных контекстов. Но об этом уже в другой раз.

20 июня, четверг Санкт-Петербург, Казанская улица, 7, пространство Freedom Сбор гостей в 19:00 Всем привет! На связи команда системных аналитиков Positive Technologies. Нас объединяет любовь к сложным технологическим задачам, которые вырастают в крутые продукты в области информационной безопасности. У нас есть возможность пробовать все самое вкусное, что есть в разработке ПО: 📍 использовать возможности искусственного интеллекта, 📍 внедрять гибкие процессы разработки, 📍 проектировать сложные алгоритмы работы с данными и функциями. Если вам это близко, присоединяйтесь к нам 20 июня. 👉 Программа 👉 Регистрация

Ладно, какие я знаю способы классификации интеграций: 🔹 по предмету, что именно интегрируем: данные, документы, справочники, функции? Вот у нас есть две или несколько систем. Мы хотим чтобы что из одной системы оказалось в другой? Появились какие-то данные? Или документ из одной системы можно было бы открыть в другой? Или чтобы в обеих системах были одинаковые справочники и актуальная основная информация? Или чтобы функциями одной системы можно было воспользоваться в другой? 🔹 по "глубине": что значит "появились"? Можно просто посмотреть данные/документы, или с ними можно что-то сделать? Сделать через интерфейс, или программно? Вот я сейчас вожусь с Битрикс24 (не спрашивайте), и там многие "интеграции" выглядят так: да, теперь можно посмотреть в интерфейсе Битрикса данные из другой системы. Нет, использовать их в процессах или, например, привязать к карточке сделки/клиента — нельзя. Только посмотреть. Вот такая интеграция. Соответственно, можно рассмотреть "глубину" интеграции: те данные, документы, справочники и функции, которые вы получаете из другой системы — они насколько глубоко интегрированы в вашу систему? Практически так же, как нативные объекты, или живут в ограниченных контекстах, или существуют в совсем отдельных изолированных "резервациях", или просто точечно используются по месту, почти не проникая в вашу систему? 🔹 по уровню: об интеграции чего мы говорим? Объектов и модулей внутри одной системы? (Например, многослойная архитектура, API между бэкендом и фронтендом). Или интеграции нескольких систем/сервисов в рамках одного подразделения, с одним владельцем? Систем из разных департаментов с разными владельцами и политиками? Систем из разных организаций? Тут речь идёт о подконтрольности систем и наших возможностях диктовать правила взаимодействия и вносить изменения в системы. Рядом с этим делением идёт категоризация интеграций на внутренние и открытые (в основном говорят про внутренние и открытые API). У них могут быть совершенно разные требования по безопасности, производительности, надежности, обратной совместимости и т.п. Вплоть до маркетинга внешних API и управления сообществом разработчиков — вот где уникальные люди, мы, помню искали таких, и их в России по пальцам можно пересчитать. 🔹 по топологии: ну, тут понятно: точка-точка, звезда, шина, последовательное соединение (pipes-and-filters). 🔹 по "стилю" (из книжки "Паттерны интеграций корпоративных приложений") — не совсем классификация, поэтому авторы и называют эти стилями: файловый обмен; общая база данных; вызов удаленной процедуры (включая сюда и REST!); асинхронный обмен сообщениями. 🔹 по предмету коммуникации, что именно мы отправляем: объект данных? документ? событие? Это разные стили и даже разные архитектуры. 🔹 по цели, очевидно: мы чего хотим от интеграции? Ускорения? Увеличения гибкости? Улучшения качества данных? Снижения расходов? Для чего всё затевается? 🔹 по "аспекту", я не придумал лучшего слова. Про какой аспект информационных систем мы думаем в первую очередь, что хотим объединить? Возможно, эту классификацию можно объединить с первой, про объекты. Итак, аспекты: данные (в любом виде, включая документы), системы (имея в виду, в первую очередь, взаимозаменяемость и унифицированность интерфейсов), процессы/функции/сервисы, UI/UX (унификация и консистентность пользовательского опыта), инфраструктуры, безопасности. Дальше идет несколько классификаций отдельных подходов к интеграциям, зачастую просто выборов из двух вариантов или их смеси, не знаю, тянет ли это на отдельные классификторы: - централизация или стандартизация? - оркестрация или хореография? - синхронное или асинхронное взаимодействие? - от данных или от функций (ресурсы vs методы, REST vs RPC)? - CA, CP или AP? - at least once, at most once или exactly once? - бинарные данные или человекочитаемые? - шифрование канала или каждого сообщения? Вот что первым приходит в голову, когда мы говорим о классификации интеграций, наверняка есть ещё что-то, о чем я забыл и что не укладывается ни в какую классификацию. Пишите в комменты, обсудим!

Чудная статья от Яндекс.Практикума про типы интеграций. Написана как будто специально, чтобы поиздеваться над аналитиками: у нас есть два способа классификации интеграций и по нескольку видов интеграций в каждой классификации. Объединим обе классификации в единый нумерованный список и расскажем вам про них по очереди! 🤯 Считаю, что зря они только две классификации взяли. Нужно было расстараться и штук пять взять! И по одному примеру из каждой классификации в список добавить! В общем, какое-то "системный аналитик изнасиловал журналиста" получилось. https://practicum.yandex.ru/blog/sistemnaya-integraciya

Вот Практикум радует (правда, статья-то ещё прошлогодняя). А давайте поможем Даше накидаем разные способы классификации интеграций? Вот вы какие знаете?

⭐️ Хакатон ARCHI.Tech от ВТБ – уникальный шанс сделать проект в роли ИТ-архитектора. Приглашаем начинающих и опытных ИТ-специалистов – студентов и выпускников технических вузов, разработчиков, архитекторов, аналитиков. 🔹 Выбирайте задачу любого уровня — простую, среднюю или сложную 🔹 Собирайте архитектурные артефакты, спрятанные в заданиях, и зарабатывайте баллы 🔹 Презентуйте свои решения экспертам ВТБ 🔹 Не упустите возможность решить «разминочную» задачу и получить дополнительные баллы 🔹 Заработанные баллы, найденные артефакты и коэффициент сложности задачи помогут определить победителей 🔹 Три категории: «Архитектор стрима», «Архитектор системы» и «Архитектор данных»… 🔹… и три призовых места в каждой 🔹 Лучшие из лучших разделят призовой фонд в 1 200 000 рублей! Начало предварительного этапа – 14 июня. Соревнование стартует 28 июня – у участников будет 24 часа на решение задачи. 👉 Продемонстрируй свои знания об архитектуре – участвуй в ARCHI.Tech от ВТБ: https://cnrlink.com/architechvtbsysswing Реклама. БАНК ВТБ (ПАО). ИНН 7702070139. erid: LjN8KZCgi

В общем, как видите, тема неочевидная, и лучше в проекте договориться на старте (или в рамках всей организации), чтобы не получилось у одних так, а у других эдак. Одинаковые вещи должны выглядеть одинаково, это дает возможность предположить и угадать, а не бегать каждый раз в документацию. Документ, в котором описываются эти принципы, называется "Соглашение об именовании". Программистам с этим проще — у них есть линтеры, которые проверяют исходный код на соответствие установленному стилю. Для спецификаций я такого пока не видел. Но хотя бы договориться об этом стоит. Ссылки на стили наименования, сборники лучших практик и посты по этому поводу: https://github.com/RootSoft/Database-Naming-Convention https://dev.to/ovid/database-naming-standards-2061 https://www.belgif.be/specification/rest/api-guide/#resource-archetypes https://restfulapi.net/resource-naming/

Пост по заявкам читателей (да, так тоже можно!) про названия. Тема-то актуальная, регулярно в чатах кто-нибудь спрашивает. Итак, мы проектируем системы и даём названия разным элементам. В основном это: * таблицы в базах данных * поля в таблицах * индексы, ограничения и бизнес-правила * эндпоинты API * поля в JSON * названия файлов Есть ещё, конечно, названия модулей, функций и переменных, но это область программистов, туда не лезем. Что же у нас с рекомендациями? Удивительно, но они разные :) Вот какие вопросы обычно обсуждают. Во-первых, у нас есть разные способы записи названий, состоящих из нескольких слов. Пробелы мы почти никогда использовать не можем, остаются варианты: 👨‍🎓 PascalCase (без пробелов, с большими буквами в начале слов) 🐫 camelCase (без пробелов, с большими буквами в начале слов, начиная со второго, как горбы у верблюда) 🐍 snake_case (вместо пробелов используется подчеркивание, всё маленькими буквами) 🍢 kebab-case (вместо пробелов используется "минус", слова нанизаны на шампур) Во-вторых, какие части речи использовать — глаголы, существительные? Особенно актуально для эндпоинтов API В-третьих, для существительных — во множественном или в единственном числе их называть? В-четверых, словарь. Какими словами вы называете объекты, и как переводите на английский (надо ли говорить, что называть все объекты нужно на английском, если только у вас не 1С). Как вы назовете счет клиента? Account, Check или Schet? Любопытно, что рекомендации и лучшие практики для API и для БД иногда противоположны! Для БД советуют использовать snake_case (так проще различать слова). Для эндпоинтов API — kebab-case, т.к. в вебе ссылки принято подчеркивать, и значок "_" может потеряться. Почему не camelCase? Потому что труднее различать слова и нужно переключать регистр (URI регистрозависимые). В обоих случаях рекомендуется использовать в качестве названий существительные во множественном числе (для ресурсов REST API и для названий таблиц в БД). Один из аргументов для БД — меньше риск, что имя таблицы совпадет с зарезервированным словом. Хотя есть и контраргумент: давать таблицам и представлениям названия в единственном числе, чтобы не думать, как переводить во множественное (person — это persons или people?). Холиварная тема! Следующая тема — идентификаторы. Должны ли они называться просто id, или повторять название сущности (team_id?) Есть аргументы за и против. Внешние ключи, понятно, должны назваться по названию внешней таблицы+id. Названия таблиц и полей должны содержать полные слова, не сокращения. Нет ничего хуже таблицы pmnt23, состоящей из полей P1, NMT, ABBR14, FIELD28, ACC_NO и т.д. Названия типов также не должны становиться именами полей: DATE, TEXT или TIMESTAMP не дают никакого объяснения смысла. Также стоит подумать над более конкретными названиями — source_warehouse_id а не просто source_id. Для API, кроме того, нужно понимать — запрашиваем ли мы коллекцию или единичный элемент? Если это элемент из коллекции, то будет существительное во множественном числе / id (users/{id}), но это может быть и служебное слово, указывающее на особенный элемент коллекции (users/me). Про глаголы в REST писать не буду, пуристы скажут, что никаких глаголов в названиях эндпоинтов быть не может, но вот Google, например, считает иначе. Ну а если у вас не REST, а наоборот даже RPC, то названия методов рекомендуется писать в PascalCase по формату "ГлаголСуществительное" — что мы делаем и над чем мы это делаем, причем существительное должно указывать на тип передаваемого объекта (GetBook возвращает объект Book). Ну и пока нам не встречался camelCase, куда же без него. Он у нас живет внутри JSON — так записываются названия полей.

Курс по архитектуре и распиливанию монолита, который вы давно хотели. Называется, правда, просто "Анализ систем", но вы посмотрите на программу! Старт 13 июня, ссылка: https://tough-dev.school/system-analysis. Длится 4 недели. Учат проектировать системы: новые  — чтобы не переделывать, старые — чтобы разобрать на части и ускорить разработку. Учат обоснованно выбирать технологии и архитектурные стили, оставляя понятную для программистов документацию. Если дойдёте до конца — сможете спроектировать ПО для большинства крупных работодателей или разбить на части доставшийся в наследство монолит на 500кк строк. Что будет на каждой неделе: Неделя 0. Работа с требованиями, разделение системы на элементы (работа с требованиями, Event Storming, Модель данных, Базовое сравнение микросервисов и монолитов, Система, форма и функция системы) Неделя 1. Стратегический анализ бизнеса и архитектурные стили (Strategic DDD, subdomains; Coupling & cohesion, temporal coupling, local & global complexity; Quality attributes/non functional requirements/architecture characteristics; Поиск характеристик и перевод бизнес-терминов в характеристики; Циклы жизни систем) Неделя 2. Внешние ограничения и документация (Ограничения системы, Выбор вида БД в зависимости от характеристик, Выбор вида коммуникаций и брокера для событий, Fitness function) Неделя 3. Распиливаем монолит (Добавление новой функциональности в отдельных сервисах; Объединение сервисов; Вынос функциональности из монолита в сервис; Strangler Fig Application, Volatility Based Decomposition, Tactical Forking, Component-Based Decomposition) Неделя 4. Итоги и дальнейшие шаги. Авторы — Антон Давыдов и Школа сильных программистов. Но программировать на курсе не нужно, только рисовать квадратики и стрелочки, всё как мы любим. Есть тарифы с обратной связью и без. С личной проверкой домашек, чатом и Q^A-сессией. Для подписчиков промокод systemS10 даст дополнительную скидку в 10%. Действует до 7 июня (пт). Посмотреть программу и условия →

Если бы Ивар Якобсон создавал диаграмму устойчивости сейчас, он бы назвал её "диаграммой антихрупкости". Звучит модно, не то что какая-то там робастность! На самом деле нет. Термин "антихрупкость" (antifragile) ввел и раскрутил в одноименной книге Нассим Талеб, трейдер и риск-аналитик (до этого он так же раскрутил термин "черный лебедь"). И в книге он много пишет об отличиях антихрупкости от устойчивости: устойчивость — это способность выдерживать шоковые воздействия и восстанавливаться после них, а антихрупкость — не просто восстанавливаться в то же состояние, а становиться лучше. Как это обеспечить в реальности? Система должна иметь возможность изменять своё поведение без радикальной перестройки внутренней структуры. То есть, структура системы должна обеспечивать возможность таких изменений. Например, один из вариантов — избыточность. Мы почти всегда боремся за отсутствие избыточности и дублирования (принцип DRY), но в случае потенциальной высокой изменчивости среды это может выйти боком (например, см. заметку про это в блоге Гугла). Антихрупкая система допускает избыточность, и при изменении внешних условий какой-то вариант реализации может оказаться более подходящим. Сюда же можно отнести несколько альтернативных вариантов выполнения одного юскейса, что часто забывают. Юскейс — это набор сценариев, ведущих к достижению цели, а не один сценарий. У вас поломался пользовательский интерфейс, но остается чат, в котором ту же задачу можно решить через оператора. При этом часть функций системы может отмереть, перестать использоваться. А часть — соединиться в другой последовательности для выполнения задачи в изменившихся условиях. Это как раз позволяет проследить диаграмма устойчивости — можно ли соединить её элементы (сущности, контроллеры, интерфейсы) другим способом? На этот вызов отвечает (микро)сервисная архитектура. Для этого нужен HATEOAS с набором ссылок в REST. А жестко зафиксированный сценарий юскейса наоборот мешает. Сюда же относятся различные средства мониторинга, автоматические размыкатели и балансировщики. У аналитиков есть проблема: смотреть на сценарий юскейса, как будто это единственный экземпляр юскейса в системе. На самом деле почти все интересные системы сейчас многопользовательские, и каждый раз имеет смысл подумать, что будет, если много экземпляров юскейса выполняется параллельно в одно и то же время. Опять же, на диаграмме устойчивости это можно отметить: сколько экземпляров контроллера запущено (и какая очередь перед ним может возникнуть), есть ли конкурирующие обращения к одной и той же сущности. В антихрупкой системе всё это под мониторингом с цепями обратной связи, то есть регулируется само в положительную сторону, и останавливает каскад ошибок при развитии ситуации в отрицательную сторону. На какой диаграмме можно наметить точки мониторинга?.. Талеб также описывает "стратегию штанги", которая рекомендует фокусироваться только на супер-безопасных выборах (безрисковых) и на супер-рискованных (но потенциально приносящих большой эффект), убирая середину и сбалансированные по риску выборы. Это уже к вопросу про выбор фич. Не нужно делать что-то среднее -- нужно прокачивать то, что не меняется и гарантировано приносит пользу, и что-то безумное, что скорее всего зафейлится, но если взлетит — окупит предыдущие фейлы. Но это уже тема для отдельного поста.