Привет! 👋

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


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

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

Это значит, что внутри одной системы микросервисы могут:

1️⃣ разрабатываться на разных языках программирования;

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

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


2️⃣ развёртываться независимо друг от друга;

Развёртывание – это процесс подготовки и настройки приложения для его работы в продуктивной (или тестовой) среде.

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

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


3️⃣ легко масштабироваться.

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

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

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

#hardGetAnalyst

🔶 ПРО МАСШТАБИРОВАНИЕ СИСТЕМЫ 🔶

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

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


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

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


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

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

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


Сохраняйте пост в закладки, потому что вопросы по теме проектирования архитектуры и вариантов масштабирования решений - одни из самых популярных в собеседовании на должность СА 👍

#hardGetAnalyst

Искренне цените каждый прожитый день и создавайте приятные воспоминания с близкими. Крепко вас обнимаем ❣️

В новом эпизоде разобрана работа механизма вебхуков на примере интеграции между медицинской и страховой системой.

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

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

1:50 - Обсуждение возможных вариантов решения задачи, если вы не знакомы с механизмом вебхуков (Webhooks). Polling и Long Polling и почему.
08:53 - Что такое вебхуки - разбор на примере интеграции медицинской и страховой систем.
10:42 - Как технически реализуется вебхук в рамках интеграции систем, когда в нашу систему-подписчика надо получать уведомления из внешней.
14:54 - Почему механизм Webhooks лучше механизма Polling и других подобных способов опроса внешней системы по таймерам, по расписанию.
20:30 - Как обеспечить работу вебхуков: реализация на стороне системы, которая оповещает о событиях.
26:23 - Почему рекомендуется использовать очереди сообщений (RabbitMQ / Kafka) для рассылки уведомлений о произошедших событиях при реализации вебхуков. Алгоритм реализации обработки сообщений из очереди.
28:47 - Механизм подписки на вебхуки для потребителей уведомлений.
31:05 - Прием вебхуков на стороне системы-подписчика в очередь и последующая их обработка.
32:27 - Про реализацию метода POST для вебхука на стороне системы-подписчика.
36:08 - Больше примеров задач и бизнес-процессов, где нужны вебхуки.
39:49 - Подведение итогов и рекомендации.

🔗 Дополнительные материалы к подкасту

Эпизод доступен в:

⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify

Подписывайтесь, чтобы не пропускать новые эпизоды! 🎙

POSTMAN или SWAGGER? 🧐

Оба инструмента входят в топ необходимых для системных и бизнес-аналитиков, которые участвуют в проектировании API.
Но чем они отличаются? А чем похожи? Давайте разбираться.


1️⃣ Postman — это интуитивно-понятное приложение, которое позволяет отправлять запросы к API и получать ответы от него.
Эти функции полезны для тестирования, отладки и проверки работоспособности API.

Postman также предоставляет возможность сохранять запросы и создавать коллекции запросов, что делает процесс тестирования API более организованным и быстрым. А ещё в нем можно вести API-документацию и писать автотесты для системной логики (бэкэнда). Наш босс Екатерина говорит, что этот инструмент вообще мастхэв и ультраприорити. Честно говоря, мы с ней согласны!

2️⃣ Swagger — это набор инструментов, который позволяет создавать документацию для API.
Swagger использует язык описания OpenAPI, благодаря чему автоматически генерирует документацию для API. Это упрощает процесс описания и тестирования API.

🥷: Документировать API можно и другими способами (например, с помощью Git-документации или Confluence). Поэтому аналитику осваивать Swagger однозначно нужно, но не так срочно, как Postman, например.


Знание Postman и Swagger может быть полезным для системных и бизнес- аналитиков при общении с разработчиками и тестировщиками. А ещё использование Postman и Swagger помогает:
🔹улучшить процесс проектирования API;
🔹упростить процесс тестирования и документирования;
🔹повысить качество кода засчет написания автотестов.

Оба инструмента бесплатные. Поэтому вы можете начать осваивать их самостоятельно в любой момент или обучаться этим навыкам вместе с командой GetAnalyst на наших вебинарах и курсах 🪄

Всем привет! 👋

Postman — это специальный сервис для создания, тестирования и документирования клиент-серверного взаимодействия.

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

Подробнее о Postman для системного аналитика рассказывает эксперт команды GetAnalyst Сергей, смотрим! 👀⬆️

🥷: А ещё делимся записью вебинара с Екатериной Ананьевой на тему работы с Postman: с нуля и до уверенного пользователя 😉

😎 Кажется, это самая понятная картинка на тему join-ов в SQL!

Используем даже два хэштега для этой картинки:
#GAhahaha и #hardGetAnalyst,
чтобы вы могли найти этот мем и использовать в работе 😉