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

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

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

Наиболее популярны два основных вида архитектур: монолитная и микросервисная.

Популярность микросервисной архитектуры в последнее время быстро растёт, и всё чаще крупные компании отказываются от монолитной организации продуктов. Но монолитную концепцию нельзя при этом назвать устаревшей: в каких-то случаях она прекрасно работает и некоторые большие компании всё ещё держат монолитные ПО. Такая архитектура полезна на начальной стадии продукта, монолит идеально подходит стартапам, которым очень важно быстро запустить продукт.
Микросервисы очень популярны и хороши, но они подходят не для всех ПО. Такая архитектура подходит сложным системам, которые должны быть гибкими и масштабируемыми.

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

Ну а затем КВИЗанём полученные знания, чтобы закрепить теорию 😉✨

#hardGetAnalyst

✨ ПРО МОНОЛИТНУЮ АРХИТЕКТУРУ ✨

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

Далее поговорим про плюсы и минусы монолитной архитектуры.


ПЛЮСЫ:

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

🟢Лучшая производительность
При правильной сборке монолитное ПО производительнее микросервисного за счёт того, что монолит обеспечивает более быструю связь между программными компонентами благодаря общему коду и памяти.

🟢Меньше проблем с сопровождением
Благодаря единой кодовой базе ПО легче взаимодействует с инструментами, например с ведением логов и историчности.


МИНУСЫ:

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

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

🟣Сложность внедрения новых технологий.
Чтобы добавить новую технологию, нужно переписать всю программу, что является очень трудоёмким и дорогим процессом.


Продолжение завтра 🫡

✨ ПРО МИКРОСЕРВИСНУЮ АРХИТЕКТУРУ ✨

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

Микросервисы — это маленькие программы, которые живут на своём сервере и выполняют только свои определённые виды задач.

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

🥷: Кстати говоря, Netflix, Amazon, Twitter, eBay и PayPal эволюционировали из монолита в микросервисы.

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

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

ПЛЮСЫ:

🟢Возможность разгрузить систему, распределив нагрузку на микросервисы

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

🟢При помощи микросервисов несколько разных команд могут быстро работать над разными сервисами независимо друг от друга.

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


МИНУСЫ:

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

🟣Угрозы безопасности ПО.
Поскольку становится больше таких микросервисов, которые могут общаться с внешними источниками, повышается вероятность атаки злоумышленников.

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


Ну как-то так.
Завтра планируем запустить КВИЗ, но хочется понять, нужны ли какие-то пояснения к теории или вы готовы проверить свои знания?

Ставьте реакции:
👍 - готовы к КВИЗу!
👀 - ничего непонятно, но очень интересно!

ИТАК, КВИЗ! 😮

Ранее мы познакомились с вами с различными видами архитектуры. Пришло время проверить свои знания 🙃

КВИЗ будет состоять из двух частей:
- в первой части мы предложим несколько высказываний, которые относятся к какому-то виду архитектуры,
- во второй части вы получите описание условий, в рамках которых необходимо определиться с наиболее подходящим видом архитектуры.

Не переживайте – вы справитесь! Но чтобы улучшить свой результат, рекомендуем ещё раз прочитать теорию из постов выше ⬆️

Как только наберём 20🔥 на этом посте, запустим КВИЗ! 😘

#quizGetAnalyst

💫 Личный опыт: как стать системным аналитиком 💫

Привет!

Мы долго к этому шли и пришли 😎 Ура! Первый эпизод подкаста GetAnalyst - Released! 🎉
Пол года подготовки, как моральной, так и техническо-организационной, и теперь мы готовы стабильно выпускать эпизоды раз в неделю 💫

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

Обсуждается профессия системного аналитика: роль, задачи и путь к карьерному росту.

0:50 - Екатерина Ананьева и сообщество GetAnalyst
4:00 - Кто такой системный аналитик
8:10 - Процесс работы с рабочими задачами
19:10 - Как Екатерина выбрала системный анализ. О мечтах и "Я тоже могу"
23:25 - Поиск работы и портфолио аналитика: первое предложение о работе junior-системному аналитику
37:55 - Почему был создан проект GetAnalyst
40:25 - Идея подкаста GetAnalyst, пожелания и рекомендации подписчикам

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

⏯ Apple Podcast
⏯ Spotify
⏯ Amazon Music
⏯ Telegram

🔗 Обратная связь и предложения

*Яндекс.Музыка, YouTube (будут выпуски с видео-сопровождением) и Google.Podast в процессе. Ссылки добавим.

Подписывайтесь на платформах! Делитесь с коллегами и начинающими системными аналитиками! 🙌