Стачка.Backend

За многие годы разработки одного из самых популярных открытых PHP фреймворков удалось набить много шишек начиная от изобретения плохих велосипедов и заканчивая почти десятилетием принципиального отказа заниматься финансовой частью проекта.

В докладе особое внимание будет уделено тому, что вас ждёт, если вы решите сделать большой OpenSource-проект.

1. Что такое OpenSource и что в нём такого?

2. Общие лучшие практики. Без чего не полетит любой открытый проект.

3. Важность общего видения и направления. Как решается, что делать а что нет.

4. Работа с сообществом. Общение, организация. Негативный фидбек.

5. Как получить первых последователей и что делать для роста сообщества.

6. Психологические аспекты. Ответственность и выгорание в OpenSource.

7. Финансовый вопрос.

DDD — сложный подход к проектированию ПО. Для его изучения требуется много прочитать и еще больше попробовать. Но когда у вас много бизнес-логики и она еще и запутанная, без подобного подхода создать развиваемое большое приложение трудно. У нас начало применения DDD по времени почти совпало со стартом активного перехода на микросервисную архитектуру. Из этого получился интересный опыт применения двух сложных, но в то же время отлично дополняющих друг друга вещей.

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

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

Выбранные для доклада грабли помогут ответить на следующие вопросы:

- Что не так с настройками (по умолчанию)?

- К каким неожиданностям должны быть готовы клиенты?

- Зачем Кафке девопс?

- Много настроек — это хорошо или плохо?

- О чём забыли написать в документации?

Kafka как платформа потоковой обработки данных становится всё более популярной. Тем, кто впечатлился обзорными докладами и решит попробовать создать рабочее приложение при помощи Kafka Streams API, предстоит освоить немало новых вещей и соответствующим образом настроить мышление.

С чего начать?

Как работает хранение и репликация локального состояния?

Что такое RocksDB и как её возможности используются в Kafka Streams «под капотом»?

Что за страшные слова: «репартиционирование» и

«копартиционирование»?

Какова семантика джойнов и оконных операций?

Как писать тесты?

Как отлаживать систему «на ходу»?

Что делать с исключениями?

На эти вопросы мы попытаемся ответить, по пути рассмотрев несколько демо-примеров.

PostgreSQL на данный момент одна из самых популярных баз данных для проектов с абсолютно разными профилями нагрузки. Естественно постоянно возникают вопросы откуда в базе данных высокая нагрузка и как с ней бороться. Вариантов возникновения такой нагрузки довольно много, в данном докладе посмотрим на проблемы с запросами, как на наиболее понятную проблему. Первым делом выясним как находить запросы, которые требуют первостепенной обработки, какими инструментами пользоваться для этого. Так же поговорим о том, какие есть типовые проблемы в существующих запросах, какую профилактику им проводить и как исправлять.

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

Зачастую "позже" так и не наступает, но бывают исключения.

Что делать если проблемы с производительностью возникли в старом и заросшем функционалом JEE монолите?

Ответ прост - засучить рукава и начать разгонять то что есть. Но просто не значит легко, в докладе Алексей Рагозин расскажет историю о том как разгоняли подобный Java монолит.

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

Основная цель Patroni это обеспечение High Availability для PostgreSQL. Но Patroni это лишь template, а не готовый инструмент (что в общем и сказано в документации).

На первый взгляд, настроив Patroni в тестовой лабе, можно увидеть какой это прекрасный инструмент и как он легко обрабатывает наши попытки развалить кластер. Однако на практике в производственной среде, не всегда всё происходит так красиво и элегантно как в тестовой лабе.

В этом докладе я попытаюсь собрать и рассказать в деталях о тех crash кейсах с которыми мы столкнулись при эксплуатации PostgreSQL и Patroni у наших клиентов.

В ходе этого доклада вы узнаете о том с какими проблемами столкнулись мы и как мы с ними справлялись и какие уроки извлекли. Так же узнаете как правильно и как неправильно конфигурировать Patroni (и возможно PostgreSQL). И конечно получите представление как оперативно выявлять возникающие проблемы и оперативно их устранять.

Мы живём в сложное микросервисное время. Нельзя просто взять и написать код. От современного разработчика требуется понимание и использование инструментов, которые выходят за рамки кода, отвечающего за бизнес функционал. Service discovery, centralized configuration, distributed tracing, circuit breaking, API gateway — все эти штуки из удела высшего общества давно превратились в обыденные механизмы, без которых не построить современное приложение. Одно хорошо — обо всём этом уже позаботились другие люди и приготовили для нас замечательные готовые решения. Казалось бы, добавил новую библиотечку в зависимости, и готово, однако всё не так просто — обрастая функциональностью, мы теряем лёгковесность. Всё это сопровождается постоянным усложнением систем и новыми функциональными хотелками.

В докладе расскажу про способ, как мы в Леруа Мерлен справляемся с ожирением наших микросервисов.

Skyeng - это множество продуктов под одним брендом: платформа для занятия английским с преподавателем в браузере, мобильные приложения, решения для корпоративных учеников, CRM для ведения бизнеса и еще много всего. В результате, пользователь может столкнуться с разными нашими продуктами в течение дня, и мы всегда должны иметь возможность его распознать. За 5 лет существования мобильного бэкенда команда накопила много опыта, грабель и удач с аутентификацией, о самых важных из которых я и хочу рассказать.

Чтобы сделать надёжное микросервисное взаимодействие, нужно позаботиться о стратегии обработки ошибок и восстановления работоспособности. Я расскажу о паттернах Retry и Circuit Breaker и объясню, когда их нужно использовать и как они дополняют друг друга. Вы узнаете, почему Random полезен в enterprise-решениях и какие ошибки являются «хорошими» для вашего приложения. Доклад будет одинаково полезен backend- и frontend-разработчикам на любых языках и технологиях.

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

Из доклада вы узнаете, как подход API First помогает снизить риски, делает разработку более контролируемой и гибкой. Этот подход не инновация и не rocket science, но остается недооцененным. Я расскажу про его предпосылки, ключевые моменты, преимущества и недостатки.

Мы в компании долго занимались "приготовлением" PHP к серьезным задачам и добились в этом определенного успеха. Но время не стоит на месте, ровно как и запросы клиентов к динамичности их приложений. Масштабность одного проекта потребовала популярный нынче "распил" на микросервисы и тогда мы познали как разные новые технологии (GraphQL, GRPC, Kubernetes и др.), так и новые, для нас, языки в мире backend - JavaScript и Golang.

Впоследствии мы начали писать все больше и больше backend на Go и JS, что познакомило нас с совершенно новым миром возможностей и трудностей:) В своем докладе я планирую рассказать именно об особенностях перехода от PHP к GoLang, а именно:

• Сравнение возможностей асинхронности

• Насколько дорого перевести разработчиков с PHP на Go

• Как сделать переход максимально "дешевым" для компании

• Где и какие повседневные задачи решать проще

В каких ситуациях какой язык больше подходит и почему?

Расскажу о задачах, которые сподвигли нас на создание собственной распределенной СУБД, почему решили писать свое решение, с какими проблемами столкнулись при проектировании архитектуры, протоколов и в реализации, а также как это работает под капотом.

Как и зачем отлавливать мошенников в процессинге?

Какие в этом плюшки для марчантов?

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

Подробно рассмотрим архитектуру нашего нового решения - Risk Control System (RCS), раскроем тайны его невероятной гибкости и потенциала развития.

Случается, что проверяют много гипотез.

Одна из гипотез выстреливает, но есть проблема реализации гипотезы на python.

Оказывается, что в продакшене на этот несчастный прототип наливают огромную нагрузку и он не справляется.

Оказывается, что у прототипа на python есть целый ряд проблем работы с ресурсами и не только.

В основе решения проблемы лежит не стандартный запуск python из С++.

Такой подход связан с некоторыми сложностями.

Такими как запуск одновременно старой и новой моделей и алгоритмов.

Подход к решению данной проблемы находится в следующем:

работа с большими фрагментами памяти и файлами off-vm;

управление жизненным циклом задач на стороне python;

простота интеграции с текущей кодовой базой.

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