Приглашаем на Cinimex DEV meetup: ИТ-событие для разработчиков (офлайн/онлайн)

Начало митапа: 19 октября в 19.00

Встречаемся: 19 октября в 18.00 на площадке LOFT idealista

Регистация: выбирайте удобный формат участия (офлайн/онлайн)

19.00 - 19.05 - Приветственное слово

19.05 - 19.45 - Разработка программ устойчивых к багам

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

19.45 — 20.25 — Верните мне мой монолит. От монолита к микросервисной архитектуре и обратно.

Можно ли со стопроцентной уверенностью сказать, что эра монолитов закончилась? Не думаю, пик хайпа и популярности микросервисов все еще очень высок, иногда это превращается даже в карго культ. Индустрия сейчас испытывает слепую веру в микросервисы. Мы все еще видим и читаем по нескольку раз в неделю посты в популярных блогах о том, что кто-то «распилил« свой монолит на 100500 микросервисов, однако есть и исключения из правил. Мы даже наблюдали несколько громких случаев миграций от микросервисов обратно к монолиту (например, некоторые сервисы Amazon, такие как Prime Video). При переходе от одного большого приложения к нескольким сервисам меньшего размера вам придется решать множество новых проблем — о них я и хотел поговорить в своём докладе. Какие »оверхеды» с точки зрения производительности и трудозатрат приносит микросервисная архитектура? Стоит ли делать однозначный выбор в пользу микросервисной архитектуры на новых проектах?

20.40 — 21.20 — Kafka и Transactional Outbox. Есть ли альтернативы?

Есть стандартная задача: сохранять изменения в БД и отправлять об этом сообщение в Кафку. Причём хочется, чтобы было честно: успешно отправили и успешно сохранили, либо же — ничего не отправили и ничего не сохранили. Во всех учебниках предлагают использовать паттерн Transactional Outbox. Но так ли он хорош? Есть ли альтернативы? И что лучше? Обо всём этом поговорим на митапе.