Комплекс доменной неполноценности — это когда веришь, что доменный слой приложения должен быть самым большим и самым важным, и винишь себя в том, что в твоём коде это не так. Это происходит, если воспринимать «Чистую архитектуру» как единственно верный способ писать код.

Привет, меня зовут Саша, я Head of mobile в компании «Метр квадратный». Под катом — почему появился этот комплекс и как с ним бороться. Сразу оговорюсь, в статье много моего личного мнения, и будет круто, если в комментах вы поделитесь своим.

— Дима, посмотри, пожалуйста, тикет по саппорту, ЭТО ОЧЕНЬ СРОЧНО!!!

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

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

Привет! Хочу поделиться историей миграции сервисов логирования и трейсинга с компонентов Elastic Stack на Grafana Stack и тем, что из этого вышло. До миграции у нас в М2 использовались достаточно классические схемы:

Писать, собирать, агрегировать и сохранять логи для последующего анализа важно: это наиболее подробное представление того, как работает система.

Логи можно собирать и отправлять в централизованную систему по-разному, например используя библиотеки в самом приложении или сторонние агенты вроде Filebeat, Fluent Bit, Vector. Есть множество систем хранения вроде Elasticsearch, Loki, Splunk, файлы на диске или объекты в S3.

Мы в М2 тоже занимаемся этим вопросом и постоянно ищем схемы и инструменты, помогающие улучшать централизованную систему логирования. Я, как инженер развития инфраструктуры, непосредственно принимаю в этом участие. В статье хотел бы поговорить об этапе агрегации и поделиться нашими наработками.

Привет, Хабр!  Разрабатывая экосистему для «Метр квадратный», мы со старта проекта планировали большую линейку продуктов. Поэтому подбирали стек, который поможет реализовать максимум идей. В итоге мы пришли к протоколу gRPC.

 В этом материале я расскажу:

— о преимуществах gRPC;

— об особенностях работы с протоколом, и о том, как с ними жить;

— о тех проблемах, с которыми мы столкнулись; 

— и о том, как их решить.

Привет! Меня зовут Максим Гореликов, я Backend Tech Lead в M2. Несколько вещей, которые надо знать об этой статье, прежде чем углубляться в нее:

— эта статья — расшифровка моего доклада на конференции Yandex Scale 2021 с некоторыми доработками;

— данные собирали с разных участников переезда и набрали много интересного, но доклад был в слоте про Yandex Data Platform, поэтому оставили кейсы только на эту тему;

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

События, описанные в статье, происходили в 2020 году, сейчас входим в топ-5 клиентов по объему потребляемых сервисов Yandex.Cloud. Когда переезжали, ещё не все процессы в Yandex.Cloud были хорошо налажены, поэтому расскажу о самых ярких воспоминаниях — проблемах, с которыми столкнулись. Хороших моментов тоже хватало, но проблемы всегда интереснее обсудить.

Привет, Хабр! Меня зовут Андрей Перепелкин. Я руководитель группы бэкенд-разработчиков, вошел в IT более 15 лет назад, 10 лет занимаюсь Java и около 4 плотно работаю с микросервисами. 

В этой статье я расскажу, как:

— мы организовали разработку микросервисов так, чтобы вынести инфраструктуру из продуктового проекта и управлять ей отдельно;

— создали общее поле разработки для независимых команд, получить единый стиль кода и контролировать качество;

— встраиваем микросервисы в инфраструктуру и собираем метрики и логи, не загружая этим разработчиков.