Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке

✍️ Автор: Гойко Аджич
📅 Год: 2017
🔤 Язык: русский

Эта книга — практическое пособие по impact mapping (картам влияния), простому, но очень эффективному методу разработки программного обеспечения. Он помогает еще на стадии стратегического планирования организовать сотрудничество различных специалистов и в результате создавать эффективные программные продукты.
Почему книга достойна прочтения:
— Impact maps позволяют составлять планы, которые обеспечат соответствие разрабатываемого программного обеспечения бизнес-целям организации.
— Они также помогают легко адаптировать программное обеспечение в ходе работы над проектом.
— Этот инструмент универсален и подойдет как для Agile-проектов, так и для классического проектного подхода.

Обзор книги на vc.ru

#планирование #стратегия

🛡Безопасность API: базовые принципы

Проектирование API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Крайне важно уделить внимание вопросам безопасности.

Способы обеспечения безопасности

1️⃣ Использование зашифрованного протокола TLS. Рекомендуется шифровать трафик запросов и ответов API для защиты конфиденциальности информации при передаче по незащищенным сетям. Общепринятой практикой является использование протокола шифрования TLS. Поверх TLS работает HTTPS, о котором мы уже писали.

2️⃣ Авторизация запросов. Авторизация подразумевает, что данному клиенту разрешено выполнять операцию над ресурсом. Следует учитывать:
▪️Проверку прав доступа к объектам при каждом запросе.
▪️Проверку того, что залогиненный пользователь имеет доступ только к разрешенным объектам.
▪️ID объектов должны быть сложными для подбора, например в виде UUID, а не простая последовательность 1, 2, 3.

3️⃣ Проверка содержимого запроса. Необходимо проверять, что запрос не содержит опасных компонентов (например, SQL-инъекции, XSS-атаки, DTD-атаки). При этом недопустимо автоматически десериализовать пришедшие данные и записывать их в БД без каких-либо проверок бизнес-логики и прав доступа.

4️⃣ Проверка скорости и количества запросов: контроль, что запросы API не превышают определенной скорости для защиты сервиса от перегрузки или атак. Может настраивать квоты запросов на клиента. Сюда входит, например, блокировка IP по результатам неудачных попыток входа.

5️⃣ Контроль размера запроса: проверяет, что полезная нагрузка запроса не превышает ограничения для операции API. Предотвращает попадание неправильных (больших) запросов к сервису.

6️⃣ Мониторинг безопасности: логировние ключевых событий, таких как неудачные попытки аутентификации, отказы в доступе, ошибки валидации входных данных. Также следует мониторить инфраструктуру, сетевую активность, загрузку ОС. Важно настроить алерты, чтобы максимально оперативно реагировать на риски.

7️⃣ Если API непубличное, следует ограничить адреса, с которых разрешено использование API. Также можно ограничивать HTTP методы, которые могут быть использованы для доступа к API и задать список заголовков, которые сервер может принимать.

📄 Стандарты в области безопасности API
1. OWASP (Open Web Application Security Project), а также есть стьтья-перевод на русском на Хабре
2. RFC 7519 — JSON Web Token (JWT)
3. OAuth 2.0, простым языком: статья на Хабре

📑 Статьи
1. Безопасность REST API от А до ПИ
2. Рекомендации по проектированию безопасности API для внутренних и облачных систем
3. Требования аутентификации и авторизации API — раздел открытого курса по документированию API
4. Защита API от атак — статья на Tadviser от ИБ-компании
5. Требования к информационной безопасности: кого вовлекать в выявление? — статья Алексея Краснова на Systems.Education

⏯ Видео
1. Защита API и микросервисной инфраструктуры — доклад директора ИБ-компании
2. Тестирование безопасности API — Катерина Овеченко. QA Fest 2019
3. Курс видеолекций "Безопасность интернет-приложений" от Mail.ru Group, МГТУ им. Н.Э. Баумана (осень 2014)
4. Основы безопасности веб-приложений — вебинар от Skillbox
5. Открытая лекция Академии Яндекса про безопасность веб-приложений (2017)
6. Информационная безопасность в аналитике — доклад Галины Матвеевой на конференции Analyst Days-9
7. Информационная безопасность и криптография. Точка зрения аналитика — доклад Сергея Евтуховича на конференции Analyst Days #15

Инфографика по безопасности API

#безопасность #api

💥Подборка от канала Системный сдвиг 💥

Ведет канал Юрий Куприянов — эксперт по системному анализу, управлению продуктами и архитектуре, автор лучших докладов на конференциях для системных аналитиков:
AnalystDays, Летний аналитический фестиваль, Flow.

Первым исследовал возможности ChatGPT применительно к системному анализу. В канале есть материалы и обсуждения докладов, и много полезных инструментов и практик.

Топ самых полезных постов:

📛 Про стоп-слова для аналитика (если вы их встретили в требованиях -- остановитесь и перепишите!)

✅ 10 техник проверки полноты требований

📝 Паттерны декомпозиции пользовательских историй

🤢 Как не быть душным при общении с пользователями?

🤷🏼‍♂️ Про самые неинтересные аналитикам темы

Посты про ChatGPT:

🤖 ChatGPT генерит техническое задание
👾Архитектурная модель C4 и её генерация
📆Про ChatGPT и оценку сроков проекта
🏆Задание для аналитика на собеседовании и как его проходит ChatGPT

💠 Микросервисная архитектура: основные понятия

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

У каждого микросервиса своя бизнес-задача: управлять каталогом, хранить содержимое корзины или проводить оплату заказа. При этом разные микросервисы могут быть реализованы на разных языках программирования и использовать разные СУБД.

🔲 Альтернатива монолиту

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

Вносить изменения в такую систему крайне сложно: малейшее изменение кода может вызвать баги в самых неожиданных местах. А ведь любой баг уронит сразу всю систему! А ещё монолит можно релизить только вест целиком.

Микросервисная архитектура предлагает альтернативу монолиту.

✅ Преимущества микросервисной архитектуры

1️⃣ Сокращение Time To Market. Главная цель перехода на микросервисы – увеличение скорости поставки конечной ценности на рынок, или, по-айтишному, сокращение длительности релизного цикла. Если эта цель не выполняется, стоит задуматься, а зачем вам микросервисы.

2️⃣ Масштабируемость. Микросервисы можно масштабировать независимо друг от друга. Например, если возрастает нагрузка на какой-либо сервис, можно создать дополнительные реплики этого сервиса или увеличить вычислительные мощности, не затрагивая систему в целом.

3️⃣ Отказоустойчивость. При падении одного из микросервисов система в целом продолжает функционировать.

4️⃣ Гибкость технологий. Любой микросервис по отдельности можно реализовывать на каком угодно техстеке.

⛔️ Недостатки микросервисной архитектуры

1️⃣ Это дорого. Требуется больше железа и людских ресурсов.

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

3️⃣ Сложно поддерживать целостность данных. Если в монолите у нас общая реляционная БД, то и схема данных у нас общая. Целостность и транзакционность находятся под контролем СУБД. В микросервисной архитектуре у каждого сервиса своя БД, а значит нет единой системы, которая бы гарантировала целостность транзакций.

❓ Когда стоит переходить на микросервисы

🔹 Монолит ограничивает эффективность бизнеса. Вносить изменения в код практически невозможно. Релизы очень сложны и долги. Ошибки приводят к большим финансовым и репутационным потерям.

🔹 Есть деньги, ресурсы и компетенции.

🔹 У вас крупный проект с большим количеством разработчиков.

🔹 Вы отлично понимаете свою предметную область. Без этого верно определить границы микросервисов нельзя.

🔹 Вы понимаете, как будут работать распределённые транзакции

❌ Когда не стоит переходить на микросервисы

➖ Малый размер проекта. Если у вас проект маленький или средний по размеру, миграция на микросервисы может привести к ненужной сложности и издержкам.

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

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

➖ Текущая архитектура работает. Если ваш монолитный проект устойчив и соответствует потребностям бизнеса.

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

➖ Высокие требования к согласованности данных. Микросервисы используют разные базы данных для разных сервисов, что может создавать сложности при согласовании данных.

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

Подборка материалов про микросервисы — в следующем посте 👈

#микросервисы #архитектура

📍
Бизнес-анализ и Системный анализ

Группа для профессионалов, начинающих специалистов, и всех, кому интересна тема бизнес-аналитики, системного анализа, проектирования систем и системной инженерии

🔥 Большая подборка материалов по микросервисной архитектуре

Призываем активно делится материалами в комментариях, если у вас есть, что показать ☺️

📑 Статьи (теория)
1. Просто о микросервисах — Хабр, блог Райффайзен Банка
2. Простым языком о микросервисной архитектуре для начинающих — VK Cloud
3. Архитектура микросервисов
4. Шпаргалка по миграции монолита на микросервисы
5. Полный перечень паттернов проектирования MSA от Криса Ричардсона
6. 26 основных паттернов микросервисной разработки на русском
7. Какого размера должен быть микросервис
8. Целостность данных в микросервисной архитектуре — как её обеспечить без распределенных транзакций и жёсткой связности
9. Сравнение подходов к реализации распределенных транзакций для микросервисов

📝 Статьи (практика)
1. Микросервисы глазами аналитика
2. Микросервисы: опыт использования в нагруженном проекте
3. Не бойся микросервиса: Алексей Баитов об использовании микросервисной архитектуры на практике
4. Kafka и микросервисы: обзор
5. Путь IVI от монолита к микросервисам
6. Переход от монолита к микросервисам: история и практика Райффайзен Банка
7. Предметно-ориентированная микросервисная архитектура от Uber
8. Распределённая трассировка: мы всё делали не так

⏯ Видео и вебинары
1. Что такое Микросервисы || Объяснение от Мартина Фаулера (пересказ на русском)
2. Микросервисная архитектура, подходы и технологии — Кирилл Ветчинкин
3. Введение в архитектуру микросервисов — Дмитрий Голых
4. Микросервисы с нуля — Семен Катаев (Авито)
5. ТОП ошибок в инфраструктуре, мешающих высоким нагрузкам — Андрей Половов (Флант)
6. Современная Микросервисная архитектура в банковской сфере — доклад Александр Соляра (Иннотех) на конференции Analyst Days-13
7. Аналитика микросервисов. Практический опыт аналитика в enterprise — доклад Валерия Разномазова на конференции Analyst Days-14
8. Проектируем приложение в микросервисной архитектуре. Разбор кейсов — доклад Максима Цепкова на конференции Analyst Days-12
9. Шаблоны проектирования микросервисов на примере Авито
10. Целостность данных в микросервисной архитектуре — Николай Голов (Avito)
11. Мастер-класс: использование брокеров сообщений в сервисной архитектуре — Андрей Бураков
12. Микросервисы vs монолит: разбираемся в архитектуре приложений — демо-занятия от Яндекс Практикум
13. Микросервисная архитектура, когда нужна, а когда нет — открытый вебинар курса «Microservice Architecture» от OTUS
14. Тестирование в микросервисной архитектуре — демо-занятие курса «Microservice Architecture»
15. Авторизация и аутентификация в микросервисной архитектуре — открытый вебинар курса «Microservice Architecture» от OTUS

Вот ссылка на плейлист в Ютубе, где собраны все видео выше + ещё несколько

📚 Книги
1. Крис Ричардсон. Микросервисы. Паттерны разработки и рефакторинга
2. Сэм Ньюмен. Создание микросервисов
3. Беллемар Адам. Создание событийно-управляемых микросервисов
4. Сэм Ньюмен. От монолита к микросервисам
5. Парминдер Кочер. Микросервисы и контейнеры Docker

⛔️ Про недостатки MSA
1. Хватит везде делать микросервисы
2. Остановитесь!!! Вам не нужны микросервисы
3. Микросервисы. Не всё то золото, что хайп
4. Видео Ах, как хочется вернуться, ворваться в монолит! — Павел Лакосников (Авито)
5. Верните мне мой монолит

#подборка #микросервисы #архитектура

📖 Создание событийно-управляемых микросервисов

✍️ Автор: Беллемар Адам
📅 Год: 2022
🔤 Язык: русский

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

#микросервисы #архитектура