ИТ-архитектура

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

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

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

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

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

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

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

https://podlodka.io/techcrew

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

🔵🟢 Blue-Green Deployments

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

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

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

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

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

#infrastructure #deployment

На связи с вами 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

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

#fun

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

#fun #career

📢 Картинка стоит тысячи слов: 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

🚀 Shopify заработала около 7 миллиардов долларов в 2023 году.

🔧 С помощью монолитного приложения на Ruby on Rails.

🤔 Получается, можно далеко зайти и без микросервисов, правда?

📜 Основной монолит содержит более 3 миллионов строк кода.

🔩 Shopify организует свой монолит в кодовые блоки, называемые компонентами. Компоненты созданы путём сортировки тысяч файлов в несколько десятков категорий, каждая из которых представляет свой домен и разделена на директории с названиями вроде:
- Доставка
- Интернет-магазин
- Товарное обеспечение
- Оформление покупок

🔄 Но не всегда было так.

🚧 Монолит Shopify начался с группировки компонентов на основе технических вопросов. С течением времени поддержка становилась всё более сложной и замедляла работу команды.

💡 Что-то должно было измениться.

🏗 Затем началась многолетняя работа:
- Компонентизация монолита
- Изоляция зависимостей между компонентами

👇 Вывод:

Хорошо определённые внутрипроцессные компоненты (модули) могут стать отличным промежуточным шагом к внепроцессным компонентам (сервисам).

#monolith #ddd

На связи с вами https://t.me/itarchitecture

Модульные монолиты можно быстро выделить в микросервисы

Необходимо заменить логические границы физическими.

Для этого нужны:
- Четко определенные границы модуля
- Способ взаимодействия модулей
- Хорошая изоляция данных в базе данных.

Миграция сводится к извлечению модуля в новый сервис.

Также потребуется переместить таблицы базы данных в отдельную базу данных.

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

Это скроет детали реализации системы от клиентских приложений.

Или вы можете использовать управляемую облачную службу для шлюза API и балансировки нагрузки.

А как насчет межмодульных коммуникаций?

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

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

Этот процесс перехода на микросервисы следует паттерну Strangler.

#patterns #microservices

На связи с вами https://t.me/itarchitecture

📊 Как выбрать правильный график для представления данных

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

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

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

#data_visualisation #presentation #graph

На связи с вами https://t.me/itarchitecture