📢 Картинка стоит тысячи слов: 9 лучших практик разработки микросервисов

При разработке микросервисов необходимо следовать следующим лучшим практикам:

🗃️ 1. Используйте отдельное хранилище данных для каждого микросервиса

📈 2. Сохраняйте код на том же уровне зрелости

🛠️ 3. Отдельная сборка для каждого микросервиса

✅ 4. Назначьте каждому микросервису одну ответственность

📦 5. Развертывайте в контейнеры

🌀 6. Проектируйте сервисы без сохранения состояния

🎯 7. Применяйте предметно-ориентированное проектирование

🔗 8. Разрабатывайте микрофронтенды (https://news.1rj.ru/str/itarchitecture/281)

🏗️ 9. Обеспечьте оркестирование микросервисов (https://news.1rj.ru/str/itarchitecture/152)

#microservice

На связи с вами https://news.1rj.ru/str/itarchitecture

Пример карьерного развития архитектора 🤣🤣🤣

#fun #career

Рубрика: найди себя 😅

#fun

Ваши данные имеют температуру, и если вы не знаете её, вы теряете деньги

📊 Горячие, тёплые и холодные данные.

Хранение данных — это не просто их сохранение; необходимо учитывать частоту доступа и период хранения данных.

Данные можно разделить на три категории в зависимости от частоты доступа:

Горячие данные (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://news.1rj.ru/str/itarchitecture

🔵🟢 Blue-Green Deployments

Blue-Green Deployments включают в себя поддержание двух идентичных сред (синей и зеленой), где одна (синяя) является текущей рабочей средой, а другая (зеленая) — это новая версия.

🔄 Вот как это работает:
- Сначала вам нужно создать вторую (зеленую) среду, равную текущей рабочей среде (синей).
- Затем вы разворачиваете новую версию в зеленой среде, пока синяя среда находится в рабочем состоянии.
- Вы запускаете smoke-тесты в зеленой среде, чтобы убедиться, что она работает правильно.
- Постепенно перенаправляете трафик из синей среды в зеленую.
- Синяя среда теперь может служить резервной копией или средой для тестирования будущих развёртываний, или вы можете её отключить.

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

⚠️ Недостатки:
- Высокая стоимость, так как необходимо дублировать существующую среду.
- Ограничения по размеру и географическому положению. Чем больше ваша существующая среда или чем более географически распределена она, тем сложнее будет её дублировать.
- Согласованность данных. Довольно сложно поддерживать данные в двух разных средах синхронизированными, не создавая дубли и не теряя данные. Чем больше операций записи в приложении, тем сложнее это сделать.
- Конкуренция и узкие места в зависимостях. Всегда будут зависимости, такие как внешние сервисы, которые невозможно дублировать. Дублирование вашей инфраструктуры и кода приведёт к конкуренции и создаст узкие места в производительности этих ресурсов.

Данный подход рекомендуется для приложений с преобладанием чтения, но критически важных для бизнеса. Многие веб-сайты и публичные API подходят под это описание.

#infrastructure #deployment

На связи с вами https://news.1rj.ru/str/itarchitecture

Podlodka Techlead Crew – онлайн-конференция для техлидов и опытных инженеров, которая пройдет с 14 по 18 октября.

Тема сезона – "Проектируем надёжность". В программе много всего интересного, и вот несколько примеров:

- как закладывать надёжную архитектуру на старте, используя механизмы самоисцеления и повторных попыток;

- публичное собеседование техлидов на понимание важности надёжности систем;

- как мелкие проблемы и человеческие ошибки могут стать причиной крупных сбоев через месяцы эксплуатации;

- как Feature Toggles помогают гибко управлять функционалом и снижать риски.

А еще архитектурная ката по проектированию надежной системы.

https://podlodka.io/techcrew

Доступна скидка для подписчиков по промокоду: techlead_crew_7_k08mgg

#podcast

Бережливый архитектор

https://pca.st/episode/26b45978-5f22-48fb-a99e-cf11646659b7

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://news.1rj.ru/str/itarchitecture

Что такое MCP — Model Context Protocol?

Простыми словами — это «USB-C для ИИ».

⚙️ В чём суть MCP?

Так же как USB-C стандартизировал подключение устройств (питание, передача данных и т.д.), MCP стандартизирует подключение ИИ-агентов к внешним источникам данных и инструментам.

👉 До MCP каждый сервис или API имел свои уникальные протоколы и методы. MCP заменяет этот зоопарк единым, универсальным интерфейсом.

🧩 Как это работает?

MCP-сервер — это совместимый инструмент, который может:
- сообщить, какие функции он предоставляет
- выполнить действие по запросу ИИ-агента

MCP-клиент (агент) умеет:
- автоматически обнаруживать, какие возможности есть у сервера
- вызывать их через единый протокол

📚 Важно: MCP — это не только про действия, но и про знания.

Например: Один MCP-сервер может быть доступом к внутренним документам компании. Другой — отправлять письма или обновлять записи.
Для агента всё это — «инструменты», просто одни возвращают данные, другие выполняют действия.

🔌 Кратко:
Подключаешь MCP-сервер — и агент сразу видит, что он умеет. Никаких дополнительных настроек, инструкций или хардкода. Всё по стандарту.

#ai #ai_agent #mcp

На связи с вами https://news.1rj.ru/str/itarchitecture

ОФИЦИАЛЬНО: ЗАПУСК 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://news.1rj.ru/str/+Oz5SUU23GtY3MWEy

Просто retries — не про устойчивость, нужно добавить таймауты, backoff, jitter и идемпотентность

Retries помогают тебе, но могут добить соседний сервис.

Retries не делают систему надёжной, если ты не добавил:
- таймауты
- backoff
- jitter
- идемпотентность

Без них retries не решают проблему — они её усиливают.

Базовый набор:

1️⃣ Таймауты
Ждать вечно — ловушка.
Зависший запрос жрёт ресурсы:
- потоки
- память
- подключения к БД.
Чем дольше висит — тем хуже всем.

2️⃣ Backoff (повтор с увеличивающимися задержками)
Не лупи по падающему сервису.
Retries должны быть с паузами. Дай системе отдышаться.

3️⃣ Jitter (случайная задержка)
Если все ретраят одновременно — это давка.
Добавь случайность. Распредели нагрузку. Спаси бэкенд.

4️⃣ Идемпотентность
Некоторые API имеют сайд-эффекты — отправка писем, списания с карт.
Если повторить такой запрос — будет беда.
Сделай так, чтобы одинаковый запрос давал один и тот же результат. Без дублей.

Retries должны работать вместе с системой, а не против неё.

#resilience #highload

На связи с вами https://news.1rj.ru/str/itarchitecture

Применимо к деятельности архитектора

“У меня есть три наставника. Когда я сталкиваюсь с проблемой и мне нужна их помощь, прежде чем обратиться к ним я сначала стараюсь как можно лучше описать свою ситуацию. Кратко излагаю контекст, саму проблему, опции на столе и свои размышления по каждой из них. Стараюсь сделать это максимально сжато, чтобы не тратить их время. Прежде чем отправить им сообщение, я пытаюсь предсказать, что они скажут. Затем возвращаюсь к тексту и обновляю его, чтобы заранее учесть их замечания. После этого я снова пытаюсь предсказать, что они скажут. В этот раз, опираясь на то, что они говорили ранее, и то, что я знаю о их философии и ходе размышлений. Пройдя весь этот процесс, я понимаю, что мне не нужно их беспокоить, т.к. решение становится очевидным. Никто из них не знает, что они мои наставники”.

- Дерек Сиверс

Задержки (latency) — смерть от тысячи порезов

Исправляем. Вот 5 проверенных способов ускорить систему:

1. Оптимизируйте запросы к БД
Один кривой запрос легко добавит +500 мс. Умножьте на тысячи запросов в секунду — получите тормоза по всей системе.

🚫 Не пишите SELECT *

🗂️ Добавляйте нужные индексы

🔄 Устраняйте N+1-запросы

📊 Измеряйте, а не гадайте (EXPLAIN, профайлеры)

2. Сократите сетевые прыжки
Каждый переход: A → B → C → D добавляет лишние миллисекунды.

🧩 Объединяйте мелкие сервисы

🏗️ Используйте backend-for-frontend (BFF)

3. Кэшируйте горячие данные
Если данные редко меняются — не тратьте время на их повторный запрос.

💾 Сессии, каталоги, конфиги держите в кэше

⚠️ Просроченный кэш неприятен, но отсутствие кэша хуже

4. Батчите и параллельте запросы
Латентность накапливается, если гонять по одному запросу.

🔗 Объединяйте запросы в один батч

🏎️ Запускайте их параллельно

📉 Меньше сетевых походов → быстрее ответ

5. Уменьшайте объём передаваемых данных
Не возите «грузовик» данных, когда нужен «рюкзак».

✂️ Убирайте ненужные поля

🗜️ Сжимайте ответы

📑 Используйте пагинацию

🖼️ Оптимизируйте изображения

⚡ Скорость — это не фича. Это фундамент UX.
Медленно = плохо.
Быстро = довольный пользователь.

#performance #latency #optimization

На связи с вами https://news.1rj.ru/str/itarchitecture

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

Приходи на новый сезон онлайн-конференции Podlodka Techlead Crew, посвященный архитектурным антипаттернам.

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

Что в программе?

🚀От спагетти кода к доменной модели: критерии выбора между Transaction Script, Active Record, DDD и Clean Architecture, практический взгляд Кирилла Ветчинкина (Авито).

🤖AI для архитектора: валидация требований, поиск зависимостей, возможность ускорения архитектурного ревью с AI в интервью с Тимуром Баюровым (Т-Банк).

🏗️Архитектура хранилища данных для вашего проекта: советы от Евгения Ненахова (МТС Web Services).

💪🏼Еда, EDA и C4 — выбери 3 из 3: практический воркшоп по Event-Driven Architecture и отказоустойчивости с разметкой в C4 проведёт Владимир Невзоров (автор канала System Design World).

🗓️13-17 октября — недельная концентрация пользы, практики и классный нетворк. Присоединяйся!

Подробности и билеты: https://podlodka.io/techcrew

А промокод «itarchitecture» даёт скидку еще в 3500 тенге или 500 руб🥳