Backend без хрупких интеграций: 5 материалов, которые вы могли пропустить
На старте проекта многие решения выглядят простыми: сделать REST API, разнести сервисы, добавить очередь, договориться о моделях данных. Но по мере роста системы выясняется, что именно эти решения определяют, насколько легко её развивать дальше.
Эта подборка будет полезна тем, кто проектирует backend‑системы, работает с API, микросервисами, доменной моделью или просто регулярно сталкивается с вопросом: «как сделать так, чтобы архитектура не мешала разработке через полгода».
Собрали 5 материалов по теме:
Как фронтенд получает данные с сервера: лучшие практики 2026 О том, как backend и frontend договариваются через API, где уместны REST, GraphQL, BFF и Server Components, и почему «быстро отдать JSON» ещё не значит сделать удобный интерфейс для клиента.
А если хотите не только читать, но и разбирать темы с практиками, смотрите дайджест — там собраны бесплатные открытые уроки по разработке, архитектуре и инфраструктуре.
Порядок сообщений, DLQ, graceful shutdown, spike нагрузки — на каждый вопрос есть минимум два рабочих ответа
Витя Михайлов, Backend Lead Garage Eight, и Женя Янченко, руководитель разработки и автор тг-канала @jane_yanchenko, разобрали 5 вопросов про брокеры со стороны RabbitMQ и Kafka соответственно.
Вопрос 1. Как вы обеспечиваете
порядок сообщений, когда это критично для бизнес-логики? Например, событие «покупка товара» не должно обработаться раньше события «счет пополнен».
RabbitMQ:
Только один консьюмер на очередь.
Ack( ) только после завершения бизнес-логики.
Если используешь nack — убедись,
что тип очереди не quorum: он меняет логику requeue.
Publish только строго с confirmation mode, и обработчиком connection.blocked, чтобы FlowControl не испортил нам порядок (выключить его нельзя).
— Витя
Kafka:
Kafka обеспечивает порядок в рамках одной партиции. Партиция определяется по ключу: все сообщения с одинаковым ключом попадут в одну партицию.
Например, если выбрать ключом ID заказа, все события по нему попадут
в одну партицию.
Нюансы:
определенные настройки ретраев продюсера могут привести к нарушению порядка
изменение числа партиций может сломать прежнее распределение
— Женя
Вопрос 2. Что делать с сообщением, которое консьюмер не может обработать уже
10 раз подряд? Стратегии retry, DLQ, алертинг — как это устроено
на практике.
RabbitMQ:
Сначала понять: можно ли вообще обработать сообщение? Битый JSON
или некорректные данные — повторные попытки бессмысленны. Отправляем
в DLX или дропаем с записью в лог.
Если обработать можно — два варианта:
1) Ретраить бесконечно (осторожно: poison message handling). Нужен мониторинг и rate limit на повторы. 2) Отбросить в DLQ, но тогда теряем порядок обработки.
— Витя
Kafka:
Заводим отдельный топик — Dead Letter Queue (DLQ).
1) Пробуем обработать сообщение.
Успех — коммитим оффсет. 2) Ошибка — ретраим N раз. Помогает при временных сбоях (БД не ответила), но не при битом сообщении. 3) Попытки исчерпаны — отправляем в DLQ в исходном виде + пишем в лог. 4) Сообщения в DLQ анализируются вручную.
Вопрос 3. Как обеспечить обратную совместимость схемы сообщений при обновлении сервиса? Продюсер и консьюмер деплоятся независимо —
как не сломать друг друга.
RabbitMQ:
Нельзя. Ломать. Обратную совместимость.
Миграция работает так: в какой-то момент поддерживаешь обе схемы параллельно, затем выключаешь старую.
Хороший пример с тремя реальными сценариями миграции — официальный гайд RabbitMQ по переходу с classic
на quorum queues.
— Витя
Kafka:
Схема сообщений в топике — публичный контракт, как в REST API. Изменения проектируем так, чтобы обе версии какое-то время работали параллельно.
Безопасно: Добавить необязательное поле, добавить поле с дефолтом, перестать использовать поле (но не удалять).
Опасно: Переименовать, изменить тип, удалить обязательное поле, поменять смысл.Для валидации схем — Schema Registry
(особенно при Avro или Protobuf).
Бэкенд без слепых зон: 10 открытых уроков для разработчиков
Проблемы в бэкенде редко ограничиваются неправильным условием в коде. Приложение может упереться в многопоточность, потерять данные из‑за неверных границ транзакции или превратить кеш и брокер сообщений в новый источник сбоев.
Собрали бесплатные открытые уроки для бэкенд‑разработчиков разных стеков. Преподаватели‑практики покажут рабочие подходы, разберут типовые ошибки и ответят на вопросы. Заодно можно познакомиться с экспертами и проверить формат обучения OTUS.
На сайте Hacker News завязалось любопытное обсуждение. Пользователь поделился опытом: в крошечной базе данных на 15 тысяч записей случилась коллизия UUIDv4. Приложение генерировало идентификаторы через uuid, популярный пакет npm, база имела ограничение UNIQUE, и однажды новая запись пришла с тем же UUID b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, что уже лежал в таблице с прошлого года.
Если что, то в этом плане у UUID должен быть полный иммолейт импрувед: вероятность такого события крайне мала. У 128-битного UUIDv4 122 случайных бита, то есть шанс попадания нового UUID в один из уже 15 000 существующих равен примерно один к 3,5 × 1032. Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.
Другую забавную байку в комментах поведал аноним с одноразовым аккаунтом. Примерно десять лет назад товарищ анонима перешёл на работу в некий стартап в качестве технического директора. Дела у компании шли отлично, бизнес быстро рос, в команде было порядка 200 разработчиков.
В первую неделю новый техдир обнаружил, что в стартапе заведён специальный микросервис для генерации UUID. Все остальные команды были проинструктированы передавать запросы на генерацию «безопасных» UUID именно в этот сервис. Новый сотрудник начал разбираться и обнаружил, что сервис — это запросы в отдельную базу данных, которая и хранила все до этого выданные UUID.
Логика работы микросервиса была простой: в ответ на запрос генерировался UUID, выполнялась чрезвычайно важная проверка на уникальность в этой базе данных, а затем идентификатор возвращался клиенту. Работу микросервиса поддерживала отдельная команда из трёх инженеров с собственными спринтами и канбан-доской.
Если тесты есть, а уверенности в них нет — 10 открытых уроков по тестированию (апрель‑май)
Тестирование в 2026 — это уже давно не только про «проверить, что работает». Это про архитектуру тестов, нагрузку, интеграции и всё чаще — про работу с AI.
Чувствуете, что текущего инструментария уже не хватает (или просто хочется систематизировать практику)? Собрали серию открытых уроков по тестированию — от базовых вещей до более инженерных подходов.
Подборка получилась разнообразной — и это как раз полезно. Можно точечно закрыть конкретный пробел: разобраться с нагрузочным тестированием, контрактами, API‑тестами или архитектурой фреймворка. А можно посмотреть шире — как меняется роль QA, когда тестирование всё теснее связано с разработкой, архитектурой, наблюдаемостью и AI‑инструментами.
Все уроки бесплатные и проходят в рамках онлайн‑курсов. Их ведут преподаватели‑практики, поэтому это не формат «послушать общую теорию», а возможность посмотреть на реальные подходы, познакомиться с экспертами, протестировать формат обучения и задать вопросы по теме или курсу.
📌 Посмотрите каталог курсов по тестированию: там уже не отдельные инструменты, а полноценные треки с практикой, архитектурой и реальными кейсами.
Бэкенд «тормозит», API ломаются, а архитектура трещит: уроки, которые помогают закрыть эти проблемы
У бэкенд-разработки есть неприятная особенность: большинство сложностей проявляется не в момент, когда пишется первый сервис, а позже — когда API начинает обрастать интеграциями, фоновые задачи конкурируют за ресурсы, поиск и хранилище требуют разных подходов к данным, а архитектурные решения внезапно начинают влиять на скорость разработки не меньше, чем качество кода.
В этой подборке — бесплатные демо-уроки от преподавателей-практиков про те части бэкенда, которые обычно и забирают больше всего времени в реальной работе. Это хороший способ посмотреть на чужой инженерный подход, познакомиться с экспертом, задать вопросы по своей ситуации и заодно закрыть конкретные пробелы: в API, тестировании, нагрузке, инфраструктуре, работе с данными и проектировании систем.
Конец микросервисного угара: как Amazon, Uber и Netflix внедряли монолиты
Весной 2023 года Prime Video (Amazon) выкатил кейс, который для многих стал страшным сном: они слили красивую микросервисную оркестрацию и снизили стоимость инфраструктуры более чем на 90%.
Что они сделали? Перестали гонять данные через S3 между десятком серверлесс-функций ради банальной обработки видео. Они собрали те же самые компоненты (медиаконвертер, детекторы) в один контейнер. Вызов функции в памяти оказался быстрее и на порядок дешевле, чем "облачная магия".
Шок-контент? Только для тех, кто перечитал умных книг. Остальные просто кивнули.
Скрытый налог, о котором не пишут в книжках
Мы все прочитали «Чистую архитектуру» и умеем рисовать квадратики. Мы научились резать монолиты вдоль и поперек. Но в лучших практиках почему-то обходят главный вопрос: во что это реально обходится бизнесу?
Распределенные системы — это не бесплатный апгрейд. Это класс расходов, которого физически нет в монолите.
Вы платите за:
Пересылку данных по сети вместо вызова method() в памяти.
Отладку ада, когда для исследования бага нужно поднять логи 7 разных сервисов.
Синхронизацию команд, когда чтобы решить ночной критический баг на проде вам нужно разбудить 5 тимлидов соседних команд.
В итоге мы получаем внешне технически совершенную систему, которую никто не может окупить. Бывает, что переход в микросервисы — это не инженерное решение, а следование вере.
Опыт Uber
У тебя 5 сервисов — ты держишь их в голове. У тебя 500 сервисов — ты не инженер, ты -- смотритель в зоопарке.
В 2016 году в компании Uber поймать баг означало пройти по 50 сервисам из 12 разных команд. Инженеры тратили больше времени на синхронизацию в слаке, чем на написание кода.
Решение Uber (DOMA) для многих стало интересным: они не стали переписывать код в монолит. Они сгруппировали этот зоопарк по реальным доменам и прикрыли их общими шлюзами.
Монолит 2.0: как было в Netflix
В 2012-м Netflix тушил каскадные отказы через Hystrix. Но для длинных бизнес-процессов (прием контента, кодирование, раскатка по CDN) это было как пластырь на переломе. Инженеры собирали логи руками.
В 2016-м они выкатили решение Conductor — оркестратор. По сути, это монолитный движок с UI для визуализации потоков своих микросервисов. В Netflix не побороли сложность, а переупаковали её. Теперь им нужна отдельная команда, чтобы поддерживать монолит который оркестрирует микросервисы.
Прежде чем пилить новый сервис или склеивать старый, ответьте себе на три вопроса.
Может ли одна команда выкатить фичу без согласования с пятью другими? Если для баг-фикса нужна координация 10+ команд — границы проведены неверно. Вы строите самый худший в мире архитектурный паттерн: распределенный монолит. Вы получите все минусы микросервисов и все минусы монолита одновременно.
Какая доля бюджета уходит на бизнес-логику, а какая — на то, чтобы сервисы могли просто "договориться"? Готовы ли вы содержать сложный слой оркестрации (как Prime Video) только ради того, чтобы система технически работала?
Есть ли у вас цифры, по которым вы поймете, что архитектура перестала окупаться? Prime Video начали с серверлесса и слепили всё в один процесс под реальной нагрузкой.
Выводов не будет, вы сделаете их сами. Послушать расширенную версию статьи как сказку на ночь без донатов и рекламы можно на Яндекс.Музыке, Звуке и Apple Podcasts.
Брокер сообщений для микросервисов — звучит страшно, но только пока не разберешься. NATS написан на Go, запускается за минуты и не требует сложной инфраструктуры.
В блоге разобрали, как установить NATS на Linux и Windows, настроить аутентификацию, TLS и JetStream — и сразу проверить всё это из консоли.
С некоторым опозданием предлагаем вам почитать обзор на переведённую нами книгу Диего Пачеко и Сэма Сгро "Принципы модернизации программных архитектур". Обзор сделали в своём корпблоге специалисты дружественной нам компании SSP-Soft. Книга появилась в продаже в начале декабря, пока только бумажная версия.
Наряду с темами, традиционными для такой литературы - обеспечение слабой связности, проектирование микросервисов, горизонтальное масштабирование - книга рассматривает и более продвинутые вопросы, в частности, как организовать миграцию кода и миграцию данных. Значительное внимание в ней уделено как известным, так и недооценённым архитектурным антипаттернам. Например, авторы аргументированно причисляют к антипаттернам распределённый монолит.
Многие используют подход API First в проектировании систем, но зачастую даже не задумываются, что порождают таким образом сервисы с анемичными доменными моделями, проектируя по сути REST-обертки над базой данных с отсутствием какой-либо бизнес-логики.
API First и Богатая доменная модель не являются взаимоисключающими понятиями, если правильно выстроить процесс и архитектуру.
Главная проблема: API First фокусируется на контрактах внешнего мира, что часто приводит к созданию DTO/Model классов, которые являются чистыми структурами данных без поведения (анемичная модель).
API First — это про контракты, а не про реализацию. Не позволяйте инструментам кодогенерации диктовать структуру вашей доменной модели!
Правильный workflow:
1. API Design First: Создайте/обновите OpenAPI спецификацию.
2. Генерация DTO: Сгенерируйте или создайте классы для API‑контрактов.
3. Projection First: Спроектируйте доменную модель независимо от DTO, фокусируясь на поведении и инвариантах.
4. Создание Mapping Layer: Напишите преобразователи между DTO и Domain Objects.
5. Реализация Application Service: Тонкий слой, который координирует работу домена.
Стек технологий, который помогает:
— MapStruct: Для автоматизации маппинга между DTO и Domain — JUnit 5: Для тестирования доменной логики — OpenAPI Generator: Для автоматической генерации DTO из спецификации — ArchUnit: Для проверки архитектурных правил (например, запрет на анемичные модели)
// ArchUnit тест, проверяющий, что в доменных классах есть поведение
@ArchTest
static final ArchRule domain_models_should_have_business_methods =
classes()
.that().resideInPackage("..domain..")
.and().areAnnotatedWith(Entity.class)
.should().containAnyMethodsThat(
DescribedPredicate.describe(
"have business methods",
method -> !method.getName().startsWith("get") &&
!method.getName().startsWith("set")
)
);
Приглашаем на бесплатный вебинар «Микросервисы: 5 главных ошибок и как их избежать с самого начала». Обсудим, какие ошибки возникают при переходе на MSA: от не тех границ сервисов до хаоса и технического долга.Вы узнаете, как с самого начала проектировать архитектуру правильно и получите чек-лист «10 признаков здоровой микросервисной системы» чтобы не создать «распределенный монолит».
‼️ Обратите внимание, что чек-лист будет выдан только участникам эфира.
🕓 Когда: 25 ноября, 16:00–17:00 (Мск)
👨🎓 Спикер: Бурцев Николай — cпециалист по архитектуре ПО, проектированию MSA, .NET-разработке.
Разберём:
1️⃣ Неправильное выделение границ микросервисов: бизнес-декомпозиция против технической.
2️⃣ REST-зависимость: когда API превращается в паутину.
3️⃣ «Всё через брокер»: когда Kafka и RabbitMQ создают больше проблем, чем решают.
4️⃣ Архитектура без инфраструктуры: CI/CD, наблюдаемость, DevOps-влияние.
5️⃣ Архитектура без коммуникации: стандарты, код-ревью, управление качеством.
Минималистичные healthcheck-утилиты для Docker-контейнеров
Однажды я был маленький, и задавался вопросом - вот собираешь ты свое приложение, нежно помещаешь его в Docker-образ, заботишься о том чтоб и зависимостей было поменьше, и скомпилируешь его так чтоб итоговая каша из байт было погуще, но покомпактее; используешь scratch, статическую линковку, но чтоб "из коробки" был еще и healthcheck - приходится или писать свой мальний чекер каждый раз, или тянуть статичкски слинкованный curl/wget, если приложение работает как http сервер.
Потому что без healthcheck жизнь ну совсем не торт, даже при локальной разработке, когда запускаешь уже готовые образы, ставишь их в зависимость для других (в том же docker compose) - без него это все работать не будет так, как тебе хочется - демоны будут стучаться друг к другу без уважения и учета, готово оно в этому или нет.
Так родился microcheck - набор крошечных статически скомпилированных бинарников, созданных специально для healthcheck-ов. Они не имеют зависимостей от динамических библиотек, написаны на C, и работают даже в scratch и distroless образах, да умеют корректно возвращать exit-коды, понятные Docker’у (0 - здоров, 1 - приходи завтра).
В комплекте:
httpcheck — проверка HTTP-эндпоинтов (~75 KB)
httpscheck — то же самое, но с TLS и автоопределением протокола (~500 KB)
portcheck — проверка TCP/UDP-портов (~70 KB)
У вас в продакшене наверняка Kubernetes, и все проверки делает kubelet - скорее всего, вам не нужно ничего менять. Но если вы запускаете контейнеры в «голом» Docker’е или других рантаймах без встроенных healthcheck-ов - такие инструменты могут здорово упростить жизнь.
Разница по размеру в десяток мегабайт против семи десятков килобайт, а в качестве бонуса - не нужен shell-процесс, всё работает напрямую и быстро (а еще и в переменные окружения умет).
Поддерживаются все популярные архитектуры (x86_64, ARM, ppc64le, s390x и др.), есть готовые образы в GitHub Container Registry и Docker Hub.
RabbitMQ — брокер распределенных сообщений, разработанный на основе стандарта AMQP (Advanced Message Queuing Protocol). Этот инструмент собирает потоковые данные из нескольких источников, после чего распределяет и маршрутизирует их для дальнейшей обработки. Выбираем брокер сообщений и подробнее знакомим с его возможностями.
Бенефиты RabbitMQ, которые выделяют его на фоне других похожих сервисов:
надежность — все сообщения в RabbitMQ будут доставлены с соблюдением порядка, даже в случае технический сбой;
масштабируемость — может работать с большими объемами данных. Также его можно развернуть не только на отдельном сервере, но и в распределенной среде;
гибкость — поддерживает большое количество сценариев для маршрутизации и распределения сообщений. Это позволяет сочетать программу со многими приложениями.
Как настроить RabbitMQ на трех операционных системах: Ubuntu, Debian и CentOS Stream, а также об основных принципах работы этой технологии — читайте в подробном гайде в базе знаний Рег.облака.
Рецепт приготовления кролика от нашего Backend Lead U^ｪ^U
Брокеры сообщений, в частности RabbitMQ, широко применяются во всем IT. Однако это далеко не магическая коробка, а написать код так, чтобы не потерять свои сообщения — крайне нетривиальная задача.
Этим летом наш Backend Lead Витя Михайлов выступил на Saint HighLoad++ 2025, где рассказал, как же правильно готовить RabbitMQ, и поделился классными кейсами.
Больше записей лекций и полезных материалов от нашей команды найдешь в нашем телеграм-канале. Например, там есть другие выступления Вити, а также рассказ о его хобби.
Тестируем микросервисное приложение с кучей интеграций — четыре совета из практики
На одном из финтех-проектов наша команда тестирования столкнулась с серьезными вызовами: нестабильные партнерские API, отсутствие тестовых сред у партнеров, лимиты на запросы и риски всё сломать одним обновлением.
В этом посте — примеры, как команда с этим справилась и как можно поступить в похожих ситуациях. Эта подборка может сэкономить кому-то часы (а то и дни) работы.
🛠️ Внешние сервисы без тестовых контуров
Решение: собственный мок-сервис на основе WireMock.
Как он работает:
тестировщик задает нужный ответ и отправляет его через HTTP-запрос в БД;
нужные вызовы подменяются в конфигурации;
при тестировании запрос уходит не во внешний API, а в мок, который отдает нужный ответ.
Моки у нас кастомные, конфигурируются через Swagger, и не завязаны напрямую на CI/CD — это упрощает запуск и дает гибкость.
Плюс: так мы не зависим от внешних API, которые то работают, то нет.
💸Платные вызовы и лимиты на тестовые запросы
Решение: изолированные стенды и замещение моками везде, где возможно.
Если API-партнер дает 150 вызовов в месяц, а вам нужно 500 на автотесты — моки опять же спасают. Мы блокируем обращения к реальным API на командных стендах и заменяем их заглушками. Проверку живых интеграций оставляем только на пред-проде.
Плюсы:
не сжигаем бюджет;
эмулируем ошибки и нестандартные ответы;
ускоряем тесты без зависимости от внешней стороны.
🔄 Нестабильность интеграционных тестов
Решение: изоляция и моки как защитный слой.
Микросервисная архитектура — это боль, когда один упавший сервис ломает релиз. Поэтому мы:
эмулируем нестабильные вызовы моками;
изолируем свою часть и фокусируемся на ее стабильности;
прогоняем тесты на командных стендах — быстро, стабильно и без флуктуаций от партнеров.
🤝 Десятки команд, завязанных на общий процесс
Решение: интеграционные проверки и ревью на совместимость.
Когда много команд делают один продукт, любое изменение может зацепить чужой модуль. Мы выстроили систему так, чтобы ошибки ловились до мерджа, а не после инцидента. Что помогло:
общие тестовые фреймворки и единый подход к интеграционным тестам;
сценарии, которые включают зависимости от других команд;
проверка обратной совместимости: если что-то ломает чужой функционал — фича не проходит MR.
Что такое архитектура ПО и почему она не про красивые диаграммы
Изображение сгенерировано при помощи DALL-E 3
🏗️ Архитектура программного обеспечения — это не просто модное слово для повышения ставки на собеседовании. Это фундамент, на котором строится вся система.
Что это такое на самом деле? Архитектура ПО — это структура компонентов системы, их взаимосвязи, взаимодействия с внешней средой и принципы разработки. Звучит скучно? А вот и нет! Это как план города: без него у вас получится не Москва, а какая-то деревня Гадюкино с кривыми улочками.
Зачем это нужно?
Снижает сложность системы через декомпозицию
Определяет рамки развития (чтобы не росло как раковая опухоль)
Помогает команде говорить на одном языке
Экономит нервы и деньги в долгосрочной перспективе
Под капотом архитектура отвечает за: ✅ Разбиение системы на модули (как LEGO, только для взрослых) ✅ Способы взаимодействия компонентов (REST, RPC, события) ✅ Распределение ответственности между модулями ✅ Выбор технологического стека
Простой пример: Представьте интернет-магазин. Без архитектуры у вас будет один гигантский файл на 50,000 строк, где корзина покупок живёт рядом с логикой оплаты, а пользовательские данные перемешаны с каталогом товаров. С архитектурой — отдельные модули: UserService, CatalogService, PaymentService, каждый со своей зоной ответственности.
🔧 Давайте разберём базовые понятия архитектуры, без которых никуда. Это как алфавит — скучно учить, но без него читать не получится.
Компонент — часть системы, выполняющая изолированную функцию. Думайте о нём как о сотруднике в компании: у каждого своя роль, свои обязанности, и если он заболел — его можно заменить.
Пример компонентов:
Authentication Service (следит, чтобы чужие не лезли)
Notification Service (шлёт уведомления)
Data Storage (хранит данные, очевидно)
Интерфейс — способ взаимодействия между компонентами. Это как протокол дипломатии: все знают правила игры, никто не лезет с кулаками.
Типы интерфейсов:
REST API (классика жанра)
Message Queue (асинхронные сообщения)
RPC (удалённые вызовы)
Database API (работа с данными)
Связи — физические или логические каналы передачи данных между компонентами. Это как дороги в городе: определяют, кто с кем может общаться и как.
Примеры связей:
HTTP-соединения (веб-траффик)
TCP/UDP сокеты (низкоуровневая связь)
Message Brokers (Apache Kafka, RabbitMQ)
Database connections (пул соединений с БД)
Модуль — логическая группировка компонентов по функциональности. Это как департаменты в компании: HR, IT, Бухгалтерия.
Примеры модулей:
User Management Module (всё что касается пользователей)
Payment Processing Module (платежи и транзакции)
Analytics Module (метрики и отчёты)
Сервис — автономная единица бизнес-логики с чётко определённой ответственностью. Это как мини-приложение внутри большого приложения.
Примеры сервисов:
Order Service (управление заказами)
Inventory Service (управление товарами)
Billing Service (выставление счетов)
Хранилище данных — компонент, отвечающий за персистентность информации. Это как склад или архив компании.
Типы хранилищ:
Реляционные БД (PostgreSQL, MySQL)
NoSQL (MongoDB, Redis)
Файловые системы (S3, локальные диски)
Кэши (Redis, Memcached)
SLA — характеристики работы сервиса. Это контракт: "обещаю работать 99.9% времени и отвечать за 200ms".
Зачем нужны SLA:
Понимание ожиданий от системы
Планирование мощностей
Определение критичности сервисов
Основа для мониторинга
Практический пример: Сервис авторизации должен:
Отвечать за 100ms в 95% случаев
Быть доступным 99.95% времени
Выдерживать 1000 RPS
Чеклист для правильного проектирования: ✅ Каждый компонент имеет чёткую ответственность ✅ Интерфейсы документированы ✅ Связи (способы взаимодействия) определены ✅ Деление на сервисы произведено ✅ Способ хранения данных определен ✅ SLA определены и измеряемы ✅ Зависимости между компонентами минимальны
Помните: хорошая архитектура начинается с понимания базовых элементов. Без этого ваша система превратится в спагетти-код корпоративного масштаба.
Продолжаю по мере сил пополнять базу проекта NotCVE информацией о проблемах безопасности, которым разработчики не желают присваивать CVE (делал заметку об этом проекте). В этот раз одна проблема в компиляторе Go привела к регистрации сразу 2-х записей:
Т.к. помимо самого компилятора Go, пострадал и Kubernetes:
The Go team has released a fix in Go versions 1.21.11 and 1.22.4 addressing a symlink race condition when using os.RemoveAll. The Kubernetes Security Response Committee received a report that this issue could be abused in Kubernetes to delete arbitrary directories on a Node with root permissions by a local non-root user with the same UID as the user in a Pod.
Из сообщения в гитхабе Kubernetes видно насколько заразительна тенденция вместо регистрации CVE называть фикс проблемы безопасности хардерингом:
The Go team has not issued a CVE for this, as it is considered a hardening issue, and the SRC is following that decision as well.
Собственно, в случае с Docker в этом году было то же самое, для них это тоже хардеринг (моё обращение в MITRE так и не привело к появлению CVE, поэтому я зарегистрировал NotCVE-2025-001).
Как видно, ситуации, когда проблемы безопасности не приводят к появлению CVE случаются не редко. А некоторые разработчики даже пытаются оспаривать назначение CVE.
В обсуждениях тестирования микросервисов часто всплывает статья Мартина Фаулера Testing Strategies in a Microservice Architecture. Опубликованная в 2014 году, она опирается на концепцию тестовой пирамиды, сформулированную ещё в 2009-м. С тех пор ландшафт тестирования заметно изменился — в первую очередь за счёт появления и широкого распространения Docker и Testcontainers, которые существенно повлияли на практики и экономику тестирования.
Эта трансформация хорошо отражена в более современных источниках:
В контексте вашего проекта это означает, что использование интеграционных тестов в 2025 году оказывается существенно проще, дешевле и эффективнее, чем это предполагалось в рамках модели 2009 года.
Прошёл месяц с момента моего обращения в MITRE про нежелание разработчиков делать CVE из-за фикса в Docker Engine 28.0.0. От MITRE никаких новостей больше не было. Поэтому я обратился в NotCVE (об этом сервисе я делал заметку). Спустя буквально пару дней меня оповестили о создании идентификатора NotCVE-2025-0001. Проект NotCVE пока ещё мало известен. По этой причине по запросу "NotCVE-2025-0001" пока далеко не во всех поисковиках что-то можно найти (в Гугл нашёл 1 запись, в Яндексе и DuckDuckGo - ничего). Да и идентификаторов в NotCVE пока всего лишь 6. Очень надеюсь, что проект обретёт популярность и количество идентификаторов увеличится. И в первую очередь - из-за повышения осведомлённости об этом проекте и увеличении обращений (из-за нежелания разработчиков признавать проблему и создавать CVE). В данном случае показательно, что идентификатор NotCVE-2025-0001 завели по моему обращению несмотря на то, что проблему нашёл не я. Я просто не смог пройти мимо, увидев нежелание разработчиков регистрировать CVE.
ITFB Group совместно с BPMSoft приглашает на вебинар, посвященный теме организации правильной подготовки к выбору сложных ИТ-решений на примере CRM-платформы.
Вебинар будет полезен компаниям крупного бизнеса (включая Enterprise), планирующим внедрение с нуля или замену legacy-систем как в рамках импортозамещения, так и при смене самописных решений для широкого класса ИТ-систем, автоматизирующих различные бизнес-процессы (BPM, HRM, ATS, КЭДО, SRM, СЭД и др.)
Обсудим:
⏩ Как важно подготовиться к выбору сложных ИТ-решений для крупного бизнеса на примере выбора CRM-системы
⏩ Почему запросы предложений не содержат необходимой информации для проведения точной оценки стоимости внедрения
⏩ Как методология предпроектного обследования (ППО) от ITFB Group помогает создать качественный RFP (запросы предложения)
⏩ Кейсы: ППО незначительно увеличивает сроки и бюджет, но сильно снижает риски
⏩ Как при помощи ППО и гибкого лицензирования вендора можно снизить ТСО в проекте CRM
⏩ Применение ППО для выбора других сложных ИТ-систем (BPM, СЭД, SRM, HRM, ATS, КЭДО)
Спикеры: Николай Чекин — директор по развитию отношений с партнерами, ITFB Group Максим Илюхин — директор по продажам, BPMSoft
3 ключевые метрики, которые спасут микросервисный проект
Современные системы — это сложные экосистемы, где каждая ошибка может стоить бизнесу денег и репутации. Рассказываем, какие метрики нельзя игнорировать, чтобы не пропустить критичные сбои.
Инфраструктурные метрики
Базовые показатели вроде CPU и RAM уже не спасают. Для микросервисов важнее:
Статус подов в Kubernetes:
Количество рестартов.
Фейлы readiness/liveness проб.
Используйте метрику kube_pod_status_ready в Prometheus, чтобы находить «битые» поды.
Трассировка запросов: время выполнения каждого этапа через Jaeger.
Пример: Если поды перезапускаются чаще 5 раз в час — это сигнал к немедленной проверке.
Бизнес-метрики
Инфраструктура может быть идеальной, но если падает конверсия — бизнес теряет клиентов. Отслеживайте:
Конверсию платежей (например, от корзины к оплате).
Время обработки заказов.
Код для .NET-сервиса:
using App.Metrics;
public class PaymentService {
private readonly IMetrics _metrics;
public PaymentService(IMetrics metrics) => _metrics = metrics;
public void ProcessPayment() {
try {
// Логика платежа...
_metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);
}
catch {
_metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);
}
}
}
Эти метрики интегрируются в Grafana, чтобы вы видели, как каждая транзакция влияет на бизнес.
Пользовательский опыт
Даже 1 секунда задержки может увеличить отток пользователей на 7%. Контролируйте:
Почему классический мониторинг не работает для микросервисов и облаков? Переход к Observability
Современные системы давно перестали быть монолитами — теперь это сложные экосистемы из микросервисов, облачных сервисов и распределенных баз. Но если ваш мониторинг всё ещё фокусируется только на CPU и RAM, вы рискуете пропустить критические сбои.
Главные проблемы классического подхода:
Невидимые бизнес-сбои: Сервер «живой», но конверсия платежей падает.
Поиск иголки в стоге сена: При ошибке в цепочке из 10 микросервисов метрики инфраструктуры не укажут на источник проблемы.
Ручная настройка: Часы на алерты для каждого сервиса вместо автоматизации.
Решение — Observability:
Объедините метрики (Prometheus), логи (EFK) и трейсы (Jaeger), чтобы система сама «объясняла» свои сбои.
Пример кода
Отслеживание конверсии платежей в .NET-сервисе:
// Отслеживание конверсии платежей
using App.Metrics;
public class PaymentService
{
private readonly IMetrics _metrics;
public PaymentService(IMetrics metrics) => _metrics = metrics;
public void ProcessPayment()
{
try
{
// Логика обработки платежа...
_metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);
}
catch
{
_metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);
}
}
}
Код автоматически фиксирует успешные и неудачные платежи. Эти метрики интегрируются в Grafana для анализа бизнес-показателей.
Fix a security issue that was allowing remote hosts to connect directly to a container on its published ports. moby/moby#49325 Fix a security issue that was allowing neighbor hosts to connect to ports mapped on a loopback address. moby/moby#49325
В официальном блоге вышла статья с подробностями проблемы и возможными сценариями атак. Но, CVE заводить разработчики не захотели. Я не знаю какими принципами руководствовались разаботчики. По мне слова "Fix a security issue" тождественны созданию CVE. Я обратился в MITRE с описанием ситуации через эту форму (выбрал Request type - other). И получил такой ответ:
Thanks for the submission. We will treat this as a dispute/escalation request and reach out to Docker next. Hopefully that will spur them on to assign (it often does) but if not, we will take a look at assignment.
Once we hear back we'll let you know if they changed their mind and decided to assign or what the next steps will be.
Надеюсь, CVE заведут. Мне и моим коллегам по цеху по безопасности гораздо удобнее оценивать безопасность архитектуры, имея единый источник проблем безопасности (база CVE). А не рыскать по всему интернету, пытаясь собрать воедино информацию о проблемах безопасности конктерных продуктов, придумывая какие-то запросы, вовзращающие релевантную информацию. Даже если описание в самом CVE сухое - всегда проще искать подробности по уникальному идентификатору CVE, чем выдумывать разные запросы для каждого конктерного продукта.
К сожалению, нежелание признавать CVE со стороны различных разработчиков случается периодически. В моей практике была ситуация, когда разработчик не просто не хотел заводить CVE, а ещё и желал, чтоб я сам отозвал CVE. После моего отказа пытался CVE оспорить (но, неудачно). Подробности - в статье "Как я зарегистрировал CVE и разозлил вендора"
Приглашаю вас на весеннюю сессию вебинаров! Мы подготовили много экспертного контента и готовы поделиться с вами актуальной информацией о текущем состоянии и развитии рынка, а также современными подходами к защите веб-приложений и API.
Основные темы вебинаров:
• Защита веб-приложений (WAF)
• Защита интеграций между сервисами (API Security)
• Тренды развития рынка защиты веба
• Безопасная разработка
Для кого:
CISO
ИБ-специалисты
ИТ-специалисты
DevOps
Приготовьтесь к морю полезной информации, лучшим практикам и встрече с ведущими экспертами отрасли. Мы расставим все точки над «и».
Вы можете зарегистрироваться как на всю сессию сразу, так и на любой отдельный вебинар.
Вариант схемы взаимосвязей между элементами модели для технологического и физического слоев в версии Archimate 3.2
Хочу поделиться итогами последней моей переписки с ребятами из OpenGroup по поводу особенностей применения стандарта Archimate 3.2 для описания микросервисной архитектуры с использованием Docker.
Как оказалось, паттерн, который был предложен 4 года назад с применением элементов Node для моделирования docker-контейнеров после выхода версии стандарта 3.2 стал неактуален - поскольку Node потерял большинство типов связей, которые были для него допустимыми по отношению к Artifact. Спросите, почему этот вопрос встал только сейчас ? Потому что полностью стандарт 3.2 был поддержан в редакторе Archi относительно недавно... плюс как раз появилась необходимость в актуализации старых схем технологического слоя - и тут-то и выяснилось, что больше нельзя показать, что docker-контейнер (Node) реализуется посредством docker-образа (Artifact).
Резюмируя итоги обсуждения с коллегами из OpenGroup:
рекомендуется использовать для моделирования докер-контейнеров элемент Системное ПО (System Software), для которого по прежнему доступно установление связи Реализации от докер-образа (Artifact)
элемент Node остается как элемент для моделирования некоей условной совокупности программно-аппаратных средств (включая физические, "не-ИТ" объекты - т.е. станки и др) - цитирую Jean-Baptiste Sarrodie: "используем Node, чтобы показать что именно будет размещать или предоставлять сервисы, не обращая внимания на то как эта функция будет реализована (приложение, сервер, контейнер и т.д.)". Иначе говоря Node остается некоей логической структурой, объединяющей физические элементы (System Software, Device и др.).
элемент Device рекомендуется применять для моделирования не только физических, но и виртуальных машин (до этого были варианты использовать для "виртуалок" элемент Node) - но возможно в новой версии Archimate что-то уточнится
P.S.: почти месяц назад, 25 января, вышла версия Archi 5.5 - за это время удалось пощупать, и могу сказать, что обновляться стоит.
Из ощутимых улучшений:
возможность удалять на схеме элементы-контейнеры (стиль nested - когда элементы помещаются друг в друга) без удаления вложенных элементов (команда "Delete from view (keep children)" )
инструменты для фильтрации дерева (регулярные выражения, фиксация папок верхнего уровня, учет регистра текста, вовлечение пользовательских свойств элементов и видов) и навигации по нему (вкл/выкл режима синхронизации выбранного в схеме элемента с деревом)
Наша линейка продуктов ПроAPI, основанная на собственной концепции к управлению и защите API, уже успела себя хорошо зарекомендовать. Однако задача ИБ-специалистов – постоянно быть на шаг впереди злоумышленников. Сегодня у нас есть идеи, как усилить безопасность и противостоять новым вызовам, мы хотели бы узнать ваше мнение относительно их.
По ссылке ниже мы предлагаем пройти небольшой опрос, который займет не более 10 минут. https://t.me/wmx_xdrbot
Мы благодарны каждому, кто найдет время ответить на наши вопросы. В конце анкеты обязательно укажите, как с вами связаться, чтобы мы смогли отправить небольшой подарок.
Последний Go-митап в этом году: как Go меняет подходы к разработке и тестированию
Уже через несколько часов, в 19:00, начнется онлайн-трансляция финального в этом году Go-митапа, где разработчики и технические лидеры сообщества обсудят инструменты кодинга на Go. В мероприятии примут участие эксперты из YADRO, Wildberries, Weborama и Ви.Tech. Регистрируйтесь на онлайн-участие.
Программа:
Приветственное слово: Руслан Барсуков, ведущий инженер по разработке ПО в YADRO, и Виталий Левченко, технический менеджер в Wildberries, расскажут о планах Go-сообщества в Нижнем Новгороде.
«Генерация стабов для тестирования микросервисов по gRPC»
Кирилл Шувалов, разработчик дивизиона Телеком в YADRO, покажет, как с помощью Protoc стандартизировать тесты, упрощая их написание и повышая читаемость.
«Стриминг данных из Snowflake в Couchbase»
Александр Ванюшкин, разработчик в Weborama, поделится опытом создания плагина для Redpanda/Connect для оперативной обработки данных.
«Сборка проектов на Go: от Make до Mise»
Даниил Подольский, эксперт по разработке ПО в YADRO и один из лидеров внутреннего Go-сообщества, расскажет о развитии инструментов сборки и выборе оптимальных решений.
«Почему мы пилим монолит без микросервисов»
Кирилл Кузин, старший golang-разработчик, Ви.Tech, объяснит, как команда поддерживает сложную архитектуру и избегает ошибок при распиле монолита.
Кто и как создаёт архитектуру программного обеспечения, какими навыками должен обладать такой специалист и каковы его карьерные перспективы? Чему учиться и как развиваться мидлам и синьорам, чтобы начать работать с архитектурой?
Некоторые контейнеры (docker, например) могут внутри себя использовать iptables. Это означает, что и port knocking можно реализовать прямо в контейнере. Популярные вопросы: зачем нужен port knocking и какой смысл делать его в контейнере? Port knocking может снизить обнаружение сервиса (вместо попыток бороться с последствиями, когда сервис уже обнаружен: брутфорс, эксплуатация уязвимости). В случаях, когда нельзя использовать ACL. Особенно актуально в условиях, когда компании не успевают оперативно устранять уязвимости. В контейнере эта мера может быть полезной как подстраховка: если firewall (на хостовой системе или роутере) внезапно ослабнут правила защиты. Также это поможет разгрузить правила firewall хостовой системы. Безусловно, port knocking, как и любая технология, не является "серебряной пулей". И в общем смысле не является заменителем какой-то другой. Но, используя port knocking совместно с другими решениями, можно существенно повысить безопасность сервисов. Внедрение данной защиты также потенциально увеличит доступное время для устранения уязвимости (пока её не начнут пытаться эксплуатировать на защищаемом сервисе). Использование port knocking также приводит к уменьшению логов. А, значит, логи проще обрабатывать. Кроме того, эта мера поможет решить проблему безопасности: доступности портов контейнеров NotCVE-2025-0001 (если используется docker версии ниже 28). О проблемах на практике при внедрении port knocking, вариантах решения самых частых проблем и нюансах использования в docker контейнерах рассказано в этой статье. Сам скрипт для использования port knocking в docker контейнере тут.
Поговорим снова о микросервисах. Я уже писал, почему не стоит делать слишком мелкие микросервисы https://t.me/javaKotlinDevOps/305 (блог в телеге я стал вести сильно раньше, чем на Хабре) Но встает закономерный вопрос - "сколько вешать в граммах", в смысле - а какого размера должны быть микросервисы? Обозначим нижний и верхний предел, а для этого придется вспомнить DDD.
Для начала рассмотрим понятие ограниченного контекста (bounded context). Это связанный набор сущностей из реального мира, для наименования которых используется "единый язык" (ubiquitous language) - непротиворечивый набор терминов. Эти сущности описываются в аналитике, тест-кейсах и превращаются в классы в нашем сервисе и в таблицы в БД. Контекстом как правило занимается одна команда - так проще всего поддерживать "единый язык". И за микросервис тоже должна отвечать одна команда. Т.е. ограниченный контекст - это отличный кандидат на микросервис. Но при этом у одной команды может быть несколько микросервисов. И контекст может быть достаточно большим. Т.е. у нас есть верхняя граница микросервиса.
Теперь рассмотрим понятие агрегата - группу сущностей, имеющую уникальный идентификатор, изменение которой производится атомарно. Т.е. агрегат - граница транзакции в БД. А т.к. возможность делегировать управление транзакцией СУБД - это очень крутая штука, то разделять агрегат между разными БД не стоит. При этом один микросервис = одна БД. Поэтому агрегат - нижняя граница микросервиса.
Паттерн Saga используется в микросервисной архитектуре для управления распределенными транзакциями. В отличие от монолитных приложений, где транзакции происходят в одной базе данных, в микросервисах транзакции охватывают несколько сервисов, что требует особого подхода для сохранения целостности данных.
Например, вы разработали систему для покупки билета на самолет. В нем три сервиса: оплата, уведомление, бронирование. Сервис успешно списал деньги, выслал уведомление о покупке, но возникла ошибка на этапе бронирования. Как откатить изменения, когда у нас три независимых сервиса? В монолитном приложении нас бы спасли транзакции ACID. А в случае с микросервисами — Saga.
Принципы работы Saga:
Разбиение на шаги: Saga состоит из шагов (транзакций) в каждом микросервисе, таких как списание средств и бронирование.
Компенсирующие транзакции: если один шаг не удался, запускаются компенсирующие действия для отмены изменений предыдущих шагов.
Асинхронное выполнение: шаги могут выполняться асинхронно, а при ошибке запускаются компенсирующие транзакции.
Стратегии реализации:
Оркестрация: один сервис или оркестратор управляет всем Saga, что упрощает реализацию, но создает единую точку отказа.
Хореография: каждый микросервис сам управляет своими транзакциями и компенсирующими действиями, что делает систему более децентрализованной, но усложняет управление.
Мы расширили линейку IaaS-, PaaS- и SaaS‑решений и запустили новое — Kubernetes as a Service (KaaS).
Сегодня 30 % заказчиков облачной платформы Рег.ру предпочитают разрабатывать клиентские приложения на базе микросервисной инфраструктуры с применением технологии оркестрации контейнеров Kubernetes.
Kubernetes считается наиболее популярным и удобным инструментом для управления контейнерами, хотя его самостоятельное развертывание занимает в среднем от нескольких часов до нескольких дней. Услуга Kubernetes as a Service поможет сократить этот этап до 5–10 минут и снизить количество рутинных процессов при обслуживании ИТ-инфраструктуры.
В рамках KaaS можно создать несколько кластеров и учесть различные конфигурации. Для каждого кластера доступен выбор типа: распределенного или нераспределенного. В каждом из кластеров можно создать до десяти групп воркеров и выбрать подходящий тариф и объем. Первоначальная установка, настройка и круглосуточная техническая поддержка останется на стороне Рег.ру.
Кстати, сервис KaaS уже используется нашими разработчиками для решения корпоративных задач и показывает отличные результаты.
Меня зовут Дмитрий. В ИТ я сравнительно недавно, всего 25 лет, из которых последние 22 в банковском секторе (ЦБ, ВТБ, Банк ДОМ.РФ). И за это время я стал смотреть по-другому на многие привычные вещи.
Вот недавно я подумал, что русская народная сказка про царевну-лягушку, это не только про неё. Вы помните: "... нелегко с Кощеем сладить: его смерть ☠️ на конце иглы, та игла в яйце 🥚, яйцо в утке 🦆, утка в зайце 🐇, тот заяц сидит в каменном сундуке 🗃️, а сундук стоит на высоком дубу 🌳, и тот дуб Кощей Бессмертный, как свой глаз, бережёт...". Будто бы это не и сказка вовсе, а лаконичное описание архитектуры развертывания. Словно «игла» это приложение 🤖, со встроенной killer-feature, при падении которой происходит необратимое последствие - смерть Кощея. Если перевести на бизнесовый - уход ключевого клиента.
А сколько такого в жизни! И Кощей был побеждён лишь потому, что с гео-распределённым решением заморачиваться не стал, или не смог. 🙈 То есть, в переводе на ИТ-шный, намек этой сказки может выглядеть так: хотите чтобы Ваши сервисы жили вечно - не поступайтесь вопросами надежности ИТ архитектуры. 🏛️
Сказка - ложь, да в ней намёк, ИТ директору урок!
А раньше эта сказка мне казалась просто сказкой ... ☀️
Задача обеспечения безопасности REST API может быть менее очевидной, но важно помнить, что REST API используется везде, где пользователю сайта или приложения нужно предоставить данные с сервера.
Приглашаю на вебинар 30 мая в 12:00, посвященный превентивной защите REST API.
Ведущие вебинара — Вадим Шепелев, инженер по информационной безопасности Вебмониторэкс и Лев Палей, CISO Вебмониторэкс.
О чем расскажем на вебинаре:
Польза от спецификации API и как её собрать на основании трафика
Какие типы уязвимостей это позволит обнаружить
Как уменьшить поверхность атаки при помощи «ПроAPI Защита»
В наше время все больше компаний предоставляют свои возможности через API. Задача обеспечения безопасности REST API может быть менее очевидной, но важно помнить, что REST API используется везде, где пользователю сайта или приложения нужно предоставить данные с сервера.
Компания Вебмониторэкс приглашает на вебинар 30 мая в 12:00, посвященный превентивной защите REST API.
Ведущие вебинара — Вадим Шепелев, инженер по информационной безопасности Вебмониторэкс и Лев Палей, CISO Вебмониторэкс.
О чем расскажем на вебинаре:
Польза от спецификации API и как её собрать на основании трафика
Какие типы уязвимостей это позволит обнаружить
Как уменьшить поверхность атаки при помощи «ПроAPI Защита»
Кому полезно:
Специалистам, участвующим в разработке критичных для бизнеса веб-приложений
Руководителям подразделений по информационной безопасности
Специалистам Application Security
Почему полезно:
Актуальная проблема защиты REST API обусловлена участившимися атаками на веб-ресурсы российских компаний
Найти все API — важная задача в процессе выстраивания их успешной защиты. Поэтому, имея сведения о структуре своих API, вы уже окажетесь на шаг впереди злоумышленников. А что делать с этой информацией?
Компания Вебмониторэкс ответит на этот и другие вопросы на своем вебинаре 16 мая. Теорию подкрепит практический кейс заказчика.
О чем расскажем на вебинаре:
- На что обратить внимание при обеспечении безопасности API в современных условиях. - Изменения в инфраструктуре. Что дальше? - Защита и управление API. Почему это важно. - Подходы по защите API. От зрелости к эффективности: Знать. Защищать. Не допускать. - Реализация на платформе «Вебмониторэкс»: компоненты для защиты и управления API.
Ведущий вебинара — Лев Палей, CISO Вебмониторэкс. Специальный гость — Кирилл Ильин, CISO «СберАвто». Он честно и открыто расскажет о задачах, практике и результатах защиты API в своей компании.
Кому полезно:
- Специалистам, участвующим в разработке критичных для бизнеса веб-приложений - Руководителям подразделений по информационной безопасности - Специалистам Application Security
Почему полезно:
- Узнаете о современной концепции управления API - Увидите пример ее реализации на платформе «Вебмониторэкс» - Услышите от CISO об успешном опыте защиты и управления API на примере компании «СберАвто»
Из опыта я глубоко убеждён, что в 99% случаем начинать создание новой системы лучше с монолита. Особенно если это абсолютно новый продукт, которому только предстоит выйти на рынок.
При работе с монолитом система эволюционирует. Изначально ваш проект будет не очень большим и сложным, поэтому он будет быстро расти и развиваться. В какой-то момент вы придёте в стадию, где писать проект уже сложно и он не справляется с нагрузкой. Это очень хороший знак, потому что он говорит, что продукт востребован и им пользуются.
Главное - чтобы не получилось так
В такой ситуации вы начнёте спокойно делить монолит на микросервисы. Выделите связанные контексты, начнёте вынос кода и миграцию баз данных. Это стандартная история IT-мира. У нас был монолит, но мы выросли и мигрировали на микросервисы.
Такой подход позволяет сохранить естественный порядок вещей: сложное вырастает из простого путём эволюции (а порой и революции). Обычно такие системы лучше продуманы и более устойчивы к изменениям, а у компании достаточно денег на техническое и инфраструктурное обеспечение.
Начинать с микросервисов - это гораздо больший риск. Если вы делаете стартап, то у вас вряд ли будет возможность адекватно разделить границы микросервисов. Вам придётся либо постоянно переделывать кучу микросервисов, либо делать распределённый монолит с большим количеством межсервисных взаимодействий и низкой надёжностью.
Вебмониторэкс приглашает вас 17 апреля в 12:00 (мск) на вебинар, во время которого мы раскроем тему значимости обеспечения безопасности API в современных условиях.
Ведущие вебинара - Лев Палей, CISO и Сергей Одинцов, системный аналитик Вебмониторэкс.
Расскажем об изменении ландшафта угроз и отражении этих изменений в OWASP API Security. Подробно рассмотрим обеспечение безопасности веб-приложений в наиболее атакуемых отраслях (телекоммуникационные компании и интернет платформы). Покажем, как платформа «Вебмониторэкс» решает задачи по защите веб-приложений и API.
Почему полезно: - Узнаете о новых уязвимостях в OWASP API Security и вариантах их эксплуатации - Получите рекомендации по защите своих API - Увидите примеры, иллюстрирующие изменения OWASP API Security
Продолжительность вебинара 1 час 30 минут! Регистрируйтесь на вебинар по ссылке.
