На десятом митапе Software Craftsmanship мы рассмотрим такую сложную тему, как распределенные транзакции. Мы увидим, почему возникает необходимость в распределенных транзакциях и какие бывают протоколы для реализации распределенных транзакций.
Микросервисная архитектура часто влечет за собой распределенные транзакции, и поэтому мы поговорим о том, как можно делать отдельные микросервисы максимально независимыми между собой.
Распределенные транзакции сложны эксплуатации, поэтому мы рассмотрим также и подходы, которые позволяют минимизировать или обойти необходимость в них, в то же время сохраняя необходимые бизнесу свойства приложения.
Software craftsmanship фиксит проблемы AgilePavel Veinik
На 6м митапе мы подойдем к проблеме говна со стороны команды и процессов, а не со стороны технологий и архитектуры, и рассмотрим поближе, чем и как нам могут помочь принципы Software Craftsmanship. Мы увидим, что суть всех процессов - это коммуникации, а суть коммуникации - это настроенные каналы передачи информации. Мы рассмотрим, как настраивать эти каналы передачи информации, и увидим, что процессы - это отношения между людьми, прописанные на бумаге.
Software craftsmanship meetup 21: CQRS что такое и для чего Pavel Veinik
Мы рассмотрим что такое CQRS, какие проблемы он может решить и какие проблемы создать, а также сопутствующие подходы и приемы, такие как event sourcing, предагрегация данных для чтения, использование in memory баз данных. Также разберем ситуации, в которых выгодно использовать CQRS, и назовем несколько систем, в которых он используется.
Также разберем вопросы data consistency в CQRS-архитектурах, и другие возникающие проблемы.
Software craftsmanship фиксит проблемы AgilePavel Veinik
На 6м митапе мы подойдем к проблеме говна со стороны команды и процессов, а не со стороны технологий и архитектуры, и рассмотрим поближе, чем и как нам могут помочь принципы Software Craftsmanship. Мы увидим, что суть всех процессов - это коммуникации, а суть коммуникации - это настроенные каналы передачи информации. Мы рассмотрим, как настраивать эти каналы передачи информации, и увидим, что процессы - это отношения между людьми, прописанные на бумаге.
Software craftsmanship meetup 21: CQRS что такое и для чего Pavel Veinik
Мы рассмотрим что такое CQRS, какие проблемы он может решить и какие проблемы создать, а также сопутствующие подходы и приемы, такие как event sourcing, предагрегация данных для чтения, использование in memory баз данных. Также разберем ситуации, в которых выгодно использовать CQRS, и назовем несколько систем, в которых он используется.
Также разберем вопросы data consistency в CQRS-архитектурах, и другие возникающие проблемы.
Software craftsmanship 16: online building ml pipelinePavel Veinik
16й митап Software Craftsmanship пройдет онлайн и будет посвящен построению ML pipeline с точки зрения инженера-разработчика.
В последние год-два все чаще появляются вакансии, в которых инженеру необходимо выстроить ML pipeline. Такие вакансии получают название ML Ops.
В ML pipeline входят такие вещи, как построение моделей, хранение, сравнение качества моделей, поддержание версионность моделей, работа с feature storage, и само собой разумеется, применение модели в prod.
Модель обычно оформляется как микросервис, который можно просто разворачивать, масштабировать и поддерживать.
При этом, как правило, другими членами команды оказываются data scientists или ML engineers, которые сильны в своих областях, но не могут сделать простой масштабируемый REST API для своей модели. В рамках совместной работы с ними и приходится реализовывать ML pipeline.
На митапе мы коснемся того, для чего необходим ML pipeline, из каких шагов он состоит, и каким образом организована работа инженера в ML команде.
Про качество и красоту кода говорят и пишут очень многие, хотя при этом довольно часто забывают, для чего существует это качество и эта красота.
Двадцать второй онлайн митап Software Craftsmanship будет посвящен Engineering Excellence. мы рассмотрим что такое Engineering Excellence, кому и для чего оно нужно на проекте, из каких частей состоит и как определить что нужно конкретному проекту.
На митапе мы рассмотрим взаимосвязь разработчиков, тестировщиков, девопсов, разберем метрики, практики и процессы необходимы для постоянного улучшения проекта.
Подход и инструменты измерения эффективности процесса разработки или как держ...HOWWEDOIT
— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
DevOps Fest 2020. Максим Безуглый. DevOps - как архитектура в процессе. Две к...DevOps_Fest
Сотни вопросов о структуре и процессах, которые ставят и решают архитекторы и практики DevOps на примере решений в своем проекте.
Взаимоопределяющие вопросы архитектуры, DevOps, бизнеса и разработки.
Взрыв сложности - представьте, что вместо простого gmail подобного почтового SPA вам нужно построить и развивать новый sendmail на сервере + thunderbird для клиентов (desktop, мобильную и веб версию) по SAAS multi tenant модели.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Дмитрий Грибов, Трава и грибы как средства управления разработкойScrumTrek
Управление разработкой в ЛитРес: Игровые грибы на службе управления проектами Холакратия, настоенная на травах Деревянный Agile Спринты длинною в час и ежедневный релиз Рыночная игра как альтернатива микроменеджменту KPI для разработчиков, основанный на реальных результатах (сдельная оплата программистам в штате) История о том, как команда из 27-и человек эффективно поддерживает и развивать сервис с миллиардной выручкой
Software craftsmanship meetup 20. транзакции и data constistency в микросерви...Pavel Veinik
Рассмотрим обеспечение транзакционности в микросервисах, от “транзакционной” отправки сообщений до “транзакционного” обновления данных в нескольких микросервисах. Рассмотрим и соответствующие типовые решения - шаблон Transactional outbox, двухфазные транзакции, а также шаблон Saga вместе с компенсирующими транзакциями.
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Сегодня очень часто можно услышать множество модный словечек, но даже среди них девопс и микросервисы будоражат умы людей как то по особенному.
Для обычного инженера DevOps и Микросервисы – это всего лишь маркетинговая профанация. Куда важнее “держать DevOps в своих руках” и уметь им пользоваться. Хочется понять где заканчиваются наши и чужие фантазии, где начинаются реально полезные практики, какие инструменты нам помогут и какие фундаментальные принципы помогут увеличить профит от используемых практик и инструментов.
Доклад в первую очередь про внедрение различных технологий, инструментов и методологий в большой организации. Поделюсь проблемами с которыми мы столкнулись при внедрении различных принципов и технологий, расскажу о решениях и выработанных принципах масштабирования процессов/инструментов.
Сегодня наш лозунг будет “DevOps в руках а не в головах”. Но то что в головах всё же важно, хоть это и совсем другая история.
Kubernetes is not needed to 90 percents of the companies.rusIvan Glushkov
Эйфория и хайп вокруг Kubernetes не дают всем компаниям возможности трезво взглянуть на сложности, проблемы и риски процесса перехода на Kubernetes.
Я попробую остудить пыл самых смелых и наивных, и показать, что этот путь очень тернист и опасен:
рассмотрю список стандартных проблем,
покажу, на что следует обратить внимание при планировании перехода,
и посоветую "ничего не трогать, пока работает".
Стандартно, банально, но может сэкономить вам массу нервов и денег.
Алексей Рагозин "Java и linux борьба за микросекунды"IT Event
Java используется для широкого спектра приложений, некоторые из них могут иметь жёсткие требования по времени отклика.
Но если речь идёт про сотни микросекунд, годится ли Java, в принципе, для таких задач?
Доклад осветит практические аспекты разработки решений с малым временем отклика на платформе Java + Linux
Software craftsmanship 16: online building ml pipelinePavel Veinik
16й митап Software Craftsmanship пройдет онлайн и будет посвящен построению ML pipeline с точки зрения инженера-разработчика.
В последние год-два все чаще появляются вакансии, в которых инженеру необходимо выстроить ML pipeline. Такие вакансии получают название ML Ops.
В ML pipeline входят такие вещи, как построение моделей, хранение, сравнение качества моделей, поддержание версионность моделей, работа с feature storage, и само собой разумеется, применение модели в prod.
Модель обычно оформляется как микросервис, который можно просто разворачивать, масштабировать и поддерживать.
При этом, как правило, другими членами команды оказываются data scientists или ML engineers, которые сильны в своих областях, но не могут сделать простой масштабируемый REST API для своей модели. В рамках совместной работы с ними и приходится реализовывать ML pipeline.
На митапе мы коснемся того, для чего необходим ML pipeline, из каких шагов он состоит, и каким образом организована работа инженера в ML команде.
Про качество и красоту кода говорят и пишут очень многие, хотя при этом довольно часто забывают, для чего существует это качество и эта красота.
Двадцать второй онлайн митап Software Craftsmanship будет посвящен Engineering Excellence. мы рассмотрим что такое Engineering Excellence, кому и для чего оно нужно на проекте, из каких частей состоит и как определить что нужно конкретному проекту.
На митапе мы рассмотрим взаимосвязь разработчиков, тестировщиков, девопсов, разберем метрики, практики и процессы необходимы для постоянного улучшения проекта.
Подход и инструменты измерения эффективности процесса разработки или как держ...HOWWEDOIT
— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
DevOps Fest 2020. Максим Безуглый. DevOps - как архитектура в процессе. Две к...DevOps_Fest
Сотни вопросов о структуре и процессах, которые ставят и решают архитекторы и практики DevOps на примере решений в своем проекте.
Взаимоопределяющие вопросы архитектуры, DevOps, бизнеса и разработки.
Взрыв сложности - представьте, что вместо простого gmail подобного почтового SPA вам нужно построить и развивать новый sendmail на сервере + thunderbird для клиентов (desktop, мобильную и веб версию) по SAAS multi tenant модели.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Дмитрий Грибов, Трава и грибы как средства управления разработкойScrumTrek
Управление разработкой в ЛитРес: Игровые грибы на службе управления проектами Холакратия, настоенная на травах Деревянный Agile Спринты длинною в час и ежедневный релиз Рыночная игра как альтернатива микроменеджменту KPI для разработчиков, основанный на реальных результатах (сдельная оплата программистам в штате) История о том, как команда из 27-и человек эффективно поддерживает и развивать сервис с миллиардной выручкой
Software craftsmanship meetup 20. транзакции и data constistency в микросерви...Pavel Veinik
Рассмотрим обеспечение транзакционности в микросервисах, от “транзакционной” отправки сообщений до “транзакционного” обновления данных в нескольких микросервисах. Рассмотрим и соответствующие типовые решения - шаблон Transactional outbox, двухфазные транзакции, а также шаблон Saga вместе с компенсирующими транзакциями.
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Сегодня очень часто можно услышать множество модный словечек, но даже среди них девопс и микросервисы будоражат умы людей как то по особенному.
Для обычного инженера DevOps и Микросервисы – это всего лишь маркетинговая профанация. Куда важнее “держать DevOps в своих руках” и уметь им пользоваться. Хочется понять где заканчиваются наши и чужие фантазии, где начинаются реально полезные практики, какие инструменты нам помогут и какие фундаментальные принципы помогут увеличить профит от используемых практик и инструментов.
Доклад в первую очередь про внедрение различных технологий, инструментов и методологий в большой организации. Поделюсь проблемами с которыми мы столкнулись при внедрении различных принципов и технологий, расскажу о решениях и выработанных принципах масштабирования процессов/инструментов.
Сегодня наш лозунг будет “DevOps в руках а не в головах”. Но то что в головах всё же важно, хоть это и совсем другая история.
Kubernetes is not needed to 90 percents of the companies.rusIvan Glushkov
Эйфория и хайп вокруг Kubernetes не дают всем компаниям возможности трезво взглянуть на сложности, проблемы и риски процесса перехода на Kubernetes.
Я попробую остудить пыл самых смелых и наивных, и показать, что этот путь очень тернист и опасен:
рассмотрю список стандартных проблем,
покажу, на что следует обратить внимание при планировании перехода,
и посоветую "ничего не трогать, пока работает".
Стандартно, банально, но может сэкономить вам массу нервов и денег.
Алексей Рагозин "Java и linux борьба за микросекунды"IT Event
Java используется для широкого спектра приложений, некоторые из них могут иметь жёсткие требования по времени отклика.
Но если речь идёт про сотни микросекунд, годится ли Java, в принципе, для таких задач?
Доклад осветит практические аспекты разработки решений с малым временем отклика на платформе Java + Linux
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)Ontico
NodeJS — достаточно молодой фреймворк, и пока не каждый решается использовать его в продакшене, а тем более в highload.
В течение последнего года мы разрабатывали проект DMP (Data Management Platform), используя NodeJS для прототипирования. На данный момент проект в большей степени все еще остался на JS и без труда справляется с текущими нагрузками в 10 000 запросов в секунду.
В докладе я расскажу, почему остановились именно на NodeJS и совсем не жалеем об этом.
К сожалению, никакое дело не обходится без граблей и костылей. Я расскажу обо всех встретившихся проблемах и уделю особое внимание проблемам со спагетти-кодом, утечками и нехваткой памяти. Как мы убили немало времени, тщетно ища источник проблем, и какие правила мы составили для себя на будущее, чтобы не повторить своих ошибок.
Расскажу немного о применении микросервисов для решения проблемы спагетти-кода.
И, как итог, опишу ряд рекомендаций, которые помогут избежать большой траты времени при использовании NodeJS.
Панаскин Денис: Архитектура для Internet of Things проектов с учетом расходов...DevPoint Kyiv
- Немного про Big Data “Zoo”;
- Что такое лямбда архитектура?
- Имплементация: Apache Kafka, Apache Spark, Cassandra;
- Не очевидные плюсы и явные минусы лямбда архитектуры;
- Незабываем про микросервисы;
- Что делать когда все дорого? Как минимизировать расходы на Minimum Viable Product (MVP)
самое интересное в мире блокчейн, опыт и рецепты от сбербанкаСбертех | SberTech
6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.
какие бывают типы микросервисных архитектур (распределенный монолит, слои микросервисов, feature-based микросервисы) и как именно микросервисы взаимодействуют друг с другом в рамках того или иного типа.
Разработка портируемой инфраструктуры New Relic — контейнеры, CoreOS и прочие...Ontico
HighLoad++ 2017
Зал «Кейптаун», 7 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/2897.html
Нашей группе было поручено создать новый самостоятельный “регион” для всех продуктов New Relic, предназначенный для обслуживания европейских клиентов, подпадающих под ограничения GDPR. Здесь следует отметить, что так как наша компания предоставляла свои услуги исключительно через “облако” (SaaS), то хорошо выработанных процессов для настройки всей инфраструктуры “с нуля” у нас не было.
...
Эволюция корпоративных Web приложений. Молотков Андрей D2D Just.NETDev2Dev
Для многих enterprise-разработка ассоциируется с бесконечным унаследованным кодом, устаревшими технологиями и неповоротливыми монолитами. Использование подходов построения сервис-ориентированной архитектуры может существенно улучшить ситуацию. Мы пишем небольшие приложения с чёткой зоной ответственности и покрытием модульными тестами, используем современные протоколы OData и OAuth, а legacy-приложения развиваем подключением повторно используемых модулей. В своем докладе я расскажу о том, чего удалось добиться за последние пару лет, какие роли мы выделили и с какими сложностями столкнулись.
Максим Барышников, Что такое типовые проблемы нагруженных проектов и как их р...Tanya Denisyuk
Расскажу, какие подходы и инструменты практически применяются в Wargaming при обработке данных в гигантской, без преувеличений, системе. Частичный список затрагиваемых вопросов
NoSQL versus/with RDBMS или каждый инструмент на своем месте
Синхронные и асинхронные подходы к построению систем: почему асинхронные системы не могут быть быстрее синхронных, но асинхронность, тем не менее, очень полезна
API и интерфейсы — важная составляющая хорошо спроектированной системы
Performance vs Scalability
Мониторинг и профилирование
Евгений Лазин. Неизменяемая структура данных HAMT для создания БД в памятиFProg
В данном докладе рассматривается пример использования персистентной структуры данных - функциональной версии HAMT, для создания main memory базы данных. Данная реализация HAMT располагается в shared memory и используется для хранения индексов.
Рассматриваются задачи, которые были быстро и эффективно решены благодаря использованию неизменяемых структур данных (управление изменениями, поддержка ACID-свойств), а также проблемы, возникшие из-за этого. Также, рассмотрен метод реализации персистентного графа, использующий изменяемые данные и позволяющий достичь большей производительности, по сравнению с аналогичной, неизменяемой структурой данных.
Чему мы научились, разрабатывая микросервисы / Вадим Мадисон (RuTube)Ontico
Начав разработку нового продукта через микросервисы, мы неожиданно для себя обнаружили, что микросервисы — это не просто "вместо одного большого приложения теперь пишем много маленьких". При разработке большой системы она сама собой через какое-то время становится набором отдельных сервисов, которые должны взаимодействовать между собой, поэтому стабильная работа сервисов и их взаимодействие не стало чем-то новым. Неожиданностью стало то, что система стала значительно более динамической, она стала постоянно изменяться отдельными небольшими частями, сервисы стали часто перезапускаться, а количество запущенных нод сервисов стало расти по экспоненте.
Очень быстро стал актуальным вопрос конфигурирования — если раньше, выкатив новую версию монолита с единым конфигом, мы применяли правки на всю систему сразу, то с микросервисами все сложнее — пара сотен работающих нод и всем нужно применить изменения. Требования к деплою также поменялись — он стал частью процесса разработки, а тестирование стало частью деплоя. Количество необходимого ПО для функционирования системы также стало некоторым сюрпризом.
В докладе я расскажу о том, как в итоге это работает у нас, как мы решили такие вопросы как:
- конфигурирование сервисов;
- интеграция между собой;
- тестирование;
- версионирование;
- масштабирование.
Расскажу, какие тулзы мы в итоге используем, а от каких отказались.
Чему мы научились разрабатывая микросервисы?Vadim Madison
Доклад с конференции Backend Conf 2016
Начав разработку нового продукта через микросервисы, мы неожиданно для себя обнаружили, что микросервисы — это не просто "вместо одного большого приложения теперь пишем много маленьких". При разработке большой системы она сама собой через какое-то время становится набором отдельных сервисов, которые должны взаимодействовать между собой, поэтому стабильная работа сервисов и их взаимодействие не стало чем-то новым. Неожиданностью стало то, что система стала значительно более динамической, она стала постоянно изменяться отдельными небольшими частями, сервисы стали часто перезапускаться, а количество запущенных нод сервисов стало расти по экспоненте.
Очень быстро стал актуальным вопрос конфигурирования — если раньше, выкатив новую версию монолита с единым конфигом, мы применяли правки на всю систему сразу, то с микросервисами все сложнее — пара сотен работающих нод и всем нужно применить изменения. Требования к деплою также поменялись — он стал частью процесса разработки, а тестирование стало частью деплоя. Количество необходимого ПО для функционирования системы также стало некоторым сюрпризом.
В докладе я расскажу о том, как в итоге это работает у нас, как мы решили такие вопросы как:
- конфигурирование сервисов;
- интеграция между собой;
- тестирование;
- версионирование;
- масштабирование.
Расскажу, какие тулзы мы в итоге используем, а от каких отказались.
СИ — это способ построить успешную систему и объединить всех людей на проекте в одно целое для продуктивного решения задачи любой сложности. Это неотъемлемая часть грамотного руководства проектом, именно поэтому по статистике зарплаты системных инженеров самые высокие в любой отрасли и IT не является исключением.
Software craftsmanship 15 online: Reliability and ResiliencyPavel Veinik
Мы возобновляем после перерыва митапы Software Craftsmanship, и наш пятнадцатый митап будет посвящен надежности и устойчивости систем. Мы разберем stability, reliability, fault-tolerance, availability, resilience, узнаем как они связаны друг с другом и как можно их измерять, а также как разрабатывать устойчивые и надежные программы.
Также мы сформулируем принципы создания надежных систем, паттерны и антипаттерны надежности и устойчивости, отдельное внимание уделим устойчивости микросервисов в облаке.
План митапа:
Stability, reliability, fault-tolerance, availability, resilience, их связь и отличия
Архитектура и шаблоны availability
Шаблоны resilience
Техники fault tolerance
Устойчивости и надежность в облаке
Software craftsmanship 14 online Splitting the MonolithPavel Veinik
Каждый развивающий бизнес на определенном этапе своего жизненного цикла сталкивается с задачей масштабирования. Для монолитного приложения эта задача может оказаться сложнее, чем написать с нуля масштабируемую систему - потому что нужно учитывать миграцию данных и пользователей, а также недостаточные ресурсы.
Мы попытаемся понять, в каких случаях монолит распиливать стоит, а когда можно применить более простые подходы. Рассмотрим преимущества и недостатки монолитной архитектуры и микросервисной. Разберем несколько стратегий распиливания монолита, а также аспекты, которые необходимо учесть во время этого процесса.
Двенадцатый митап Software Craftsmanship пройдет онлайн и будет посвящен высоконагруженным системам. Мы систематизирует инструменты, применяемые для разработки архитектуры высоконагруженных приложений, опишем базовый алгоритм из 6 шагов проектирования нагруженной системы.
Также мы рассмотрим 3 примера нагруженных приложений - клиент для участия в Real Time Bidding аукционах, поисковик вместе с краулером для него, чат.
Мы коснемся опасностей, которые подстерегают новичков и опытных архитекторов.
Кроме того, рассмотрим подходы к построению высоконагруженных систем в стартапе и в сервисной компании.
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Программирование и лингвистика: как понять язык и извлечь знания из текстовPavel Veinik
Knowledge extraction с помощью open source java технологий - что это такое, как, и для чего? На примере реального проекта докладчик расскажет о том, как создать систему извлечения знаний и как с ее помощью получать полный и минимальный обзор событий в интересующих областях.
Человеческий фактор в разработке, или ORM на noSql через JPA.Pavel Veinik
Зачем переводить работающий проект с RDBMS на noSql? Как это сделать, и как это нельзя делать? Что важнее для успеха пректа - технологическое преимущество или доверительные отношения в команде? Какова роль процесса в успехе проекта и что бывает, когда каждый член команды действует в соответствии со своими локальными интересами.
2. Мы снова новом месте
Зарегистрировались 88 человек
Фаталисты?
Наш первый митап в Digital Unicorn
При поддержке Sam Solutions
3. План митапов
6. Как Software Craftsmanship фиксит проблемы Agile
7. БД: проектирование, масштабирование,
шардирование, реплицирование…
8. Процессы и инструменты для CI/CD
9. Логирование и мониторинг
10. Распределенные транзакции
4. Что интересует вас
ACID в dtx
Dtx – car
Шаблоны для dtx
Dtx – логгирование, сбои,
согласованность
Dtx scaling
Целостность tx
Опыт с dtx
Надо ли мне dtx?
Выбор между хорошими
решениями
Хаос в процессах
Нет видения
Нет свободного времени
5. Что интересует вас
Dtx Saga
Баланс техники и бизнеса
Целостность данных
Поиск проблем в распред
среде
Много джуниоров
Вызов API изнутри tx
Нечеткие требования
Непрозрачные решения
Нет возможности учиться
Legacy
Сроки
6. Что интересует вас
Accidental complexity
Отладка интеграций
Целостность данных
Scaling
Transactions
Лень
Как мотивировать
разработчиков делать well-
crafted решения
Необходимость отвечать на
обязательные вопросы
7. План этого митапа
1. Какие бывают транзакции
2. Проблема dtx
3. Уровни изоляции dtx
4. Подходы и шаблоны
28. Избегаем dtx. Вариант 2
Пишем в бд job и регулярно пробегаем по
нему
Как будто свой tx log и свой tx manager
29. Избегаем dtx. Вариант 3
Pessimistic time-base locking
Добавляем в качестве lock поля id транзакции
в состояние объекта, который хотим изменить
Обнуляем поле при commit/rollback
Обнуляем поле по timeout
30. Избегаем dtx. Вариант 4
Optimistic locking
Служит для обнаружения, а не для избежания
ошибок
Сначала обновляем локальную запись
Потом пытаемся обновить remote
Откатываем локальную при ошибке
31. Избегаем dtx. Вариант 4
Optimistic locking
Можно откатывать локальное изменения в
batch job, или с помощью лога транзакций
34. Idempotence - повторяемость
Нужно уметь распознавать повторные запросы
и делать сервисы repeatable
Возвращать уже существующий ответ на
повторный запрос
Очень сильно снижает сложность системы
микросервисов
35. Idempotence - повторяемость
Можно использовать tx id для определения
повторного запроса
Но как шарить tx id в кластере одинаковых
микросервисов?
Получается shared state, и требуются доп
усилия
36. Избегаем dtx. Вариант 5
Вручную своим кодом
Нет tx manager
Каждая tx рассматривается отдельно
Проблема с нетранзакционными сервисами,
которые нельзя откатить
43. Saga
Вспоминаем митап 4 «Интеграция систем и
очереди сообщений»
Дает eventual consistency
Микросервисы общаются через event bus
Хореография или оркестрация