🚀 Shopify заработала около 7 миллиардов долларов в 2023 году.
🔧 С помощью монолитного приложения на Ruby on Rails.
🤔 Получается, можно далеко зайти и без микросервисов, правда?
📜 Основной монолит содержит более 3 миллионов строк кода.
🔩 Shopify организует свой монолит в кодовые блоки, называемые компонентами. Компоненты созданы путём сортировки тысяч файлов в несколько десятков категорий, каждая из которых представляет свой домен и разделена на директории с названиями вроде:
- Доставка
- Интернет-магазин
- Товарное обеспечение
- Оформление покупок
🔄 Но не всегда было так.
🚧 Монолит Shopify начался с группировки компонентов на основе технических вопросов. С течением времени поддержка становилась всё более сложной и замедляла работу команды.
💡 Что-то должно было измениться.
🏗 Затем началась многолетняя работа:
- Компонентизация монолита
- Изоляция зависимостей между компонентами
👇 Вывод:
Хорошо определённые внутрипроцессные компоненты (модули) могут стать отличным промежуточным шагом к внепроцессным компонентам (сервисам).
#monolith #ddd
На связи с вами https://t.me/itarchitecture
🔧 С помощью монолитного приложения на Ruby on Rails.
🤔 Получается, можно далеко зайти и без микросервисов, правда?
📜 Основной монолит содержит более 3 миллионов строк кода.
🔩 Shopify организует свой монолит в кодовые блоки, называемые компонентами. Компоненты созданы путём сортировки тысяч файлов в несколько десятков категорий, каждая из которых представляет свой домен и разделена на директории с названиями вроде:
- Доставка
- Интернет-магазин
- Товарное обеспечение
- Оформление покупок
🔄 Но не всегда было так.
🚧 Монолит Shopify начался с группировки компонентов на основе технических вопросов. С течением времени поддержка становилась всё более сложной и замедляла работу команды.
💡 Что-то должно было измениться.
🏗 Затем началась многолетняя работа:
- Компонентизация монолита
- Изоляция зависимостей между компонентами
👇 Вывод:
Хорошо определённые внутрипроцессные компоненты (модули) могут стать отличным промежуточным шагом к внепроцессным компонентам (сервисам).
#monolith #ddd
На связи с вами https://t.me/itarchitecture
April 12, 2024
🔹 Микрофронтенды могут быть использованы, если используются микросервисы 🔹
Микрофронтенды — это микросервисы для фронтендов, но с другим подходом.
Если реализация фронтенда сложная и команда разработки большая, это может быть аргументом в пользу микрофронтендов.
Представьте, что один фрагмент кода фронтенда отвечает за рендеринг интенсивного пользовательского интерфейса и может заблокировать основной поток и вызвать сбой приложения.
Здесь вы можете обернуть этот интерфейс в отдельный микрофронтенд и рендерить его независимо, и приложение будет работать как обычно.
Чаще всего несколько команд работают над одним фронтенд-кодом, как монолит или модульный фронтенд-код.
Микрофронтенды предполагают разделение фронтенда на несколько микроприложений.
Так каждая команда, работающая над разными функциями, может:
1. Независимо работать над пользовательским интерфейсом.
2. Не зависеть от других команд.
3. Использовать общие ресурсы, такие как внутренняя библиотека для обмена компонентами или атомами.
Для создания каждого микрофронтенда можно использовать React, Angular или Vue. Но в целом надо понимать, что эта парадигма внесет анархии в ваши процессы разработки.
Таким образом, в больших командах фронтенда это помогает всем поделить пользовательский интерфейс, работать независимо и запускать в продакшн.
Но если фронтенд-приложение/код не слишком обширен, то микрофронтенды избыточны.
#microfrontend #microservice #frontend #uiux
На связи с вами https://t.me/itarchitecture
Микрофронтенды — это микросервисы для фронтендов, но с другим подходом.
Если реализация фронтенда сложная и команда разработки большая, это может быть аргументом в пользу микрофронтендов.
Представьте, что один фрагмент кода фронтенда отвечает за рендеринг интенсивного пользовательского интерфейса и может заблокировать основной поток и вызвать сбой приложения.
Здесь вы можете обернуть этот интерфейс в отдельный микрофронтенд и рендерить его независимо, и приложение будет работать как обычно.
Чаще всего несколько команд работают над одним фронтенд-кодом, как монолит или модульный фронтенд-код.
Микрофронтенды предполагают разделение фронтенда на несколько микроприложений.
Так каждая команда, работающая над разными функциями, может:
1. Независимо работать над пользовательским интерфейсом.
2. Не зависеть от других команд.
3. Использовать общие ресурсы, такие как внутренняя библиотека для обмена компонентами или атомами.
Для создания каждого микрофронтенда можно использовать React, Angular или Vue. Но в целом надо понимать, что эта парадигма внесет анархии в ваши процессы разработки.
Таким образом, в больших командах фронтенда это помогает всем поделить пользовательский интерфейс, работать независимо и запускать в продакшн.
Но если фронтенд-приложение/код не слишком обширен, то микрофронтенды избыточны.
#microfrontend #microservice #frontend #uiux
На связи с вами https://t.me/itarchitecture
April 14, 2024
This media is not supported in your browser
VIEW IN TELEGRAM
🔄 Репликация базы данных необходима для обеспечения надежности, но она также может вызвать задержку репликации
Но что же такое "задержка репликации"?
В типичной конфигурации репликации с ведущим узлом все операции записи направляются на основной узел.
Тем не менее, запросы на чтение могут обрабатываться любой репликой (включая основную в некоторых случаях).
Это хорошо, потому что вы можете масштабировать операции чтения, добавляя больше реплик.
Но для получения полного преимущества от репликации используется асинхронная репликация.
Однако, когда ваше приложение читает данные с асинхронной реплики, существует большая вероятность, что оно может получить устаревшую информацию, если реплика по какой-то причине отстала.
📝 Например:
1️⃣ Пользователь А отправляет запрос на обновление (запись) на основной или ведущий узел.
2️⃣ Ведущий узел отправляет новую информацию своим репликам.
3️⃣ Реплика 1 обновляется.
4️⃣ Однако пользователь B запрашивает (читает) данные с реплики 2 и получает устаревшую информацию.
5️⃣ Позже реплика 2 в конечном итоге обновляется.
Задержка между моментом выполнения записи на ведущем узле и её отражением на подчиненном узле известна как "задержка репликации".
Задержка может составлять всего лишь долю секунды (практически незаметно).
Однако, если система работает на пределе своих возможностей, задержка также может увеличиться до нескольких секунд или даже минут.
🚨 Таким образом, основная проблема - несоответствие данных для пользователей:
1. Пользователь B может неоднократно читать данные и видеть разные результаты из-за задержки репликации.
2. Пользователь А, сделавший запись, может получить устаревшие данные при чтении с реплики.
#databases #replica #eventual_consistency
На связи с вами https://t.me/itarchitecture
Но что же такое "задержка репликации"?
В типичной конфигурации репликации с ведущим узлом все операции записи направляются на основной узел.
Тем не менее, запросы на чтение могут обрабатываться любой репликой (включая основную в некоторых случаях).
Это хорошо, потому что вы можете масштабировать операции чтения, добавляя больше реплик.
Но для получения полного преимущества от репликации используется асинхронная репликация.
Однако, когда ваше приложение читает данные с асинхронной реплики, существует большая вероятность, что оно может получить устаревшую информацию, если реплика по какой-то причине отстала.
📝 Например:
1️⃣ Пользователь А отправляет запрос на обновление (запись) на основной или ведущий узел.
2️⃣ Ведущий узел отправляет новую информацию своим репликам.
3️⃣ Реплика 1 обновляется.
4️⃣ Однако пользователь B запрашивает (читает) данные с реплики 2 и получает устаревшую информацию.
5️⃣ Позже реплика 2 в конечном итоге обновляется.
Задержка между моментом выполнения записи на ведущем узле и её отражением на подчиненном узле известна как "задержка репликации".
Задержка может составлять всего лишь долю секунды (практически незаметно).
Однако, если система работает на пределе своих возможностей, задержка также может увеличиться до нескольких секунд или даже минут.
🚨 Таким образом, основная проблема - несоответствие данных для пользователей:
1. Пользователь B может неоднократно читать данные и видеть разные результаты из-за задержки репликации.
2. Пользователь А, сделавший запись, может получить устаревшие данные при чтении с реплики.
#databases #replica #eventual_consistency
На связи с вами https://t.me/itarchitecture
April 21, 2024
📢 Картинка стоит тысячи слов: 9 лучших практик разработки микросервисов
При разработке микросервисов необходимо следовать следующим лучшим практикам:
🗃️ 1. Используйте отдельное хранилище данных для каждого микросервиса
📈 2. Сохраняйте код на том же уровне зрелости
🛠️ 3. Отдельная сборка для каждого микросервиса
✅ 4. Назначьте каждому микросервису одну ответственность
📦 5. Развертывайте в контейнеры
🌀 6. Проектируйте сервисы без сохранения состояния
🎯 7. Применяйте предметно-ориентированное проектирование
🔗 8. Разрабатывайте микрофронтенды (https://t.me/itarchitecture/281)
🏗️ 9. Обеспечьте оркестирование микросервисов (https://t.me/itarchitecture/152)
#microservice
На связи с вами https://t.me/itarchitecture
При разработке микросервисов необходимо следовать следующим лучшим практикам:
🗃️ 1. Используйте отдельное хранилище данных для каждого микросервиса
📈 2. Сохраняйте код на том же уровне зрелости
🛠️ 3. Отдельная сборка для каждого микросервиса
✅ 4. Назначьте каждому микросервису одну ответственность
📦 5. Развертывайте в контейнеры
🌀 6. Проектируйте сервисы без сохранения состояния
🎯 7. Применяйте предметно-ориентированное проектирование
🔗 8. Разрабатывайте микрофронтенды (https://t.me/itarchitecture/281)
🏗️ 9. Обеспечьте оркестирование микросервисов (https://t.me/itarchitecture/152)
#microservice
На связи с вами https://t.me/itarchitecture
April 21, 2024
May 3, 2024
May 24, 2024
Ваши данные имеют температуру, и если вы не знаете её, вы теряете деньги
📊 Горячие, тёплые и холодные данные.
Хранение данных — это не просто их сохранение; необходимо учитывать частоту доступа и период хранения данных.
Данные можно разделить на три категории в зависимости от частоты доступа:
Горячие данные (Hot Data) 🔥
- Определение: Данные с высокой частотой обращения и минимальной задержкой доступа.
- Хранилище: Быстродействующие решения, такие как SSD или оперативная память (RAM).
- Примеры: Кэшированные результаты поиска, рекомендации продуктов в реальном времени.
- Стоимость: Высокие затраты на хранение, низкие затраты на доступ из-за постоянной готовности данных.
Тёплые данные (Warm Data) 🌡️
- Определение: Данные со средней частотой обращения, например, раз в месяц.
- Хранилище: Менее дорогое, но всё ещё доступное хранилище, такое как Amazon S3 Infrequently Accessed Tier или Google Nearline.
- Примеры: Архивные логи, аналитические данные средней давности.
- Стоимость: Более низкие затраты на хранение по сравнению с горячими данными, но доступ дороже и медленнее.
Холодные данные (Cold Data) ❄️
- Определение: Данные, редко используемые, предназначенные для длительного хранения.
- Хранилище: Наиболее экономичные решения, такие как HDD или облачные архивные сервисы (например, AWS Glacier).
- Примеры: Старые резервные копии, исторические записи для соответствия нормативам.
- Стоимость: Минимальные затраты на хранение, но высокие затраты на доступ из-за длительного времени восстановления.
Управление временем хранения данных (Data Retention Management) — это критически важный аспект, основанный на четырёх ключевых принципах:
1. Ценность данных (Data Value) 💡
Определите, являются ли данные критически важными и необходимыми для бизнеса, или их можно восстановить при необходимости. Важные данные требуют более длительного хранения.
2. Время хранения (Time to Live, TTL) ⏳
Для данных с быстрым доступом, таких как данные в RAM или на SSD, используйте политику "Time To Live" (TTL) для автоматического перемещения данных в более дешёвое хранилище по истечении определённого времени.
3. Соответствие нормативам (Compliance) 📜
Учтите требования законодательства, которые могут предписывать определённые сроки хранения или удаления данных. Автоматизация процессов управления данными поможет соответствовать нормативным требованиям.
4. Затраты на хранение (Storage Cost) 💰
Оптимизируйте затраты на хранение, автоматизируя процессы удаления или архивирования данных, которые больше не нужны для оперативного использования.
🔑 Не просто храните данные — управляйте ими эффективно, чтобы оптимизировать затраты и соответствовать требованиям бизнеса.
#data_management
На связи с вами https://t.me/itarchitecture
📊 Горячие, тёплые и холодные данные.
Хранение данных — это не просто их сохранение; необходимо учитывать частоту доступа и период хранения данных.
Данные можно разделить на три категории в зависимости от частоты доступа:
Горячие данные (Hot Data) 🔥
- Определение: Данные с высокой частотой обращения и минимальной задержкой доступа.
- Хранилище: Быстродействующие решения, такие как SSD или оперативная память (RAM).
- Примеры: Кэшированные результаты поиска, рекомендации продуктов в реальном времени.
- Стоимость: Высокие затраты на хранение, низкие затраты на доступ из-за постоянной готовности данных.
Тёплые данные (Warm Data) 🌡️
- Определение: Данные со средней частотой обращения, например, раз в месяц.
- Хранилище: Менее дорогое, но всё ещё доступное хранилище, такое как Amazon S3 Infrequently Accessed Tier или Google Nearline.
- Примеры: Архивные логи, аналитические данные средней давности.
- Стоимость: Более низкие затраты на хранение по сравнению с горячими данными, но доступ дороже и медленнее.
Холодные данные (Cold Data) ❄️
- Определение: Данные, редко используемые, предназначенные для длительного хранения.
- Хранилище: Наиболее экономичные решения, такие как HDD или облачные архивные сервисы (например, AWS Glacier).
- Примеры: Старые резервные копии, исторические записи для соответствия нормативам.
- Стоимость: Минимальные затраты на хранение, но высокие затраты на доступ из-за длительного времени восстановления.
Управление временем хранения данных (Data Retention Management) — это критически важный аспект, основанный на четырёх ключевых принципах:
1. Ценность данных (Data Value) 💡
Определите, являются ли данные критически важными и необходимыми для бизнеса, или их можно восстановить при необходимости. Важные данные требуют более длительного хранения.
2. Время хранения (Time to Live, TTL) ⏳
Для данных с быстрым доступом, таких как данные в RAM или на SSD, используйте политику "Time To Live" (TTL) для автоматического перемещения данных в более дешёвое хранилище по истечении определённого времени.
3. Соответствие нормативам (Compliance) 📜
Учтите требования законодательства, которые могут предписывать определённые сроки хранения или удаления данных. Автоматизация процессов управления данными поможет соответствовать нормативным требованиям.
4. Затраты на хранение (Storage Cost) 💰
Оптимизируйте затраты на хранение, автоматизируя процессы удаления или архивирования данных, которые больше не нужны для оперативного использования.
🔑 Не просто храните данные — управляйте ими эффективно, чтобы оптимизировать затраты и соответствовать требованиям бизнеса.
#data_management
На связи с вами https://t.me/itarchitecture
August 24, 2024
🔵🟢 Blue-Green Deployments
Blue-Green Deployments включают в себя поддержание двух идентичных сред (синей и зеленой), где одна (синяя) является текущей рабочей средой, а другая (зеленая) — это новая версия.
🔄 Вот как это работает:
- Сначала вам нужно создать вторую (зеленую) среду, равную текущей рабочей среде (синей).
- Затем вы разворачиваете новую версию в зеленой среде, пока синяя среда находится в рабочем состоянии.
- Вы запускаете smoke-тесты в зеленой среде, чтобы убедиться, что она работает правильно.
- Постепенно перенаправляете трафик из синей среды в зеленую.
- Синяя среда теперь может служить резервной копией или средой для тестирования будущих развёртываний, или вы можете её отключить.
✅ Преимущества:
- Нет простоя, нет даже снижения производительности.
- Наоборот, вы будете какое-то время работать с двойной производительностью.
- Легко переключиться обратно на синюю среду, если возникнут проблемы во время переключения.
- У вас будет достаточно времени между началом развёртывания и перенаправлением трафика, что позволяет использовать приложения с длительным холодным запуском и с необходимостью миграции данных.
⚠️ Недостатки:
- Высокая стоимость, так как необходимо дублировать существующую среду.
- Ограничения по размеру и географическому положению. Чем больше ваша существующая среда или чем более географически распределена она, тем сложнее будет её дублировать.
- Согласованность данных. Довольно сложно поддерживать данные в двух разных средах синхронизированными, не создавая дубли и не теряя данные. Чем больше операций записи в приложении, тем сложнее это сделать.
- Конкуренция и узкие места в зависимостях. Всегда будут зависимости, такие как внешние сервисы, которые невозможно дублировать. Дублирование вашей инфраструктуры и кода приведёт к конкуренции и создаст узкие места в производительности этих ресурсов.
Данный подход рекомендуется для приложений с преобладанием чтения, но критически важных для бизнеса. Многие веб-сайты и публичные API подходят под это описание.
#infrastructure #deployment
На связи с вами https://t.me/itarchitecture
Blue-Green Deployments включают в себя поддержание двух идентичных сред (синей и зеленой), где одна (синяя) является текущей рабочей средой, а другая (зеленая) — это новая версия.
🔄 Вот как это работает:
- Сначала вам нужно создать вторую (зеленую) среду, равную текущей рабочей среде (синей).
- Затем вы разворачиваете новую версию в зеленой среде, пока синяя среда находится в рабочем состоянии.
- Вы запускаете smoke-тесты в зеленой среде, чтобы убедиться, что она работает правильно.
- Постепенно перенаправляете трафик из синей среды в зеленую.
- Синяя среда теперь может служить резервной копией или средой для тестирования будущих развёртываний, или вы можете её отключить.
✅ Преимущества:
- Нет простоя, нет даже снижения производительности.
- Наоборот, вы будете какое-то время работать с двойной производительностью.
- Легко переключиться обратно на синюю среду, если возникнут проблемы во время переключения.
- У вас будет достаточно времени между началом развёртывания и перенаправлением трафика, что позволяет использовать приложения с длительным холодным запуском и с необходимостью миграции данных.
⚠️ Недостатки:
- Высокая стоимость, так как необходимо дублировать существующую среду.
- Ограничения по размеру и географическому положению. Чем больше ваша существующая среда или чем более географически распределена она, тем сложнее будет её дублировать.
- Согласованность данных. Довольно сложно поддерживать данные в двух разных средах синхронизированными, не создавая дубли и не теряя данные. Чем больше операций записи в приложении, тем сложнее это сделать.
- Конкуренция и узкие места в зависимостях. Всегда будут зависимости, такие как внешние сервисы, которые невозможно дублировать. Дублирование вашей инфраструктуры и кода приведёт к конкуренции и создаст узкие места в производительности этих ресурсов.
Данный подход рекомендуется для приложений с преобладанием чтения, но критически важных для бизнеса. Многие веб-сайты и публичные API подходят под это описание.
#infrastructure #deployment
На связи с вами https://t.me/itarchitecture
August 27, 2024
Podlodka Techlead Crew – онлайн-конференция для техлидов и опытных инженеров, которая пройдет с 14 по 18 октября.
Тема сезона – "Проектируем надёжность". В программе много всего интересного, и вот несколько примеров:
- как закладывать надёжную архитектуру на старте, используя механизмы самоисцеления и повторных попыток;
- публичное собеседование техлидов на понимание важности надёжности систем;
- как мелкие проблемы и человеческие ошибки могут стать причиной крупных сбоев через месяцы эксплуатации;
- как Feature Toggles помогают гибко управлять функционалом и снижать риски.
А еще архитектурная ката по проектированию надежной системы.
https://podlodka.io/techcrew
Доступна скидка для подписчиков по промокоду: techlead_crew_7_k08mgg
Тема сезона – "Проектируем надёжность". В программе много всего интересного, и вот несколько примеров:
- как закладывать надёжную архитектуру на старте, используя механизмы самоисцеления и повторных попыток;
- публичное собеседование техлидов на понимание важности надёжности систем;
- как мелкие проблемы и человеческие ошибки могут стать причиной крупных сбоев через месяцы эксплуатации;
- как Feature Toggles помогают гибко управлять функционалом и снижать риски.
А еще архитектурная ката по проектированию надежной системы.
https://podlodka.io/techcrew
Доступна скидка для подписчиков по промокоду: techlead_crew_7_k08mgg
October 7, 2024
Backend for Frontend (BFF)
Сегодня, когда повсеместно используются микросервисы, облачные архитектуры и множество различных клиентских устройств — от веб-приложений до мобильных приложений и IoT — использование универсального единого backend часто не приносит ожидаемых результатов. Именно здесь на помощь приходит архитектура BFF, предлагая более точечный и эффективный подход.
1. Что такое BFF?
💡BFF представляет собой отдельный backend-слой для каждого типа клиентского интерфейса: мобильного приложения, веб-приложения или «умного» устройства. Каждый слой предоставляет только те данные и функциональность, которые действительно необходимы конкретному клиенту.
Основные преимущества BFF:
🔹 Объединение запросов к различным сервисам в единый API, понятный клиенту.
🔹 Форматирование данных в удобный для конкретного интерфейса вид.
🔹 Разгрузка основного backend-а от логики, специфичной для определённых клиентов.
Разделение ответственности помогает упростить разработку и сделать пользовательский опыт более адаптированным к каждому устройству.
2. Почему BFF востребован:
✨ Индивидуальный пользовательский опыт:
Каждый клиентский интерфейс получает только те данные, которые ему действительно нужны, без избыточных или недостаточных запросов.
⚡ Повышение производительности:
Снижение количества ненужных запросов к API делает приложения быстрее и удобнее.
🤝 Упрощение разработки:
Различные команды могут работать над своими BFF независимо друг от друга, минимизируя узкие места и задержки.
🔒 Дополнительный уровень защиты:
Хотя основная безопасность часто обеспечивается отдельными механизмами, BFF может выполнять дополнительную фильтрацию данных, управление доступом и валидацию запросов.
3. Когда имеет смысл использовать BFF:
📱 Приложения для разных платформ:
Если ваше приложение должно работать с веб-интерфейсами, мобильными устройствами и IoT-устройствами, каждая из этих платформ может иметь свои уникальные потребности. BFF позволяет учесть эти различия и предоставить каждому клиенту оптимальные данные.
🔗 Упрощение взаимодействия с микросервисами:
BFF упрощает сложные запросы, объединяя данные из разных backend-сервисов в единый ответ.
🔧 Модернизация устаревших API:
BFF может выступить в роли адаптера, скрывая сложные или неудобные аспекты старых систем от современных интерфейсов.
4. Когда BFF может не понадобиться:
Если у вас небольшой проект с ограниченным числом клиентских интерфейсов, где все они имеют схожие требования, BFF может оказаться ненужным. В таких случаях избыточная сложность и дополнительные затраты на разработку могут перевесить преимущества.
5. Лучшие подходы для успешного использования BFF:
✔️ Минимизируйте логику: Позвольте основным сервисам обрабатывать сложные вычисления, а BFF сосредоточьте на адаптации данных и маршрутизации запросов.
✔️ Внедряйте кэширование: Повышайте производительность, особенно при медленных сетях.
✔️ Централизуйте обработку ошибок: Сделайте ответы об ошибках единообразными для всех клиентских платформ.
✔️ Защитите BFF: Используйте проверку доступа, валидацию данных и управление скоростью запросов.
6. Примеры из практики
🎥 Netflix:
Оптимизирует ответы для мобильных пользователей, предоставляя облегчённые данные, а для настольных приложений предлагает более богатые функции.
🎵 Spotify:
Обеспечивает согласованную работу данных на телефонах, планшетах и умных динамиках, предоставляя удобный и стабильный пользовательский опыт.
7. Преимущества BFF:
🌟 Создание приложений с высокой скоростью работы и персонализацией.
🌟 Упрощение сложных процессов взаимодействия с backend-сервисами.
🌟 Повышение масштабируемости и обеспечение дополнительного уровня безопасности.
#bff #backend #frontend
На связи с вами https://t.me/itarchitecture
Сегодня, когда повсеместно используются микросервисы, облачные архитектуры и множество различных клиентских устройств — от веб-приложений до мобильных приложений и IoT — использование универсального единого backend часто не приносит ожидаемых результатов. Именно здесь на помощь приходит архитектура BFF, предлагая более точечный и эффективный подход.
1. Что такое BFF?
💡BFF представляет собой отдельный backend-слой для каждого типа клиентского интерфейса: мобильного приложения, веб-приложения или «умного» устройства. Каждый слой предоставляет только те данные и функциональность, которые действительно необходимы конкретному клиенту.
Основные преимущества BFF:
🔹 Объединение запросов к различным сервисам в единый API, понятный клиенту.
🔹 Форматирование данных в удобный для конкретного интерфейса вид.
🔹 Разгрузка основного backend-а от логики, специфичной для определённых клиентов.
Разделение ответственности помогает упростить разработку и сделать пользовательский опыт более адаптированным к каждому устройству.
2. Почему BFF востребован:
✨ Индивидуальный пользовательский опыт:
Каждый клиентский интерфейс получает только те данные, которые ему действительно нужны, без избыточных или недостаточных запросов.
⚡ Повышение производительности:
Снижение количества ненужных запросов к API делает приложения быстрее и удобнее.
🤝 Упрощение разработки:
Различные команды могут работать над своими BFF независимо друг от друга, минимизируя узкие места и задержки.
🔒 Дополнительный уровень защиты:
Хотя основная безопасность часто обеспечивается отдельными механизмами, BFF может выполнять дополнительную фильтрацию данных, управление доступом и валидацию запросов.
3. Когда имеет смысл использовать BFF:
📱 Приложения для разных платформ:
Если ваше приложение должно работать с веб-интерфейсами, мобильными устройствами и IoT-устройствами, каждая из этих платформ может иметь свои уникальные потребности. BFF позволяет учесть эти различия и предоставить каждому клиенту оптимальные данные.
🔗 Упрощение взаимодействия с микросервисами:
BFF упрощает сложные запросы, объединяя данные из разных backend-сервисов в единый ответ.
🔧 Модернизация устаревших API:
BFF может выступить в роли адаптера, скрывая сложные или неудобные аспекты старых систем от современных интерфейсов.
4. Когда BFF может не понадобиться:
Если у вас небольшой проект с ограниченным числом клиентских интерфейсов, где все они имеют схожие требования, BFF может оказаться ненужным. В таких случаях избыточная сложность и дополнительные затраты на разработку могут перевесить преимущества.
5. Лучшие подходы для успешного использования BFF:
✔️ Минимизируйте логику: Позвольте основным сервисам обрабатывать сложные вычисления, а BFF сосредоточьте на адаптации данных и маршрутизации запросов.
✔️ Внедряйте кэширование: Повышайте производительность, особенно при медленных сетях.
✔️ Централизуйте обработку ошибок: Сделайте ответы об ошибках единообразными для всех клиентских платформ.
✔️ Защитите BFF: Используйте проверку доступа, валидацию данных и управление скоростью запросов.
6. Примеры из практики
🎥 Netflix:
Оптимизирует ответы для мобильных пользователей, предоставляя облегчённые данные, а для настольных приложений предлагает более богатые функции.
🎵 Spotify:
Обеспечивает согласованную работу данных на телефонах, планшетах и умных динамиках, предоставляя удобный и стабильный пользовательский опыт.
7. Преимущества BFF:
🌟 Создание приложений с высокой скоростью работы и персонализацией.
🌟 Упрощение сложных процессов взаимодействия с backend-сервисами.
🌟 Повышение масштабируемости и обеспечение дополнительного уровня безопасности.
#bff #backend #frontend
На связи с вами https://t.me/itarchitecture
January 27
Что такое MCP — Model Context Protocol?
Простыми словами — это «USB-C для ИИ».
⚙️ В чём суть MCP?
Так же как USB-C стандартизировал подключение устройств (питание, передача данных и т.д.), MCP стандартизирует подключение ИИ-агентов к внешним источникам данных и инструментам.
👉 До MCP каждый сервис или API имел свои уникальные протоколы и методы. MCP заменяет этот зоопарк единым, универсальным интерфейсом.
🧩 Как это работает?
MCP-сервер — это совместимый инструмент, который может:
- сообщить, какие функции он предоставляет
- выполнить действие по запросу ИИ-агента
MCP-клиент (агент) умеет:
- автоматически обнаруживать, какие возможности есть у сервера
- вызывать их через единый протокол
📚 Важно: MCP — это не только про действия, но и про знания.
Например: Один MCP-сервер может быть доступом к внутренним документам компании. Другой — отправлять письма или обновлять записи.
Для агента всё это — «инструменты», просто одни возвращают данные, другие выполняют действия.
🔌 Кратко:
Подключаешь MCP-сервер — и агент сразу видит, что он умеет. Никаких дополнительных настроек, инструкций или хардкода. Всё по стандарту.
#ai #ai_agent #mcp
На связи с вами https://t.me/itarchitecture
Простыми словами — это «USB-C для ИИ».
⚙️ В чём суть MCP?
Так же как USB-C стандартизировал подключение устройств (питание, передача данных и т.д.), MCP стандартизирует подключение ИИ-агентов к внешним источникам данных и инструментам.
👉 До MCP каждый сервис или API имел свои уникальные протоколы и методы. MCP заменяет этот зоопарк единым, универсальным интерфейсом.
🧩 Как это работает?
MCP-сервер — это совместимый инструмент, который может:
- сообщить, какие функции он предоставляет
- выполнить действие по запросу ИИ-агента
MCP-клиент (агент) умеет:
- автоматически обнаруживать, какие возможности есть у сервера
- вызывать их через единый протокол
📚 Важно: MCP — это не только про действия, но и про знания.
Например: Один MCP-сервер может быть доступом к внутренним документам компании. Другой — отправлять письма или обновлять записи.
Для агента всё это — «инструменты», просто одни возвращают данные, другие выполняют действия.
🔌 Кратко:
Подключаешь MCP-сервер — и агент сразу видит, что он умеет. Никаких дополнительных настроек, инструкций или хардкода. Всё по стандарту.
#ai #ai_agent #mcp
На связи с вами https://t.me/itarchitecture
April 13
ОФИЦИАЛЬНО: ЗАПУСК AEA KAZAKHSTAN CHAPTER 🇰🇿
Друзья, с гордостью сообщаю:
Казахстан официально присоединился к глобальному сообществу архитекторов предприятия (Association of Enterprise Architects – AEA Global).
Подписано соглашение о запуске Kazakhstan Chapter. Мы стали частью международной сети архитекторов, объединяющей экспертов из более чем 100 стран мира.
Кто мы?
Мы - профессиональное сообщество архитекторов, стратегов и ИТ-лидеров, которые:
- Строят архитектуру цифрового будущего
- Делятся практиками и международными стандартами (TOGAF, ArchiMate, DDD, System Design & etc.)
- Создают площадку для обмена знаниями, развития карьеры и нетворкинга
Офицеры Казахстанского отделения:
Председатель: Даурен Досымбек, Solution Architect, PhD researcher
(https://lnkd.in/dVK7-2qj)
Основные учредители:
1. Жанат Нурбекова (https://lnkd.in/d9yuybg8)
2. Александр Полоротов (https://lnkd.in/dT__U3jn)
3. Виталий Тренкеншу (https://lnkd.in/dEXCEZtw)
4. Давид Туганов (https://lnkd.in/dRhThpsY)
5. Сапарбек Досымбек (https://lnkd.in/dxf2SfZ8)
6. Даулет Бешеев
7. Димаш Тореханов
8. Марат Сагалов (https://lnkd.in/dYTXr8mC)
9. Айжаркын Акпаров (https://lnkd.in/dnCSAnJV)
10. Акарыс Мусабек (https://lnkd.in/dVgVHAfB)
Что дальше?
В ближайшее время:
- Запуск сайта и социальных страниц
- Онлайн-встречи и митапы (в т.ч. с международными спикерами)
- Образовательные инициативы, менторство и сообщества по интересам
- Открытый диалог — для архитекторов, CTO, BA, IT-стратегов и не только
Приглашаем присоединиться к нашему пути.
Будем вместе формировать сильное архитектурное мышление в Казахстане и показывать миру, что у нас есть чему научить.
Добро пожаловать!
Будущее начинается с архитектуры.
Ссылка на группу Chapter https://t.me/+Oz5SUU23GtY3MWEy
Друзья, с гордостью сообщаю:
Казахстан официально присоединился к глобальному сообществу архитекторов предприятия (Association of Enterprise Architects – AEA Global).
Подписано соглашение о запуске Kazakhstan Chapter. Мы стали частью международной сети архитекторов, объединяющей экспертов из более чем 100 стран мира.
Кто мы?
Мы - профессиональное сообщество архитекторов, стратегов и ИТ-лидеров, которые:
- Строят архитектуру цифрового будущего
- Делятся практиками и международными стандартами (TOGAF, ArchiMate, DDD, System Design & etc.)
- Создают площадку для обмена знаниями, развития карьеры и нетворкинга
Офицеры Казахстанского отделения:
Председатель: Даурен Досымбек, Solution Architect, PhD researcher
(https://lnkd.in/dVK7-2qj)
Основные учредители:
1. Жанат Нурбекова (https://lnkd.in/d9yuybg8)
2. Александр Полоротов (https://lnkd.in/dT__U3jn)
3. Виталий Тренкеншу (https://lnkd.in/dEXCEZtw)
4. Давид Туганов (https://lnkd.in/dRhThpsY)
5. Сапарбек Досымбек (https://lnkd.in/dxf2SfZ8)
6. Даулет Бешеев
7. Димаш Тореханов
8. Марат Сагалов (https://lnkd.in/dYTXr8mC)
9. Айжаркын Акпаров (https://lnkd.in/dnCSAnJV)
10. Акарыс Мусабек (https://lnkd.in/dVgVHAfB)
Что дальше?
В ближайшее время:
- Запуск сайта и социальных страниц
- Онлайн-встречи и митапы (в т.ч. с международными спикерами)
- Образовательные инициативы, менторство и сообщества по интересам
- Открытый диалог — для архитекторов, CTO, BA, IT-стратегов и не только
Приглашаем присоединиться к нашему пути.
Будем вместе формировать сильное архитектурное мышление в Казахстане и показывать миру, что у нас есть чему научить.
Добро пожаловать!
Будущее начинается с архитектуры.
Ссылка на группу Chapter https://t.me/+Oz5SUU23GtY3MWEy
May 12
Просто retries — не про устойчивость, нужно добавить таймауты, backoff, jitter и идемпотентность
Retries помогают тебе, но могут добить соседний сервис.
Retries не делают систему надёжной, если ты не добавил:
- таймауты
- backoff
- jitter
- идемпотентность
Без них retries не решают проблему — они её усиливают.
Базовый набор:
1️⃣ Таймауты
Ждать вечно — ловушка.
Зависший запрос жрёт ресурсы:
- потоки
- память
- подключения к БД.
Чем дольше висит — тем хуже всем.
2️⃣ Backoff (повтор с увеличивающимися задержками)
Не лупи по падающему сервису.
Retries должны быть с паузами. Дай системе отдышаться.
3️⃣ Jitter (случайная задержка)
Если все ретраят одновременно — это давка.
Добавь случайность. Распредели нагрузку. Спаси бэкенд.
4️⃣ Идемпотентность
Некоторые API имеют сайд-эффекты — отправка писем, списания с карт.
Если повторить такой запрос — будет беда.
Сделай так, чтобы одинаковый запрос давал один и тот же результат. Без дублей.
Retries должны работать вместе с системой, а не против неё.
#resilience #highload
На связи с вами https://t.me/itarchitecture
Retries помогают тебе, но могут добить соседний сервис.
Retries не делают систему надёжной, если ты не добавил:
- таймауты
- backoff
- jitter
- идемпотентность
Без них retries не решают проблему — они её усиливают.
Базовый набор:
1️⃣ Таймауты
Ждать вечно — ловушка.
Зависший запрос жрёт ресурсы:
- потоки
- память
- подключения к БД.
Чем дольше висит — тем хуже всем.
2️⃣ Backoff (повтор с увеличивающимися задержками)
Не лупи по падающему сервису.
Retries должны быть с паузами. Дай системе отдышаться.
3️⃣ Jitter (случайная задержка)
Если все ретраят одновременно — это давка.
Добавь случайность. Распредели нагрузку. Спаси бэкенд.
4️⃣ Идемпотентность
Некоторые API имеют сайд-эффекты — отправка писем, списания с карт.
Если повторить такой запрос — будет беда.
Сделай так, чтобы одинаковый запрос давал один и тот же результат. Без дублей.
Retries должны работать вместе с системой, а не против неё.
#resilience #highload
На связи с вами https://t.me/itarchitecture
May 19
May 23