Ах, как хочется вернуться, ворваться в монолит! / Павел Лакосников (Авито)

[@ВладимирАкимов-х5х]

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

[@nomorerabb1ts]

Кажется, эффективные менеджеры уже придумали, чем будут заниматься в Авито последующие 8 лет :-)

[@TheMMgo]

Портить малину инженерам и запиливать сервисв обратно в монолит, конечно-же :sarcasm:

[@romanbush5164]

Согл, а когда команда из 5 человек, 3 из которых разработчики бэка, решают распилить монолит и идти в микро сервисы, я не знаю как это назвать... В мелкой компании где всего 10 сотрудников

[@nikitavilunov1913]

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

[@SergeiPeshalov]

Полная чушь. 1) "Десять подзапросов на каждый запрос" - самый обычный случай - у тебя конвейер. Там хоть 100 будет - и что дальше?. 2) Если у тебя запрос ложится в 2-3 подзапроса - у тебя настолько ничтожно-малая система, что не понятно нафига вообще тебе микросервисы?

[@proger150]

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

[@TheMMgo]

К счастью участь распределенного монолита мы избежали. репликация данных из сервиса в сервис - есть такой подход, да. Но это - не самый дешевый подход (особенно на масштабах Авито с десятками террабайт данных в сервисе), требует вместе с данными тащить и логику их получения\заполнения (ведь сервисы это таки не CRUD, а если CRUD - у тебя проблемки) Идея в том, что если у тебя глубина цепочки >1 ты уже не можешь поставить бряку в произвольной точке, как раньше. А этого ох как хочется.

[@constantinegeist1854]

"Неправильно распилили монолит" - это как "real communism was never tried". Есть якобы какой-то идеальный распил, но никто его не видел

[@bgckrbm]

Все знают, что распил монолитов придумали для распила фота.

[@dmitriyobidin6049]

Микросервисы - это следующий этап развития монолита. Не альтернатива, как многие думают. Для 99% компаний SoA, по сути флот из малого количества средне размерных монолитов общающихся по общей шине(той же кафке) - золотая середина.

[@sasichkamega]

Чё такое SoA нахой?

[@germanmalinovsky1719]

@@sasichkamega Service-oriented architecture

[@germanmalinovsky1719]

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

[@funcelot]

Основные недостатки монолита - это limits по coonection к DB, и TCP pooling (почти одно и то же), количеству соединений с клиентами. Если решить обе данные проблемы изменением исходного кода операционной системы хоста, базы данных и клиента, (т.к. аппаратное железо стало в 400 раз мощнее, чем в 1980 году, когда оформилась модель OSI и ограничения по стеку TCP/IP, например. Если на WX3990 можно свободно повесить в 400 раз больше пользователей, то экономия составит те самые 95% (но это потребует скилловых системных программистов, и отличных девопсов, способных сделать хороший api-gateway на lambda)

[@-dubok-]

Проблема микросервисов в том, что из-за синхронной манеры общения между ними (в стиле запрос/ответ) они в сумме мало отличаются от монолита - просто добавляются сетевые издержки и куча условностей в общении между ними. Если не поменять сам подход к созданию системы, то у вас так и останется монолит, но прибавится куча проблем. А выход - в EDA, event-driven architecture, в событийно-ориентированной архитектуре. И, по идее, надо изначально делать систему именно такой. Распилить монолит и сделать его в другой архитектуре не получится. EDA - это асинхронный подход к созданию распределённой системы. Из-за этого прямые связи между модулями отсутствуют, передаются безадресные события через некого посредника-шину. Это делает систему очень надёжной, устойчивой к выходу из строя отдельных модулей (например, во время их обновления), а также к полной независимости модулей друг от друга, что и позволяет использовать любые языки. Всё, что общее - это события, которые все модули понимают одинаково. Но EDA - это совсем другой мир и тут надо совсем по-другому мыслить и изначально делать систему в таком виде.

[@i.p.1832]

EDA не панацея и не серебрянная пуля. Посмотрите полезный доклад на тему Event Sourcing You are doing it wrong by David Schmitz

[@-dubok-]

@@i.p.1832 event sourcing не равно EDA. Эта технология может использоваться вне EDA, а EDA может не использовать event sourcing.

[@-dubok-]

​@@hloraet по существу ничего не сказал. Кроме наезда уловил только мысль о том, что иногда нужен мгновенный ответ. Само собой, но как раз-таки глупо использовать этот паттерн в сложной системе, где нужна модульность для простоты поддержки и разработки. Одной команде сложно работать с монолитом, даже разбитым на микросервисы. Там, где нужен быстрый ответ, там его и нужно использовать, а если он не нужен (что чаще всего и бывает), то лучше использовать события, потому что они делают части системы независимыми и самодостаточными, о чём мечтают все нормальные программисты, потому что такой код проще контролировать.

[@-dubok-]

​@@hloraet вообще не согласен. Как показала практика, именно асинхронные приложения и сервера самые быстрые! Как яркий пример, победа асинхронного Nginx над тормознутым и жрущим море памяти синхронным Apache, также это победа асинхронного Node.js над серверами на Python и других синхронных языков или подходов к написанию серверов. Вроде бы и Node.js и Python интерпретируемые, содержат оба море оптимизаций, но асинхронный Node.js в разы быстрее Python в серверной части. И только асинхронные реализации серверов на Python'е показывают нормальную производительность. Асинхронность - это лучшее решение для серверов, потому что такова их сущность. Синхронные вычисления нужны в других областях, там, где всё предсказуемо, где нет ожиданий, а почти в любом приложении так или иначе они есть: даже ожидание записи в базу - это уже задержка, и ты какую технологию не используй, запрос/ответ или очередь, всё равно будешь ждать. Синхронность нужна на низком уровне: например, при обработке игрового цикла, когда fps стабилен и когда постоянно повторяются одни и те же циклы. Она нужна в драйверах, когда задержки предсказуемы. Но любые места, где ты не можешь быть уверен, что не будет задержки, предполагают использование асинхронности. Сервер - это обработка множества запросов, очереди тут будут в любом случае, вот поэтому асинхронность в серверной части - это must have, без этого ни один сервер работать скоро не будет, просто потому, что не выдержит конкуреции. Да и уже все крупные компании используют приложения на основе шины событий. Kafka у всех на устах не просто так.

[@shadowfaxenator]

@@-dubok- корректнее сказать не быстрый, а синхронный, но полностью поддерживаю все вышесказанное. EDA, это то, что люди просто отказываются признавать, потому что свои ошибки в проектировании очень сложно сразу признать. Нужно уметь рефлексировать.

[@ddruganov]

извините конечно, но 2.5-4к сервисов? я может чего-то не понимаю, но откуда они берутся? на каждую кнопку свой сервис?)

[@TheMMgo]

в Авито 5 больших, не похожих друг на друга, вертикалей бизнеса: Авто, Работа, Недвижимость, Услуги, Товары Каждая вертикаль - живет по своим законам. Считай - что каждая вертикаль - отдельный бизнес, отдельный(нет) набор микросервисов. Добавим сюда - пачку внутренних сервисов, и пачку тестирующихся в моменте АБ-тестов (иногда с отдельными мини сервисами под эксперимент)

[@redneck_prm5429]

@@TheMMgo А сколько в среднем выходит численность команды, поддерживающей один микросервис? Или на таких числах уже выходит несколько микросервисов на команду?

[@TheMMgo]

@@redneck_prm5429 сложно ответить, владение сервисами идет не персональное а командное. и это сильно зависит от самой команды, ее размера, ее бизнес-домена

[@viacheslav90]

На каждого бекендера по сервису)) Мне кажется что большинство проблем у них из-за того что слишком мелко все распилили

[@N5O1]

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

[@nekodim]

Версионность на 2К микросервисов в принципе не рассматривается? Даже если представить не 2К, а хотя-бы 200 микросервисов в бакенде, включить версионность, совместимость (матрицу совместимости АПИ), и кросс-тестирование совместимости всего этого после нескольких лет интенсивной разработки, не забыть про поддержку старых версий и прочее. Теоретически можно, если 50 человек на саппорт архитектуры, но это не точно.

[@TheMMgo]

версионированность чего именно? у нас внутренние методы, и события версионируются. есть постоянное контрактное тестирование как часть жизненного цикла ЛЮБОГО сервиса. И теперь это не требует 50 человек на поддержку (часы поддержки тратим на иное =))

[@sergeya3184]

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

[@TheMMgo]

могу сравнить только было и стало. Но это 2 разных Авито. Число фич и развесистость функционала выросла кратно, кмк.

[@qinabu]

"Сорян-мусорян", но кто написал 2300 сервисов? Кто отвернулся в другую сторону когда это случилось? =) Всем привет!

[@TheMMgo]

мы и написали, да -) И не стоит мое "нытье" воспринимать как сожаление о своем решении. Путь в микросервисы был долгим, дорогим. И мы многое потеряли в процессе - тот же дебагинг. Но оно того стоило в итоге. Хоть и жаль тот же дебагинг...

[@alexanderkolinchenko]

Микросервисы - имхо это только и исключительно про сохранение константной скорости разработки системы при любом дополнительном объеме этой разработки. Кардинальное упрощение большой части системы ценой сильного, но контролируемого, усложнения ее в целом. Уверен, что доп функционала, хотя бы близко сравнимого с тем, который заложен в 2500+ мс, в монолите за это же время, имея даже, не знаю, x2 людей, сделать было бы невозможно.

[@AndreiMoiseev-g2g]

Микросервисы - это способ раздувания хэдкаунта и ЧСВ менеджеров.

[@linermgn]

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

[@romanbush5164]

что 1000 микросервисов стало сложно поддерживать? и 200 которые неизвестно кто и зачем написал

[@TheMMgo]

все известно, все прозрачно. И их действительно поддерживать сложнее

[@Prof-Shor]

Вывод: пилите микросервисы, будете обеспечены работой до пенсии и даже после!))

[@urbalex]

Честно говоря, рассказ скорее выглядит грустно, чем поучительно. Over 2500 микросервисов, долгие релизы, огромные команды поддержки платформы. Вы точно поняли как делать правильно? это совсем не похоже на agile ни в каких местах. Для бизнеса это колоссальная боль маневрировать так медленно и долго

[@PsychoDelissemo]

Спасибо за доклад, все по делу от практиков 😊

[@yegorpetrov]

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

[@SebastianHagl]

Так радуйтесь, можно денег больше снять

[@germanmalinovsky1719]

IT болен слепым следованием моде.

[@andreiosipov2766]

Так сделайте им микросервис. Один.

[@3fsfqp]

Теперь я понял зачем понадобился хайп вокруг микросервисов. Вот приходит заказчик и ему говорят можем сделать монололит за n рублей, а можем сделать микросервисы за 5n рублей. Микросервисы лучше, но конечно, дороже. Заказчик верит. Для понимания разницы между монолитом и микросервисами особых знаний и технического опыта не требуется: есть аналогии из повседневной жизни. Профит. Конечно никто не скажет заказчику, что микросервисы не дают преимуществ. Это тайна. А вообще чего плохого, создаются дополнительные рабочие места, программистов становится больше, конкуренция среди них выше, зарплаты ниже. Микросервисы можно рассматривать как способ привлечь инвестиции в отрасль.

[@SergeiPeshalov]

Начало распила - реально горе от ума )

[@SergeiPeshalov]

И правильно что хочется! Монолит - сила! Микросервисы - могила! Микросервисы - для программистов с микропенисами!

[@TheMMgo]

У парней с монолитом 49.5 см

[@МихаилБратухин]

@@TheMMgo в диаметре!

[@alexchto]

@@TheMMgoвнутрь

[@uipo1122]

кажется для людей в вебе начинает доходить, а кто-то об этом говорит годами

[@ElisDN]

Ну давайте теперь слейте код 2500 сервисов в монолит и попробуйте запустить на ноутбуке :)

[@TheMMgo]

ну пока был монолит "все работало"

[@ElisDN]

@@TheMMgo Пардон, но то, что работало и влезало в ноутбук семь лет назад не заработает и не влезет сейчас, когда кода стало в ХХ раз больше.

[@Rusebor]

забавно, что этот комментарий, был сделан скорее всего из под ОС, которая представляет из себя монолитное ядро, в котором поболее чем 2.5к сервисов

[@ElisDN]

@@Rusebor В ядре Linux это 82 396 файлов с голыми процедурами и функциями на C, которые проверяются быстрыми юнит-тестами. Это не 2.5к модулей, обслуживающих HTTP-запросы и ходящих в свои таблицы БД и свои очереди, что нужно тестировать более медленными интеграционными. Но даже так каждый релиз ядра занимает 2 месяца, а свои проекты мы скорее всего релизим почти каждый день.

[@ElisDN]

@@Rusebor Я про простую математику. Что если микросервис из ~30 файлов и 3 таблиц в БД с 3 миграциями и 6 фикстурами можно на ноуте запустить и всеми линтерами и тестами разных типов проверить за 10 секунд, то после склейки 2.5к таких сервисов итоговый монолит из 75к файлов с 7.5к таблицами по 7.5к миграциям с 15к фикстурами эти же проверки займут пару часов.

[@mrvillst]

Офигенное выступление, выпал на "Позиция SRE" профилирование микросервисов, ахахахха

[@bfg5244]

Интересно, почему ни слова о SLA

[@delir0]

Видимо потому что с таким количеством микросервисов в SLA нет ни одной девятки)

[@TheMMgo]

Я рассказывал больше о DX Число девяток примерно одинаково Но достигаются они сильно разными подходами

[@dmitriyobidin6049]

8:50 Ну так если раньше собирались, то и при микросервисах будут собираться, т.к. скорее всего меняется апи/контракты/и т.д. А если меняется только внутренний код - то модули же решают.

[@vyacheslavkovalev9824]

весело, живо о печальном )

[@АлексейБондаренко-т8т]

Докладчик молодец. Можно и монолит держать, как микросервис. Т.е. можно проводить границы в рамках монолита. Авито - огромная компания. Если компания рога и копыта то там и микросервисов будет пару. Легко поддерживать.

[@redkostia]

Всё так. На текущем проекте сливаем обратно микросеоаисы в один сервис😂

[@artemiy_uo]

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

[@artemiy_uo]

@@hloraet ну не всегда. Долго работал в компании или где 10 сервисов на банке и в целом все не плохо.

[@АртемАрте-г5х]

@@hloraet нет. Там где не умеют в микросервисы а-ка EDA , а делают распределённые монолиты - там так, да. В общем-то во многих крупных русских компаниях почему-то не умеют в микросервисы и пилят распр. монолиты.

[@bananasba]

Обо всем и ни о чем

[@urbalex]

про амазон история в деталях выглядит совсем не так, как ее разобрали многие кликбейтные заголовки kzbin.info/www/bejne/p5_HhIueoNOriMU

[@SYMBAT.K.E]

Второй доклад от авито и опять фигня какая-то

[@nickyat2]

Переодически проскакивала мысль - что ты куришь докладчик?

[@TheMMgo]

не курю, спасибо-) но можешь угостить меня виски -)

[@proger150]

ну а как же офигенно огромной ттм в жирном монолите? Про проблемы сервис меша - это все валидно и инженеры страдают. Но профит для бизнеса огромен когда есть возможность доставлять гранулярно фичи без глобального регресса. Каким образом тогда как минимум гонять QA пайплайны? по всему монолиту сразу? Вы не назвали главного плюса который по истечению этапа мучений перекрывает все минусы - это быстрая адаптация к изменению бизнес требований(относительно быстрая конечно же). Как это делать в условиях просто тотально жирного монолита - не совсем понятно. Наверное в теме доклада ставилась цель донести только минусы, в противном случае вы через чур сильно нас напугали). Но на старте конечно это должен быть монолит чтобы компания смогла скоре заработать и не тратить на оверинжиниринг

[@nikitavilunov1913]

Ответ в том, что нужно не монолиты или микросервисы делать, а сервисы здравого размера, которые достаточно гранулярны чтобы их релиз не стопорил всю компанию, но достаточно большие чтобы не страдать от типичных проблем распределенных систем. А еще нужно осознавать дележку по бизнесу и дележку по техническим требованиям и не надо эти границы всегда делать одинаковыми. > это быстрая адаптация к изменению бизнес требований Мутно сформулированный тезис, который сложно конструктивно обсуждать. Монолиты в целом проще рефакторить, проще модифицировать при затрагивании нескольких доменов одновременно, следовательно он адаптируется быстрее. > Каким образом тогда как минимум гонять QA пайплайны? по всему монолиту сразу? Нет, гоняйте только по изменившимся модулям. Нет тулинга? Так там платформенная команда на 50 человек, может и тулинг сварганить.

[@proger150]

@@nikitavilunov1913 > Мутно сформулированный тезис, который сложно конструктивно обсуждать. Монолиты в целом проще рефакторить, проще модифицировать при затрагивании нескольких доменов одновременно, следовательно он адаптируется быстрее. Быстрая адаптация - это опять же вопрос размера этого монолита.Мой тезис имеет место быть только если работаем со сравнительно внушительных размером модульным монолитом. Автор доклада, как я понял, рассказывает о том что процесс распила был инициирован как рас тогда когда монолит стал жирным(в контексте их реалий). Опять же простота рефакторинга напрямую зависит от его модульности и от уровня изоляции доменов на уровне кода. Если мы говорим о четко выдерженных джентельменских соглашених, когда команды из соседних доменов свои ручки к чужим не суют(что тоже является соблазном и легко пропускается на ревью), если есть тулы которые позволяют делать различного рода рестрикшены на уровне контрибьютинга и т д . Я к тому, что в SOA границы четко расставлены по сервисам, есть возможность внедрения API first на уровне общепринятых инструментов(генераторы и свагеры...), есть железные контракты, которые поломать не так просто(элементарно на уровне приватности тех же репозиториев). В монолите, как вы выразились, для этого всего нужен кастомный тулинг(я конечно с монолитами таких масштабов не работал, может такого рода тулы и существуют. Как-то раньше до распила дело доходило). Если поделитесь ссылочкой на доклад где тема такого рода раскрывается - буду Вам благодарен > Ответ в том, что нужно не монолиты или микросервисы делать, а сервисы здравого размера, которые достаточно гранулярны чтобы их релиз не стопорил всю компанию, но достаточно большие чтобы не страдать от типичных проблем распределенных систем Да, да. Это тру. Микро или не микро - это всегда философский вопрос, ответ на который варьируется от мнения к мнению. Распиливая монолит на любого размера сервисы так или иначе придется делать саги разного уровня сложности(ну в большинстве случаев) и тут мы и сталкиваемся со всеми этими проблемами. Даже если мы начнем "Душить" монолит и по итогу будет монолит + пару сервисов, то уже распределенная система со всеми ее проблемами -> Нет, гоняйте только по изменившимся модулям. Нет тулинга? Так там платформенная команда на 50 человек, может и тулинг сварганить. Можно конечно, опять же вопрос выставления границ. Я с этим не сталкивался, потому как опять же не доводили до такого. Но пилить такого рода тулы - это уже сигнал к тому что какой-то булшит происходит и стоит уже задуматься о долгосрочной перспективе

[@proger150]

Да и к тому же сам факт того что весь биг тех переезжает(или уже переехал) на SOA - неоспоримое подтверждение преимуществ гибкости. Если бы проблемы распределенных систем были бы камнем преткновения , полагаю что CTO, за плечами которых опыта вагон и маленькая тележка, не стали бы тратить на это такое кол-во времени. Мода на сервисы переросла в эмпирически полученный ценный опыт по масштабированию и стала каноном хайлоада в той или иной мере(не придирайтесь только к словам плиз)

[@nikitavilunov1913]

@@proger150 > Я к тому, что в SOA границы четко расставлены по сервисам На практике это не так, вот даже у автора доклада походу получился распределенный монолит, и вообще, я лично никогда не видел хорошо поделенных микросервисов. Границы это не что-то что можно идеально понять с первого раза, а зачастую и со второго-третьего. И даже если ты их поймешь и реализуешь, может прийти что-то новое и затребовать пересмотреть границы. Перенести код между двумя модулями одного сервиса намного проще, чем между двумя разными сервисами, это и делает монолиты гибче. > легко пропускается на ревью Это очень хороший поинт, я часто сталкиваюсь с тем что что-то нежелательное пропускается на ревью. Что с этим можно сделать? 1. Задокументировать неявные свойства кода, сделать их явными, чтобы можно было на них сослаться и в принципе прочитать их если сомневаешься. 2. Покрыть тестами и линтами точки каплинга, валить CI если нарушены договоренности о проведении границ. > если есть тулы которые позволяют делать различного рода рестрикшены на уровне контрибьютинга Делайте тулинг, я ж уже сказал, можно юзать освободившийся ресурс из-под платформы микросервисов. Вопрос того что тулинг нужен уже как бы и не стоит, просто можно его в другую сторону делать. > это уже сигнал к тому что какой-то булшит происходит и стоит уже задуматься о долгосрочной перспективе Почему тулинг для поддержания бизнесовой дележки без влияния на техническую дележку - это булшит, а форсировать одинаковую дележку микросервисами - это не булшит? Второе звучит намного булшитнее. > Да и к тому же сам факт того что весь биг тех переезжает на SOA - неоспоримое подтверждение преимуществ гибкости Нет тут ничего неоспоримого, мало того что очевидно требования бигтеха не ложатся даже на тот же авито, так еще и бигтех сам по себе допускает ошибки. Это не какой-то непоколебимый мудрец, это такие же работяги, которые уязвимы к модным нововведениям и хотят пополнить ими свои сивишечки.

[@proger150]

> Нет тут ничего неоспоримого, мало того что очевидно требования бигтеха не ложатся даже на тот же авито, так еще и бигтех сам по себе допускает ошибки. Это не какой-то непоколебимый мудрец, это такие же работяги, которые уязвимы к модным нововведениям и хотят пополнить ими свои сивишечки. Мода перетекла в здравый смысл. Если есть компании, которые имея несколько тысяч инженеров которые довольны монолитом, то я был бы рад услышать рассказ об их опыте и увидеть их довольные лица а не гарольдфейс) я апеллирую тем, что вижу на этих докладах. Обратной тенденции не наблюдается. Инженеры готовы проходить весь этот путь и идти на коспромиссы распределенных систем. Опять же, если не прав, поделитесь опытом) > Делайте тулинг, я ж уже сказал, можно юзать освободившийся ресурс из-под платформы микросервисов. Вопрос того что тулинг нужен уже как бы и не стоит, просто можно его в другую сторону делать Думаете экономически целесообразно когда распил грозит в будущем?) > 1. Задокументировать неявные свойства кода, сделать их явными, чтобы можно было на них сослаться и в принципе прочитать их если сомневаешься. 2. Покрыть тестами и линтами точки каплинга, валить CI если нарушены договоренности о проведении границ. Ну вы же понимаете что документация кода - это то что надо всегда поддерживать) это так не работает в условиях agile. Документировать будут продукт, а не код. Да и то документация по продукту устаревает, я уж не говорю про документирование кода

[@AntonioLopez8888]

Авито что-то опасная компания, я смотрел несколько видео от них..либо для начинающих либо инфантильное вроде этого. Что у вас там происходит?

[@MurtagBY]

В чем заключается инфантильность?

[@alexanderk3762]

Ростовчане то вам че не угодили?:))))))

[@TheMMgo]

Ростовчане лапочки-)

[@linermgn]

IDE подсветит))) Ты просто был моложе, а когда моложе то и ярки краше и еда вкуснее и монолит приятнее)

[@OnenessVoices]

Перших 15-20% загального часу спікер розповідае про традиційну невиліковну хворобу ВСІХ російських бізнесів - «відсутність професійного менеджменту, відсутність грамотної взаемодіі команд + авральний способ праці ВСІХ». «Жирні нафтови» рокі стрімко закінчились, на порозі военна мілітаризація, стагнація всього, що «не для війни», та арешт закордонних активів + «залізний занавес». Останніх 1-2 рокі бюджетів доя розробки чогось цівільного…

[@АртемАрте-г5х]

@@hloraet 1. Это бот. 2. ИТ на украине на порядок выше классом, чем ИТ в России. потому что ИТ на украине это придаток ИТ в США, с их подходами , менеджментом и технологиями. У нас это почему-то "свой путь." Наблюдаю это на примере тех же "микросервисов". Только русские крупные компании продолжают делать распределённый синхронный монолит, вместо асинхронной EDA - трушной мс архитектуры. И ещё спорят с пеной у рта.