⭐️ Гайд по 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

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

Почему так и плохо ли это? 🧐

Мы, аналитики, работаем с большим объемом информации. Чтобы начать работу над задачей, нужно погрузиться в контекст и настроиться. Это может занимать от 15 минут до 2 часов, даже если задача знакомая и я возвращаюсь к её решению.

4 раза отвлечься = минимум 1 час времени в никуда 😞

Ответы на сообщения и звонки - тоже задача. Чтобы в нее погрузиться, тоже нужно время.

Итого:
⏳тут 5 минут на сообщения,
⏳тут 10 минут на поговорить,
⏳тут на 30 минут “маленькая задачка и очень срочно”,
⏳и созвон по расписанию…
⏳соцсети открывать вообще не хочется.

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

Знакомо?

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

Хочется завершать работу вовремя и выключаться после неё полноценно, а не думать о незавершенных задачах.

Чтобы жизнь не превращалась в работу 24/7, я ввела правила, которые помогают держать тишину в процессе работы.

0. О правилах сфокусированной работы знают друзья, близкие и все, кто со мной взаимодействует. Без обид.

1. Все звуковые уведомления выключены. Только баннеры на самое важное. Дозвониться можно со второго раза.

2. Временные блоки на задачи 30, 60, 90 или 120 минут. В перерывах по 10-15 минут гуляю и/или звоню и отвечаю на срочные сообщения.

3. Ответить на сообщения и позвонить - тоже работа. Под нее два временных блока в сутки.

4. Работа в местах, где не будут отвлекать и задавать лишние вопросы.

5. Продуктивность в путешествиях не работает. Лучше брать отпуск на дни перемещений.

Это основные правила-спасатели 🙌


А как вы относитесь к отвлечениям во время работы и какие советы можете дать для повышения продуктивности рабочего процесса?

👀 Продолжение про модульный монолит и его направленность на переход в микросервисы 👀

Получается, что если разработчики заранее позаботились об организации структуры кода в монолите - разбиении его на независимые модули, то в дальнейшем он легко “пилится” на сервисы и микросервисы. Но как?

Уточню несколько моментов про контейнеризацию, независимые релизы, Kubernetes и OpenShift.



▫️ Сервер-приложение модульного монолита по умолчанию упаковывается в один контейнер

Модульный монолит - это одна кодовая база. “По волшебству” обновлять отдельно каждый модуль, как микросервисы, не получится.

Как модульный монолит может работать на старте:

1. Пусть у нас уже есть модули кода, которые могут работать независимо. В идеале, без вызова других.

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

3. Итого, этот один контейнер будет релизиться через Kubernetes всё ещё как одно большое монолитное сервер-приложение. В консоли OpenShift мы будем видеть одно сервер-приложение, которым можно управлять - увеличивать или уменьшать количество запущенных экземпляров.

👉 Это случай, когда модульность никаких преимуществ ПОКА не даёт.

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




▫️ Далее, каждый модуль монолита может быть упакован в отдельный контейнер и работать независимо

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

Когда модуль упаковывают в отдельный контейнер, то происходит примерно следующее:

1. Берут код модуля из общего репозитория монолита.
Что касается дальнейшего хранения кода. Есть разные решения, но скорее всего код модуля будут выносить из общего репозитория.

2. Берут библиотеки, конфигурации и другие ресурсы связанные с модулем.

3. Проверяются зависимости с другими модулями:
3а. Если их не было - готово! Ваш модуль может быть вынесен из монолита и упакован в отдельный контейнер.
3б. Если они были, то тут сложнее. Надо продумывать как вынесенный модуль будет взаимодействовать с основным монолитом. Надо глубже погружаться в особенности взаимодействия подов в Kubernetes, в межсервисное взаимодействие в Kubernetes.

4. Упаковывают всё, что взяли, в отдельный контейнер от основного монолита.

5. Запускают контейнер отдельно и независимо.

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

А если ему добавить свою БД, убрать взаимодействие с общей БД, добавить API, и еще много других важных действий, то он станет микросервисом. Но это уже слишком много дополнительных действий, которые требуется сделать.




▫️ Итого:

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

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

❗️Коллеги аналитики, вопросами развертывания монолита и правильной упаковки модулей в контейнеры занимаются разработчики и команда инфраструктуры (DevOps специалисты, которые отвечают за релизы приложений). Это их зона ответственности и системных аналитиков сюда не допускают.

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


Для тех, кому стала интересна тема инфраструктуры, даю почитать понятные для аналитиков статьи, от которых можно далее продолжать исследования в темах инфраструктуры и DevOps для монолитов и микросервисов.

Отдельным постом 👇📚📚📚


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