Заряжающие выходные 🙌🌸🌱
Друзья, длинные выходные это то время, которое вы должны посвятить настоящему отдыху:
🌸 сходить на прогулку,
🌸 запланировать душевную встречу с друзьями,
🌸 провести ужин в ресторане с близким человеком,
🌸 пролежать под одеялом с сериалами весь день,
🌸 сходить в СПА или на массаж,
🌸 съездить в путешествие, даже в небольшое,
🌸 картинг, рисование или прогулка на лошадях.
Занятия, которые мы вечно переносим из-за работы и переработок, должны быть реализованы. Отдых важен, и сейчас точно есть время на него!
Майские каникулы - это почти середина года. Время, когда можно остановиться и в спокойной обстановке поразмыслить что уже получилось с начала Нового года, что нет, скорректировать планы на следующую часть года и начать их реализацию. Я использую это время так 🚀
А если вы уже хорошо отдохнули в первой половине каникул, чувствуете заряд энергии, и сейчас хочется сделать что-то полезное для карьерного роста, то предлагаю заглянуть в Материалы для самостоятельного обучения GetAnalyst, которые мы собрали для вас 🙌
Эти практические занятия помогут вам с легкостью и без препятствий начать идти по пути карьерного роста в продолжении 2024 года! 🎉🌱
Друзья, длинные выходные это то время, которое вы должны посвятить настоящему отдыху:
🌸 сходить на прогулку,
🌸 запланировать душевную встречу с друзьями,
🌸 провести ужин в ресторане с близким человеком,
🌸 пролежать под одеялом с сериалами весь день,
🌸 сходить в СПА или на массаж,
🌸 съездить в путешествие, даже в небольшое,
🌸 картинг, рисование или прогулка на лошадях.
Занятия, которые мы вечно переносим из-за работы и переработок, должны быть реализованы. Отдых важен, и сейчас точно есть время на него!
Майские каникулы - это почти середина года. Время, когда можно остановиться и в спокойной обстановке поразмыслить что уже получилось с начала Нового года, что нет, скорректировать планы на следующую часть года и начать их реализацию. Я использую это время так 🚀
А если вы уже хорошо отдохнули в первой половине каникул, чувствуете заряд энергии, и сейчас хочется сделать что-то полезное для карьерного роста, то предлагаю заглянуть в Материалы для самостоятельного обучения GetAnalyst, которые мы собрали для вас 🙌
Эти практические занятия помогут вам с легкостью и без препятствий начать идти по пути карьерного роста в продолжении 2024 года! 🎉🌱
❤14👍5🦄2👏1
💫 Архитектура в C4 / Context - проект TelMed 💫
Самый верхний уровень C4 / Context показывает систему и её окружение. Проектируя его, мы не заморачиваемся с тем, какой подход к архитектуре будет выбран — будь то монолит, сервисно-ориентированная архитектура или микросервисы.
Все, что показывает C4 / Context:
1. Пользователей, которые работают с системой.
2. Интеграции с внешними системами.
Основное преимущество этого уровня заключается в его наглядности и доступности как для IT-команды, так и для бизнес-стейкхолдеров. Его может разработать как системный аналитик, так и бизнес-аналитик.
Понимание пользователей критично для определения ролевой модели системы, управления доступами и выявления потенциальных ограничений. Этот уровень также позволяет предположить, какие приложения могут быть важны для пользователей.
А интеграции это то, что нужно знать о любой системе. Это вся техническая суть C4 / Context.
Интеграции влияют на:
+ Работу отдельных бизнес-процессов в системе и синхронизацию данных по ним, а также на работу с данными в системе в целом.
+ Доступ бизнеса к данным по отдельным бизнес-процессам через внешние приложения, благодаря настроенной синхронизации.
+ Безопасность, так как каждая точка интеграции в системе это потенциальное место для атаки.
+ Масштабируемость, так как в системе одновременно может работать большое количество пользователей и важно понимать, как много одновременных запросов от нашей системы сможет обрабатывать внешняя система.
Пример схемы проекта по телемедицине TelMed поможет нам понять, как реализуется C4 / Context на практике. См. картинку к посту.
Подробный гайд по всем уровням нотации моделирования архитектуры C4 тут, если вы пропустили его на прошлой неделе и хорошо отдохнули на праздничных выходных 💫
Вопросы по схеме? Пишите комментарии.
Всё понятно и готовы идти дальше? Ставьте 👍
#АрхитектураGA #TelMedGA
Самый верхний уровень C4 / Context показывает систему и её окружение. Проектируя его, мы не заморачиваемся с тем, какой подход к архитектуре будет выбран — будь то монолит, сервисно-ориентированная архитектура или микросервисы.
Все, что показывает C4 / Context:
1. Пользователей, которые работают с системой.
2. Интеграции с внешними системами.
Основное преимущество этого уровня заключается в его наглядности и доступности как для IT-команды, так и для бизнес-стейкхолдеров. Его может разработать как системный аналитик, так и бизнес-аналитик.
Понимание пользователей критично для определения ролевой модели системы, управления доступами и выявления потенциальных ограничений. Этот уровень также позволяет предположить, какие приложения могут быть важны для пользователей.
А интеграции это то, что нужно знать о любой системе. Это вся техническая суть C4 / Context.
Интеграции влияют на:
+ Работу отдельных бизнес-процессов в системе и синхронизацию данных по ним, а также на работу с данными в системе в целом.
+ Доступ бизнеса к данным по отдельным бизнес-процессам через внешние приложения, благодаря настроенной синхронизации.
+ Безопасность, так как каждая точка интеграции в системе это потенциальное место для атаки.
+ Масштабируемость, так как в системе одновременно может работать большое количество пользователей и важно понимать, как много одновременных запросов от нашей системы сможет обрабатывать внешняя система.
Пример схемы проекта по телемедицине TelMed поможет нам понять, как реализуется C4 / Context на практике. См. картинку к посту.
Подробный гайд по всем уровням нотации моделирования архитектуры C4 тут, если вы пропустили его на прошлой неделе и хорошо отдохнули на праздничных выходных 💫
Вопросы по схеме? Пишите комментарии.
Всё понятно и готовы идти дальше? Ставьте 👍
#АрхитектураGA #TelMedGA
👍21❤9🔥2🥰2👏2
🪨 Монолитная архитектура в C4 / Container - пример для проекта TelMed 🪨
На прошлой неделе я рассказала теорию про монолиты, а теперь хочу показать, как выглядит монолитная архитектура на примере телемедицинского проекта.
Для демонстрации воспользуюсь C4 / Container (контейнеры) и покажу, как она расширяет предыдущий уровень C4 / Context.
Монолит для TelMed - идеальное решение, если мы делаем разработку с нуля. Пока у нас нет пользователей и масштабных нагрузок, зачем усложнять?
Таже в нашем проекте мы избегаем жесткой монолитной архитектуры — мы не будем смешивать код пользовательского интерфейса веб-приложений (UI) и Backend. Такое решение обусловлено наличием мобильных приложений, для которых в любом случае потребуется разработка API.
Итого, мы создаем современную версию монолитной архитектуры, где монолитным остается только Backend (приложение для сервера).
Внутри монолитного Backend можно будет организовать функциональные модули. Их обычно показывают на схеме C4 / Component. Модульный монолит в будущем поможет легче переехать на сервисную архитектуру, если это потребуется.
Основное на схеме C4 / Container для монолита:
- Пользователи.
- Внешние системы и оборудование.
- Приложения пользователей.
- Монолитное сервер-приложение - Backend.
- Базы данных - для монолита одна, отдельные схемы не отражают.
- Очереди сообщений, брокеры.
Для монолитной системы онлайн-приёмов к врачам пример схемы есть ✅ Схема прикреплена к посту.
Для системного аналитика понимание архитектуры проекта необходимо, чтобы:
1. Делать точные и технически грамотные постановки задач на разработчиков, в частности, на интеграции систем.
2. Понимать нефункциональные требования, и зачем мы их делаем. В частности про безопасность, надежность и масштабирование.
3. Уверенно чувствовать себя в диалогах с разработчиками и архитекторами, потому что понимаешь всё и не теряешься, когда тебя просят задокументировать архитектуру.
Разбирайте и запоминайте, чтобы в будущем перенести этот опыт на свои задачи 🙌
#АрхитектураGA #TelMedGA
На прошлой неделе я рассказала теорию про монолиты, а теперь хочу показать, как выглядит монолитная архитектура на примере телемедицинского проекта.
Для демонстрации воспользуюсь C4 / Container (контейнеры) и покажу, как она расширяет предыдущий уровень C4 / Context.
Монолит для TelMed - идеальное решение, если мы делаем разработку с нуля. Пока у нас нет пользователей и масштабных нагрузок, зачем усложнять?
Таже в нашем проекте мы избегаем жесткой монолитной архитектуры — мы не будем смешивать код пользовательского интерфейса веб-приложений (UI) и Backend. Такое решение обусловлено наличием мобильных приложений, для которых в любом случае потребуется разработка API.
Итого, мы создаем современную версию монолитной архитектуры, где монолитным остается только Backend (приложение для сервера).
Внутри монолитного Backend можно будет организовать функциональные модули. Их обычно показывают на схеме C4 / Component. Модульный монолит в будущем поможет легче переехать на сервисную архитектуру, если это потребуется.
Основное на схеме C4 / Container для монолита:
- Пользователи.
- Внешние системы и оборудование.
- Приложения пользователей.
- Монолитное сервер-приложение - Backend.
- Базы данных - для монолита одна, отдельные схемы не отражают.
- Очереди сообщений, брокеры.
Для монолитной системы онлайн-приёмов к врачам пример схемы есть ✅ Схема прикреплена к посту.
Для системного аналитика понимание архитектуры проекта необходимо, чтобы:
1. Делать точные и технически грамотные постановки задач на разработчиков, в частности, на интеграции систем.
2. Понимать нефункциональные требования, и зачем мы их делаем. В частности про безопасность, надежность и масштабирование.
3. Уверенно чувствовать себя в диалогах с разработчиками и архитекторами, потому что понимаешь всё и не теряешься, когда тебя просят задокументировать архитектуру.
Разбирайте и запоминайте, чтобы в будущем перенести этот опыт на свои задачи 🙌
#АрхитектураGA #TelMedGA
👏9👍5❤4🔥2
🖥 Сервисная архитектура - что важно знать системному аналитику 🖥
Сервис-ориентированная архитектура (SOA) представляет собой подход, который позволяет разрабатывать приложения как набор взаимосвязанных сервисов.
Когда мы думаем о серверной части приложения Backend, то надо представлять, что это НЕ одно большое приложение, как монолит, НЕ один прямоугольник “Backend” на схеме архитектуры, а много разных прямоугольников - сервисов, каждый из которых может быть установлен на отдельном сервере, иметь свою собственную базу данных и обновляться независимо от остальных.
Эти сервисы общаются друг с другом, обычно через веб-сервисы или API, для выполнения различных бизнес-задач.
Например, в проекте TelMed, я могу вынести в отдельный сервис весь процесс работы с анализами, включая интеграцию с лабораториями. Когда мне нужно будет обновлять функциональность, связанную с анализами пациентом, то временно недоступна в системе будет только эта часть про анализы. Вся остальная система будет работать без остановки и доступна пользователям всё время в процессе обновления.
Ключевые особенности SOA + отличия от Монолита:
💪 Backend разбивается на отдельные, независимые сервисы.
💪 Сервисы можно легко добавлять, удалять или обновлять без влияния на остальную часть системы. Каждый сервис можно разрабатывать, тестировать, развертывать и масштабировать независимо.
💪 Сервисы могут масштабироваться независимо друг от друга как горизонтально, так и вертикально, что оптимизирует ресурсное использование и управление нагрузкой.
💪 Ошибки в одном сервисе обычно не влияют на работу других сервисов, что повышает надежность всей системы.
💪 SOA позволяет использовать различные технологии и языки программирования в рамках одного проекта. То есть сервис анализов может быть на PHP, а вся остальная система на Java. Это позволяет программистам пробовать осторожно внедрять новые технологии в проекты при разработке новых сервисов.
#АрхитектураGA #TelMedGA
Сервис-ориентированная архитектура (SOA) представляет собой подход, который позволяет разрабатывать приложения как набор взаимосвязанных сервисов.
Когда мы думаем о серверной части приложения Backend, то надо представлять, что это НЕ одно большое приложение, как монолит, НЕ один прямоугольник “Backend” на схеме архитектуры, а много разных прямоугольников - сервисов, каждый из которых может быть установлен на отдельном сервере, иметь свою собственную базу данных и обновляться независимо от остальных.
Эти сервисы общаются друг с другом, обычно через веб-сервисы или API, для выполнения различных бизнес-задач.
Например, в проекте TelMed, я могу вынести в отдельный сервис весь процесс работы с анализами, включая интеграцию с лабораториями. Когда мне нужно будет обновлять функциональность, связанную с анализами пациентом, то временно недоступна в системе будет только эта часть про анализы. Вся остальная система будет работать без остановки и доступна пользователям всё время в процессе обновления.
Ключевые особенности SOA + отличия от Монолита:
💪 Backend разбивается на отдельные, независимые сервисы.
💪 Сервисы можно легко добавлять, удалять или обновлять без влияния на остальную часть системы. Каждый сервис можно разрабатывать, тестировать, развертывать и масштабировать независимо.
💪 Сервисы могут масштабироваться независимо друг от друга как горизонтально, так и вертикально, что оптимизирует ресурсное использование и управление нагрузкой.
💪 Ошибки в одном сервисе обычно не влияют на работу других сервисов, что повышает надежность всей системы.
💪 SOA позволяет использовать различные технологии и языки программирования в рамках одного проекта. То есть сервис анализов может быть на PHP, а вся остальная система на Java. Это позволяет программистам пробовать осторожно внедрять новые технологии в проекты при разработке новых сервисов.
#АрхитектураGA #TelMedGA
👍21❤5🔥4
🌱 Микросервисная архитектура (MSA) 🌱
Микросервисная архитектура (MSA - MicroService Architecture) - принцип разработки программного обеспечения, в котором сложное приложение разбивается на небольшие, независимые части, выполняющие конкретные функции. Эти части называют микросервисами.
Микросервисы обычно общаются с другими сервисами через HTTP API, REST API, также наблюдаются тренды внедрения gRPC.
Ключевые особенности MSA и отличия от SOA:
💪 Приложение разделяется на множество небольших сервисов, каждый из которых отвечает за выполнение конкретной бизнес-функции. Обычно они более специализированы, чем в SOA. В SOA логика одного сервиса может включать широкий набор возможностей.
💪 Сервисы могут разрабатываться, тестироваться и развертываться независимо друг от друга. То же верно и для SOA.
💪 Разные микросервисы могут использовать разные технологии и базы данных, оптимизированные под их конкретные задачи. То же, что и в SOA.
💪 Ошибки в одном сервисе обычно не влияют на работу других сервисов, что повышает надежность всей системы. То же, что и в SOA.
💪 По классическому шаблону MSA для каждого микросервиса делают свою БД, в то время как для SOA допустимо использование одной БД несколькими сервисами.
💪 Микросервисы используют более простые и децентрализованные методы связи как API Gateway, хореограф и оркестратор, в то время как SOA может полагаться на более сложные механизмы, такие как Enterprise Service Bus (ESB).
Примеры мировых проектов с MSA:
🔸 Netflix: микросервисы для стриминга видео, рекомендаций контента, управления профилями пользователей и другие.
🔸 Amazon: сервисы управления заказами, обработки платежей, управления каталогом товаров и другие.
🔸 Банковская сфера: микросервисы аутентификации и авторизации, управления счетами, уведомлений и другие.
Ключевые отличия между SOA и MSA показала на прикрепленной к посту картинке. Раскроем каждый пункт по особенностям SOA в следующем посте сегодня 😉
#АрхитектураGA
Микросервисная архитектура (MSA - MicroService Architecture) - принцип разработки программного обеспечения, в котором сложное приложение разбивается на небольшие, независимые части, выполняющие конкретные функции. Эти части называют микросервисами.
Микросервисы обычно общаются с другими сервисами через HTTP API, REST API, также наблюдаются тренды внедрения gRPC.
Ключевые особенности MSA и отличия от SOA:
💪 Приложение разделяется на множество небольших сервисов, каждый из которых отвечает за выполнение конкретной бизнес-функции. Обычно они более специализированы, чем в SOA. В SOA логика одного сервиса может включать широкий набор возможностей.
💪 Сервисы могут разрабатываться, тестироваться и развертываться независимо друг от друга. То же верно и для SOA.
💪 Разные микросервисы могут использовать разные технологии и базы данных, оптимизированные под их конкретные задачи. То же, что и в SOA.
💪 Ошибки в одном сервисе обычно не влияют на работу других сервисов, что повышает надежность всей системы. То же, что и в SOA.
💪 По классическому шаблону MSA для каждого микросервиса делают свою БД, в то время как для SOA допустимо использование одной БД несколькими сервисами.
💪 Микросервисы используют более простые и децентрализованные методы связи как API Gateway, хореограф и оркестратор, в то время как SOA может полагаться на более сложные механизмы, такие как Enterprise Service Bus (ESB).
Примеры мировых проектов с MSA:
🔸 Netflix: микросервисы для стриминга видео, рекомендаций контента, управления профилями пользователей и другие.
🔸 Amazon: сервисы управления заказами, обработки платежей, управления каталогом товаров и другие.
🔸 Банковская сфера: микросервисы аутентификации и авторизации, управления счетами, уведомлений и другие.
Ключевые отличия между SOA и MSA показала на прикрепленной к посту картинке. Раскроем каждый пункт по особенностям SOA в следующем посте сегодня 😉
#АрхитектураGA
⚡13👍11🔥4❤3
🌱 Микросервисная архитектура (MSA) - детальный разбор с примерами 🌱
Микросервисная архитектура представляет собой решение, позволяющее эффективно адаптироваться к быстро меняющимся требованиям и масштабироваться при росте пользователей и функций в системе.
Разбираем ключевые особенности на примерах:
💪 Приложение разделяется на множество небольших сервисов, каждый из которых отвечает за выполнение конкретной бизнес-функции.
Другими словами, каждый сервис будет отвечать за работу с одной конкретной сущностью или узконаправленной функциональностью.
В TelMed можно выделить микросервисы управление записями на приём, управления записями о докторах, обработки платежей. В SOA сервисы управления записями на приём и докторами могли бы быть объединены в один сервис общей логики.
Микросервис управления перс. данными пациентов строится вокруг конкретной бизнес-потребности — обеспечение безопасности и конфиденциальности, в соответствии с требованиями закона о защите данных. Он занимается только этой узконаправленной задачей.
💪 Сервисы могут разрабатываться, тестироваться и развертываться независимо друг от друга.
Над микросервисами управления медицинскими картами, врачей и видеоконсультаций могут работать разные команды параллельно.
Тестирование, программирование и релизы совершенно не пересекаются, и команды могут не бояться задеть друг-друга или внести несовместимые изменения в код. Это разные кодовые базы.
Проблемы возможны только при наличии внутренних интеграций, если изменения касаются состава данных, которые передаются из одного микросервиса в другой.
💪 Разные микросервисы могут использовать разные технологии и базы данных, оптимизированные под их конкретные задачи.
В одном микросервисе могут использовать реляционную СУБД PostgreSQL, в то время как для другого подберут нереляционную СУБД MongoDB.
То же верно и для языков программирования.
Но по опыту скажу, что стараются держать общие подходы на весь проект и не устраивать зоопарк из технологий.
Продолжение 👇
#АрхитектураGA #TelMedGA
Микросервисная архитектура представляет собой решение, позволяющее эффективно адаптироваться к быстро меняющимся требованиям и масштабироваться при росте пользователей и функций в системе.
Разбираем ключевые особенности на примерах:
💪 Приложение разделяется на множество небольших сервисов, каждый из которых отвечает за выполнение конкретной бизнес-функции.
Другими словами, каждый сервис будет отвечать за работу с одной конкретной сущностью или узконаправленной функциональностью.
В TelMed можно выделить микросервисы управление записями на приём, управления записями о докторах, обработки платежей. В SOA сервисы управления записями на приём и докторами могли бы быть объединены в один сервис общей логики.
Микросервис управления перс. данными пациентов строится вокруг конкретной бизнес-потребности — обеспечение безопасности и конфиденциальности, в соответствии с требованиями закона о защите данных. Он занимается только этой узконаправленной задачей.
💪 Сервисы могут разрабатываться, тестироваться и развертываться независимо друг от друга.
Над микросервисами управления медицинскими картами, врачей и видеоконсультаций могут работать разные команды параллельно.
Тестирование, программирование и релизы совершенно не пересекаются, и команды могут не бояться задеть друг-друга или внести несовместимые изменения в код. Это разные кодовые базы.
Проблемы возможны только при наличии внутренних интеграций, если изменения касаются состава данных, которые передаются из одного микросервиса в другой.
💪 Разные микросервисы могут использовать разные технологии и базы данных, оптимизированные под их конкретные задачи.
В одном микросервисе могут использовать реляционную СУБД PostgreSQL, в то время как для другого подберут нереляционную СУБД MongoDB.
То же верно и для языков программирования.
Но по опыту скажу, что стараются держать общие подходы на весь проект и не устраивать зоопарк из технологий.
Продолжение 👇
#АрхитектураGA #TelMedGA
👍12❤3👏3
💪 В микросервисах ошибки в одном сервисе обычно не влияют на работу других сервисов, что повышает надежность всей системы.
Если микросервис платежей отключится, то микросервис поиска докторов это не затронет и пользователи, которые работают с поиском докторов, могут даже не заметить, что какая-то часть системы не работала.
💪 По классическому шаблону MSA для каждого микросервиса делают одну свою БД, в то время как для SOA допустимо использование одной БД несколькими сервисами.
Это позволяет быть микросервисам полностью независимыми. В SOA при обновлении структуры БД могут стать недоступны все связанные с ней сервисы, которых может быть 5. А в MSA при обновлении одной БД может быть недоступен только один связанный с ней микросервис.
💪 Микросервисы используют более простые и децентрализованные методы связи как API Gateway, хореограф и оркестратор, в то время как SOA может полагаться на более сложные механизмы, такие как Enterprise Service Bus (ESB).
🔸 Два самых важных отличия между SOA и MSA - размеры сервисов и количество БД на один сервис. Остальное во многом схоже.
Знания о микросервисах позволяют аналитикам ставить более точные задачи разработчикам, прогнозировать последствия изменений в функциональности и гарантировать высокую надежность и производительность системы. Аналитики ясно и понятно формулируют технические требования к межсервисному взаимодействию для разработчиков, что значительно повышает качество и ценность их работы для ИТ-компаний.
В связи с этим, для крупных проектов предпочтение отдают системным аналитикам, которые имеют опыт работы с микросервисной архитектурой. Такие специалисты понимают сложности, связанные с синхронизацией данных между различными базами данных и особенности внутренних и внешних интеграций проекта 🙌
#АрхитектураGA #TelMedGA
Если микросервис платежей отключится, то микросервис поиска докторов это не затронет и пользователи, которые работают с поиском докторов, могут даже не заметить, что какая-то часть системы не работала.
💪 По классическому шаблону MSA для каждого микросервиса делают одну свою БД, в то время как для SOA допустимо использование одной БД несколькими сервисами.
Это позволяет быть микросервисам полностью независимыми. В SOA при обновлении структуры БД могут стать недоступны все связанные с ней сервисы, которых может быть 5. А в MSA при обновлении одной БД может быть недоступен только один связанный с ней микросервис.
💪 Микросервисы используют более простые и децентрализованные методы связи как API Gateway, хореограф и оркестратор, в то время как SOA может полагаться на более сложные механизмы, такие как Enterprise Service Bus (ESB).
🔸 Два самых важных отличия между SOA и MSA - размеры сервисов и количество БД на один сервис. Остальное во многом схоже.
Знания о микросервисах позволяют аналитикам ставить более точные задачи разработчикам, прогнозировать последствия изменений в функциональности и гарантировать высокую надежность и производительность системы. Аналитики ясно и понятно формулируют технические требования к межсервисному взаимодействию для разработчиков, что значительно повышает качество и ценность их работы для ИТ-компаний.
В связи с этим, для крупных проектов предпочтение отдают системным аналитикам, которые имеют опыт работы с микросервисной архитектурой. Такие специалисты понимают сложности, связанные с синхронизацией данных между различными базами данных и особенности внутренних и внешних интеграций проекта 🙌
#АрхитектураGA #TelMedGA
👍6❤5💯3
Архитектура для аналитиков: опыт работы здесь 🙌
В этом году я запустила новую практическую программу, которая улучшилась в процессе ведения первого потока и дополнилась огромным количеством дополнительных материалов и разборов примеров.
🌟 Проектирование архитектуры
🌟 Старт предобучения 28 мая 2024
🌟 Подробности о программе и запись
В ней я проявила максимальные занудство и дотошность. Собирала не только свой опыт, но и подключила других экспертов.
Один из важных отзывов, повторяемый разными словами в чатах:
Эта программа подойдёт только для опытных системных аналитиков (Middle и выше), кто уже работал с интеграциями, и хочет расти в Senior внутри компании, или переходить в интересные и сложные проекты.
🎁 С 15 до 22 маяоткрыта предзапись на специальных условиях + дополнительное обучение по REST API в подарок.
Для всех, кто оставлял запросы до сегодняшнего дня и уже связался с нами, действует аналогичное предложение 🎁
Навыки работы с архитектурой, очередями, API, взаимодействием систем в реальном времени, которые аналитики получили в ходе работы, уже сейчас помогают им:
+ проходить аттестацию в компании на повышение грейда,
+ менять работу,
+ получать повышения.
Создавать IT-таланты в Системном Анализе - цель GetAnalyst.
И Архитектура - самая сложная, но самая интересная часть в этом пути 🙌
2024 - год больших и крутых перемен ♥️ Давайте идти к ним вместе!
В этом году я запустила новую практическую программу, которая улучшилась в процессе ведения первого потока и дополнилась огромным количеством дополнительных материалов и разборов примеров.
🌟 Проектирование архитектуры
🌟 Старт предобучения 28 мая 2024
🌟 Подробности о программе и запись
В ней я проявила максимальные занудство и дотошность. Собирала не только свой опыт, но и подключила других экспертов.
Один из важных отзывов, повторяемый разными словами в чатах:
“Есть возможность попрактиковаться в проектировании архитектурного решения, выйти за пределы "пузыря" моей работы и налаженных процессов на работе”
Эта программа подойдёт только для опытных системных аналитиков (Middle и выше), кто уже работал с интеграциями, и хочет расти в Senior внутри компании, или переходить в интересные и сложные проекты.
🎁 С 15 до 22 мая
Для всех, кто оставлял запросы до сегодняшнего дня и уже связался с нами, действует аналогичное предложение 🎁
Навыки работы с архитектурой, очередями, API, взаимодействием систем в реальном времени, которые аналитики получили в ходе работы, уже сейчас помогают им:
+ проходить аттестацию в компании на повышение грейда,
+ менять работу,
+ получать повышения.
Создавать IT-таланты в Системном Анализе - цель GetAnalyst.
И Архитектура - самая сложная, но самая интересная часть в этом пути 🙌
2024 - год больших и крутых перемен ♥️ Давайте идти к ним вместе!
👍10❤3🔥1
🧐 Как определить, что в проекте нужна микросервисная архитектура? 🧐
Микросервисную архитектуру стоит рассматривать как решение, если проекту уже несколько лет, он работает как монолит, и наблюдается успешная динамика роста:
+ постоянно внедряется новая функциональность,
+ растет нагрузка и число пользователей.
Также для государственных систем, банков и подобных проектов, где при создании новой системы гарантировано огромное количество пользователей с первых дней работы.
Микросервисы идеальны:
✅ Для больших и сложных систем, где необходимо обеспечить гибкость изменений и независимость компонентов. Например, нужно обеспечить скорость разработки и работу 5 и более команд одновременно над разными независимыми частями проекта.
✅ При высоких требованиях к масштабируемости: микросервисы могут масштабироваться независимо, что позволяет оптимизировать ресурсы на серверах и управлять нагрузкой на сервера эффективнее.
✅ В динамичных и инновационных проектах, где частые изменения и эксперименты с новыми технологиями являются нормой.
Для начинающих свой жизненный путь проектов и стартапов, когда мало пользователей, микросервисная архитектура не рекомендуется из-за своей сложности. Лучше брать монолитный подход и стартовать с ним. Так проще, дешевле и надежнее.
Поэтому задача “переехать с монолита на микросервисы или сервисы” встречается гораздо чаще в реальном мире, чем задача “спроектировать микросервисную архитектуру для нового проекта”.
#АрхитектураGA
Микросервисную архитектуру стоит рассматривать как решение, если проекту уже несколько лет, он работает как монолит, и наблюдается успешная динамика роста:
+ постоянно внедряется новая функциональность,
+ растет нагрузка и число пользователей.
Также для государственных систем, банков и подобных проектов, где при создании новой системы гарантировано огромное количество пользователей с первых дней работы.
Микросервисы идеальны:
✅ Для больших и сложных систем, где необходимо обеспечить гибкость изменений и независимость компонентов. Например, нужно обеспечить скорость разработки и работу 5 и более команд одновременно над разными независимыми частями проекта.
✅ При высоких требованиях к масштабируемости: микросервисы могут масштабироваться независимо, что позволяет оптимизировать ресурсы на серверах и управлять нагрузкой на сервера эффективнее.
✅ В динамичных и инновационных проектах, где частые изменения и эксперименты с новыми технологиями являются нормой.
Для начинающих свой жизненный путь проектов и стартапов, когда мало пользователей, микросервисная архитектура не рекомендуется из-за своей сложности. Лучше брать монолитный подход и стартовать с ним. Так проще, дешевле и надежнее.
Поэтому задача “переехать с монолита на микросервисы или сервисы” встречается гораздо чаще в реальном мире, чем задача “спроектировать микросервисную архитектуру для нового проекта”.
#АрхитектураGA
👍9❤2👏1
Микросервисы не нужны, монолит лучше 😬
Ниже приведены ситуации, когда использование микросервисной архитектуры может быть неоправданным решением:
❌ Быстрый старт проекта:
Микросервисы могут замедлить процесс запуска проекта из-за необходимости разработки и поддержки более сложной инфраструктуры.
Монолитные архитектуры позволяют быстрее выйти на рынок, что особенно важно для стартапов и проектов с ограниченными сроками.
❌ Высокие требования к согласованности данных:
Микросервисы часто используют паттерн "база данных на сервис", что может усложнить согласованность данных между различными сервисами.
Для проектов, требующих высокой согласованности данных, микросервисы могут не подойти.
❌ Тесная связанность компонентов:
Если функциональные компоненты приложения тесно связаны и не могут быть легко изолированы, переход на микросервисы потребует значительной переработки кода и архитектуры.
Актуально не только для задач на переезд, но и для этапа проектирования новых систем.
❌ Сложности отладки и мониторинга:
В микросервисных архитектурах отладка и мониторинг могут быть затруднены, поскольку проблемы могут распространяться по множеству сервисов и зависеть от их взаимодействия.
❌ Сложность организации инфраструктуры и процесса разработки:
Разработка и создание инфраструктуры для микросервисов требует значительных усилий и ресурсов на начальном этапе, что может быть неоправданно для небольших проектов или проектов, где скорость выхода на рынок критична.
❌ Необходимость в высокой квалификации разработчиков и системных аналитиков:
Микросервисы требуют от команды разработчиков высокого уровня квалификации и понимания распределенных систем, что может быть проблематично для небольших команд или стартапов.
Важно помнить, что микросервисы — это инструмент, а не цель. Перед переходом на микросервисную архитектуру необходимо провести тщательный анализ, учитывая специфику проекта, цели бизнеса и имеющиеся ресурсы.
Мартин Фаулер, один из основоположников идеи микросервисов, предлагает подход "Сначала — монолит" (MonolithFirst). Этот подход предполагает начало работы в монолитной архитектуре, и последующий постепенный переход на микросервисы, когда это станет необходимо: при достижении определенного уровня сложности и размера проекта.
Так что задача перехода с монолита на микросервисы еще долго будет оставаться актуальной 🙂
#АрхитектураGA
Ниже приведены ситуации, когда использование микросервисной архитектуры может быть неоправданным решением:
❌ Быстрый старт проекта:
Микросервисы могут замедлить процесс запуска проекта из-за необходимости разработки и поддержки более сложной инфраструктуры.
Монолитные архитектуры позволяют быстрее выйти на рынок, что особенно важно для стартапов и проектов с ограниченными сроками.
❌ Высокие требования к согласованности данных:
Микросервисы часто используют паттерн "база данных на сервис", что может усложнить согласованность данных между различными сервисами.
Для проектов, требующих высокой согласованности данных, микросервисы могут не подойти.
❌ Тесная связанность компонентов:
Если функциональные компоненты приложения тесно связаны и не могут быть легко изолированы, переход на микросервисы потребует значительной переработки кода и архитектуры.
Актуально не только для задач на переезд, но и для этапа проектирования новых систем.
❌ Сложности отладки и мониторинга:
В микросервисных архитектурах отладка и мониторинг могут быть затруднены, поскольку проблемы могут распространяться по множеству сервисов и зависеть от их взаимодействия.
❌ Сложность организации инфраструктуры и процесса разработки:
Разработка и создание инфраструктуры для микросервисов требует значительных усилий и ресурсов на начальном этапе, что может быть неоправданно для небольших проектов или проектов, где скорость выхода на рынок критична.
❌ Необходимость в высокой квалификации разработчиков и системных аналитиков:
Микросервисы требуют от команды разработчиков высокого уровня квалификации и понимания распределенных систем, что может быть проблематично для небольших команд или стартапов.
Важно помнить, что микросервисы — это инструмент, а не цель. Перед переходом на микросервисную архитектуру необходимо провести тщательный анализ, учитывая специфику проекта, цели бизнеса и имеющиеся ресурсы.
Мартин Фаулер, один из основоположников идеи микросервисов, предлагает подход "Сначала — монолит" (MonolithFirst). Этот подход предполагает начало работы в монолитной архитектуре, и последующий постепенный переход на микросервисы, когда это станет необходимо: при достижении определенного уровня сложности и размера проекта.
Так что задача перехода с монолита на микросервисы еще долго будет оставаться актуальной 🙂
#АрхитектураGA
👍13❤2🔥2👏1
GetAnalyst_Архитектура_5_основных_сервисов_и_микросервисов.pdf
1.4 MB
🌐 5 основных сервисов и микросервисов, о которых нужно знать 🌐
В большинстве проектов, которые используют подход сервисной и микросервисной архитектуры, можно встретить эти пять основных сервисов.
Если я работаю над проектом с нуля, то использую этот список как чек-лист “С чего начать". Поможет всем IT-специалистам в задачах, связанных с архитектурой.
❤️ Аутентификация и авторизация
Управление процессами аутентификации пользователей и контроля доступа к ресурсам системы.
Пользователи отправляют свои учетные данные (логин и пароль) в микросервис аутентификации. Микросервис взаимодействует с БД пользователей для проверки учетных данных и, если необходимо, генерирует токены доступа (например, JWT). После успешной аутентификации микросервис возвращает токен для пользователя. Токен проверяется на каждом запросе к защищенным ресурсам.
❤️ Управление пользователями
Обработка регистраций, управление профилями пользователей, хранение и обработка данных пользователей. Взаимодействует с сервисом аутентификации для создания учетных записей и управления ими.
❤️ Уведомления и рассылки
Отправка уведомлений и сообщений пользователям через различные каналы (email, SMS, push-уведомления).
Получает запросы на отправку уведомлений от других сервисов. Обеспечивает интеграцию с внешними поставщиками услуг для отправки email, SMS и push-уведомлений, управляет очередями сообщений и шаблонами уведомлений.
❤️ Управление контентом (блоги на сайтах, новости и подобное)
Управление статическим и динамическим контентом (тексты, изображения, видео), организация структуры и хранения контента. Взаимодействует с базами данных и файловыми хранилищами.
❤️ Биллинг и платежи
Обработка и учет платежей, интеграция с платежными шлюзами, выставление счетов. Взаимодействует с внешними платежными шлюзами и банковскими системами.
Обоснование для выделения сервисов и их назначение более подробно описаны в прикрепленной мини-книге.
Пересылайте пост в ЛС и сохраняйте в избранное, чтобы не потерять ❤️
#АрхитектураGA
В большинстве проектов, которые используют подход сервисной и микросервисной архитектуры, можно встретить эти пять основных сервисов.
Если я работаю над проектом с нуля, то использую этот список как чек-лист “С чего начать". Поможет всем IT-специалистам в задачах, связанных с архитектурой.
❤️ Аутентификация и авторизация
Управление процессами аутентификации пользователей и контроля доступа к ресурсам системы.
Пользователи отправляют свои учетные данные (логин и пароль) в микросервис аутентификации. Микросервис взаимодействует с БД пользователей для проверки учетных данных и, если необходимо, генерирует токены доступа (например, JWT). После успешной аутентификации микросервис возвращает токен для пользователя. Токен проверяется на каждом запросе к защищенным ресурсам.
❤️ Управление пользователями
Обработка регистраций, управление профилями пользователей, хранение и обработка данных пользователей. Взаимодействует с сервисом аутентификации для создания учетных записей и управления ими.
❤️ Уведомления и рассылки
Отправка уведомлений и сообщений пользователям через различные каналы (email, SMS, push-уведомления).
Получает запросы на отправку уведомлений от других сервисов. Обеспечивает интеграцию с внешними поставщиками услуг для отправки email, SMS и push-уведомлений, управляет очередями сообщений и шаблонами уведомлений.
❤️ Управление контентом (блоги на сайтах, новости и подобное)
Управление статическим и динамическим контентом (тексты, изображения, видео), организация структуры и хранения контента. Взаимодействует с базами данных и файловыми хранилищами.
❤️ Биллинг и платежи
Обработка и учет платежей, интеграция с платежными шлюзами, выставление счетов. Взаимодействует с внешними платежными шлюзами и банковскими системами.
Обоснование для выделения сервисов и их назначение более подробно описаны в прикрепленной мини-книге.
Пересылайте пост в ЛС и сохраняйте в избранное, чтобы не потерять ❤️
#АрхитектураGA
👍26❤🔥8🔥3❤2⚡1👏1
⚡ Виды API для взаимодействия компонентов системы ⚡
API (Application Programming Interface) — это набор правил и методов, позволяющих разным программам взаимодействовать друг с другом. Он позволяет одной программе общаться с другой, отправляя запросы и получая ответы, даже если они написаны на разных языках программирования или работают на разных устройствах / серверах.
Другими словами, если для взаимодействия пользователя и программы как правило используется пользовательский интерфейс (UI - User Interface), то для взаимодействия программы с другой программой используется программный интерфейс (API - Application Programming Interface) 🧈
Основные виды API:
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket
В деталях 👇
⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепциях ресурсов и методов (GET, POST, PUT, PATCH, DELETE и другие).
Широко используется для веб-, мобильных приложений и микросервисной архитектуры.
Пример документации:
Wildberries
Pinterest
⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает сложные операции и стандарты безопасности.
Считается, что в основном применяется в корпоративных системах, требующих высокого уровня надежности и безопасности. Устаревает. Современные средства безопасности на уровне инфраструктуры делают REST более приятным и менее тяжеловесным в использованию по сравнению с SOAP.
Пример документации:
PayPal (обратите внимание, что устаревший)
Самые интересные API с примерами документации чуть позже 😉👇
#АрхитектураGA
API (Application Programming Interface) — это набор правил и методов, позволяющих разным программам взаимодействовать друг с другом. Он позволяет одной программе общаться с другой, отправляя запросы и получая ответы, даже если они написаны на разных языках программирования или работают на разных устройствах / серверах.
Другими словами, если для взаимодействия пользователя и программы как правило используется пользовательский интерфейс (UI - User Interface), то для взаимодействия программы с другой программой используется программный интерфейс (API - Application Programming Interface) 🧈
Основные виды API:
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket
В деталях 👇
⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепциях ресурсов и методов (GET, POST, PUT, PATCH, DELETE и другие).
Широко используется для веб-, мобильных приложений и микросервисной архитектуры.
Пример документации:
Wildberries
⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает сложные операции и стандарты безопасности.
Считается, что в основном применяется в корпоративных системах, требующих высокого уровня надежности и безопасности. Устаревает. Современные средства безопасности на уровне инфраструктуры делают REST более приятным и менее тяжеловесным в использованию по сравнению с SOAP.
Пример документации:
PayPal (обратите внимание, что устаревший)
Самые интересные API с примерами документации чуть позже 😉👇
#АрхитектураGA
🔥24👍5❤4👏1🤩1
⚡ GraphQL
Позволяет клиенту запрашивать только те данные, которые ему необходимы, с помощью декларативного языка запросов.
Удобен для сложных приложений с изменяемыми потребностями в данных, для мобильных приложений и микросервисов с целью оптимизации трафика между клиентом и сервером, который реализует API.
Пример документации:
Contentful
⚡ gRPC
Использует Protocol Buffers для сериализации данных и поддерживает как синхронные, так и асинхронные вызовы.
Эффективен для микросервисной архитектуры с высокими требованиями к производительности. Очень много коллег, кто в новых проектах на микросервисной архитектуре его использует сразу, даже не рассматривая REST.
Пример документации:
Dropbox от Google
⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.
Используется для приложений, требующих мгновенного обмена данными, например, чаты или системы оповещений.
Пример документации:
Binance Биржа
Для системного аналитика важно понимать, когда и в каких случаях используются определенные виды API, чтобы точно описывать требования к различным интеграциям и понимать, с помощью каких технологий можно реализовывать различные сценарии работы системы.
#АрхитектураGA
Позволяет клиенту запрашивать только те данные, которые ему необходимы, с помощью декларативного языка запросов.
Удобен для сложных приложений с изменяемыми потребностями в данных, для мобильных приложений и микросервисов с целью оптимизации трафика между клиентом и сервером, который реализует API.
Пример документации:
Contentful
⚡ gRPC
Использует Protocol Buffers для сериализации данных и поддерживает как синхронные, так и асинхронные вызовы.
Эффективен для микросервисной архитектуры с высокими требованиями к производительности. Очень много коллег, кто в новых проектах на микросервисной архитектуре его использует сразу, даже не рассматривая REST.
Пример документации:
Dropbox от Google
⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.
Используется для приложений, требующих мгновенного обмена данными, например, чаты или системы оповещений.
Пример документации:
Binance Биржа
Для системного аналитика важно понимать, когда и в каких случаях используются определенные виды API, чтобы точно описывать требования к различным интеграциям и понимать, с помощью каких технологий можно реализовывать различные сценарии работы системы.
#АрхитектураGA
👍8❤4❤🔥1👏1💯1
😱 Я боюсь публичных выступлений 😥
Немного о моем пути в изучении английского...
Да, я говорю по-английски. Свободно, быстро. Меня понимают, но я слышу ошибки в своей речи, слышу акцент. И. Неожиданно. У меня страх публичных выступлений на английском. С ним я борюсь уже не первый год.
Два последних года я пыталась самостоятельно преодолеть этот барьер, но максимум, который я достигла - в работе с клиентами и в разговорах один на один я чувствую себя уверенно и не теряюсь. А вот на публику презентации делать боюсь.
Впервые, чуть больше 5 лет назад, я серьезно занялась английским, так как мне надо было учиться в США. Тогда я просто каждый день учила новые слова, читала, смотрела новости и работала с преподавателями, чтобы меня двигали вперед и направляли в обучении. С педагогами база и задания, далее самостоятельная отработка и проверка.
Это продвинуло мой английский с уровня "Hello, my name is Katya" и отсутствия понимания собеседников, до сложных душевных и бизнесовых диалогов.
Пришел час X. Сейчас мне нужно выступать на английском. И одна я себя с места не сдвину. Поэтому теперь у меня еще минус 3 часа в неделю на дополнительное обучение. Я уверена в своих силах, я знаю, что могу достичь идеала, но мне нужен тот самый прорыв, который, кажется, мне не под силу сделать без наставника.
Сейчас я ищу митапы и конференции, на которых смогу позориться, как мне кажется. Это большой шаг для меня, страшно, но мне нужны эти изменения.
Иногда, чтобы действительно двигаться вперед, нужно признать, что даже самым упорным из нас может понадобиться чья-то помощь. Верю, что к первому дедлайну должна стать лучшей версией англоговорящей себя.
Пожелайте удачи! 🦄🙏❤️
Немного о моем пути в изучении английского...
Да, я говорю по-английски. Свободно, быстро. Меня понимают, но я слышу ошибки в своей речи, слышу акцент. И. Неожиданно. У меня страх публичных выступлений на английском. С ним я борюсь уже не первый год.
Два последних года я пыталась самостоятельно преодолеть этот барьер, но максимум, который я достигла - в работе с клиентами и в разговорах один на один я чувствую себя уверенно и не теряюсь. А вот на публику презентации делать боюсь.
Впервые, чуть больше 5 лет назад, я серьезно занялась английским, так как мне надо было учиться в США. Тогда я просто каждый день учила новые слова, читала, смотрела новости и работала с преподавателями, чтобы меня двигали вперед и направляли в обучении. С педагогами база и задания, далее самостоятельная отработка и проверка.
Это продвинуло мой английский с уровня "Hello, my name is Katya" и отсутствия понимания собеседников, до сложных душевных и бизнесовых диалогов.
Пришел час X. Сейчас мне нужно выступать на английском. И одна я себя с места не сдвину. Поэтому теперь у меня еще минус 3 часа в неделю на дополнительное обучение. Я уверена в своих силах, я знаю, что могу достичь идеала, но мне нужен тот самый прорыв, который, кажется, мне не под силу сделать без наставника.
Сейчас я ищу митапы и конференции, на которых смогу позориться, как мне кажется. Это большой шаг для меня, страшно, но мне нужны эти изменения.
Иногда, чтобы действительно двигаться вперед, нужно признать, что даже самым упорным из нас может понадобиться чья-то помощь. Верю, что к первому дедлайну должна стать лучшей версией англоговорящей себя.
Пожелайте удачи! 🦄🙏❤️
❤61🔥21👏13👍6❤🔥3⚡2
С днём рождения, GetAnalyst 🎊🎉🥳
18 мая 2021 года - официальная дата запуска проекта. Купили домен. Сделали первую версию синего сайта. Я отправилась на конференцию собирать первых аналитиков в сообщество на 0 участников. А на этой неделе нас перевалило за 8 тысяч человек.
В прошлом году я рассказывала через что прошла, чтобы сделать GetAnalyst. Трудоголизм, дисциплина и желание делиться опытом.
Бывает всякое. За кулисами есть разные дни)) Много непрерывных улучшений. Каждую неделю десятки новых постов, до 5 презентаций по обучению проходят преобразование или разработку. Много задач. Но я дисциплинированный трудоголик, который любит своё дело. С одной работы на вторую, но я вижу результаты. Это важно.
В этом году на позитиве расскажу, что сделано с 18 мая 2023 нашей командой:
1. Запустили подкаст.
2. Развиваем YouTube-канал.
3. Запустили программу Архитектура - самый топ для системных аналитиков.
4. Запустили уникальные практикумы по БД на продвинутые темы.
5. Одна голова - хорошо, а больше опытных в узких темах экспертов - лучше. Улучшаем всё что возможно и дополняем новым опытом.
6. Редизайн всего. Мелочь, а приятно.
7. Сайт почти на 100% обновили. Платформа получилась)) Обратите внимание на блог и подкасты, если еще там не были.
8. Почти 400 аналитиков выросли с нами за год.
(9. Благодаря GetAnalyst и приобретенной публичности, мне удалось получить продвинутое членство в международных ассоциациях, признание Young Professional, рекомендации и благодарственные письма от крупных компаний 🙏)
Спасибо вам, что рекомендуете сообщество своим коллегам и начинающим аналитикам. Делитесь полезными материалами из канала, приходите на открытые вебинары и остаётесь с нами.
Благодаря вам GetAnalyst продолжает становиться лучше.
GetAnalyst - это не Катя Ананьева. GetAnalyst - это вы ❤️
С тремя годиками. Расти большой 🚀
Happy Birthday! 🥳
С любовью,
Екатерина Ананьева
и команда GetAnalyst.
18 мая 2021 года - официальная дата запуска проекта. Купили домен. Сделали первую версию синего сайта. Я отправилась на конференцию собирать первых аналитиков в сообщество на 0 участников. А на этой неделе нас перевалило за 8 тысяч человек.
В прошлом году я рассказывала через что прошла, чтобы сделать GetAnalyst. Трудоголизм, дисциплина и желание делиться опытом.
Бывает всякое. За кулисами есть разные дни)) Много непрерывных улучшений. Каждую неделю десятки новых постов, до 5 презентаций по обучению проходят преобразование или разработку. Много задач. Но я дисциплинированный трудоголик, который любит своё дело. С одной работы на вторую, но я вижу результаты. Это важно.
В этом году на позитиве расскажу, что сделано с 18 мая 2023 нашей командой:
1. Запустили подкаст.
2. Развиваем YouTube-канал.
3. Запустили программу Архитектура - самый топ для системных аналитиков.
4. Запустили уникальные практикумы по БД на продвинутые темы.
5. Одна голова - хорошо, а больше опытных в узких темах экспертов - лучше. Улучшаем всё что возможно и дополняем новым опытом.
6. Редизайн всего. Мелочь, а приятно.
7. Сайт почти на 100% обновили. Платформа получилась)) Обратите внимание на блог и подкасты, если еще там не были.
8. Почти 400 аналитиков выросли с нами за год.
(9. Благодаря GetAnalyst и приобретенной публичности, мне удалось получить продвинутое членство в международных ассоциациях, признание Young Professional, рекомендации и благодарственные письма от крупных компаний 🙏)
Спасибо вам, что рекомендуете сообщество своим коллегам и начинающим аналитикам. Делитесь полезными материалами из канала, приходите на открытые вебинары и остаётесь с нами.
Благодаря вам GetAnalyst продолжает становиться лучше.
GetAnalyst - это не Катя Ананьева. GetAnalyst - это вы ❤️
С тремя годиками. Расти большой 🚀
Happy Birthday! 🥳
С любовью,
Екатерина Ананьева
и команда GetAnalyst.
❤67🍾40❤🔥11🔥11👏5🎉5👍3
⚡ API как часть архитектурного проектирования ⚡
Взаимодействие приложений в системе через API - одно из ключевых архитектурных решений, особенно в сервисной и микросервисной архитектуре.
При разработке схемы архитектуры в С4 необходимо указывать технологии для каждого элемента системы (сервиса, микросервиса, приложения), а также виды API, обеспечивающие взаимодействие этих элементов.
Это справедливо не только для C4. В любой упрощенной схеме архитектуры следует делать то же самое.
🟢 API и правила их выбора определяют на этапе проектирования архитектуры.
Интересный факт:
Для одного сервиса может быть два или даже три вида API, которые он предоставляет своим клиентам. Всё зависит от бизнес-логики и назначения сервиса. Это отражается на схеме и в архитектурной документации.
Касательно нотации моделирования архитектуры C4, которую мы разбираем на примере проекта TelMed, API отображаются на следующих уровнях:
⚪️ Контекстная диаграмма (Context Diagram):
Показывать виды API не обязательно, но полезно указать, через какие API происходит взаимодействие с внешними системами.
⚪️ Диаграмма контейнеров (Container Diagram):
API могут быть отображены как интерфейсы между приложениями, сервисами и внешними системами.
⚪️ Диаграмма компонентов (Component Diagram):
Показывает API, которые реализуются внутри контейнера - приложения, сервиса или микросервиса, чтобы к ним могли обращаться другие системы и сервисы. Также показывает API к внешним системам, если есть интеграции.
⚪️ Диаграмму кода мы не рассматриваем, так как она не актуальна для аналитиков.
Обратите внимание, что на схемах для каждого вида API также указываются протоколы и форматы сообщений, с которыми они работают, например, HTTP/JSON.
Знание основных видов API, принципов их работы, примеров использования и умение проверять их работу, помогают системным аналитикам (с архитекторами и разработчиками) приземлить отдельные бизнес- и нефункциональные требования на конкретные технологии.
Примеры схем С4 с API:
+ Шаблон C4 в Miro
+ Статья по C4
#АрхитектураGA
Взаимодействие приложений в системе через API - одно из ключевых архитектурных решений, особенно в сервисной и микросервисной архитектуре.
При разработке схемы архитектуры в С4 необходимо указывать технологии для каждого элемента системы (сервиса, микросервиса, приложения), а также виды API, обеспечивающие взаимодействие этих элементов.
Это справедливо не только для C4. В любой упрощенной схеме архитектуры следует делать то же самое.
🟢 API и правила их выбора определяют на этапе проектирования архитектуры.
Интересный факт:
Для одного сервиса может быть два или даже три вида API, которые он предоставляет своим клиентам. Всё зависит от бизнес-логики и назначения сервиса. Это отражается на схеме и в архитектурной документации.
Касательно нотации моделирования архитектуры C4, которую мы разбираем на примере проекта TelMed, API отображаются на следующих уровнях:
⚪️ Контекстная диаграмма (Context Diagram):
Показывать виды API не обязательно, но полезно указать, через какие API происходит взаимодействие с внешними системами.
⚪️ Диаграмма контейнеров (Container Diagram):
API могут быть отображены как интерфейсы между приложениями, сервисами и внешними системами.
⚪️ Диаграмма компонентов (Component Diagram):
Показывает API, которые реализуются внутри контейнера - приложения, сервиса или микросервиса, чтобы к ним могли обращаться другие системы и сервисы. Также показывает API к внешним системам, если есть интеграции.
⚪️ Диаграмму кода мы не рассматриваем, так как она не актуальна для аналитиков.
Обратите внимание, что на схемах для каждого вида API также указываются протоколы и форматы сообщений, с которыми они работают, например, HTTP/JSON.
Знание основных видов API, принципов их работы, примеров использования и умение проверять их работу, помогают системным аналитикам (с архитекторами и разработчиками) приземлить отдельные бизнес- и нефункциональные требования на конкретные технологии.
Примеры схем С4 с API:
+ Шаблон C4 в Miro
+ Статья по C4
#АрхитектураGA
❤7👍5🔥1💯1
💥 Сервисная архитектура с нуля для проекта TelMed 💥
Мы познакомились с теорией по сервис-ориентированному и микросервисному подходам к проектированию архитектуры, понимаем отличия от монолитов.
Пришло время разобраться на практике, как может выглядеть архитектура проекта TelMed.
Хочу сразу отметить, что буду использовать смешанный подход: чистых микросервисов или чистого SOA не будет. Это смесь, как в реальной жизни. Теория-теорией, но в реальности она другая. Поэтому в заголовке поста название "сервисная", как нечто более общее.
Для выделения списка сервисов воспользуюсь чек-листом из предыдущего поста и знанием бизнес-контекстов проекта (очень помогает!).
Сервисы и микросервисы TelMed:
1. Аутентификация и авторизация
2. Управление пользователями
3. Уведомления и рассылки
4. Личный кабинет пациента
Регистрация пациентов, хранение персональных данных, медицинской карты и медицинской истории.
5. Запись на прием
Поиск врачей, планирование и отслеживание консультаций, уведомление пациентов.
6. Учет оборудования
Управление заказом и доставкой медицинского оборудования.
7. Онлайн-консультации
Обеспечение защищенной видеосвязи, чат и обмен документами.
8. Аптечные услуги
Создание электронных рецептов, мониторинг наличия лекарств, управление доставкой.
9. Анализы
Выдача направлений на анализы, автоматическое получение результатов.
10. Платежи
Обработка и учет платежей, интеграция с платежными системами.
11. Личный кабинет врача
Управление профилем врача и настройка доступного времени для консультаций.
Для отображения архитектуры я буду использовать нотацию C4 / Container.
В каком инструменте сделать пример сервисной архитектуры, чтобы вы могли забрать себе исходник?
1. Miro - пример будет как тут 👍
2. Structurizr - через код, доп. примеры по нему тут ❤️
3. Draw.io 🔥
Голосуйте реакцией 👍❤️🔥
#АрхитектураGA #TelMedGA
Мы познакомились с теорией по сервис-ориентированному и микросервисному подходам к проектированию архитектуры, понимаем отличия от монолитов.
Пришло время разобраться на практике, как может выглядеть архитектура проекта TelMed.
Хочу сразу отметить, что буду использовать смешанный подход: чистых микросервисов или чистого SOA не будет. Это смесь, как в реальной жизни. Теория-теорией, но в реальности она другая. Поэтому в заголовке поста название "сервисная", как нечто более общее.
Для выделения списка сервисов воспользуюсь чек-листом из предыдущего поста и знанием бизнес-контекстов проекта (очень помогает!).
Сервисы и микросервисы TelMed:
1. Аутентификация и авторизация
2. Управление пользователями
3. Уведомления и рассылки
4. Личный кабинет пациента
Регистрация пациентов, хранение персональных данных, медицинской карты и медицинской истории.
5. Запись на прием
Поиск врачей, планирование и отслеживание консультаций, уведомление пациентов.
6. Учет оборудования
Управление заказом и доставкой медицинского оборудования.
7. Онлайн-консультации
Обеспечение защищенной видеосвязи, чат и обмен документами.
8. Аптечные услуги
Создание электронных рецептов, мониторинг наличия лекарств, управление доставкой.
9. Анализы
Выдача направлений на анализы, автоматическое получение результатов.
10. Платежи
Обработка и учет платежей, интеграция с платежными системами.
11. Личный кабинет врача
Управление профилем врача и настройка доступного времени для консультаций.
Для отображения архитектуры я буду использовать нотацию C4 / Container.
В каком инструменте сделать пример сервисной архитектуры, чтобы вы могли забрать себе исходник?
1. Miro - пример будет как тут 👍
2. Structurizr - через код, доп. примеры по нему тут ❤️
3. Draw.io 🔥
Голосуйте реакцией 👍❤️🔥
#АрхитектураGA #TelMedGA
🔥47👍15❤13
Ищу эксперта в REST API, Postman и Swagger, готового учиться публично выступать 👀
Если ты эксперт, то подробности и Google-форма тут 🤝
Если ты эксперт, то подробности и Google-форма тут 🤝
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
🙌 Новый эпизод подкаста GetAnalyst про Нефункциональные требования 🙌
В этом эпизоде мы обсуждаем нефункциональные требования: не только в теории, но и на практике. Приводятся конкретные примеры для каждого вида таких требований, которые могут быть применены в реальных ИТ-проектах.
Этот выпуск поможет системным и бизнес-аналитикам при подготовке к собеседованиям или перед стартом работы над нефункциональными требованиями для ТЗ нового проекта.
1:08 - Когда мы встречаемся с нефункциональными требованиями и что важно знать о них перед началом работы. Знакомство с проектом TelMed (https://t.me/getanalysts/1646).
08:09 - Что такое нефункциональные требования (НФТ). О проверяемости нефункциональных требований.
12:28 - Определение нефункциональных требований по Вигерсу (книга “Разработка требований к программному обеспечению”), ГОСТ-34 и Software Requirements Specification, IEEE.
23:21 - Источники нефункциональных требований.
29:54 - Виды нефункциональных требований на примере медицинского проекта TelMed. Этап сбора потребностей из источников - первичная аналитика.
45:04 - Работа с нефункциональными требованиями для ТЗ и рядовых постановок задач на разработчиков. Личный опыт. Связь с принципами дизайна UI и архитектурой.
51:06 - Доступность. SLA - service-level agreement. Удобство установки.
01:01:36 - Целостность данных. Совместимость. Производительность.
01:06:24 - Надежность. Устойчивость. Защита и безопасность.
1:13:00 - Удобство использования. О боли про “Интуитивно понятный интерфейс”.
1:16:10 - Эффективность использования ресурсов.
1:18:10 - Модификация. Переносимость. Возможность повторного использования.
1:21:41 - Масштабируемость.
1:24:03 - Проверяемость и тестируемость. Другие требования по ГОСТ-34.
1:27:28 - Порядок работы с нефункциональными требованиями.
1:34:54 - Заключение и рекомендации.
📚 Статья к подкасту
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify
Делитесь с коллегами и подписывайтесь на всех площадках! 😉
В этом эпизоде мы обсуждаем нефункциональные требования: не только в теории, но и на практике. Приводятся конкретные примеры для каждого вида таких требований, которые могут быть применены в реальных ИТ-проектах.
Этот выпуск поможет системным и бизнес-аналитикам при подготовке к собеседованиям или перед стартом работы над нефункциональными требованиями для ТЗ нового проекта.
1:08 - Когда мы встречаемся с нефункциональными требованиями и что важно знать о них перед началом работы. Знакомство с проектом TelMed (https://t.me/getanalysts/1646).
08:09 - Что такое нефункциональные требования (НФТ). О проверяемости нефункциональных требований.
12:28 - Определение нефункциональных требований по Вигерсу (книга “Разработка требований к программному обеспечению”), ГОСТ-34 и Software Requirements Specification, IEEE.
23:21 - Источники нефункциональных требований.
29:54 - Виды нефункциональных требований на примере медицинского проекта TelMed. Этап сбора потребностей из источников - первичная аналитика.
45:04 - Работа с нефункциональными требованиями для ТЗ и рядовых постановок задач на разработчиков. Личный опыт. Связь с принципами дизайна UI и архитектурой.
51:06 - Доступность. SLA - service-level agreement. Удобство установки.
01:01:36 - Целостность данных. Совместимость. Производительность.
01:06:24 - Надежность. Устойчивость. Защита и безопасность.
1:13:00 - Удобство использования. О боли про “Интуитивно понятный интерфейс”.
1:16:10 - Эффективность использования ресурсов.
1:18:10 - Модификация. Переносимость. Возможность повторного использования.
1:21:41 - Масштабируемость.
1:24:03 - Проверяемость и тестируемость. Другие требования по ГОСТ-34.
1:27:28 - Порядок работы с нефункциональными требованиями.
1:34:54 - Заключение и рекомендации.
📚 Статья к подкасту
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify
Делитесь с коллегами и подписывайтесь на всех площадках! 😉
🔥19❤5❤🔥2👍2🦄2⚡1
😕 Завышение сложности архитектуры (овер-инжиниринг): создание избыточно сложной архитектуры в проектах, где в этом нет необходимости 😕
Завышение сложности архитектуры случается, когда для системы создают слишком сложную систему, не всегда нужную для обеспечения её работы.
Это может включать использование избыточного количества технологий, паттернов проектирования или большого количества компонентов для реализации, усложняющих понимание, разработку, тестирование и поддержку системы.
◽ Пример:
Разработка системы интернет-магазина для малого бизнеса, который продает всего несколько видов товаров. Вместо использования простой монолитной архитектуры или шаблонного "интернет-магазина из коробки", команда решила реализовать собственную систему на основе микросервисов, разделив каждую функцию (обработку заказов, управление каталогом товаров, обработку платежей) на отдельные сервисы.
Это значительно увеличило сложность проекта, требуя дополнительных ресурсов для разработки, координации между сервисами и обеспечения их надежной работы. В результате, затраты на разработку и поддержку системы оказались гораздо выше, чем если бы была выбрана более простая архитектура, адекватная масштабам и потребностям бизнеса.
Почему происходит:
🔻 Переоценка требований.
🔻 Стремление к совершенству
🔻 Недостаточный опыт
Рекомендации:
✅ Стремитесь к простоте в проектировании, избегая ненужной сложности в целом. Идеальная архитектура простая и понятная.
✅ Не учитывайте функциональность до тех пор, пока она действительно не потребуется.
✅ Держите баланс между долгосрочным планированием и текущими потенциальными усложнениями.
✅ Используйте принцип итеративной разработки. Разрабатывайте функции в системе поэтапно, добавляя сложность только тогда, когда это оправдано.
✅ Регулярно пересматривайте архитектуру на возможность упрощения и улучшения.
Какие еще ошибки встречаются в проектировании архитектуры? 🧐
Подробности и ответ в статье:
🔗 Ошибки в проектировании архитектуры: на что обращать внимание
#АрхитектураGA
Завышение сложности архитектуры случается, когда для системы создают слишком сложную систему, не всегда нужную для обеспечения её работы.
Это может включать использование избыточного количества технологий, паттернов проектирования или большого количества компонентов для реализации, усложняющих понимание, разработку, тестирование и поддержку системы.
◽ Пример:
Разработка системы интернет-магазина для малого бизнеса, который продает всего несколько видов товаров. Вместо использования простой монолитной архитектуры или шаблонного "интернет-магазина из коробки", команда решила реализовать собственную систему на основе микросервисов, разделив каждую функцию (обработку заказов, управление каталогом товаров, обработку платежей) на отдельные сервисы.
Это значительно увеличило сложность проекта, требуя дополнительных ресурсов для разработки, координации между сервисами и обеспечения их надежной работы. В результате, затраты на разработку и поддержку системы оказались гораздо выше, чем если бы была выбрана более простая архитектура, адекватная масштабам и потребностям бизнеса.
Почему происходит:
🔻 Переоценка требований.
🔻 Стремление к совершенству
🔻 Недостаточный опыт
Рекомендации:
✅ Стремитесь к простоте в проектировании, избегая ненужной сложности в целом. Идеальная архитектура простая и понятная.
✅ Не учитывайте функциональность до тех пор, пока она действительно не потребуется.
✅ Держите баланс между долгосрочным планированием и текущими потенциальными усложнениями.
✅ Используйте принцип итеративной разработки. Разрабатывайте функции в системе поэтапно, добавляя сложность только тогда, когда это оправдано.
✅ Регулярно пересматривайте архитектуру на возможность упрощения и улучшения.
Какие еще ошибки встречаются в проектировании архитектуры? 🧐
Подробности и ответ в статье:
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11👍7🔥1
🔔 Завершаем предзапись на архитектуру сегодня в 23:59 Мск🔔
Подробнее об условиях предзаписи можно почитать здесь и в программе на сайте.
Старт предобучения 28 мая 2024
Подробности о программе и запись
А пока мы продолжаем рассказывать о программе словами коллег-аналитиков, которые буквально вчера завершили обучение на первом потоке 🙌 🎉🥳
Больше обратной связи будем постепенно добавлять на сайт 💛
Если честно, то нам тоже надо оставлять публичную обратную связь на тех, кто у нас учится. Я и все эксперты, кто работал с группой "Архитектура" (и не только), разными словами делимся друг с другом впечатлениями о том, насколько осознанная группа и насколько круто было работать.
Команда аналитиков с нами не для галочки "я на обучении", все работают на результат 💪💎🤝 Спасибо вам за это!
Уже работаем над улучшениями и готовимся ко встрече с новой командой "Архитектура"!
Подробнее об условиях предзаписи можно почитать здесь и в программе на сайте.
Старт предобучения 28 мая 2024
Подробности о программе и запись
А пока мы продолжаем рассказывать о программе словами коллег-аналитиков, которые буквально вчера завершили обучение на первом потоке 🙌 🎉🥳
Решила пойти не думая, т.к. предыдущие курсы, которые прошла, очень понравились
подачей, объемом информации и, самое главное, качественной объемной практикой с ДЗ и качественной проверкой ДЗ.
Задания не абстрактные, а конкретные, жизненные, привязанные к системам, которыми мы пользуемся ежедневно. Выполняя задание, мы можем сразу увидеть как это все работает уже со стороны не только пользователя, но и аналитика.
Было очень интересно познавать, как это работает с точки зрения архитектуры, микросервисов и БД. Хочу отметить, что проверка ДЗ ведется глубоко и индивидуально, "не для галочки".
Больше обратной связи будем постепенно добавлять на сайт 💛
Если честно, то нам тоже надо оставлять публичную обратную связь на тех, кто у нас учится. Я и все эксперты, кто работал с группой "Архитектура" (и не только), разными словами делимся друг с другом впечатлениями о том, насколько осознанная группа и насколько круто было работать.
Команда аналитиков с нами не для галочки "я на обучении", все работают на результат 💪💎🤝 Спасибо вам за это!
Уже работаем над улучшениями и готовимся ко встрече с новой командой "Архитектура"!
👍6❤3👌1