⭐️ Гайд по C4 с примерами [Моделирование архитектуры для системных аналитиков] ⭐️

Нотация C4 - одна из самых удобных для визуализации архитектуры информационных систем. Разработана в 2011 году Саймоном Брауном, системным архитектором.

C4 - это 4 уровня детализации:
⭐️ Context
⭐️ Container
⭐️ Component
⭐️ Code

Преимущества по сравнению с нотацией Archimate: более техническая, меньше бизнес-контекста.

Все подробности собрала в прикрепленном к посту гайду.

В нём больше наглядных примеров, инструменты для C4 и полезные ссылки! Сохраняйте и пользуйтесь ❤️

#АрхитектураGA

💫 Архитектура в C4 / Context - проект RideFlow 💫

Самый верхний уровень C4 / Context показывает систему и её окружение.
Проектируя его, мы не заморачиваемся с тем, какой подход к архитектуре будет выбран — будь то монолит, сервис-ориентированная архитектура или микросервисы.

Все, что показывает C4 / Context:
1. Пользователей, которые работают с системой.
2. Интеграции с внешними системами.

Основное преимущество этого уровня заключается в его наглядности и доступности как для IT-команды, так и для бизнес-стейкхолдеров. Его может разработать как системный, так и бизнес-аналитик.

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

А интеграции это то, что нужно знать о любой системе. Это вся техническая суть C4 / Context.

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

Пример схемы проекта по заказу такси #RideFlow поможет нам понять, как реализуется C4 / Context на практике. См. картинку к посту.

Вопросы по схеме? Пишите комментарии.
Всё понятно и готовы идти дальше? Ставьте 👍

#АрхитектураGA

🌱 Архитектура для аналитиков: опыт работы и рост здесь 🙌

Погружение в архитектуру систем и опыт работы в сложных проектах с микросервисной архитектурой - точки роста для опытных системных аналитиков.

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

🌟 Проектирование архитектуры
🌟 Старт предобучения 29 августа 2024
🌟 Подробности о программе и запись

🎁 С 14 до 22 августа открыта предзапись на специальных условиях + дополнительное обучение по REST API в подарок.

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

Один из важных отзывов, повторяемый разными словами в чатах:

“Есть возможность попрактиковаться в проектировании архитектурного решения, выйти за пределы "пузыря" моей работы и налаженных процессов на работе”

Программа подойдёт только для опытных системных аналитиков (Middle и выше), кто уже работал с интеграциями, хочет расти в Senior внутри компании, или переходить в интересные и сложные проекты.

Навыки работы с архитектурой, очередями, API, взаимодействием систем в реальном времени, которые аналитики получили в ходе работы, уже сейчас помогают им:
+ проходить аттестацию в компании на повышение грейда,
+ менять работу и выбирать офферы по душе,
+ получать повышения.

Создавать IT-таланты в Системном Анализе - цель GetAnalyst.
И Архитектура - самая сложная, но самая интересная часть в этом пути 🙌

2024 - год больших и крутых перемен ♥️ Давайте идти к ним вместе!

🔸 Монолит, Сервисная и Микросервисная архитектура - сравнение 🔸

Для системных аналитиков важно не только знать, какие виды архитектур существуют, но и понимать их ключевые отличия и области применения. В этом посте мы познакомимся с наиболее распространенными видами архитектуры.

🔸 Монолитная архитектура
В монолитной архитектуре все компоненты приложения находятся в одной кодовой базе и работают как единое целое. Это обеспечивает простоту разработки и релизов системы.
Хорошо подходит для стартапов и небольших проектов.

БД:
Обычно используется одна БД, что упрощает взаимодействие между различными частями приложения, но может стать узким местом при масштабировании.

Внутренние интеграции:
Все компоненты взаимодействуют только на уровне кода. Интеграции между ними по API и другими способами не нужны. Внутренние интеграции могут быть только при наличии очередей или брокеров сообщений.


🔸 Сервисная архитектура SOA (Service-Oriented Architecture)
SOA разделяет функциональность на отдельные сервисы, которые взаимодействуют между собой через сетевые вызовы - по API, через шину данных (ESB) или другими способами.

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

Например, в Интернет-магазине сервис каталога и сервис заказов можно поделить, чтобы инсталлировать на сервере 10 копий сервиса каталога, но всего 3 копии сервиса заказов, т.к. до заказа товаров доходит меньше пользователей чем тех, кто просто смотрит каталог.

БД:
Каждый сервис может использовать свою собственную БД, что облегчает масштабирование и изоляцию сервисов, но также несколько сервисов могут использовать одну БД, что отличает SOA от MSA.

Внутренние интеграции:
Сервисы интегрируются через API, что упрощает интеграцию. Могут использовать шину - ESB.

#АрхитектураGA

Продолжение 👇

🔸 Микросервисная архитектура MSA (Microservice Architecture)
MSA состоит из множества маленьких, независимо разрабатываемых и развертываемых сервисов, каждый из которых выполняет одну бизнес-функцию.

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

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

БД:
Каждый микросервис, в идеале, управляет своей собственной БД, что позволяет избежать зависимостей и упрощает масштабирование каждого сервиса по отдельности.

Внутренние интеграции:
Взаимодействие между микросервисами часто строится по API на легких протоколах, таких как REST или gRPC, и может включать очереди и брокеры сообщений для асинхронной коммуникации.



👉 Выбор архитектуры проекта зависит от специфики и требований к системе.

На практике часто используют либо смесь подходов SOA и MSA, либо начинают проекты с монолита и через 3-5 лет задумываются о переезде на SOA в качестве первого этапа деления монолита на микросервисы.

🧐 Основная рекомендация опытных архитекторов:

Начинай стартап с монолита и сразу правильно организуй модули кода в нём, которые потом можно будет выделить в отдельные сервисы и микросервисы.

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

Понимание ключевых аспектов каждого подхода поможет аналитикам определить наиболее подходящую архитектуру для конкретного случая, а также принимать активное и осознанное участие в обсуждениях с разработчиками и архитекторами 🌱

#АрхитектураGA

👩‍💻🧑‍💻 Как проводят собеседования на системного аналитика: про найм и подготовку к смене работы 🧑‍💻👩‍💻


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

01:17 - Актуальные вакансии в компаниях и почему они появляются.

04:37 - Кто составляет вакансии системных аналитиков и задает требования к кандидатам.

10:46 - Структура собеседования на системного аналитика. Теоретические и практические вопросы. Какого уровня системных аналитиков ищут, какой опыт нужен и что ожидают от кандидатов.

17:24 - Про зубрежку теории: почему это не работает на пользу кандидату. Подробный список вопросов собеседования и требований к системным аналитикам от СберЗдоровье.

21:54 - Отношение к собеседованию на 1.5 часа и техническим задачам во время собеседований.

30:04 - Про найм джунов (младших системных аналитиков): ожидания по навыкам и опыту. Цитата из эпизода: “Джуны - единственная сила, которая работает”.

35:21 - Процесс онбординга: что происходит после успешного найма системного аналитика. Как можно помочь адаптироваться новому сотруднику в IT-компании.

42:57 - Ожидания от нанятых сотрудников в течение испытательного срока. 

46:40 - Сложности высадки новых сотрудников. Истории провального найма системных аналитиков. И про обязательный выходной по средам.

52:27 - Удаленка и построение взаимоотношений в компании. Интересные решения по развитию корпоративной культуры ИТ-компаний.

59:53 - Рекомендации по подбору сотрудников для руководителей в ИТ и по смене работы и собеседованиям для системных аналитиков.

Ведущая:
Екатерина Ананьева

Гости:
Никита Финько, Росбанк
Ольга Пашкова, СберЗдоровье


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify


Ждём вопросы в комментариях, чтобы рассказать больше в следующем эпизоде 😉

Просто помни об этом 😉

💫 Пример C4 / Container для монолита с брокерами, БД и ФХ - проект RideFlow 💫

Рассказала теорию про основные виды архитектуры: монолиты, сервисы и микросервисы.
Показала пример схемы монолита #RideFlow без нотаций.
А теперь хочу показать этот же монолит, но уже с использованием нотации C4 / Container.


➡️ C4/Container расширяет расширяет предыдущий уровень C4/Context, на котором вид архитектуры уже точно должен быть понятен.

➡️ Основное на схеме C4 / Container для монолита (🔗ИСХОДНИК):
- Пользователи
- Внешние системы, оборудование
- Приложения с UI
- Монолитное сервер-приложение - Backend
- Базы данных - для монолита обычно одна, отдельные схемы не отражают
- Файловые хранилища
- Очереди, брокеры


Почему я подробно показываю и разбираю монолиты?

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

Монолит идеален для небольших проектов и стартапов. И можно остановиться на нём для RideFlow, но...

Монолит - идеальное решение, если мы делаем разработку с нуля, пока у нас нет пользователей и масштабных нагрузок.
К микросервисам для RideFlow мы перейдем далее,

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

Дополнительно про "жесткий монолит":

В нашем проекте мы избегаем "жесткой монолитной архитектуры" — мы не будем смешивать код пользовательского интерфейса веб-приложений (UI) и Backend (серверной логики и обращений к БД), как это обычно бывает в монолитах.
Такое решение обусловлено наличием мобильных приложений, для которых потребуется разработка API.

➡️ Итого:
На схеме показана современная версия монолитной архитектуры, где монолитом является только Backend (приложение сервера).


Внутри монолитного Backend можно будет организовать функциональные модули.
Их, согласно нотации C4, показывают на следующем уровне - C4/Component.
Модульный монолит в будущем поможет легче переехать на сервисную или микросервисную архитектуру.

#АрхитектураGA

⭐ Масштабирование - что важно понимать ⭐

Термин "масштабироваться" относится к способности системы адаптироваться к изменяющемуся количеству функций в ней или запросов от пользователей: увеличение или уменьшение ресурсов и мощностей для обеспечения эффективной работы.


Масштабирование может быть вертикальным или горизонтальным.

⭐ Вертикальное масштабирование (scaling up/down) означает добавление ресурсов к одному серверу или экземпляру приложения. Например, увеличение объёма оперативной памяти, мощности процессора или места на диске.

Это сравнимо с переездом из маленькой квартиры в большую: вы получаете больше места и ресурсов для своих нужд.

👉 Вертикальное масштабирование имеет свои ограничения, связанные с максимально доступными ресурсами оборудования - нельзя бесконечно добавлять память и ядра процессора.


⭐ Горизонтальное масштабирование (scaling out/in) подразумевает добавление дополнительных экземпляров серверов или приложений, работающих параллельно, для распределения нагрузки. Т.е. запускаются одинаковые копии приложений.

Это можно сравнить с созданием сети из множества магазинов, каждый из которых обслуживает своих клиентов: если один магазин переполнен, клиенты могут перейти в другой.

👉 Горизонтальное масштабирование обычно предпочтительнее, так как оно обеспечивает более высокую доступность и устойчивость к отказам.


➡️ Эти определения важно знать при работе с архитектурой систем, чтобы понимать, почему выбирают микросервисы вместо монолита.


#АрхитектураGA

⚡️ Переезд на микросервисную архитектуру ⚡️

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

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

Такое деление позволит оптимально применять принцип горизонтального масштабирования.

👉Ситуация:
Сервис геолокации использует большой объем ресурсов сервера и из-за него тормозит всё приложение.
👉Решение для монолита:
Вертикальное масштабирование, пока это возможно, или горизонтальное - выделение мощностей для параллельно работающей копии монолита, хотя причиной проблем является только одна его часть.
👉Решение для микросервисов:
Горизонтальное масштабирование независимого сервиса геолокации - выделение мощностей для развертывания только его параллельно работающих копий.

MSA не так часто выбирают на старте ИТ-проектов. Она позволяет горизонтально масштабировать систему без перерасхода серверных ресурсов, делает удобной релизы. Но ее реализация и сопровождение стоят очень дорого 💰

Специалисты, кто имеет опыт работы c MSA, стоят на порядок дороже. Не каждый маленький проект или стартап могут себе это позволить.

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

#АрхитектураGA #RideFlow

⚡️ Принципы выделения микросервисов ⚡️

Первое, что нужно понять при разработке системы в MSA - как выделять микросервисы? 🧐

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

Базовые принципы выделения микросервисов:

1. Бизнес-функциональность:
Подход заключается в разделении системы на микросервисы по бизнес-функциям.
Примеры: управление пользователями, управление заказами, калькулятор стоимости поездки, геолокация, уведомления, интеграции с внешними системами бухгалтерии.


2. Выделение по техническим аспектам:

2.1. Масштабируемость: выделяются микросервисы для тех частей системы, которые требуют повышенной производительности и могут масштабироваться независимо.
Пример: Сервис расчета стоимости поездки может быть выделен в отдельный микросервис, так как он может требовать большого объема вычислений.

2.2. Независимость разработки и развертывания: микросервисы выделяются так, чтобы разные команды могли разрабатывать и деплоить (выпускать обновления) сервисы независимо.
Пример: Сервис управления пользователями и сервис оплаты могут разрабатываться разными командами. Если будут выпускать обновления для сервиса пользователей и он будет на время обновления временно недоступен, то сервис оплат продолжит работать без остановки

2.3. Реплицируемость данных: если определенные данные должны быть реплицированы или доступны в различных географических зонах, то соответствующие микросервисы могут быть выделены для управления этими данными.


3. Разделение по данным:
Каждый микросервис должен владеть своими данными об отдельных объектах.
Примеры: заказ (все о заказах), платеж (все о транзакциях), пользователи (всё о пользователях).
Результаты такого деления похожи на деление по бизнес-функциональности, но ориентированы больше на принцип управления данными об одном конкретном объекте.


Знание этих базовых принципов поможет сделать первые шаги по выделению микросервисов в вашем проекте ✅

#АрхитектураGA #RideFlow

🤩 5 сервисов и микросервисов, которые есть почти в каждом проекте 🤩

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

Если я работаю над проектом с нуля, то использую этот список как чек-лист “С чего начать". Поможет всем IT-специалистам в задачах, связанных с архитектурой.


✅ Аутентификация и авторизация
Управление процессами аутентификации пользователей и контроля доступа к ресурсам системы.
Пользователи отправляют свои учетные данные (логин и пароль) в микросервис аутентификации. Микросервис взаимодействует с БД пользователей для проверки учетных данных и, если необходимо, генерирует токены доступа (например, JWT). После успешной аутентификации микросервис возвращает токен для пользователя. Токен проверяется на каждом запросе к защищенным ресурсам.

✅ Управление пользователями
Обработка регистраций, управление профилями пользователей, хранение и обработка данных пользователей. Взаимодействует с сервисом аутентификации для создания учетных записей и управления ими.

✅ Уведомления и рассылки
Отправка уведомлений и сообщений пользователям через различные каналы (email, SMS, push-уведомления).
Получает запросы на отправку уведомлений от других сервисов. Обеспечивает интеграцию с внешними поставщиками услуг для отправки email, SMS и push-уведомлений, управляет очередями сообщений и шаблонами уведомлений.

✅ Управление контентом (блоги на сайтах, новости и подобное)
Управление статическим и динамическим контентом (тексты, изображения, видео), организация структуры и хранения контента. Взаимодействует с базами данных и файловыми хранилищами.

✅ Биллинг и платежи
Обработка и учет платежей, интеграция с платежными шлюзами, выставление счетов. Взаимодействует с внешними платежными шлюзами и банковскими системами.


Обоснование для выделения сервисов и их назначение более подробно описаны в прикрепленной к посту мини-книге.

#АрхитектураGA

😎 OpenShift, Kubernetes: знакомые слова, но что это и зачем? 😎

Архитектура тесно связана с инфраструктурой. Поэтому при работе с ней я уделяю много внимания нефункциональным требованиям, таким как масштабируемость и производительность.

Чтобы их обеспечивать, на помощь приходят инфраструктурные решения OpenShift и Kubernetes.


🔵 Kubernetes — это система, которая управляет контейнерами, в которых работают приложения.

Она позволяет запускать и обновлять их, чтобы они работали стабильно и без сбоев.

Контейнеры - это как коробки, которые содержат всё необходимое для работы приложения: код, библиотеки, зависимости, настройки и другие ресурсы.

Ключевые функции:
1. Запуск и мониторинг контейнеров - обеспечение работы параллельно запущенных копий приложения.
2. Балансировка нагрузки - распределение запросов между запущенными копиями приложения
3. Автомасштабирование - увеличение или уменьшение запущенных копий приложения
4. Обновления без простоя - можно делать постепенный переход на новую версию, заменяя старые контейнеры новыми
5. Автовосстановление в случае сбоев


🔴 OpenShift — это улучшенная версия Kubernetes. Это платформа контейнеризации, построенная на основе Kubernetes.

OpenShift создали, чтобы сделать Kubernetes более удобным за счет предоставления графического интерфейса и интеграции с другими сервисами.

OpenShift также добавляет дополнительные функции для обеспечения безопасности.


Kubernetes и OpenShift могут использовать как вместе, так и раздельно.

Применяются не только для систем с микросерверной архитектурой, но и для монолитов.


➡️ При работе на проектах, где используются Kubernetes и OpenShift, системный аналитик может встретиться с ситуацией, когда нужно описать поведение системы при недоступности одного из контейнеров.

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

#АрхитектураGA

🌱 Еще не микросервисы, но сильно улучшенный монолит 🌱

Или о том, как я больше года думала, что мы разрабатываем микросервисы, а потом узнала, что это модульный монолит, который легко поделится на микросервисы, и “ЯЖГОВОРИЛ” 🤣

Мы уже знаем как выглядит проект системы заказа такси #RideFlow в монолитной архитектуре. Главное, что мы из этого должны были усвоить:

➕ Единое сервер-приложение:
Все запросы и ответы от веб- и мобильных приложений направляются в одно место.

➕ Единая БД:
Все данные в одной схеме, то есть одна ER-диаграмма которую нужно знать, возможно с 100+ таблицами 🙂 Но исключения есть, бывает несколько БД.

➕ Может быть несколько API-интерфейсов:
В одном проекте может быть деление того же REST API на две и более части - public и admin, как минимум. Также нормальной практикой считается, когда у монолита поддержаны сразу несколько видов API: SOAP, REST, GraphQL и WebSocket, например.

😞 Проблема, которая есть у монолита - вся нагрузка в одно место. Лёг монолит - легло всё. И если код никак не разделен на независимые модули, то это печально.


В прошлом посте мы узнали про контейнеризацию приложений, OpenShift и Kubernetes. Так вот… Есть одна хитрость, которой пользуются стартаперы и молодые проекты - модульный монолит и контейнеризация модулей 🤩


👉 Модульный монолит создается по следующим правилам:
1. Монолит делят на независимые модули
2. Код поделен на части, но всё еще в одном месте - в одном репозитории
3. Зависимости между модулями остаются
4. Коммуникация между модулями по внутренним вызовам функций и методов классов
5. Общие ресурсы - БД, конфиги, библиотеки
6. Развертывание модулей может быть сделано независимо, каждый модуль можно масштабировать отдельно благодаря OpenShift и Kubernetes
7. У монолита есть счастливое микросервисное будущее 🌱

Картинку сделала чтобы максимизировать отличия и ваше понимание))

А подробнее про каждый из пунктов про модульный монолит, и особенно про 6, расскажу дальше 😉

#АрхитектураGA

👉Модульный монолит создается по следующим правилам👇

1. Монолит делят на независимые модули
Получаются логически независимые компоненты, каждый из которых отвечает за свою часть функциональности.

В приложении такси #RideFlow это управление пользователями, управление заказами, калькулятор стоимости поездки, геолокация. По сути то же, что мы прикидывали для микросервисов.


2. Код поделен на части, но все еще в одном месте
Вся кодовая база хранится всё ещё хранится в одном репозитории. Несмотря на разделение на модули, все они компилируются и деплоятся вместе как одно целое приложение.

Это отличие от микросервисной архитектуры, где каждый микросервис - независимое приложение со своим собственным репозиторием и циклом развертывания


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

Например, модуль "Заказы" может использовать функции модуля "Пользователи" для получения информации о нем


4. Коммуникация между модулями
В монолите модули взаимодействуют друг с другом по внутренним вызовам функций и методов классов кода.

А микросервисы общаются между собой только по сети (например, по HTTP), то есть через API.


5. Общие ресурсы
Модули разные, а вот база данных, конфигурационные файлы и библиотеки у них могут быть общие, в то время как у каждого микросервиса всё своё


6. Развертывание (релиз приложения сервера)
Та-дам 🎉 Вот тут то и ключевое преимущество!

❗️Каждый модуль монолита может быть упакован в отдельный контейнер

Это позволяет частично изолировать модули монолита, развертывать и обновлять их независимо, благодаря OpenShift и Kubernets.

Так, отдельный модуль можно будет запустить в 10 экземплярах, работающих параллельно, а другой всего лишь в 1-м


7. Счастливое микросервисное будущее🙌
Модули в будущем могут быть значительно легче вынесены из монолита и превращены в микросервисы. Но из-за общей БД, конфигураций и других ресурсов могут быть сложности...

#АрхитектураGA