#76 Монолит или микросервисы? Что выбрать в 2026 | Алексей Солодкий

В этом выпуска у нас в гостях Алексей Солодкий, инженеринг-менеджер и бывший руководитель разработки BelkaCar. Человек, чья карьера практически совпала с расцветом микросервисной архитектуры: от раннего энтузиазма «пилить всё на сервисы» до болезненного переосмысления и обратного движения к более прагматичным решениям.

Мы детально прошлись по  микросервисам - где они действительно решают проблему, а где создают новые? Почему семь инженеров и «монолит — это злое зло» — плохая отправная точка для архитектурных решений? И правда ли, что средний монолит стабильнее средних микросервисов?

В выпуске:

— как 200 бэкендеров контрибьютили в один монолит в Badoo и при этом релизились дважды в день
— что такое «распределённый монолит» и почему это худшее из двух миров
— как микросервисы превращаются в культ карго и начинаются «роликом на YouTube»
— синхронная vs асинхронная коммуникация: где действительно нужен event bus, а где подойдет обычный HTTP 
— идемпотентность, сетевые таймауты, “exactly once” и иллюзии, в которые верят инженеры
— graceful degradation и как проектировать систему так, чтобы она жила без части своих сервисов
— observability, трейсинг, метрики и реальная стоимость прозрачности
— зачем API нужно проектировать под клиента, а не под внутреннюю структуру сервисов
— почему иногда правильнее «монолитить» обратно


Отдельно обсудили болезненную тему: микросервисы требуют гораздо более высокой квалификации, чем кажется. Писать отдельный сервис просто. Построить устойчивую распределённую систему — нет. Цена ошибки здесь выше, чем в монолите, а переделывать разрезы между сервисами крайне дорого.

Полезные ссылки:
YouTube - https://www.youtube.com/playlist?list=PLZVF-B6xjrIuX-gMghg9HnYtr7GvGHfQh
Telegram - https://t.me/solodkiy

Подписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog
– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): https://podcast.ru/1734325321
– Смотреть в ВК Видео: https://vkvideo.ru/video-224967259_456239247

🔹 Telegram-канал Организованного Программирования: https://t.me/orgprog
🔹Хекслет Клуб в Telegram https://t.me/HexletClubBot



#микросервисы #архитектура #backend #монолит #systemdesign #itподкаст #кириллмокевнин #организованноепрограммирование 

Монолит или микросервисы?  Что выбрать в 2026  | Алексей Солодкий #76

• (00:00) - Введение. Микросервисы — спасение или модная ловушка?
• (04:40) - Микросервисы тогда и сейчас: что изменилось?
• (10:43) - Один сервис — ещё не микросервисная архитектура. Разбираем сателлитную модель.
• (19:20) - Микросервисы 2.0 скоро вернутся? Цикличность хайпа в индустрии.
• (30:03) - Главный принцип: сервис должен уметь падать безопасно.
• (38:02) - Бизнес против идеальной архитектуры
• (44:20) - Пример Amazon: как крупные системы исправляют ошибки оплаты
• (53:34) - Метрики важнее логов? Почему графики — это правда системы.
• (01:02:52) - Микросервисы — это пузырь? Возможен ли откат назад
• (01:14:51) - Почему микросервисы требуют более высокой квалификации
• (01:23:29) - Стандарты коммуникации: почему каждая компания изобретает своё
• (01:32:36) - От микросервисов к сателлитной архитектуре
• (01:41:43) - Заключение: микросервисы — это инструмент, а не религия.

★ Support this podcast ★

Creators and Guests

Guest

Алексей Солодкий

Член ПК Podlodka PHP Crew, Ex Head of Dev BelkaCar

What is Организованное программирование?

Пишем код, за который не стыдно. Разбираем базу, даем рекомендации и встречаемся с умными людьми

Друзья, привет. Это подкаст Организованное программирование. Я его ведущий Кирилл Макевнин. В гостях у меня Алексей Солодкий. Мы с Лёшей знакомы очень давно. Лёша инженеринг-менеджер, а в прошлом руководитель разработки в Белкар. Ну и вообще много интересных мест, в которых он работал и работает. Я думаю, ты чуть больше про себя расскажешь. Лёш, привет. Привет.

Мы собрались сегодня поговорить про микросервисы. Если у нас эта тема так или иначе проскакивала в разных подкастах, то сегодня мы эту тему решили разобрать, вот только ей посвятить подкаст и разобрать как бы не только в основном мы часто говорили про негативные стороны, но и про реальные проектирования, использования там, где это нужно и с какими сложностями придётся столкнуться, как лучше с ними справляться. Вот такая вот у нас тема сегодняшнего подкаста. Да, Лёш, ещё раз привет. Ещё раз привет. Немножко про меня. Собственно, я недавно прошлом руководил разработкой Белкар. И в целом, наверное, вся моя карьера как бы пересекалась с микросервисами, потому что, скажем так, моё развитие, там, моего моё моя эволюция как инженера, она, по сути, наложилась на эволюцию концепции микросервисов. А по сути, я не особо не помню, что было до, да. Вот есть некое сервисоориентированное программирование, архитектура, точнее, да. И я, по сути, начал уже с микросервисов. Я хорошо помню, вот у меня была там первая офисная работа, где я уже как-то себя осознал как инженер. И вот на этой работе у меня поставили техническим директором. Мне было 20 сколько-то лет, мне кажется, 22. А я там был условно третьим инженером. Мне сказали: "Вот ты самый ответственный, будешь техническим директором". Я такой: "Да, это прямо моё". Да, и я хорошо помню, что это был примерно 2014 год, наверное. Я в какой-то момент просыпаюсь и понимаю, что вот у меня монолит, у меня семь инженеров в команде, и надо срочно его пилить на микросервис, потому что вот придёт восьмой, девятый инженер, а у меня монолит, как они будут вместе работать. Вот такое витало в те в те времена. И я действительно начал это делать. И, в принципе, имею такой как некий хзон опыт. именно, скажем так, с нуля внедрения всей этой истории. А после этого вот я работал какое-то время инфраструктурным инженером в компании Bado. Это такой достаточно проект на PHP был. Там, мне кажется, что-то типа 500 млн пользователей, какая-то очень большое число, короче, было. И, скажем так, эта работа меня заставила сильно переосмыслить вот те границы, в которых можно жить в монолите. Потому что Баду был монолитом, на самом деле, в каком-то смысле даже распределённым. сотнями разработчиков, да, там было около 200, мне кажется, человек в пичp в пике. Вот. И они все вот этот монолит пилили. А после я, соответственно, перешёл в белку. И белка - это такой пример, как делать не надо было. Тоже он позволил мне как вот такого вот настоящего опыта набраться. А в каком-то там большом биктехе на 10.000 микросервисов я не работал, поэтому, может быть, что-то я и не успел ещё увидеть в своей карьере. Но что-то успел и с чем-то, наверное, готов поделиться. Да. Ну, ты знаешь, да, что Лёша рыбак у нас был пару раз здесь в студии. Да. Да. Так что Баду большой след оставил вообще в разработке на PHP и в целом разработке ВРФ и не только. Да. Вот есть такая штука Inнкс, например, да. Очень очень большой след оставили, точнее PHP в P. Дадада. Да, они именно в PHP вкладывались много. У меня, значит, первый вопрос, знаешь какой? Я услышал иронию в твоих словах, когда ты говорил, что у вас семь инженеров, и вы там начали микросервисы перепиливать. Действительно, был какой-то момент, в который вот вообще за это время много каких штук появлялось, да, там ивоs появлялся, и микросервисы, и много чего ещё можно вспомнить, что появлялось. И вот действительно, когда это появлялось, я как раз-таки был в лагере, когда, ну, типа серии со стороны смотрю, наблюдаю, мне это просто самому было не нужно. Но была история, что все сказали: "Монот - это зло". Да, вот такое массовое витало. Это очень сильно влияло. особенно на молодых ребят. Хотите расти как разработчик не в одиночку, а вместе с сильным сообществом? И уровень уровень деления был чуть ли не просто до функций, то есть или классов, но ни в коем случае не сервисо в плане, как обычно это понималось. То есть, например, типовая история же она обычно как вот у тебя есть проект развивается, ты понимаешь, что вот биллинг у тебя прямо отдельная команда - это прямо отдельная фигня, ты там очевидным образом отделил биллинг. Ну и таким образом какие-то вещи у тебя там из проекта выделяются. А здесь как бы пошли в предел и сказали: "А давайте вообще в принципе только таким способом думать". И многие, конечно, так сделали и много наделали ошибок. Тогда вот мне хочется тебе задать вопрос: как, собственно, общая, наверное, концепция не только в твоей голове, но общеая эволюционировала? То есть что люди считали и что описывалось как микросервисы тогда? И осталось ли это тем же самым? Просто мы стали взрослее, умнее и сильнее или на самом деле сама концепция микросервисов изменилась за это время? Вот это хороший вопрос. Вот ты сказал, что типа не в моей голове, а вот в общем где-то вот какая-то настоящая концепция. И вот тут я хочу сказать, что в целом в IT, на мой взгляд, есть большая проблема с терминологией, потому что в разных компаниях, э, у разных инженеров одни и те же слова часто значат разные вещи. И какого-то единого словаря у нас нету. И это проблема, на мой взгляд. Часто нам приводит к комму недопониманию. А мне кажется, ближе всех Мартин Фаулер к этому подошёл. Вот я как раз, когда готовился к подкасту, я, скажем так, пытался найти какое-то определение, а что такое микросервисы сегодня, потому что я хорошо помню, что было микросервисы тогда. Опять же, мне кажется, что я хорошо помню, потому что в какой-то момент я начал искать определение, и оно вот совсем не матчилось тем, что я помнил тогда. А я думал, может, какой-то эффект манделы, может, я это себе придумал, может все придумали. Но я хорошо помню, что тогда действительно, а микросервис - это было про маленькие штуки. То есть я прямо помню, была какая-то концепция типа 200-300 строк максимум. Сервис надо обязательно там иметь возможность переписать за день, если это потребуется. Вот что-то такое было. Были какие-то такие слова. Точно. Дадада. И сейчас этого как будто нету. То есть я уже очень давно не слышал именно таких определений. Все как будто ушли от вот это вот микро. Я в своё время как бы, скажем так, бунтовал против этого ещё раньше. Я просто сказал: "У меня сервисная архитектура". Все спрашивали: "А что это такое? Чем отличается от микросервиса?" Я объяснял. И в какой-то момент я просто устал и, ну, начал говорить: "Ну, микросервис у меня, да, как у всех". По сути, понятие эволюционировало. Теперь нету вот, на мой взгляд, вот этого вот размера. Он стал абсолютно вторичен. Угу. Но при этом, а, как бы размер он родился, на мой взгляд, как некий способ дистанцирования от сервисо ориентированной архитектуры, потому что как бы и там сервисы, и тут сервисы, но хотелось, наверное, ребятам как-то, ну, отделиться. И в этом плане было, наверное, два основных отличия. Это вот микросервис, они обязаны работать условно с какими-то своими данными, свои базы данных каждый отдельно. Сервис ориентированной архитектуре было с этим попроще такое отношение. И второе, что микросервисы должны были быть маленькими. А на мой взгляд, сейчас чётко сказать, чем отличаются микросервисы от сервисо ориентированной архитектуры, уже сложно, потому что, как бы, они сплелись в каком-то смысле в какой-то единый концепт. Уже никто особо не помнит, что было сервисо ориентированная архитектура. И поэтому, мне кажется, это почти одно и то же. Сейчас мы прошли некий круг в этом плане. Мне кажется, скоро ребята изобретут микросервисы 2.0, как-нибудь по-другому их назовут просто и будут говорить, что там 150 строчек максимум писать. Но артефакты точно остались, потому что раньше, по крайней мере, вот набора паттернов микросервисной архитектуры не было. Хотя это тоже немножко, знаешь, иногда всё равно меня, как не то чтобы старовера, но человека, который многие эти вещи и видел раньше, да, например, такие вот outбокс паттерн и там все с этим бегают. И ты понимаешь, что, ну, ты так и делал, когда это надо было, просто у тебя названия не было. Поэтому, с одной стороны, вроде бы терминология действительно разъехалась, но всё-таки хороший артефакт то, что все эти вещи, которые мы доходили там до них методом протык, натыкивание опыта негативного, а сейчас уже, в общем-то, паттерны, которые ходят и все бросаются ими без остановки. Это правда. Мне кажется, Аутбок в этом плане как синглотон стал, да, потому что вот синглотон, все про него говорят и Outbox чуть что сразу: "Ой, ребята, надо Outbox включить". Ну, синлтон обычно в негативном каком-то коннотации говорят. Box всё-таки такая, мне кажется, ну, позитив, да, достаточно полезная штука, да. И вот ты привёл пример вот про биллинг, да, вот условно, если у меня там вынести биллинг, например, будет это микросервисом или нет? Опять же, я буду давать, наверное какие-то определения сегодня вот разных вещей и, ну, потому что, чтобы мы как-то были на одной волне. Тут ещё интересный момент, если ты будешь не согласен с этим определением или у тебя будет что дополнить, говори. Мне кажется, это я камеру выключу. такой кикнул записи: "Уходи отсюда". Тоже вариант. А давай. А просто на самом деле, опять же, у нас такая ситуация с определениями, что вот я что-то скажу, ты что-то скажешь, придёт в комментариях чувак на Ютубе что-нибудь скажет, ему придёт в комментарии, чувак что-то скажет, что типа нет, это вы все неправильно понимаете, все в четвером. Соответственно, я считаю, что вот если у нас есть сервис и мы из него выносимпербилинг, да, то это ещё не микросервис. А если у нас есть в архитектуре какой-то микросервис, один, второй, третий, это ещё не делает саму архитектуру микросервис. Угу. Потому что лично я, да, это может тоже не самый популярный какой-то паттерн архитектурный, но мне он лично очень нравится какой-то чётким вот своим названием и хорошей метафорой. А есть такая штука, называется сателлитная архитектура. Идея в том, что у тебя есть какой-то монолитик такой покрупнее, такой главный какой-то сервис, и вокруг него маленькие сервисы побочные. как спутники они вокруг него вращаются. И вот у тебя вполне может быть, например, такая ситуация. То есть вот ты вынес биллинг, у тебя остался какой-то монолинг, монолит, биллинг вынес. Биллинг вполне себе самостоятельный, хороший сервис, там свои базы данные и прочее, но всё это вместе ещё микросервисами не стало. Знаешь, у меня всегда есть такой критерий внутренний. Вот когда мы говорим про тот же биллинг, ну биллингов вообще много существует. Допустим, ты там интегрировался с каким-нибудь страйпом. Страйп - это гигантская компания Бигтех. Ты как ты её вообще микросервисом назовёшь? Не, то есть даже если у тебя билинг поменьше, это всё равно фактически законченный сервис. Ты с таким же успехом мог бы воспользоваться внешней какой-то системой. Вот. А поэтому, да, я тоже, когда вот на это смотрю, думаю: "Так, это не то". А когда ты говоришь про э вот сател элиты, давай просто примеры приведём сразу. Знаешь, что всплывает в голове? Это просто какие-то примитивные вещи, типа, например, обработка картинок. Вот у тебя есть фигня, которая там их, не знаю, мапит, режет, обрезает. Вот она деревянная, как дрова. Её реально микро можно назвать. Там полторы функции вызываются. Да, ещё оно написано на каком-нибудь расте или зиге, чтобы быть более перформанс. У. Угу. О'кей. Теперь, когда ты про это уже сказал, всё-таки как мы понимаем, что это надо или не надо или вот это микросервис? То есть мы мы же вообще, кстати, вот тоже, наверное хочется сказать, мы же всегда говорили, вот когда про паттерны обсуждаем что-то где-то, да, люди, которые к ним приходят, они обычно такие: "Ой, паттерн классно, куда его воткнуть?" Начинает искать, куда воткнуть. Здесь же, правильно я понимаю, здесь же точно такая же история. Нам не надо пытаться думать через микросервисы. Мы просто понимаем проблему, которая у нас есть. И вот эту проблему мы решаем за счёт того, что экстра, ну, выделяем какие-то части, правильно? Ведь вот давай по про это поговорим. По какому принципу и когда мы понимаем, давай, да? Я сторонник того, что, э, как бы микросервисы - это решение какое-то проблемы, то есть проблема должна быть. И микросервисы - это усложнение относительно монолит. монолит гораздо проще концептуально и не имеет кучи сложностей и проблем, которые микросервисы несут. Они как бы несут и проблемы, и сложности, и ещё там какие-то решения. Но эти решения, они нужны далеко не всем и далеко не всегда. И вот когда я говорил про семь инженеров, вот это не тот уровень, например, когда это надо. Или опять же, если у вас есть там задача, например, вы хотите там из-за перфоманса переходить на микросервисы, потому что опять же вам надо какие-то картинки колбасить или там видео, да, тоже вполне себе можно остаться в сателлитной архитектуре, напилить вот один какой-то сервис, и всё будет работать замечательно. Не надо для этого переходить как бы на микросервисы. А микросервисы вот в моей голове это история, когда у нас нету какого-то главного сервиса. То есть они все там плюс-минус равнозначны. У них есть какой-то IP gateway, вот паттерн, который мне очень не нравится, на самом деле. И вот у нас вот эти 1тысяпоинтов смотрит как-то наружу. И там же по ситуации там какое-нибудь клиентское приложение ходит то в один сервис, то в другой. Там есть какой-то сервис авторизации и так далее. И вот мы как-то размазали всю свою бизнес-логику между этими сервисами. Как-то её там где-то она в итоге находится, но, скажем так, непонятно, какую проблему мы этим решаем, потому что это усложнение. А какие проблемы можно решать? Это либо количество людей, то есть вот у тебя в организации очень много людей, и как бы им уже некомфортно работать монолить. И тут опять же вот на меня важное влияние оказало Баду, где я увидел, как 200 инженеров бэкэндеров в один монолит контрибьют. Реально один репозиторий комитет. Да, там не то, что репозиторий, да? То есть там такая вот была штука, типа, э, полумонолит, полураспределённый монолит, полумонорепа. То есть репозиторий один, но деплоился он, э, скажем так, в разных конфигурациях на разные сервера. То есть здесь он выглядит так, здесь вот так. Но по факту кодовая база на этаж. Если тебе нужно какую-то правку сделать, ты её можешь очень легко раскатить как бы по всей кодой базе. Рефакторинг очень просто проходит и прочее. Но там нету никаких разделений. Там же модули были такие какие-то. Типа, скажем так, эта кодовая база, она была интересна тем, что там было три разных варианта модульности, там было четыре разных варианта обработки ошибок и, мне кажется, пять разных вариантов логирования. То есть вот это то, от чего страдает монолих на самом деле. Вот. Ну, Legacy когда большой, да, да, да. И это вот то, что у микросервисов про проще, да, потому что вот есть один сервис, у него границы гораздо уже и можно там творить всякое, что там переписало и так далее. Действительно, есть налитах с этим сложнее. И если говорить про монолиты, в какой момент они могут ещё жить, а в какой уже не могут, да? Это вот количество людей в Баду было много, инженеров, 200 достаточно много, на мой взгляд. Понятно, что это не бигтех вот такой, где там 10.000, да, но при этом вопрос, скажем так, а сколько инженеров нужно было бы, если бы всё то же самое было в микросервисах? Скорее всего, больше. Именно вот за счёт того, что оно было проще в плане монолита, мне кажется, ребятам удавалось делать меньшим количеством инженеров то же самое. Любят было не очень комфортно работать с минолитом. То есть, ну, там, конечно, ну, были какие-то тёрки, но при этом бадона перерелизилась дважды в день. Сейчас вот не каждый там микросервис так релизится по факту. Вот дважды в день по расписанию никаких проблем это не вызывал. И там ещё на самом деле дважды в день это был плановый релиз. А был у нас ещё, особенно в платформе, где я работал, был такой флоow, назывался подчи, то есть можно было кусочек кода там вне релиза отправить. И платформа только так и релизилась, на самом деле. То есть мы там по 200 комитов в день фигачили вот мимо этих релизов. Хотел пошутить по FTP PHP отладка такая классическая. Как-то там принты принт делал, да, и все на на сайте увидел. Кстати, по-моему, Лёша про это рассказывал. Он рассказывал примеры, когда Ну, они же тоже когда начинали всё только начиналось, что действительно там по айпишникам, если айпишник такой, покажи прямо на страничке, распечатай какой-нибудь дампик. Это классика. Многие проходили через это, на самом деле. Дадада. Через вот такой дебак. Это прикольно. Вот. И условно 200 инженеров это ещё может содержать, но больше уже сложнее, да, если у вас действительно большой продукт в плане там количества людей или количество функционала, которые вы хотите пилить, э, больше, чем BДУ, да? А BДУ большая система, потому что внутри кажется, что ну чего это там приложение свайп влево, вправо и всё. На самом деле там большой мониторинг, большой антиспам, большой бэк-фис, куча всего под капотом, огромное количество аналитических вопросов, наверное, немерено, да, чтобы аналитику собирать, конечно, билинг тот же взять. Эта же штука работала на огромное количество стран, и у каждой страны там своя юрисдикция, свои подрядчики и так далее. Вот. Но в целом работал, вот что интересно. И вот это на меня оказало большое влияние, что так можно. На самом деле на восьмом инженере всё не заканчивается, ээ, можно работать так. Но что я для себя тогда понял, это то, что, э, монолит требует, э, сильной руки. Это очень важно в этой истории, если у тебя есть какой-то, я бы даже сказал, не то, что там группа какая-то архитекторов, а скорее конкретный чувак, там технический директор или какой-то главный архитектор или кто-то ещё, не знаю, может он там даже тестировщик, да, но человек, который овни этот монолит, который принимает ключевые решения, условно какая там система модульности у нас сейчас будет, да, тогда это может работать. Если у вас в организации такого человека нету, то вот монолите будет очень больно именно за счёт того, что будут рождаться какие-то конкурирующие подходы в одной котовой базе. И это действительно неприятно. И вот тогда микросервисы или там сервисы, наверное, даже так буду говорить, это вариант выхода из этой ситуации. Но опять же не обязательно пилить этот монолит там на сразу на 500 этих сервисов маленьких таких, да, на самом деле, возможно, разделив там просто по доменам каким-то или отделив какой-то большой кусок в сервис, уже можно очень много профита получить. И, возможно, этого достаточно. Опять же, если говорить про какую проблему мы решаем. Мне это напоминает старые такие представления о разработке. Ну, старый в том плане, что это начальные представление, когда у тебя майнфреймы, когда у тебя тысячи людей над ним работают и была вот эта концепция, что у тебя есть, значит, там инженеры, архитекторы, потом есть типа кодеры, ну, что-то в этом духе, которые просто пишут код, и у тебя такая жёсткая структура, что есть те, кто планирует, придумывают, те есть те, кто имплементирует и не парится. И вот монолит действительно помнишь, ну, наверное, вот как раз ты не помнишь, потому что ты начал сразу в микросервисах. До микросервисов постоянно про это говорили, типа, ну, как программист может просто кодер и не кодер, там все друг другу пытались это объяснить. Ты кодер или ты не кодер или ты разбираешься. Было очень обидное слово такое. Да. Ну да. Но а самое главное у тебя действительно в монолите вот оно видишь как бы сходится. Ты не можешь быть просто кодером. Ну так не бывает. У тебя каждый какие-то принимает решения, что-то делает и может сильно повлиять и сломать. И поэтому у тебя прошло там 5 7 10 лет в проекте, и у тебя появилось пять разных видов логирования, сбора событий и взаимодействия там внешних систем, допустим, да? А микросервисы позволяют это действительно разделить. Так что ты микро, ну сервис микросервис, ну да, ты его через жопу написал, но как бы на систему это не влияет, ты за рамки этого не выйдешь. А учитывая ещё там, знаешь, яишку и всё остальное, как будто бы это меньше проблемой становится. Поэтому это способ ещё немножко разделить. Хотя это должно быть обидно для тех, кто пилит микросервисы. Потому что по факту им планку снизили, типа, ребята, говнокотьте, на вас никто не смотрит. Важно понимать, что как бы на самом деле это раньше вот в те какие-то времена далёкие, дикие каждый мог пилить на чём хотел, на любом языке и прочее, потому что же это казалось тогда, а почему бы нам не написать это на расте теперь на, не знаю, что там, насе этот сервис, на чём-нибудь ещё. Э какая разница? Это же микросервис, мы его перепишем за полдня, если что. Сейчас по факту такого нет тоже, да. Сейчас как бы есть жёсткие шаблоны, генераторы сервисов, и они все плюс-минус всё равно получаются одинаковыми. И всё равно есть люди, которые следят, чтобы ты, не дай бог, там не ту технологию не втащил. То есть потому что если этого не делать, будет даже хуже, чем в монолите. Потому что, ребята, там монолите там как бы есть куда разгуляться, но в целом, если ты начнёшь лезть туда, куда не надо, это заметят сразу и тебе как бы по рукам дадут. В микросервисах можно как бы в своём сервисе что-то такого наделать. Никто это не будет видеть до тех пор, пока, условно, ты не уволишься и этот сервис не придётся кому-то поддерживать. Ну, мы здесь говорим ещё о том, что за эти годы мы дошли не просто до она не просто эволюционировала микросервисная архитектура, но появились ещё платформенные решения, когда у тебя не просто там давайте сейчас на спрингте с нуля что-нибуд фиганём, а когда у тебя есть команда платформы, которая говорит: "Вот кнопка жмякай", вот выбор с таких шаблонов. Вот тебе сейчас всё развернётся автоматом. Правильно я понимаю? Да, вот тебе фреймворк, пиши вот здесь вот код конкретно в этом месте, да? Да. То есть за тебя всё всю обвязку уже продумали, придумали и все взаимодействие выстроили. Это понятно. Это на самом деле очень важная история, потому что без этого микросервисы работают плохо. То есть это обвязка, это добавочная стоимость, она нужна. Э без неё очень плохо получается. Ну да, ты там задолбаешься, у тебя как мне сийку внедрить, а тесты писать, а всё это интегрировать в общий процесс, а релизы и так далее. Такое количество головной боли. Мы с тобой сейчас, кстати, об этом поговорим, а к этому придём. Это очень важные моменты, связанные с тем, как всё это грамотно делать. Я ранее вот хотел тебе задать вопрос, собственно, про объём людей, да? То есть когда им становится тесно, а есть прямо понимание числа. Просто знаешь, что интересно? Вот мы говорим баду, там, допустим, 200 человек. Ведь это что на самом деле обозначает? В мире все привыкли, что ка бигтехи только существуют. Мне, кстати, немножко обидно. Я потому что работают в компании, в которой там там до 100 человек, допустим, из которых разработчиков несколько человек. И вот мы десятилетиями работаем, да, и мы же не одни такие. То есть продуктов, которых, ну, особенно B2B саасы вот типовые, да, у них обычно там 10-20 разработчиков. И это бизнес, это средний бизнес, малый бизнес, его очень много. И это очень важная часть вообще экосистемы, потому что, слава богу, не всё только к корпорациям. То есть получается, что в их случае 200 человек, то есть 200 человек - это очень много, это у тебя богатая компания, это дофига, это так не бывает просто так. Это означает, что всё-таки для большинства предпринимателей, кто делает вот просто продукты, ситуация, при которой они дойдут до микросервисов, она почти, ну, нереальная. Я имею в виду хотя бы с точки зрения вот именно объёма разработки, то есть 20 человек, количество людей, да. Да. Ты, ну, не упрёшься ты ни во что здесь. И это моя позиция, на самом деле, я с этим согласен. И эту позицию я вот транслирую там через свои доклады, когда, условно говоря, говорю, что вам стоят микросервис на самом деле. Вот. Потому что ну зачем? По количеству людей вы сюда не уходите. А можно говорить про перформанance, например. Очень многие, вот я собеседую людей периодически, ребята приходят, говорят: "Вот микросервис нужны, чтобы перформанс повышать". Да, но опять же а как как вы этого достигаете? Потому что надо очень чётко отвечать на этот вопрос. Потому что, если мы опять же говорим про то, что есть какая-то конкретная задача, где нужен там какой-то конкретный язык программирования, да, то, ну, можно сделать сателлит и всё будет замечательно. Не надо как бы там пилить всё остальное. Абсолютно нет в этом необходимости. Всё будет замечательно, быстро работать. А бывают ситуации, что в принципе как бы язык, на котором написано там фреймворк, да, он не очень как бы подходит под то, чтобы его там как-то много масштабировать, да, потому что, например, тот же PHP там баду, он очень хорошо и очень быстро масштабируется, абсолютно без проблем, потому что, условно говоря, он не тратит оперативную память, то есть есть гигантский монолит, но подгружается только то, что нужно для работы. Нет такого, что ему там нужно там 20 минут, чтобы как-то завестись, прогреться и прочее. просто нет. И это как бы хорошо на самом деле. Вот. И если у вас как бы технология такая, что вот у вас как, например, нужно эту штуку, она слишком большая, просто чтобы там влезть в оперативную память, её нужно из-за этого делить. Ну, можно поделить, но опять же как бы не обязательно на совсем маленькие штуки можно поделить там пополам, на три или что-то такого плана. Да, кстати, вот именно про это часто говорят, когда рассказывают про микросервисы и почему они появились, приводя в пример в первую очередь не типовые веб-проекты, где, ну, в целом жить можно вот как баду, да, а показывая всякие медицинские банковские системы, когда у тебя джавовое приложение, там час стартует, в которо которой жрёт память из там 100 гигов. И вот как-то оно там работает. И, конечно, да, ты смотришь на это там десятки миллионов строккода. Ну, наверное, здесь уже уже пора в таких. Ну, важно ещё понимать, что как бы Java тогда и сейчас тоже сильно разный язык и, возможно, часть тех проблем, которые были тогда уже не так актуальны, как и оперативной памяти у всех стало побольше, на самом деле, в целом. Да, ну, в любом случае миллионы строк в одном приложении довольно, ну, так нормально. У вас, кстати, какой объём был, ты не помнишь? Ну, так, если очень грубо в строго. Ой, не помню. Я помню, что репозиторий весил несколько гигабайт, мне кажется. или 1 ГБ, вот что-то такого формата вместе с модулями. Нормально так поклалонировать. Я тебе про перфоманс хотел историю рассказать. Значит, история про производительности. Значит, у меня был сабес. Причём не в компанию набрали, это просто наставники, которых вот мы на Хекслите брали. И я тогда всех собесил сам. И мы разговаривали с чуваком, он говорит: "У нас приложение на джанге. И вот мы, значит, на микросервис ушли". На на всякий случай их три разработчика. Вот. А я говорю: "А зачем?" Он говорит: "Ну, по перфомансу". А начал узнавать, почему. Оказывается, у них были деревья, ну, просто какой-то каталог там, не сказать даже, что огромный, ну, какой-то просто каталог. И когда они пытались сделать нему запросы, они делали запросы рекурсивные, потому что там просто parent ID и всё. И, соответственно, они строили рекурсивные запросы. А он ещё в этот момент говорил, что вообще в целом у Рем плохие, они там тормозят и всё такое. И, соответственно, вот им здесь помог помогло им микросервис. У меня, конечно, приподнялась бровь, но он этого не увидел, потому что мы без видео разговаривали. Я его спросил, я говорю: "Хорошо, вот у вас parent ID там хранится, а почему вы не попробовали нестат или материализованный путь?" И в этот момент стало понятно, что человек не знает про существование таких вещей. То есть фактически собезнчился тем, что он сказал: "Блин, интересно, я пойду посмотрю". Вот. И по мне вот как раз так значит пошёл зря, да? По подмена понятия абсолютное произошла просто из-за недостатка квалификации вот в этом месте. У меня тоже был совет забавный. Вот я тоже вспомнил. Я люблю, на самом деле, спрашивать ребят про микросервисы, потому что, э, скажем так, по глубине ответа можно много сказать, э, об инженере, да. Вот у меня, например, был чувак, который вот, я не помню детали, но вот он выл выдал какой-то тезис, который вот за который я прямо цепился, его раскручивал, и мне прямо не удалось сдвинуть человека с какого вот понимания этого тезиса. Вот. Потому что он сказал, что вот бернетис он чем хорош, да? Потому что ты натягиваешь виртуальную сеть поверх обычной, и она становится быстрее. Угу. Интересный тезис. Так. И вот я как-то гон доказал тебя. Он доказал тебе, скорее я не доказал ему. Вот мы прямо, ну, как-то спорили на эту тему и разошлись, как бы каждый при своём мнении. И вот такое часто с микросервисом тоже бывает, потому что важно понимать, что добавление там нового сервиса, оно само по себе замедляет, потому что у вас появляется сетевое взаимодействие, которого не было до этого. Раньше ты транзакцию открыл, данные в базу отправил и закрыл, конец. А тут у тебя есть Outbox, очередь, там, что-то ещё. ка-нибуд GPC какое-нибудь, и это по умолчанию вас замедляет. Чем больше этих сервисов, тем тем медленней. И надо как-то очень постараться так, чтобы это стало быстрее. Надо чётко понимать, что ты делаешь. Давай перейдём ко второй части и поговорим непосредственно про микросервисную архитектуру. Вот именно с точки зрения того, как надо, когда, что нужно учитывать, с чем человек столкнётся и так далее. То есть вот, допустим, мы разрабатываем какую-то систему. Кстати, забавно, но мы ведь говорим о том, что у нас изначально монолит, и это неплохо. Вот он такой. Но в какой-то момент мы упираемся, а давай, допустим, не в количество людей, а вот какая-то подсистема. Вот давай начнём с того, какие критерии могут быть, что мы такие: "Так, вот эту часть всё-таки надо вытаскивать". У меня есть такой критерий, он интересно, я его использую, не стесняюсь. Это критерии, на самом деле, иногда надо что-то вытаскивать просто потому, что хочется. -э, потому что вот у тебя монолит - это какая-то не модная технология, в резюме тяжело это продавать, а есть какая-то штука, которую можно вытащить и на этом попрактиковаться. На самом деле бизнесу это может быть даже и не нужно, да, но на самом деле от одного вытащенного сервиса хуже не станет. Плюс-минус никому, да. Но при этом, возможно, у тебя как у инженера появится какое-то понимание, вот стоило это вообще делать или нет. И как бы я свой как бы опыт инженерный во многом на вот таких вот решениях как бы приобрёл. То есть я что-то просто пробовал, э-э, потому что у меня была такая возможность, я как бы никому не говорил, что я собираюсь делать. И смотрел, что из этого в итоге получится через год, через два, через три. Так что это первый критерий - это просто хочется. Вот просто тут важно не заиграться, тут важно как бы себя ограничивать и делать что-то не суперважное. Ну давай, допустим, поговорим с тобой про простой кейс, который, я думаю, для всех понятен. Это обработка картинок. Вот есть у нас тяжёлая обработка картинок, и мы решили её вынести. Что мы должны учитывать сразу? То есть мы не просто же такие: "О'кей, давай сделаем приложение, мы его просто запустили рядом". Ты как раз до этого говорил о том, что это ещё, ребята, не микросервис, у тебя там некая единая структура, у тебя появляются проблемы коммуникации, некоторые принципы, которые надо заранее закладывать, а то ещё хуже получится, если строить эту структуру по наитию, просто не думая о том, как оно всё вместе будет работать. Даже с, ну, релизы, собственно, их совпадения, да, если у тебя что-то не работает, как это будет взаимодействовать. Давай, тут большой большая история. Начни с того, что тебе важнее кажется. Да, давай попробуем раскрутить. Действительно, это ещё не микросервисы, и это и хорошо, да, потому что как бы в принципе, если мы одну штуку выносим, можно как бы сильно какую-то там архитектуру и не строить. Можно вынести одну штуку и как бы всё будет работать. Просто на понимание того, что две штуки в каком-то количестве. У минимальная коммуникация, да? Минимальный набор всё равно какой будет? Минимальный. Ну не знаю, скажет: "Это кавку давайте поставим что-нибудь ещё". По-хорошему, они, во-первых, должны быть независимы друг от друга, да? То есть идеальный хороший сервис - это сервис, при падении которого у тебя, а, как бы основная основная функциональность выполняется. То есть я вот делал, например, доклад про каскадные отказы и это, на самом деле, тема, которая как будто бы очевидна. И люди часто говорят тоже, что типа микросервисы нужны, чтобы всё было стабильнее, чтобы если сервис упал, как бы всё продолжило работать. Важно понимать, что я такого очень много видел по умолчанию, если как бы это системно не делать осмысленно, да, средний монолит гораздо стабильнее, чем средние микросервисы, которые сделаны как бы ребятами, которые не имеют достаточно опыта в этом построении этих самых микросервисов. Монолит просто будет как бы статистически стабильнее, потому что он один, он как бы либо упал, либо не упал. А в микросервисов у вас какой-то там упадёт и всё, как он попадает. И вот нужно думать на тему того, что а как мне адаптировать бизнес, как мне адаптировать функционал к тому, что вот этого функционала не будет. И это в том числе история про то, как выбирать границы сервисов. Потому что хорошая граница сервиса - это именно то, когда вот без этого можно как-то фулбекнуться на что-то и оно продолжит работать. То есть, например, вот у нас в Белке мы билинг сделали, так что без билинга всё работает. И это как бы, ну, прикольно, на самом деле. Вот. Может, не прямо всё-всё, да, но условно поездки ездят, можно начинать новые поездки. Идея в том, что Билинг потом просто поднимается и досписывает деньги, потому что данные как бы все там в очередях копятся. И это достижение, я считаю, очень важно. Вот. И надо стремиться к тому, чтобы сервис, который вы делаете, он был как сказать не основным, он всегда был каким-то побочным, без которого можно жить какое-то время хотя бы. Это очень важно. Дальше, как бы, если крутить, нам нужна действительно коммуникация. И как бы в этом плане очень важно вопрос консистентность, потому что это та проблема, которая к вам приходит, как только вы добавляете какой-то сервис. А важно на самом деле понимать, что эта проблема, она не только в микросервисах существует. Вот ты приводил до этого примеры, вот у меня там есть трайп какой-то, да, вот казалось бы, вот ни разу не микросервисы, но но сервисная архитектура уже есть. И мы живём в мире, где фактически невозможно в веб-разработке не иметь какой-то второй сервис. Эн всегда будет, даже вот у тебя есть база данных, это уже второй сервис, на самом деле. И поэтому как бы э то там условно может в чём о чём могут не париться там, не знаю, ребята, которые игры разрабатывают какие-то локальные, да, потому что у них там всё как-то внутри крутится. Но если ты работаешь в веб-разработке, у тебя ты обязан понимать концепцию межсервистного взаимодействия и все эти вопросы, независимо от того, микросервис у тебя или менолит на самом деле, потому что у тебя всё равно это будет вот. Вот абсолютно правда. Я просто, да, хотел сказать, что в целом это как бы распределённая система. То есть как только у тебя распределёна система, законы те же. Неважно, называешь ты это микросервисами или нет, у тебя ретрай, доставки сообщений, ошибки сетевые и так далее, всё вместе. Ты сразу получаешь полбу сетью. Всё так просто в микросервисах этого типа сильно больше. То есть если в монолите ещё можно как-то обходить, опять же, вот классический пример, вот нужно обновить данные здесь и там. Открыл транзакцию в одну базу данных, обновил здесь и там закрыл. Всё. Вот нет проблем больше. Это пишется 10 минут. Чем микросервисы дорогие? Это тем, что какие-то простые с точки зрения там рядового продукта задачи становятся сложными инженерными задачами. И тебе нужно там в какой-то отдел девопсов. Во-первых. Во-вторых, инженеры приходят, говорят: "Ну, понимаешь, у нас эти данные живут в этом сервисе, эти в этом, и нам нужно проложить какой-то там маршрут, бас-то ещё". И просто думать: "Да надо кнопку покрасить просто. Вы что?" А это реально так. Вот. И в этом плане очень важно, чтобы опять же в плане разделения сервисов, вот опять к этому возвращаюсь, типа, как их резать вообще, да? А потому что самый важный вопрос. Очень важно, чтобы они были нарезаны так, чтобы фича, которую ты делаешь, она была в рамках, э, плюс-минус меньшего количества сервисов. То есть она не была там так, что вот я хочу что-то сделать бизнесовое, и мы там везде всё правим, потому что это вот долго и дорого. Соответственно, возвращаясь к консистентности, э замечательные паттерны такие, как outbox, в принципе, потому что стараться по возможности нужно делать асинхронное взаимодействие. Возвращаюсь опять же к первому пункту, чтобы падение этого сервиса не было замечено основной системой. То есть какая-нибудь кавка, например, хорошо работает как баз, опять же eventт сорсинг какая-нибудь модель, где мы там кладём события такие, которые вот любой может читать, а не кто-то конкретный, то есть ненаправленные события, это называю. Вот. И сервис их вычитывает, делает какие-то действия, кладёт какие-то другие события. И всё как-то на этом работает. Если мы говорим про синхронную коммуникацию, то здесь тоже как бы своих сложностей на самом деле куча, потому что как бы вот тоже на примере биллинга, например, я делал доклад на хайлоуде, рассказывал про около там четырёх вариантов, как вот обеспечивать констентность данных в условиях просто двух систем, условно, там билинг и и ваша система, потому что там много чего может пойти не так. У вас появляется сеть, пакет может не дойти, вы можете его отправить, и вы думаете, что вот вы запрос отправили, значит, э-э, как бы всё хорошо, не так. Если вам ответ не дошёл, вы думаете: "Всё плохо", это тоже может быть не так, потому что ваш типизапрос может уйти, там, обработаться, а ответ вам не придёт, и у вас как бы, ну, типа тайм-аут, да, по факту задача сделана. Тенпотентность здесь помогает тоже. И это всё надо просто понимать. То есть как бы не понимая вот эти все концепты межсервисного взаимодействия, микросервисы делать не стоит. Вот я с таким столкнулся вот с примером, где ребята э делали как раз-таки микросервисы, не понимая, чего это стоит и что нужно для этого. Было очень страшно. Ну, конкретно про то, что ты говоришь, это, кстати, действительно вот в распределённых системах всегда появляется. У меня были кейсы, когда, а, семантика доставки сообщений в распределённых системах, то про что-то сказал: "At least ones, at most ones, exactly on, ребята в каких-то проектах, которые просто реально не знали, что это физическое ограничение мира, если у тебя есть две распределённые системы, ты не можешь по-другому сделать. Если они друг о друга и не знают, если они друг о друге знают, у тебя появляются ключи до демпотентности, ты можешь себе срезать углы и как бы обойти это тут. Правда? А поэтому там как бы тройные, двойные запросы, неважно, если ключ есть отпотетности. Тем более в HTTP сейчас внедрено, а в биллингах так вообще любую опишку открываешь, у тебя сразу про это написано э везде. Ну мы говорим про Ну мы говорим про биллинги взрослые, если открываешь какой-нибудь страйп, естественно, там всё это есть. Мы не внутренние штуки. Я просто хочу заметить, что да, я с билингом много работал. И если говорить про там условно российские системы, да, то на уровне условно платёжного интегратора это есть, а в банке этого нету. И как бы иногда реально страшные какие-то вещи. Ты думаешь, эти эти люди твои деньги считают, как бы там просто реально нет ключа компотенентности для там каких-то ряда запросов на уровне банка просто. Ага. Я сейчас тоже про это скажу. Короче, я изначально знаешь про что хотел сказать? Короче, я видел людей, вот, как ты говоришь, не надо начинать действительно из-за нехватки вот этой компетенции человек, с которым я общался, он верил в то, что он может построить exagклин семантику. Но он не знал этих слов, конечно, да. Смысл в том, что ровно одно сообщение уходит. Если не было ошибок, то оно, значит, гарантированно доставлено. Гарантированно всё хорошо. Если ошибка, гарантированно не доставлена. Из-за этого он строил как бы очень сложную, многоступенчатую систему, думая, что он сможет победить. Мне это, кстати, напоминает попытки построить вечный двигатель, когда всё сложнее и сложнее, думая, что в какой-то момент оно закрутится. Поэтому ты абсолютно прав. И более того, приходится в конечном итоге выбирать там логи. О'кей, мы пропускаем. Здесь надо двойные какие-то там наоборот. А, но я могу следующую вещь сказать. Когда всё-таки мы говорим про бизнес большой, да, м, там выбор-то очень простой. Всегда на этом уровне выбор идёт не в пользу человека. То есть, если у тебя биллинг или что-то ещё может ложануть, то всегда выбирают ложануть в сторону того, что с пользователя спишется два раза. А уж это потом его проблема прийти в банк и писать заявки и пытаться вернуть свои бабки. Я это видел везде. Я это видел в биллингах телекомов, я это видел в сам, собственно, много раз сталкивался, когда, ну или сервисы, которые у тебя списывают по подписке, да, бам, два раза списал. Ну, ты должен заметить и пойти им написать. И поэтому я часто, знаешь, как пользователь я недоволен, но как инженер я понимаю и точнее даже скорее больше, как как бизнесмен, я понимаю, почему было принято такое решение. Потому что если бы они не досписывали, тебе бизнес бы на этом, конечно, разорялся. Тебе бы пришлось нанимать команду, которая сидит такая: "Ну, позяст, заплатите вы, да, мы с вас деньги не списяли, а вы нам должны". Это обратная ситуация, на самом деле. Ситуация, где у тебя есть какой-то жёсткий закон. Вот, условно, например, в компании, где я работал, очень важно выписывать чеки. И это как бы очень важно, потому что если ты, не дай бог это не сделаешь, то какой-то один чувак может куда-то пожаловаться и тебе поставят очень большой штрафы и вообще тебя закроют там, пристановят деятельность. И поэтому ты выбираешь наоборот вот типа вот максимально вот именно в этом месте ты вот обязан сделать чётко и корректно, потому что там пользователь там условно там, например, в белке пользователи терялись на регистрации, они не могли зарегистрироваться. Вот когда я пришёл в компанию, там скажем так из-за того, что сервисы коммуницировали друг с другом не очень эффективно, назовём это так, э пользователь не мог пройти фло регистрации там процентов 20 случаев, наверное, то есть 20% пользователей, они просто лет теря процент. Да-да, да. Ну, 20 - это перебор, да. Как бы с этим биз это очень неприятно, понятно, но с этим бизнес может жить, а если к тебе приходит налоговае, вот уже другие разговоры начинаются. Не, 20%, конечно, много. Ну, если заканчивать вот коммуникацию, то есть, грубо говоря, когда мы говорим про сервисы, правильно я понимаю, что в целом история про то, что мы синхронно делаем без запросы, не рассматривается по дефолту. То есть это только тогда, когда у тебя такой API, ты тебе деваться некуда. Ну, допустим, там, не знаю, тот же самый какой-нибудь cloud payments хочет от тебя там работы или вебхуки он там принимает, да, и ты должен это сделать. Но во всех остальных случаях мы всегда выбираем какую-то шину, и почти наверняка это будет кавка, правильно или я скажу так, мы стараемся выбрать асинхронное взаимодействие, но у меня, например, есть такая позиция, я считаю, что если процесс по своей природе синхронный, то лучше как бы не придумывать синхронное взаимодействие на синхронном, а а делать синхронные запросы. То есть тот же пример билинга, когда чувак условно хочет списать деньги, ему важен ответ этой операции. То есть списались они или не списались. И в зависимости от этого ответа мы как бы пойдём либо тем, либо другим путём. И в этом плане как бы городит то, что мы там кидаем события, потом ждём, когда нам прилетит какое-то другое событие. И условно в том же самом коде это ожидание у нас происходит, это мы просто маскируем эту синхронность. Вот здесь я сторонник того, что как бы проще сделать простопизапрос, а не родить какие-то там хитрые туннели и усложнять системы. Это, кстати, интересно, потому что как будто то, что ты рассказываешь, специфично именно для вашего внутреннего билинга. Знаешь почему? Потому что все внешние системы, с которыми я работал, работают в таких ситуациях асинхроно. Почему? Потому что, как правило, форма оплаты у тебя на Джесе, и ты вообще не имеешь права, ты же не процесишь карточки, да? Ты не имеешь права вмешиваться в эту историю. он тебе на сервер ничего не отправляет. Поэтому это происходит на фронтде. Дальше тебе дают токен, который ты там на БК уже сохраняешь, и ждёшь вебху, который к тебе придёт. То есть в моей картине мира эти операции как раз-таки все асинхронные. Есть ещё важный важный критерий. Второй на самом деле, где ещё асинхронность решает, это когда нужна скорость. То есть есть операции, которые надо делать как можно быстрее, прямо реально очень быстро, да. И в этом плане асинхронность всегда добавляет накладных расходов на скорость. HTP синхронный запрос, он в среднем будет всегда быстрее, кроме там случаев, где у тебя запрос повис на тайм-аут. Вот там неприятно, это правда, но в девяносто девятом процентиле он будет прямо быстрее. И такие примеры есть, где эта скорость нужна. Ну, мы, кстати, сразу с тобой попадаем в ситуацию, что условия возможности работы без какого-то сервиса - это теоретическая конструкция. То есть мы бы хотели, мы к этому стремимся, но как только у тебя появляется синхронный вызов, всё, у тебя два сервиса повязаны. Один от второго, ну, они не могут не работать, ну, для определённых частей операции. Не всегда прямо так, потому что, в принципе, можно делать фулбеки, то есть можно делать запрос, сервис не ответит, и мы такие: "А, ну тогда мы включаем фулбк". То есть, в принципе, мы будем работать и без того сервиса, несорён на синхронный запрос. А тогда ты тут разделяешь дальше. Получается, в смысле, оно не работает, но с точки зрения пользователя мы, по крайней мере, ему не пиццу сотку показываем, а просто говорим: "Сон, приди попозже". Да, да, конечно. Ну не невестно. Смотри, вот это, кстати, по дефолту подразвивается. Пример немножко другой. Тут ты говоришь, как бы мы показываем ошибку, да? А мы можем деградировать функционал. То есть опять же пример, там мы идём в бидинг для того, чтобы списать с него деньги. Это почему-то у нас синхронный запрос. Ну вот так получилось, да. Ну он идёт, ты имеешь в виду в биллинг, чтобы с точки зрения пользователя, то есть я захожу в личный кабинет и, допустим, хочу поменять карту. Давай такой кейс. Я пытаюсь поменять карточку. Угу. Нет, даже не поменять карту, а ты хочешь вот начать аренду в Коршеринге. То есть в этом плане списание денег - это какая-то побочная операция, да, с точки зрения пользователя. И мы можем получить как бы ошибку на этом запросе, не списать деньги за счёт того, что у нас ошибка, этот запрос был синхронным, но мы при этом можем выполнить действия пользователя, который он изначально собирался делать. То есть мы такие: "Ну, держи эту аренду в долг". Всё, я я тебя понял. Я тебя понял. Забавно получается, это абсолютная правда, но это такое м работает для операций, где это допустимо, потому что если непосредственно я сейчас, да, если я непосредственно делаю оплату, то, ну, как, например, в интернет-магазине, но, очевидно, никто мне не даст никакую дальше типа получай товар, за, потом с тебя спишем. Так, конечно, никто делать не будет. Это правда. Но опять же, это тот же кейс, где вот асинхронщина особо тебе никак не поможет, потому что тебе важен ответ. Вот везде, где важен ответ, то, что ты переписываешься на какой-то бас, тебе никак не помогает, потому что всё ещё ждёшь этого события, и тебе даже сложнее, потому что, ну, у тебя это какой-то прямо гарантированный тайм-аут HTP, он, скорее всего, тебе раньше даст ошибку. Знаешь, я сейчас что вспомнил? А там, конечно, действительно всё немножко хитро. А я сейчас вспомню такую вещь. Я когда на Амазоне что-то покупаю, он, если у тебя в принципе карта работоспособна и он, видимо, что-то там чекает, он действительно пишет тебе, что, ну, всё, покупка совершена. Но у меня реально регулярно бывает, потому что я обычно покупаю с амазоновской специально их карты. У них есть кредитка, которая там ограниченный очень, ну, лимит есть на деньги. И иногда бывает, что он в этот лимит упирается и уже типа через какое-то количество часов у меня летает нотификация, что деньги-то мы не списали, иди меняй карту. А вот я не уверен, что они при этом блокируют отправку. Нет, они точно блокируют отправку. Я вспомнил, у меня был кейс, когда он мне написал, я уснул в надежде, что всё, завтра придёт товар, за ночь возникло это отказ, и я увидел, что товар заблокировался, не приехал. Вот интересно, есть ли у них там эта связь? Типа не шипим. То есть, грубо говоря, мы к человеку пишем, что всё хорошо, но товар мы не шипем до тех пор, пока транзакция не закроется внутри. Да, наверное, как-то так это устроено. Это может быть так, это может быть и отмена через какой-то тайм-аут, на самом деле. И тоже вот такие паттерны есть. И у нас в Бильнке, в Белке он был такой паттерн, называется, вернуть всё взад просто. В любом непоняти ситуации ты возвращаешься какой-то дефолт, в который ты можешь вернуться. Угу. Дете интересный момент. И это вот про то, про что я говорил ранее. Потому что здесь идёт такой большой стык архитектуры системы и бизнеса. То есть иногда инженер и хороший инженер, он приходит и говорит бизнесу: "Давай вот мы как-то вот так вот сделаем, например, чтобы у нас не было точки отказа здесь. Давай вот мы позже отменим заказ, чтобы улучшить пользоский экспериенс". И это хорошо. Вот так и надо делать. Понятно, что кто-то потом в итоге страдает. Вот как как ты пострадал? Не, ну в целом самое главное, он действительно в целом работает. И ты потом можешь, ну, заказ-то уже оформлен, то есть ты просто карточку быстро меняешь или там денег докидываешь и просто одну кнопку жмёшь. Я просто, знаешь, про что думаю? И если у тебя там две карты привязаны, Amazon может, скорее всего, там пойти второй, попробовать, ещё что-нибудь намутить, потому что есть такая возможность. Ну, этого он точно сам не сделает. Это потому что супер неожиданно может быть. Мало ли ты там забыл что-то, да, им влетит за это. Ну, может. Но знаешь, я сейчас что понял? А это ведь такая вот история на стыке квалификации, потому что вот что мы сейчас с тобой обсуждали, это ведь требует очень высокого уровня квалификации, чтобы вообще думать такими понятиями, выходящими сильно далеко за рамки просто программирования. И в этом и сложность. И типовой разработчик микросервисо, ну, мне кажется, недостаточно будет его знаний, чтобы вот та на таком уровне размышлять об этих вещах. В этом и проблема, да, потому что, скажем так, концепция микросервисов, она, с одной стороны прячет сложность в том, что у тебя есть сервис, ты в его границах делаешь опишку и просто там внутри что-то пишешь на любом языке, на котором тебе нравится, просто реализуй контракт, да. И это действительно выглядит очень просто. Вот у тебя есть маленькая штука, реализуй контракт. Но, э, о чём редко говорят, это о том, а кто эти все контракты глобально собирает в рабочую систему с точки зрения бизнеса. То есть как бы нужен действительно вот ещё один какой-то инженер условный или там группа инженеров железной рукой, которые как и в случае с монолитом, но в этом случае уже соберут вот эту систему в какую-то вот рабочий бизнес-модель. И это сложнее делать, чем монолите. Цена ошибки здесь выше, на самом деле. И в плане определения, да, насколько там дали сервисы. Вот я ещё такую метафору придумал. Вот есть какой-то кусок кода, вот там, не знаю, 200 строк у тебя, да, и ты вот начитался там, не знаю, фаулера или там Анкл Боба, да, не дай бог. и начал его рефачить, там, выносить какие-то кузки, там прочее. Вот. И есть некий момент, в который надо остановиться, потому что если ты продолжишь дробить это дело на функции, уменьшать этот код, он станет менее понятный, чем был. Вот опять же у того же Анклбоба есть какой-то кусок кода, где онтортосфена, мне кажется, пишет. И вот я в этот момент как-то очень скептически начал смотреть на чувака, потому что вот мне не понравился результат итоговый. То есть мне показалось, что оно стало сложнее, чем было. Вот с микросервисами то же самое. То есть есть какая-то бизнесзадача, вот всё. Да, я просто хотел, знаешь, так вовремя рекламная вставка, потому что я недавно буквально сделал, я же разбор делаю, да, и у меня вышло последнее видео, как раз, где я разбираю классы и там вот то, что ты сказал, там не ре чтотосфена, но там было А, стой, подожди, точно, там была генерация этих простых чисел. Простых чисел, да. И он такой, и я прямо вот разбирал это в видео, что он показывает листинг на экран, а в итоге делает листинг на пять экранов просто с кучей классов взаимодействий. И я прямо в видео говорил, что это вообще невозможно понять, что он здесь сделал. Вот ты про это именно про этот кейс, да? Это вот тот экспириенс, который Да, да, который я испытывал, когда ты в книжку впервые читал. Это было лет, не знаю, 15 назад условно, да. И я так думаю, блин, говорят же вроде типа, ну это, ну ти я так думаю, это я что-то не понимаю, или или в индустрия что-то не понимает, но это стало хуже, да. Вот посмотрите это видео, если ещё не смотрели, как интеграци. Да, я там это разбираю. Да, да. Соответственно, с микросервисами то же самое. То есть есть какой-то сервис такой средний, среднего размера. Если его начать дробить дальше, может стать сильно хуже с точки зрения бизнеса, потому что появятся ненужные разделения. Опять же в Белке такое было тоже. А и каждая задача, надо будет вот всю эту группу сервисов там менять, постоянно их деплоить в правильном порядке и так далее. Это, кстати, то, что мы называем graceful degradation или это не совсем то, это оно есть, да? Ээ ну куда-то далеко мы отошли к GR degradation - это именно про то, что когда сервис не работает, у нас всё остальное работает. Может, немножко не так, но оно работает. То есть основная задача выполняется, но вот не так. Да. Ну, видишь, хорошо, что сейчас ещё пришли к пониманию, что всё равно, если ты прямо эту операцию делаешь и именно эту операцию ты ходишь и она не работает, ну тогда она не работает. Сорян, тут ты уже с этим ничего не сделаешь, да. Но ключевое, что иногда даже в этой ситуации можно что-то придумать. То есть пример такой, да, у тебя есть, например, какая-нибуд динамическая тарификация. Вот у тебя есть сервис динамической тарификации, да, кидаешь вводные, пришли мне цену какую-нибудь, он там его генерит, возвращает тебе, да, может даже синхронным образом, потому что по сути это синхронное взаимодействие концептуальное. Вот мне здесь и сейчас мне нужна эта цена. Не когда-то там событиям, да, а здесь и сейчас. А если сервис падает, мы можем просто откатиться на уровне первого сервиса на какой-то фулбк, типа на статическую тарификацию. И пользователь он даже может не поймёт разницу. Дублирование систем делаем свой боинг, да? То есть на самом деле это вот не только дублирование, сколько по-хорошему. Вот есть такой, не знаю, паттерн, не паттерн, не знаю название, но я это часто использую в разработке. У тебя по-хорошему, вот условно в каждом сервисе должен находиться какой-то микровариант очень тупой, простой сервиса, в который ты ходишь. И вот тогда ты на него просто фолбечишься, и у тебя всё хорошо. И это не так сложно делается, что важно, если вот подумать в эту сторону и вот начать думать: "А что вот не просто, ну, ну упадёт у меня тарификация, у меня синхронный запрос, ну всё, тогда каскадом падаем". А как сделать так, чтобы мы не каскадом не падали? Я просто представляю какой-то безумный объём работы с точки зрения продуктов, которые всё это смотрят, потому что они-то, может, когда планировали такую фичу, вообще не воспринимали такие варианты. А ты им говоришь, что не, ребята, вот тут у меня может упасть тогда так. Они такие: "Блин, у нас и так 50 состояний, которые надо учитывать, сколько у человека денег, в каком какую он роль там имеет, какие права имеет, может он вообще корпора корпоративный доступ какой-нибудь. А вы мне ещё просите, что: "А если вдруг не работает система выдачи, не знаю, скидок, а я вообще не знал, что это отдельная система, да, я ещё должен подумать, а что сделать в случае вот этого?" Ну я в своей практике просто стараюсь что-то предложить самостоятельно, потому что, ну, при этом я говорю: "Вот давай сделаем вот так". И это сработает там типа 2 часа там в год, да? Вот это вот это фулбк. Он такой: "Ну ладно, сойдёт". Окей. Вот. А я получил систему, которая откуда устойчива. Следующий вопрос. Graceful Degradation. Поговорили. Давай поговорим про коммуникацию. Знаешь с какой точки зрения? С точки зрения, как это правильно называется? Это обсеsрabбилитиility ведь называется, да? Мы пытаемся вообще увидеть по сути некую распределённую транзакцию. То есть если раньше чем ещё монолит хорош, да? Ты в одном месте просто видишь всё: у тебя транзакция, у тебя логи, у тебя красота. Сходу, если заранее об этом не подумать, будет очень весело, когда вдруг окажется, что произошло что-то не то, и ты такой: "А где это вообще произошло?" И начинается очень весёлая отладочка. Вот. Да, уже принтфа не расставишь по системе, как раньше с монолитом можно было. Это правда. Да. Вот расскажи про это. И сейчас мы вступаем вот этот слой, скажем так, необходимой инфры, которая нужна, если у тебя там условно больше трёх сервисов. Вот условно, да, потому что условно на двух в принципе можно там посмотрел, тут посмотрел, нормально. Вот 3чеп уже тебе нужна инфра. Инфры нужно достаточно много. То есть, условно говоря, если стоимость монолита, она растёт там более-менее как-то линейно, да, и потом куда-то улетает в космос с количеством строк, да, то мы то микросервис, они сразу стартуют где-то вверху и растут медленно. И вот есть точка, где они пересекаются. И вот именно поэтому вот я, в частности, и многие рекомендуют начинать с монолита, потому что когда он маленький, это просто дешевле. Если говорить про инфру, соответственно, нам нужно где-то это разворачивать, да? То есть нужно какой-то кабернетис, сварм, что-то ещё. Докер ещё помогает. Нам нужно логирование. Нам нужно собирать какие-то текстовые данные. Почему тоже тут есть куча разных подходов, как это делать. Нам нужно собирать метрики, потому что прозрачность это, на самом деле, на мой взгляд, про метрики в первую очередь, про графики, про то, как система говорит, чем она сейчас занята. Это же это вот я много делал в своей практике. Нам нужно эти логины, например, связывать друг с другом. Мы говорим уже про трейсинг. Э нам нужно замерять перформанс там какой-то конкретной операции, которая слаивается на операции. Часть этих операций какой-то синхронно ещё улетают. Это очень большая сложность, да, потому что, ну, у нас как бы есть концептуально синхронная операция. Вот почему я люблю концептуально синхронные операции делать синхронными, потому что иначе очень тяжело трейсить, потому что вот ты начал синхронную операцию, вот кто-то отправил запрос тебе, да, а он там улетел в виде события в НБА, в другой сервис, там оттуда в другое событие. Они как бы не связаны, но тебе надо их связать теперь. Вот это сложно. Давай, чтобы люди понимали. Я не уверен, что все до конца это понимают. Мы говорим про сквозную идентификацию по сути, чтобы всегда любое событие можно было связать. Да, наверное, хорошая новость в том, что есть готовые инструменты, кроме того, что ты просто прокидываешь везде там transaction ID. Ну, важно понимать, что эти инструменты как бы на мой взгляд, нет такого, что ты вот взял, подключил и всё хорошо. Это вот, на мой взгляд, это скорее конструктор. У тебя есть готовые кубики, но собирать из них замок придётся всё равно тебе, ээ, потому что, ну, их нужно интегрировать. Их нужно интегрировать, причём не только в код, что очень важно, их нужно интегрировать в процесс. А потому что мало добавить систему логирования во все сервисы. Надо ещё научить всех разработчиков, а что мы логируем, а как, а как мы там прокидываем параметры, а что делать в секьюрити этих параметров, чтобы там пароли не бегали по логам, а как нам выбирать уровень логирования. Вот очень моя любимая тема. Типа вот есть там 50 разных вариантов уровня логирования и непонятно вот это инфа или вардинг. А в этой системе, а в этой. Ну это сложный вопрос, на самом деле. Это нужно определиться. Это должен быть какой-то полиси, должен быть кто-то, кто будет за этим следить, превью условно это спускать ещё, чтобы там вся команда, все команды как-то одинаково это понимали. Оказалось бы, да, у нас вот есть чувак, который свой сервис билит, и он как бы независим, а нет, он всё равно как бы получается в общей какой-то массе варится и должен соблюдать общие пайлайны, иначе потом, ну, будет тяжело всем. Ну, фильтрацию не поделаешь там по типу какому-нибудь ошибок или типу операции, например. Это всё согласовывать надо сквозь все сервисы. Ну да, и есть там вариант, например, который, что мы там принимаем, что там, не знаю, ошибка уровня там, это мы там сего звоним, например. Вот тоже, значит, там кто-то написал там джунир разработчику в свом сервисе и приехали. Ну, тут бы, конечно, пришлипс с сказали: "Надо подключить Виктор Опс, там роутинг настроить, и он сам позвонит и отправит эсэмэску". А, кстати, давай ключевое слово с Проблема-то не в этом, а в том, что сам звонок произойдёт, которого не до не должно было быть изначально. Да, человека будить не надо. Какой инструмент используется? Я по сам не пользовал, но я знаю, что там Зипкин одно время был на небосводе, так сказать, этого процесса. А сейчас что? Слушай, ну вот если говорить, например, про логирование, точнее про давай про метрики сначала. Промитиус считается отраслевым стандартом, но при этом есть другая штука вот которая, на которую мы, например, в белке перешли под названием Victoria Matrix, которая всем хороша и в первую очередь тем, что она обратно совместима с Prtius, то есть ты можешь заменить одно на другое. И у тебя как бы это очень быстро происходит. При этом она имеет куча там. Да. Обязательно посмотрите моё видео с фаундером Виктория Matтрикс, где мы разбирали, как он его придумал. И я теперь он, кстати, меня убедил. Я тоже всем рассказываю, что уходить из Метеуса на Viктория Matтрикс. У нас чисто позитивный опыт тоже с Виктори Matтрикс, на самом деле, это такой какой-то Промитиус, как он должен быть, потому что Промитс он местами очень странно себя ведёт. Очень странно. Угу. Хорошая система. Вот раньше мне очень нравилась система DataDog. Это такой САС американский. Э, но в какой-то момент что-то случилось, они нас забанили за там условно не ту страну. А, и вот пришлось срочно пережать на Промитиус. Но до этого я всем всегда говорил: "Очень классная система, очень удобная. Там есть и трейсинг, и логи, и вообще полный набор. Если вы вдруг находитесь в юрисдикции какой-то другой, можете попробовать, но я вам не рекомендую, потому что я обиделся на этих ребят. очень они поступили плохо, потому что они там ещё условно деньги на аккаунтеста оставили и прочее. И сделали это, короче, вообще очень неприятно. Так не надо делать, даже вот если обстоятельства вас нуждают. Ну мы по той же причине ушли, по той же причине от них ушли. Хотя учиться точно надо на них. Типа как вообще сделать так, чтобы было вау. Вот дата docг - это номер один. Да. После этого действительно, условно после перехода на Промитес ощущение было, как с Мака на Linux пересел. То есть вроде всё то же самое, но вот оно как-то всё не для людей. Обидели людей немножко. Ну ладно, зато комментариев больше будет,

если про про логи говорить. Да, здесь вот тоже есть всякие разные инструменты интересные. Они причём, э, ну, есть условный ластик. А, а мы на первобелке пошли таким достаточно интересным путём. Он не очень распространённый. Мы взяли штуку под названием, а, не помню даже, как он. Э, есть ещё Виктория Loxс. А вот я её не щупал на горе. Хорошо. Они недавно, да, они недавно появились. А вспомнил, вот мы взяли Локи. Это в стейке графаны, мне кажется, он находится, по-моему, да? Соответственно, Локи - это очень интересная система. Мне она очень понравилась тем, что она безумно тупая в плане своего функционала. То есть она вот настолько простая концептуально, что её можно написать самостоятельно. Вот это такой микросервис. То есть его реально можно взять и свой локи и в принципе за пару часов с ишкой написать. И этом она меня подкупила, потому что условно ластика - это большая сложность система, она тормозит, она при этом тебе даёт там быстрый поиск, но тебе нужно какие-то индексы придумать и прочее. Идея локи в том, что вот ээ система говорит: "У тебя log - это строчка вот прямо текст". И он эти логи хранит в виде там газип файликов просто. И за счёт этого она очень много логов может хранить очень дёшево в плане, скажем так, доступного места. Это всё на S3 куда-то может сливаться. И вот мы столько логов начали хранить, мы бы в жизни вот это просто там типа в 100 раз было дешевле, чем в ластике их хранить. При этом поиск помедленнее, потому что там вот такая же концепция, скажем так, индекса, как в Прометеусе, то есть их не так много можно сделать. Вот. Но при этом вот моя личная позиция, что да, не нужен тебе быстрый поиск полога. То есть вот ты берёшь там какое-то недельное окно, запускаешь, он там минуту ищет эту запись. Ну ничего страшного, не так часто надо, на самом деле. Вот. Э, оно перевешивает тем, что это условно работает консистентно, потому что там условно греб и у тебя нет такого, что у тебя там какие-то окончания слов другие попадают. Ты вроде искал эту ошибку, а куча какого-то мусора нашёл просто потому, что у тебя там полнотекстовый поиск сработал, да? Ты как написал, то и нашёл. Вот абсолютно детерминированно работает. Очень мне нравится система. Ну и для самых колхозанов типа наш, кому желательно вообще ничего не использовать, можно просто в облаках. У тебя облака просто поддерживают из коробки. Поэтому, если вы в облаке и не усложняете себе жизнь и у вас нет 2.000 серверов, вполне, наверное, тоже нормальное решение. И в Амазоне, везде есть как бы свои эти облачные, да, о системки, которые сами собирают. В общем, не хочется заморачиваться вполне себе. Хотя, наверное, это дорого, если большие объёмы. Мне сложно говорить, у нас не такие объёмы, чтобы это стало, наверное, с проблемой. Но подозреваю, что если у тебя большая система, то ты там офигеешь платить. Это, кстати, вот ты когда про это рассказываешь, я правильно понимаю, что все эти штуки, все эти системы, это, как правило, всё-таки реально не облака, это где-то своё железо или в рамках облаков, но свои просто сетапы этих. Слушай, так сложилось, что вот компании, в которых работал, они в основном были либо BMAL, либо, э, скажем так, такие облака, где у тебя условно виртуалки находятся. А опять же в Amazon мы так и не приехали по там определённым причинам. Какие-то другие системы тоже. Ну вот так вот как-то не выбираю, может по такому принципу компании. Вот. Не, ну это правда очень дорого. Есть у тебя большая компания большая. То есть для тех, кто есть, кстати, вот один интересный тезис на этот счёт. Э-э, я убеждён, что, короче, микросервисы популяризируют и вообще всячески хайп поднимают именно вот эти компании, потому что именно им, э, это больше всего выгодно. А ещё есть как бы концепция лямбда функций, которые вот как будто бы вот ещё меньше. И ты даже Да-да, да. И, ээ, если начать как бы думать, а кому это надо, вот этим ребятам? Ой, этот баттл идёт бесконечно. У меня Twitter просто переполнен. Это касается всего. Там и Versal со своими статическими файлами, тем, как они деплот и попытка, знаешь, что же они там делают-то, кроме микросервисов и всего остального, и с производительностью. То есть они прямо намеренно не работают с производительностью каких-то вещей. Им там предъявляют за это, типа вы фреймворк делаете, да, а потом он у вас там сжирает всё. Поэтому сейчас, кстати, вот эта тенденция пошла, да, Дичевич, помнишь, там разгонял эту тему, что вот камал мы там сделали, всё съехали, 100.000 в месяц сэкономили, там просто такое бурление поднялось на тему того, что без облаков можно жить. Как будто есть такой, да, сейчас виток, что можно получать такую же экосистему, но без облаков. Есть и дело даже не только в облаках, да, в контексте даже нашей темы. Сейчас вот на мой взгляд, как бы микросервис - это в каком-то смысле пузырь, на мой взгляд, да, потому что они вот все критерии имеют, то есть он начался внезапно, очень большой был хайп, люди делали тогда, когда надо и когда не было не надо. Да, понятно, что там условно бектех это там какой-то профит свой приносит, но даже и в них мы видим там некоторые истории, там условно Uber что ли недавно сказал какую-то статью про то, что они там поспиливали там сервисы что-то помолитили и получили тоже большой профит какой-то с этого. И я думаю, скажем так, мы не то, что как бы забудем полностью технологию, это точно не будет, да, но какой-то откат назад я всё жду. Вот я всё жду. И мне кажется, вот он потихонечку на самом деле начинает, потому что всё больше людей как бы, скажем так, начинают относиться к этому как инженеры, а не вот как типа фанатики, потому что тогда мы все были молодые и все как бы, ну, все хотели чего-то модного нового. Угу. Мы с тобой про трассировку не договорили. То есть в итоге какой инструмент? Потому что вот логи поговорили, это поговорили, а трассировка, ну, по трассировке есть стандарт Openacing, и, в принципе, всё, что его использ, ну, реализует, можно брать, мне кажется, а в графана стейки тоже есть, э, штука, которая как раз-таки с Локи связана. Я не помню точно название, как она называется. Вот. Но можно использовать, в принципе, как бы плюс-минус можно менять. То есть всё, что пантилеметрию поддерживает, можно брать просто под свои нагрузки. Э-э, мы, на самом деле, вот этот интересный момент, э, мы в белке по сути треacсинг так прямо кардинально не внедрили. Мы сделали какую-то там небольшую версию про простецкую. Мы сделали идентификатор, мы его прокинули по всем логам, но мы не сделали это прямо красиво, там, со спанами и прочее, потому что есть ребята, которые считают, что это какая-то первичная задача. обязательно нужен трейсинг. Я считаю, что треacсинг - это всё-таки штука, которая помогает. То есть это штука, которая помогает чуть лучше разработчику, но она не является необходимой. То есть без трейсинга можно решать задачи просто чуть менее удобно. Вопрос просто насколько часто вы с этими задачами сталкиваетесь, чтобы вам это окупилось, потому что треacнг, на мой взгляд, достаточно дорого тоже. Ну, я правильно понимаю, что в конечном итоге мы как видим у тебя, то есть транзакция, мы видим, если визуально представить всё, что она порождает везде, как они расходятся, то есть мы видим, куда как они расходятся вплоть до самого низа, даже если там циклы, и видим вход-выход по данным. И в конечном итоге вот из этого собирается как бы понимание, что на каком этапе могла случиться ошибка. Обычно даже это не столько про ошибки, сколько про перформанс. То есть у нас есть какая-то операция, которая занимает 2 секунды, да, и мы можем разобрать в каком сервисе вот эти секунды теряются. Мм, мне знаешь, просто ещё что кажется, вот сейчас в эпохуишки, если у тебя есть как бы вот эта картинка, не просто логи, а вот прямо картинка, да, того, как оно пошло, какие данные были на входе, на выходе, это может, ну, уже сильнее повлиять на результат, на по перформанс, ну, оптимизации, скажем так, и поиску ошибок, потому что теперь можно это выишку закидывать, и он тебе как дополнительный контекст, особенно если у тебя 7 MCP, у меня уже, знаешь, как мозг работает, всё это соединили, и мне кажется, Кажется, над этим люди сейчас бьются. Ну, почему-то у меня есть такое ощущение, чтобы вот этот получать в одном месте и ты мог достаточно легко понимать, что вообще произошло, на каком этапе. Вот это как раз-таки чем хороши всякие САСы интегрированные. То есть тот же датадоog там ещё даже в те года, в четырнадцатый, пятнадцатый, когда вот я его использовал, чуть позже я его использовал ещё в Белке, там было много классных и фичей. там, условно, без генеративных моделей, но вот просто какие-то, например, там был и анализ -э инцидентов на графике, то есть ты просто там говоришь, что типа покажи мне, если что-то странное будет происходить, типа, ну, прикольно. И за счёт того, что система интегрирована, она там подтягивала ещё, говорит, наверное, вот из-за этого деплоя или вот тут вот какой-то вот это связанный лера. А мне ещё больше нравилась функция корреляция графиков. Ты прямо выделяешь, говоришь: "Вот типа вот тут какой-то пик". И он такой: "Ага, вот тебе ещё 50 метрик, где тоже этот пик произошёл". Такой: "А вот нашёл первопричину". Про что они же связаны? Это очень круто, да? Если такого нет, э, сейчас просто ишки настолько приучили вот в тех местах, где ты у себя оптимизировал, и у тебя получается очень быстро отлаживать, ты каждый раз, когда попадаешь в системы, где вот этого нет, очень чувствительно это сейчас стало. По крайней мере, я понимаю, что вот здесь я мог бы решить проблему за 10 минут, а я там часами эти данные, например, собираю, чтобы картинку хотя бы составить. И это явно мы живём в мире, где уже не надо этим заниматься, надо от этого уйти. Так что мне кажется такой, знаешь, новый виток. Все говорили там эластик, все говорили раньше, а значит, вот как графану там, там ещё что-нибудь ставишь, а теперь уже, мне кажется, много будут говорить: "Давайте себе МCпишку, всё это соединим". Потому что недавно, это, конечно, не совсем тема нашего, так сказать, подкаста, но всё равно а в какой-то момент же Сентре, они же MCP выпустили. Вот. И улупея про то, что там туда сдить, вытащить все эти данные, связать своей кодовой базой, она как бы уходит, да? То есть ты у себя в агенте его подрубил, говоришь: "Посмотри, например, последние самые критические ошибки и посмотри как бы в коде, что могло пойти не так". Вот. Я, конечно, очень-очень хочу это сделать. А у нас, знаешь, есть проблема. У нас в центре локальный стоит, и у него MCP сервера нет. Это только в облаке есть. Поэтому такие: "А, а там из-за этих из-за того, что блочат, мы не можем, короче, облачно использовать". Ну, ещё и денег будет стоить много. В нашем случае терпимо. У нас ошибок много, но не так много, как ребят, у кого там очень-очень больно. Будет мотивация ихть их количество, да, исправлять. Это тоже правда. Так, понятно. То есть вот у нас все вещи, которые нужно учитывать, с которыми нужно как бы сталкиваться. Теперь смотри, у меня такой следующий вопрос. Немножко теперь откатимся назад про белку. Ты вначале сказала, что там было сделано так, как делать не надо. Вот сейчас мы немножко поговорили про то, как делать надо. А давай поговорим, что там пошло не так для того, чтобы вот этот контраст и собрать, а где, собственно, ошибки могут встречаться в проектировании, в эксплуатации. Давай. Ээ это на самом деле интересная история, потому что, ну, вот получилось так, что вот я пришёл в компанию руководить php отделом на место другого человека, который до этого, ну, этим же отделом руководил. И мне досталась команда, мне досталось как бы проект. И этот проект он был, во-первых, крайне нестабильный. То есть там реальные инциденты происходили каждый второй день, и это как бы, ну, не преувеличение. Там действительно каждый раз что-то ломалось. И мы каждый понедельник с товарищем чинили вот этих потерянных пользователей в регистрации. Мы всё там искали какие-то баги, почему они не теряются. Каждый раз новые какие-то были, они прямо реально терялись. А это как бы ну деньги, то есть, ну, вот чувак тебе условно приходит платить деньги и потерялся, не может просто зарекаться. Это же ужасно. Вот. И у меня восложилось впечатление в какой-то момент, что вот как будто бы, ну вот ребята, которые это пилили проект, они пилили это в режиме стартапа. И как бы вызывает уважение количество функционала, которое было написано. На самом деле, за какие сроки это было сделано. Тут вот, ну, я бы так, наверное, не смог. Вот. Но при этом было какое-то ощущение, будто ребята вот тоже вот в этот хайп попали, посмотрели какой-то, не знаю, видос на Ютубе или ещё что-то и такие микросервисы прямо, да, вот надо вот это делать обязательно надо всё должно быть в микросервисах. Они с них начали. И словили они как бы все вот проблемы, которые, наверное, только можно было. Это классический такой распределённый монолит. Там было пять сервисов, которые ходили в одну базу. В какой-то момент они поняли, что, наверное, что-то не то, и шестой уже туда не ходил. Седьмой там был сильно связан. Там было два сервиса, которые, например, друг без друга вообще никак не работали и так далее. И, ээ, при этом не было не то что трейсинга, там толком не было логов, не было метрик, и система была абсолютно непрозрачна. И при этом был такой как бы прикол, что, например, э сервисы всегда они парой шли, ну, откуда с устойчивостью. Вот обязательно должно быть их два одинаковых сервиса, две инсталляции, два инстан. И был такой Сй. С cй был не везде, да? Опять же C - это какая-то прямо база-база, если у вас как бы много сервисов, потому что, ну, как что руками по FTP это деплоит, а их же много ещё. И там было такое состояние инфры, что ты как бы нажимаешь кнопку деплоить, а деплоится первый instance. Я говорю, а второй что? И мне чувак говорит, типа вот config тут хост меняешь, комитишь и ещё раз деплоишь. И вот это как бы вот то, как оно мне досталось. И вот одни из первых, что я делал, опять же, это я делал прозрачность. Я вот этот Сяй везде там раскатил, я делал шаблон на Сяй, потому что каждый сий был как-то уникален каждый сервис. Потом ещё вот это была классическая история. Каждый сервис был как бы немножко иной. Вот в этом у нас Symphony, в этом у нас, в этом у нас п Дана, в этом что-то ещё. Ребята вот каждый раз вот они такие: "Так, ну вот сейчас мы на ошибках научились, сейчас мы вот здесь вот ДД у нас лучшие технологии". Да, современ Дадада. И это тоже страшно. То есть вот это вот то самое бесконтрольное, как внедрение нового, оно всё всё разное. Оно всё ещё должно как-то интегрироваться и прочее. А деплой чем делался? Скажи, пожалуйста, деплой anle через GitLab C это, кстати, ещё нормально. А при этом там куб был или, я так понимаю, просто стартовали? Там вообще контейнеры были? Нет. Или просто на машины? Просто на машины виртуалки. То есть один общий PHP и все туда погнали. Ну, машин было много, да, просто вот как бы вот есть ENBЛ, который на эту машину деплоить, есть вот этот сервис на эту и опять же есть вот сервис безя. Тут как-то там, не знаю, я даже не помню. Слушай, а Zero Downtime при этом там ожидался или нет? Я говорю: "Сер". Ну просто я ввас это сложно сделать. Это реально сложно. Тебе надо там мутить прямо с с чем-нибудь, чтобы это заработало. Там там не то, что Zero downтайм, там сервис просто лежал постоянно именно из-за того, что что-то каскадом падало. И были такие ситуации, например, вот тоже интересная история про то, что было два сервиса и вот они друг другом событием обменивались и в качестве транспорта был выбран дис попса. То есть это система, которая как бы не хранит сообщения. Вот она как бы пересылает их просто. И когда один сервис упал на 2 дня какой-то там побочный, который вот ещё его там в понедельник подняли, оказалось, что эти события, они просто, ну, удалялись. Потому что, ну, это попса. Ну, это радио. Мы всегда говорим, что это радио, да. Если ты послушал, то всё, да, да, да. И как бы там такого было много и очень много таких вот страшных вещей. И самое забавное произошло, на самом деле, через, мне кажется, где-то на третий год моей работы, когда мы командой пошли, правда, за день рождения одного из членов этой команды, и был приглашён, в том числе чувак, который как бы весь весь этот сервис поднял изначально. Вот тот самый человек место которого пришёл. И я теперь его очень уважаю, на самом деле, потому что в какой-то момент мы там были в Караоке, мне кажется, чувак потел просто ко мне, положил мне руку на плечо и сказал: "Лёха, прости, мы посмотрели ролик на Ютубе и решили внедрять микросервис". И я както настолько проникся какой-то любовью к этому человеку сразу, потому что как бы, ну, нужно иметь какую-то тоже хорабрость и честность, чтобы тоже какие-то свои ошибки признавать. И самое забавное было то, что это реально был ролик на Ютубе. Мне кажется, мне даже скинули его потом. Вот прикольно. Ты потом скажи, я посмотрю, никому не покажу. Та такого было много. То есть в те времена в целом, ну, как бы мне кажется, сейчас просто этого меньше. Может, просто я это меньше вижу, да, э, в те времена, там 6 лет назад, условно, наверное, лет назад, очень было модно и очень мало было экспертизы, потому что она консолидировалась там в каких-то бигтехах, где-то ещё вот. А все ребята хотели туда, не понимали зачем, но все хотели. Резюме в том числе, да. И как бы это не не один сервис, который вот так вот по такому пути пошёл. К счастью, вот именно этот сервис удалось спасти. То есть по что мне кажется, есть какое-то количество сервисов, которые, ну, вот как бы, ну, когда ты лежишь каждый второй день, тяжело вести бизнес. Мне кажется, это так забавно, насколько контастирует с тем, как всегда про это говорят, да, что у тебя микросервисы, там это вот тра-та-та-та-та. На практике, знаешь, у тебя есть дефолтный вот ты, который там просто разработчик, если ты делаешь монолит, у тебя 100% будет надёжнее, чем микросервисы. То есть квалификация, блин, сильно больше нужна. Просто обычно, когда спорят и сравнивают, обычно говорят про, знаешь, вот что я всегда чувствую, такая немножко манипуляция. Говорят про написание конкретного микросервиса. Ну вот посмотри, вот он простой, посмотри. Ну проблема-то не в нём, а проблема же во всей системе, которая стала в 1.000 раз сложнее, чем она была изначально. Это правда. И вот я всегда говорю, что опять же как бы нужны очень высокие компетенции. На самом деле их не так много на рынке. Я много людей собеседовал, и как бы не их сильно меньше, чем хотелось бы, от людей, которые действительно понимают все эти концепты и понимают, как делать, как не делать, как ещё при этом с бизнесом говорить, чтобы это было как всем в итоге понятно. Их сильно меньше, чем хотелось бы. И важно понимать, что вот если ты как инженер работаешь там в Бегтехе и пишешь там 1.000 первый микросервис, э, какой-то, да, это ещё не значит, что ты придёшь и в какой-то компании с нуля сделаешь микросервис. Скорее все, у тебя получится не очень хорошо. Именно потому, что вся та инфра, которая для тебя была базой, её там не будет. Её надо будет делать с нуля. И это не так просто, как кажется, когда это у тебя есть. У меня есть такой вопрос, а который меня вот, например, всегда волновал. Ну, в каком-то смысле распилить и запустить микросервисы действительно несложно. Но, как часто бывает в любом бизнесе, у тебя в какой-то момент делается пивот. Ну или в целом ты переосознаёшь какую-то подсистему или просто требования так поменялись, что сам принцип разбиения, который ты сделал, он становится тупо неправильным. То есть, если дальше продолжать это делать, то у тебя сами потоки данных, сложности, объёмы, всё остальное будут адом. И по факту для того, чтобы двигаться дальше нормально, сначала надо перераспределить. Мне всегда казалось, что это одна из причин, по которых микросервисы хорошо работают только в том случае, если у тебя зрелый бизнес, в котором, в принципе, вот это всё устаканено. Если у тебя это меняется, скорее у тебя даже шансов нет это изменить. Настолько это сложно, как бы, в существующей системе, что ты происскажешь. Я согласен, это тоже одна из причин, по которой я рекомендую, как и многие ребят, рекомендую начинать с монолита, потому что кроме того, чтобы правильно поделить на сервисе, надо очень хорошо как бы иметь собственную экспертизу, чтобы это сделать корректно. Но этого мало, если бизнес будет меняться, а бизнес будет меняться, нестабильный. Да, дада, да. И как бы есть какой-то очень узкая прослойка бизнеса, где вы там, не знаю, что-то прямо копируете, делаете клон какого-то сервиса, который вы сами и делали, условно, там просто на какую-то другую аудиторию, на другой, может, там какой-то континент, да, тогда, да, можно начинать как бы с той же командой, условно это можно делать, но если вы как бы с бизнесом делаете какой-то стартапчик, лучше делать проще и изменяемый. Изменяемый. Тут, кстати, вот те же паттерны проектирования, они тоже про это, они как бы мешают часто. То есть я, например, сторонник того паттерна if условный оператор. То есть везде, где можно, надо написать условный оператор, а не стратегию или чего-то такого плана, потому что несмотря на то, что там условная стратегия тебе даёт э там некую гибкость, конфигурируемость и прочее, по факту придёт чувак от бизнеса и он придумает какую-то такую хрень, которая вот ни разу вот ты не мог даже представить, и она разорвёт в твою стратегию просто вот. И тебе придётся теперь писать, тебе будет больше кода. А чем проще ты пишешь, тем тем тем проще это просто выкинуть, потому что у тебя сейчас ещё if не линейный, потому что у тебя там общая какая-нибудь логика между тремя стратегиями пересекается. Это действительно правда. Я всегда, кстати, про это говорю, что полиморфизм у тебя - это просто замена ифов. Если, знаешь, вот редкие случаи, когда это хорошо прокатывает. Я вот на это с этим столкнулся. Мы для стриминга видео использовали джавовую фигню, которая действительно конфигурилась там настройками, где ты просто можешь, то есть мы в код вообще не лезем, мы не занимаемся им, но у тебя плагины конфигурируются им таким образом. И внутри я знаю, что там просто идёт подмена имплементации, он прокидывает другой класс и реализуется. Это один из, знаешь, редких случаев, когда этот open close и всё остальное действительно так сработали. Я такой: "Да, вот вот это действительно похоже на реальность". Но оно работает только, когда ты не владеешь этим кодом, и ты не имеешь права туда залазить. А если твой код, ну, не будет никакого динамического конфигурирования, что мы сейчас класс какой-то подставим. Ну, яме, вот это классика. А если базу данных захотим поменять? Ну, это, кстати, тут, знаешь, уже с базами данных же скорее сейчас ситуация такая, что да, действительно, поменять нереально. Хотя в моей практике было, я менял, прикинь, мы переходили с МQL на Постгрес, но у тебя просто так работают коннекторы к базам. Они типа обобщены, в принципе. То есть даже если ты постараешься, ты не найдёшь адаптер под конкретную базу, если это просто реляционка, например. Да. Ну проблема же не не в коде, а в том, какие запросы туда пишешь, условно говоря. То есть даже вот пример вот ээвели, вот на мой взгляд - это фрактал плохого дизайна, и мне с ним пришлось достаточно плотно поработать в белке. И там был такой пример, там был была инкапсуляция Редиса, две разных. типа два класса из того, какой под капотом модуль ты используешь, там типа нативная библиотека или написано PHP. И прикол был в том, что как бы выглядело одинаково, был интерфейс, но они кидали разные эксепшены. И с точки зрения интерфейса логического, эксепtion - это часть интерфейса, но PHP, например, не позволяет тебе задать на уровне как бы синтаксическом, какой эксепшн у тебя выкинется. Это очень частая проблема, когда на это как-то забивают и получается то, что у тебя как бы есть какой-то интерфейс, который как бы букве соответствует, но духу нет. Ну да, потому что статически проверить можно мало, на самом деле, что даже если у тебя есть, потому что действительно ты можешь скинуть что угодно. И тут мы вспоминаем про монатки, про ошибки в Расти и другой способ вообще работа с этим, где такие проблемы сильно уменьшены, прямо сильно. А нам остаётся только немножко завидовать, если мы не пишем на этих языках. Да, слушай, мне кажется, это неплохо получилось по поводу вот понимания, когда, где какие микросервисы должны появляться. А а есть ли вот с платформенной точки зрения готовые решения? Потому что почти всё, что я слышу, а это решение прямо целой платформенной команды, которые внутри сидят и тебе вот эту экосистему готовят. А сейчас не существует каких-то штук, где вот реально под конкретные фреймворки, это, я не знаю, там берёшь штуку, она такая: "Мы сейчас всё тут вам отторкестрируем". Ну, с шаблончиками, со всеми делами. Наверное, ближе всего к этому подобрались различные код технологии и лямда программирования. Вот это вот, где у тебя ты платишь в САС, ты пишешь какие-то чуть не в веб-интерфейсы, какие-то кусочки кода, ты пишешь, ты их там стрелочками соединяешь, и, в принципе, можно это вести бизнес, да? А ещё у тебя есть какая-то экселька в виде базы данных. И на этом можно вести бизнес, на самом деле. И на самом деле у меня такой есть такая позиция, она звучит так, типа, highло - это то, чего надо бояться как чума, если ты бизнес. Потому что - это про то, э, скажем, это не не про количество РПС, это про состояние душей, когда у тебя простая задача решается отделом инженеров, просто потому что она иначе не решается. Вот. То есть, если есть возможность этого избежать, надо этого избегать. Мне кажется, ты прямо предугадал мой пост, который я в телеге на следующей неделе спланировал, как раз про то, что почему всё, что вы любите, мешает бизнесу, там микросервисы, хайлоуды и так далее, что это всё надо воспринимать как абсолютное зло, которое мы делаем только потому, что у нас нет выбора, а не потому, что мы туда стремимся, иначе бизнесу от этого только хуже. Что так немножко убивает такую. И самое страшное, что, э, часто ребята к этому стремятся не потому, что это надо, а потому, что либо им так кто-то сказал, да, вот что вот надо хэллоу себе придумать, да, а либо от каких-то там собственных амбиций или каких-то ожиданий, да, ээ часто люди переусложняют системы, когда вот нет никакой причины. То есть опять же той же белки, например, да, было, мне кажется, пять инженеров и 30 сервисов. Вот я считаю, что когда у тебя сервисов больше, чем инженеров, у тебя вот что-то прямо точно не так. Вот вот те количественный критерий очень простой. Вот. Ну, кстати, это, наверное, касается в первую очередь своих сервисов, которые ты нарил, потому что потому что, да, чужих ты используешь просто по необходимости. Если тебе надо интегрироваться с какой-нибудь, не знаю, с Бером. Ну, ну ты их как бы не поддерживаешь, это очень важно, да? А вот эти как бы, ну, ты поддерживаешь. Слушай, а, кстати, знаешь, ещё что хотел спросить по поводу коммуникации? Мы с тобой говорили, но существуют ли какие-то стандарты по коммуникации? Потому что одно дело, ты берёшь кавку, а другое дело, что из себя представляет сообщение там, потому что вот есть рест, да, более-менее понятно, но даже его недостаточно, тебе надо договариваться о структуре сообщений. А вот когда мы говорим про шину, э мне почему-то кажется, что по дефолту там кто в лес, кто в подрова у тебя начинает там гулять абсолютно рандомные сообщения. Это очень типовая проблема, на самом деле, которую, на самом деле, вот по моему опыту каждая компания решает индивидуально. Вот каждая крупная компания, вот если ты посмотришь там про это, обязательно у неё есть доклад, потому что они героически прямо решают, потом выходят на халоу и рассказывают, как они изобрели какую-то там свою обёртку надбасом, обёртку, которая валидирует события, которая имеет какой-то реестр этих событий и так далее. Есть на рынке различные инструменты, из которых как с кубиков это можно собрать. Но опять же, как я говорил ранее, этого мало. Замок всё равно надо собрать самостоятельно, потому что есть система сериализации, то есть у Кавки, мне кажется, есть Авра, которая более-менее нативна. Можно стерилизовать там события, например, через протобаф тоже будет целом неплохо. Но но это всё нужно внедрять ещё и в культуру, да? То есть мало сделать тулинг. Надо, чтобы ещё люди понимали, условно, как делать так, чтобы там спека не ломалась там конзистентно и прочее. Вот есть всякие тулзы, которые за этим следят. В целом их можно использовать, но обычно применяется вот некий микросервисный подход. То есть есть какая-то заградительная точка входа, например, сервиса OneB, и туда шлются там, не знаю, там по HTP или по GPC события, и вот она уже перекладывает в кавку. И вот она валидирует, что ты там условно правильное событие отправил. Либо есть какая-то библиотека на твоей стране, которая делает то же самое, но условно без сервиса, но нужно вот либо есть какая-то там система, которая на кодрев там как-то типа отлавливает. Тут кто как придумает, на самом деле. Ну на уровне типов тут понять не наверное проще, потому что есть у тебя статически типизированный язык, ну у тебя может просто всё быть типизировано и генерируемо, что очень важно. И а плюс ещё же JС схемы, там всё это позволяет много чего сделать. Я скорее именно про сам язык внутри. То есть есть ли какие-то принятые стандарты о том, как лучше сообщения в таких системах отправлять? Ну, начинает от того, в какое поле данные, в какой метадата и так далее. Или потому что в ресте, ты знаешь, там же рестрестом, а помимо этого там существует ещё 500 способов, как упаковывать данные там Jason API. Слушай, я считаю, что такой же пузырь, как микросервис. Вот, честно, вот это одна технология, которую я так и не понял, почему её так любят. На мой взгляд, она ужасна. Я больше сторонник RPC решений различных. То есть, ээ, идея, вот я считаю, что нет никаких ресурсов, да, в которые ты ходишь постом игетом, а есть у тебя функции, которые ты можешь методы, да, которые ты можешь транслировать там в разные другие системы. Поэтому мне нравится очень GPC, мне нравится Tви, такая вот вариант реализации GRPC на минималках. Мне нравятся разные там Jonor PC схемы и так далее. Вот они как бы это транспорт. А я вот как раз про следующий уровень. Это я вот не знаю, сколько ты знаешь. Нет, вот если ты берёшь, допустим, Rest API, а у тебя в любом случае там тот же Stribe, GitHub, там вот REST API, а они часто не просто говорят, что вот у нас Rest API, вот такие данные, а мы соответствуем какому-то некому стандарту, потому что есть Jon API - это прямо спека к того, как типа упаковывать данные, там атрибуты, данные, метаданные, есть, есть HOS OS а есть ещё там гиidra и там ещё десятки их. Они и среди них не Joni, наверное, самый популярный был, но в целом всё. Иначе просто получается абсолютный разброт и шатания, да, кто в каком формате там данные, кто с заголовками, кто ошибки в коде передаёт, кто ещё что там, всякий бред. А RPC в этом плане всё равно ещё более разнообразный, потому что тут хотя бы у тебя есть getпост там, ну что-то, а здесь у тебя вообще в принципе функция, как и написал, так и написал. И вот я спрашиваю, существуют ли внутреннее представление о том, как эти функции, грубо говоря, проектировать или вообще кто влез в подрова? В хорошее компании они обязаны существовать. Они обязаны существовать, и все к этому приходят. Ответ скорее в формате того, что я не знаю каких-то внешних стандартов, то есть таких, которые бы вот все использовали как, да, общеприняты. Вот то, что я вижу, каждая компания на каком-то этапе своего развития, во-первых, каждая компания обязательно напишет свою адаптер базе данных. Вот это вот, сколько я не работал всегда, вот есть какой-то самописный адаптер базе данных. И, во-вторых, каждая компания вот решает вот эти вопросы, потому что есть вот этот класс инфраструктурных вопросов, которые которые надо решать в контексте. То есть они вот их нельзя просто купить, нельзя просто их интегрировать, да? И вот сама интеграция, вот это вот тоже про саму интеграцию. Люди такие: "Так вот, ну вот мы вот привыкли вот так работать, работали, работали, а теперь давайте наведём порядок". И обычно люди как бы стандартизируют тот процесс, который уже у них в каком-то виде был. И поэтому у них получается что-то своё. Если какой-то чувак там переходит из этой компании, какую-то свою там начинает там с нуля делать, тогда вот он, скорее всего, просто то же самое перетянет. Но так как все компании плюс-минус уже основаны, э, существующие большие, да, и они все были основаны достаточно давно, то они все проходили вот этот путь, когда не было этого стандарта. Ему поэтому нет куда особо появиться, потому что никому это уже не надо. У них уже есть свой. Угу. Такой вопрос, возможно, наверное, уже последний. Мы про Gway API давай чуть-чуть поговорим. А ты просто в какой-то момент упомянув его, заодно сказал, что он тебе не очень нравится. А можешь пояснить, что почему? Мне много черви. Ну давай, давай про него поговорим. Давай. Это вот паттерн, который у нас был в Белке. Там была как раз вот эта идея про то, что есть Ну сервисы они независимые. Там ребята старались делать как бы по концепту, что сервисы они вот эта ручка в этот сервис, это в этот и так далее. Но по факту это приводит к чему? К тому, что у тебя есть на самом деле основной клиент, то есть, например, в случае Белкар - это мобильное приложение. И вот этому клиенту нужна опишка. Я сторонник того, что опишки должны проектироваться под клиента, не под сервисы, которые у тебя тут напилены, а под клиента. Потому что если ты делаешь под сервисы, у тебя получается ситуация, где тебе нужно условно трендерить экран на мобиле, потому что его так дизайнер нарисовал. Для этого тебе нужно там пять каких-то разных ручек дёрнуть, потому что вот они в таких сервисах находятся. Так вот такая вот инфструктура. А я больше сторонник паттерна фасад. То есть вместо API у тебя есть фасад API. То есть есть какая-то точка входа, которая версионируется под конкретного клиента. Первы вот под мобильное приложение. И вот он эти запросы может транслировать в запросы к сервисам. И если у тебя, например, меняется контракт сервиса, а мобила не обязана что-то с этим делать, потому что может как бы транслироваться вот на этапе дальше. Тебе не нужно просто прокидывать, как есть. Плюс всякие там просто авторизации можешь на себя тоже брать и так далее. И это очень сильно упрощает взаимодействие с клиентом. То есть ты можешь как бы версионировать IP под клиента. Я тоже сторонник того, что у тебя как бы одна версия на IP, не на ручку, да? То есть ручка 1 2 3, а вот есть API версия 1, а есть API версия 2 и так далее. При этом эти подходы достаточно легко существуют, потому что вот нужна темновая ручка, ты вот просто рядом ещё одну сделал. Вот в RPC - это просто. Ты назвал там у тебя есть create user, ты сделал Create user 2, вот я любитель таких вариантов. И начинаешь еюзать, и ничего страшного того нет. У тебя условно есть старые мобила, которые юзает старую ручку, новая юзает вот другой сет ручек, и в какой-то момент у тебя не остаётся живых мобил, которые юзают вот старый сет, и ты просто вот вырубаешь эти ручки, удаляешь, тебе это всё прозрачно, когда у тебя есть AP gateway, а, и тебе по условно через этот же AP Gateway ходит и мобила, и админка у нас ходила, и кол-центр ходил через тот же AP gitway, получается, во-первых, ручки начинают расти по, условно говоря, вот нужно отри рисовать там карту с машинами, а она там ещё какой-то каунт считает тяжёлый на базе, потому что для админки нужно там какую-то там сумму посчитать там по деньгам, что-то такое, а пользователю это не нужно. При этом с пользователя условно в 1.000 раз больше запросов идёт, чем с колent. Но как бы у тебя концепция, что вот у меня просто сервисы как наружу торчат. Если ты начинаешь их затачивать под задачу, то есть вот делаешь вот это вот фасад, который, ну, начинает там в одну ручку, в другую ходить в разные, то всё начина сильно быстрее работать по факту и проще интегрироваться к клиентом. Это, кстати, проблематика абсолютно актуальная для любого проекта, даже без сервисов и микросервисов, потому что у тебя, допустим, всегда есть, ну, мобилка, у тебя есть админка, и в админку там даже часто авторизация и так далее, там свои истории. У тебя всегда есть фронтенд, в принципе, да. Ну и, соответственно, внешние клиенты, которых тоже может быть разное количество. И я тоже с этим часто сталкиваюсь у себя, когда такой понимаешь, что попытка делать унифицированную историю вообще не работает. Это плохая идея. Плохо для всех получается, да? Это это плохая идея. То есть я пришёл к такому подходу, что у меня есть там что ещё интересно в контексте белки. Мы переделывали по сути микросервисный подход, не получившийся, на мой взгляд, но какой-то какой был в сателлитную архитектуру. То есть я вот взял на себя ответственность, я выбрал какой-то самый жирный сервис, сказал: "Вот это будет нашим монолитом теперь". И начал туда прямо сливать какие-то сервисы. То есть вот пошёл прямо вот против шерсти относительной индустрии, начал наоборот их как-то монолитить, там парами сливать, как что-то в этот монолит. И в итоге мы этот фасад запихнули в этот сам монолит, потому что по факту 80% запросов от пользователей этот монолит как бы и обрабатывал вполне себе спокойно, без похода в какие-то другие сервисы. Это очень сильно ускорилонси, очень сильно ускорило самы запросы по факту. Вот просто с ничего просто потому, что мы убрали ненужный какой-то ход между гейтвеем, там ещё одним гйтвеем, сервисом авторизации, сервисом юзера. И только потом мы там доходим до до ручки, мы всё это делаем в одной транзакции. Просто вот так жик. И всё. Вот. Получилось очень удобно. Очень быстро это стало разрабатываться, потому что теперь хочу сделать в среднем там два сервиса занимают, не пять, как было раньше. Угу. У меня, знаешь, есть такое внутреннее правило, которое в какой-то момент выработалось, касаемо вообще разработки сервисов и опишки, в частности, мне всегда, знаешь, как помогает? Мне всегда помогает, когда я начинаю об этом не думать, не просто такой: "Так вот у нас там какая-то штука, надо с ней как-то взаимодействовать, как лучше сделать, а я всегда представляю так". Но ведь в интернете есть отдельный сервис, который, например, занимается, не знаю, это CDпишка или это CRM маркетинга, тулза какая-то, тот же самый билинг и так далее. А как бы я это проектировал? Как бы я это сделал, если бы я делал вот именно сервис, который торчит для пользователей в сети, просто бизнес отдельный. И как только я начинаю таким образом думать, вдруг все вопросы становятся очевидными, что, ну, вот это было бы глупо так реализовывать, ну, типа никто бы этим не смог пользоваться и так далее. И это всегда помогает, как раз мне вот я начитавшись, полюблю это слово барьеры абстракции. То есть вот ты как раз понимаешь границу, где у тебя барьер и как, собственно, с этой штукой взаимодействовать так, чтобы было удобно. Не то, чтобы я собираюсь это делать, но каждый сервис я в такой случай рассматриваю с точки зрения того, что а если бы мы его отчуждали от нас и сделали бы для всех на продажу, типа вот эта штука будет просто сервисом в интернете, да, на продажу, на развитие, сайтпроект, всё, что угодно, и у тебя всё становится очевидно сразу без проблем. Да, но при этом, на самом деле, тоже, наверное, важная тема, которую стоит поднять, она заключается в следующем. Иногда чётко понятно, как правильно, то есть условно там правильно вынести библиотеку, чтобы там использовать код и тут и там, да, правильно сделать там какое-то асинхронное взаимодействие, так чтобы у тебя данные дублировались, там по кавки приезжали, сохранялись в эту базу, то же са тоже, да, потому что это тоже один из паттернов, где так у тебя базы данных разные, тебе нужно дублировать данные начинать и ещё делать так, чтобы они как бы консистентно дублировались. Но у тебя есть альтернатива. У тебя есть альтернатива - это типа сделать HTP запрос. Вот тоже ты спрашиваешь, типа, вот когда HTP запрос надо делать? Вот у тебя есть инициатива сделать HTP запрос и HTP запрос сделать типа в 10 раз дешевле, а у тебя сроки горят, и ты сидишь и такой типа вот я могу сделать красиво, но мы там условно не успеем там в определённую дату и не получим профит с этого. А могу сделать как бы ну быстро, как мне концепция быстро и правильно, да? Я я вот не люблю красиво, потому что знаешь, это часто к ковенженирингу тянет людей, да. Вот если действительно ты знаешь, вот это правильное решение, а вот это решение быстрое. И часто сначала делается быстрое, а потом правильное. Но в этом заключается, кстати, инженерная взрос. А потом не делается правильно. Может быть, но в любом случае инженерная взрослость, по мне, когда человек видит эти альтернативы, знаешь, когда вас съели, у вас всё равно есть два выхода. Часто же бывает так, что решение принимается именно потому, что человек не видит другой альтернативо и не понимает, это правильное или неправильное решение. И вот тогда это проблема. Причём страшно, когда оба варианта, когда он не видит ни левого, ни правого решения. То есть, если он условно видит только овенженерию, это тоже плохо. Если он видит только простые решения, неправильные условно, какие-то концептуально, тоже плохо. Надо действительно иметь иметь видеть оба, потому что мне просто вот как раз-таки напомнило то, что сказал, что типа надо вот к сервису относиться, как будто ты его продаёшь там условно, как будто на внешней. Это часть часто дороже. Иногда есть какие-то обходные пути, где вот ты можешь делать как бы здесь, сейчас. Ну понятно, вот по факту мы же никого продавать его не будем, скорее всего, условно, ни в какой интернет мы его не будем выдавать. И ты понимаешь, как можно делать правильно, но всё равно надо делать как бы по-простому, просто потому что как бы, да, нужно делать фичи. Мы здесь, чтобы делать фичи. Здесь именно вот это вот важно подчеркнуть. Я знаешь, как это называю? Я люблю такой подход и про него часто рассказываю. Это идея из триза идеального решения. То есть, грубо говоря, когда ты пытаешься придумать что-то новое, что-то тебе надо сделать, а всегда начинай с решения, которого нет ограничений, потому что если ты сразу начинаешь исходить из текущего стейта, ты 100% [ __ ] спроектируешь. То есть надо делать так, что вот, ну, нет никаких ограничений, вот я делаю отдельный сервис, как бы я видел так, чтобы он был построен идеально. И вот только когда у тебя это есть, ты такой: "О'кей, а теперь где я реально нахожусь?" И вот теперь ты в голове эти две точки сводишь к какому-то компромиссу, думаешь, как его деградировать теперь, учитывая в том числе сроки и горение, всё остальное. Дадада. То есть у тебя реально деградация начинается, но ни в коем случае не в обратную сторону. Если ты начинаешь сразу вот так у меня вот ограничение теперь, что я могу сделать? Я готов поспорить, что во всех таких ситуациях решение будет [ __ ] потому что оно будет не пойдёт в правильную сторону. Лично поему опыту, мне кажется, в какой-то момент развития инженера возникает тот момент, который даже сложно объяснить, когда ты как-то параллельно думаешь в в обе стороны. То есть ты как-то параллельно два варианта сразу в голове крутишь достаточно быстро. И вот они где-то сходятся как бы сами. на интуиции часто, да? То есть ты даже можешь не рефлексировать, что у тебя это происходит. Вот. А на самом деле оно происходит. Это есть такое, знаешь, ещё когнитивное искажение, называется проклятие знания. Как правило, люди, которые больше всего топят за то, что тебе не нужно знать это, это, это, они это всё знают. И более того, они не могут это отделить от себя. Они не могут сказать, насколько это влияет на их мышление, на всё остальное. Поэтому все эти разговоры, они всегда очень сложные. То есть человек говорит: "А этого не надо знать". Так может быть, половину своих решений он принимает только потому, что он это знает. Но это настолько на подкорке, что он уже это не включает, и ему кажется, что оно здесь не участвует. А понятьто ты уже не можешь, всё, оно уже у тебя там прописано. Вот здесь пример, мне кажется, такая же история, да? То есть, когда я про это говорю, это не значит, что я такой так, знаешь, мыслями это проговариваю. Это скорее автоматика, которая там за секунды пробегает, пока в душе мылся, у тебя пам-пам-пам-пам всё разложилось, и ты пошёл уже набрасывать, точнее сказать, командовать агентами мысленную разработку, да. чтобы они писали код. У меня вот про такие знания на подкорке как раз-таки тоже анализировал. Вот я занимался лепиным программированием какое-то время, там в школе ещё и проче достаточно такая область специфическая. Я в какой-то момент задумался, типа вот сколько раз в жизни я на реальной работе с тех пор там применил какой-то прямо алгоритм, да? Я типа насчитал два раза. Вот у меня там карьера там лет 17, наверное, я так или иначе в разработке. И вот два раза я прямо написал веб-разработки на PHP, там какой-то алгоритм типа из олимпиадного программирования. И это было абсолютно бесполезно с этой точки зрения. Однако я считаю, что на самом деле сам вот этот фактор решения задачи, понимания структуры данных на меня очень большое влияние оказал, несмотря на то, что я алгоритмы не пишу. Я, например, хорошо их теперь понимаю и хорошо понимаю структуру данных. с базами данных мне очень легко за счёт этого, потому что, аэ, как бы мне такой термин нравится, вот который я приодически использую, это как бы некая инженерная физика. То есть я считаю, что все системы, они как бы построены на одних и тех же каких-то принципах внутри. Внутри везде ифчики и циклы в итоге, да, эти ичики и циклы складываются в какие-то структуры данных, которые вот имеют физические ограничения. То есть у тебя там сложность какая-то, у тебя есть там три алгоритма разных и других нету на самом деле, чтобы решить эту задачу. И когда ты всё начнёшь понимать, ты потом смотришь на какую-то систему, которую ты в глаза раньше не видел. Там какую-то базу данных ты берёшь, и ты уже можешь очень хорошо моделировать, а как она себя поведёт в разных ситуациях. Ты можешь делать какие-то, скажем так, допущения, что типа вот здесь она будет работать, потому что ты как бы в принципе понимаешь, как она устроена, потому что всё плюс-минус устроено одинаково, и это очень сильно помогает в работе. Ээ такой вот навык декомпозирования систем, которую даже не видно, конечно. Ну и вопросики правильно задавать сразу, а потому что у тебя есть понимание картинки более широкое, да? Слушай, мы так с тобой от микросервисов пришли, кстати, к общим инженерным штукам, но мне кажется, это в данном случае логично, потому что здесь это действительно та вещь, где нужно очень много применять мозгов, а для того, чтобы нормально получилось, потому что, а, писать код в конкретном месте действительно, может быть, становится чуть менее актуально знать все прямо как, особенно, знаешь, PHP, помнишь, раньше было там функцию каком параметре, там такая микрооптимизация, тут, значит, это всё действительно чуть-чуть становится неактуально. А вот на уровне систем принимать правильное решение, тебе никакая ишка потом не поможет, если ты уже плохо сделал. И вот это всё надо переделывать. Очень легко в катастрофу завести любую проблему. Да, очень дорого менять разрезы между сервисами, менять структуры данных, менять связи этих сервисов друг с другом. Ну, интерфейсы, да, во многом интерфейсы, они, конечно, тебя просто тебя цементируют, как бы в том состоянии, в котором есть налити дешевле. Лёш, тебе большое спасибо. за то, что ты пришёл, поделился своим опытом, так сказать, и наработками. Я надеюсь, что, ребят, вам понравилось. Напишите про ваш опыт. Был ли он позитивный или негативный? То, что вы видите в своих компаниях, является ли это культом карго? Классно ли всё это используется или вот есть те вещи, о которых мы говорили? Я подозреваю, что они наверняка есть. Компании можно не называть. Мы сами по контексту попробуем догадаться. В общем, Лёш, ещё раз спасибо. Спасибо тебе, что позвал. Было очень приятно прийти. Да. Всем пока, до новых встреч. Подписывайтесь на канал, ставьте лайки. Мы всё это ждём и любим.