Опыт автора и академический тон статьи должны как будто убедить нас, что всё написанное нужно всем. Пользуйтесь и всё у вас будет хорошо. Если прочитав эту статью вы уже идёте душить своего монолита и разделять базу данных, не торопитесь.
Для начала то о чём забыл написать автор (преклонный возраст или нежелание портить благостную картинку) - КАЖДЫЙ пункт этого набора имеет свои недостатки. Например. Вот, руководствуясь Decompose By Business Capability и Database Per Service вы вынесли покупки пользователей в одну базу, а профили пользователей в другую. Вдруг к вам прибегает окрыленное руководство и говорит - ребята срочно, у нас есть бизнес идея, для проверки нам нужно сгруппировать покупки по городам пользователей и посчитать их количество. Адрес пользователя в базе профилей, покупки в базе покупок, простой join не сделать. Как быть? В этот момент обычно приходят умные дяди с 30 летним опытом и говорят, что нам нужно data strategy, data warehouse, etl и т.д. Получается, что для того, чтобы сделать простой аналитический join в мире микросервисов вам теперь нужно иметь дополнительный тяжелый, дорогостоящий, требующий обслуживания слой. Иногда это неизбежно, но мне кажется в 90% случаев этого можно избежать.
Или же паттерн Сага. Вот вы делаете транзакцию и просходит ошибка, нужно откатиться. Ничего страшного, говорит Сергей Громов, достаточно запустить серию(sic!) компенсирующих транзакций и все вернется на свои места. Но вот в этой серии из 10 компенсирующих транзакций, восьмая упала с эксепшеном. Что теперь? Компенсируем компенсирующие транзакции? Или просто забиваем, оставляем неконсистентный стейт и называем это progressive eventual consistency?
Я уже не говорю про курьезы и перегибы, когда на 15 человек команды в компании написана сотня микросервисов. Time2market и delivery speed падают практически до 0.
Сергей как мне кажется начал не с того. Главный вопрос современности, не как удушить ваш монолит, а в каком случае вам вообще стоит использовать микросервисы и для чего они нужны. Из своего 18 летнего опыта могу сказать, что единственное, когда микросервисы действительно помогают, а не мешают - это когда у вас МНОГО разработчиков. Как в Гугле, Яндексе и прочих Майкрософтах.
Если же у вас весь отдел разработки до 50 человек, я бы порекомендовал использовать модульный монолит и сэкономить огромное количество времени и сил. Как справедливо замечает Сергей, в случае необходимости потом его всегда можно "удушить".
Случайно обнаружил эту статью после сегодняшней "Готовьтесь к росту цен". Статья не о том, как стать хорошими, а о том, как быть плохими. Рувдс, даже если вы сделаете виртуалки бесплатными, я лучше всё-же заплачу кому-нибудь другому.
Статья неплохая, но как мне кажется робкая и с оговорками. "За деревьями не видеть леса" - явно не про автора, но ведь можно описать лес просто как набор деревьев погуще, чтобы никого не волновать раньше времени. Как классифицировать статью? Мне кажется лучше всего ей подходит древняя как мир категория: Elephant in the room, с подкатегорией: "слон прикреплен цепями к полу, ключ не у нас"
Про ассемблер с отцом в детстве не знаю, но точно знаю, что наличие профильного высшего образования (или процесс его получения) обычно отличает кандидата в лучшую сторону, даже если он был далеко не отличником в не самом топовом вузе. За 12 лет найма мне только один раз попадался самородок, который смог достойно пройти интервью без высшего образования и в целом удивить меня кругозором и глубоким пониманием предмета. Во всех остальных случаях человек с образованием выгодно отличался от тех, у кого его не было. Думаю, что разачаровавшиеся кандидаты вполне могли бы назвать меня гейткипером.
Казалось бы возможность сделать форк - это тот самый open source, который никто у вас не отнимает. А какие права и кому раздавать - это дело владельца репозитория, которое к "open source" как таковому прямого отношения не имеет.
Публиковать такие статьи, нужна недюжинная смелость 😀. Уважу автора и напишу комментарий по-существу. Автору или гпт кажется, что рынки позиционируют себя как штуку, которая гарантирует процветание. Это не так. Даже на языковом уровне участник рынка - это игрок, т.е. человек, который играет в игру с непредвиденным результатом. Конечно, различные стратегии поведения на рынке имеют разные шансы на успех, но никогда этот шанс не 100%. Почему? Потому что рынки постоянно подстраиваются под изменяющуюся реальность и то, что вы продавали/покупали вчера одним образом, может иметь совершенно другие рыночные параметры сегодня. Будущее, как бы люди не пытались его предсказать до сих пор штука в абсолютном смысле непредсказуемая, поэтому реальность всегда идет какой-то своей дорогой. Рынки находятся в состоянии перманентной адаптации к постоянно изменяющейся реальности, поскольку обычно идут снизу, от реальных потребностей людей, которые в этой реальности существуют. Когда же рынки "заигрываются" и начинают планировать чуть больше и/или чуть дальше, чем нужно, это приводит к той или иной форме кризиса, которая в свою очередь смывает пену и возвращает рынок обратно к реальности. Плановая экономика идет сверху. Она конечно же в некотором моменте будет очень точна и актуальна. Но реальность движется вперед, а те, кто давят на рычаги плана, в какой-то момент начинают отставать. И вот когда реальность уже далеко, когда плановая экономика "заигрывается", то заигрывается она по-крупному, потому что "не может же начальник/плановый отдел/лидер красно-солнышко ошибаться?" И вместо того, чтобы получить пусть и болезненный, но не смертельный удар, нажав кнопку reset, она продолжает плодить неэффективные, нереалистичные, а главное ненужнык планы дальше. В какой-то момент любая плановая экономика начинает внедрять рынок в той или иной форме и разумеется не от хорошей жизни. Те кто преуспел на этом пути, остаются жить и могут даже гордо продолжать называть себя плановыми, хотя от плана там остаются обычно рожки да ножки. Некоторые даже продолжают называть себя комустическими или народными, хотя от комунизма и народности там обычно тоже рожки да ножки, и политическое устройство обычно превращаются в некоторую форму авторитарного персоналистского режима.
Мне статья понравилась. Сразу вспомнилось, как я сам в 2011 году велосипедил di для андроида, а в 2007 писал свою СУБД на файликах и sax парсер xmlя по-честному на грамматиках, без всякого antlra. Ностальгия, так что как забавное чтение перед сном вполне. В остальном вопрос только к уровню - почему он сложный?..
Если один файл будут менять много разработчиков - вы будете постоянно страдать от конфликтов. Современные ide отлично справляются с большим количеством файлов и разработчики за счет этого работают в разных частях проекта и не толкаются. Кроме того, системы вроде гитлаба давно отображают изменения как простыню, как будто это один большой файл, в которой всё как на ладони. Рабочее место разработчика должно очевидно соответствовать моменту с точки зрения ресурсов.
Скорее не надо из классика делать второй сорт и выпихивать в плагин. Хотят привлекать зумеров с vscode, пожалуйста, но примерять зумерское платье на старичках, плативших последние 15 лет кажется несколько неприлично особенно для компании, традиционно славившейся заботой о своих пользователях.
Я имел ввиду, что не думали о решении такой проблемы: как бы нам сделать так, чтобы синхронно написанный код работал асинхронно. Green Threads эту проблему не решали.
Сейчас идёт активная дискуссия, о том, как решить эту проблему технически, например вот один из тредов на эту тему: https://mail.openjdk.org/pipermail/loom-dev/2024-February/006433.html . Лично у меня нет сомнений, что эту проблему решат, поскольку с одной стороны, проблема действительно большая, а с другой Loom больше не preview фича и что-то сделать им точно придётся. Я предполагаю что следующий LTS уже будет выпущен с решением этой проблемы.
А чему ломаться, если ресурсы позволяют? https://github.com/smallnest/C1000K-Servers вот пожалуйста люди еще 9 лет назад экспериментировали и разгоняли на одной машинке 1.2 миллиона вебсокет конекшенов в том числе на Jvm и всё в порядке. Вот только на код там без слез нельзя смотреть и без мануала разобраться, это да. Идея Loom в том, что можно обойтись и без слёз при этом не сильно меняя свой код.
Казалось бы причем здесь интерфейсы?... То о чем мы говорим - это не вопрос использования/не использования абстракций, а вполне конкретный вопрос о том, как сделать так, чтобы программа выглядела синхронной (с использованием интерфейсов или без них), но при этом не занимала потоки ОС в моменты ожидания. Раньше такого действительно не было, может только если какой-нибудь Erlang так умел, но в Java да и в других языках 20+ лет назад о таком даже не думали, потому что проблемы и приоритеты были другие.
Это не оптимизм, а реализм. Во-первых Loom уже сейчас работает вполне неплохо и если у вас везде используются только lockи, без synchronized вы уже прямо сейчас можете наблюдать то самое "повышение производительности" (а если точнее, более оптимальное использование железа при большом количестве I/O операций). Во-вторых ничего сверхсложного в том, чтобы synchronized тоже "починился" нет, поскольку в конечном счете его можно на уровне Jvm "свести" к операциям с локами, которые даже текущий Loom поддерживает. Да и в целом если вы задумаетесь про Loom на концептуальном уровне - есть ли у JVM в рантайме вся информация для того, чтобы понять, что ваш поток сейчас чего-то ждёт и процессор не занимает? Конечно есть! В реализации могут быть нюансы, первый блин комом, но концептуально здесь всё довольно просто. Вспомните parallel Streamы, которые на релизе в J8 работали значительно медленнее, чем в J9. Так что я стараюсь реалистично смотреть на эту ситуацию.
Попробую чуть более развернуто ответить, если вы не до конца меня поняли.
Вполне вероятно, что ваш код 20+ лет был обычным кодом на потоках ОС. Многопоточный код на потоках ОС - это ОК. Но если таких потоков создать много, то программа дальше функционировать не сможет, поскольку ресурсы закончатся. А много их создать хочется, потому что значительную часть времени потоки находятся в процессе выполнения I/O операций, а процессор простаивает. Т.е. естественным желанием является увеличить количество потоков обработки, чтобы загрузить процессор, но в классической модели так сделать не получится.
Именно эту проблему решает "жуткий асинхронный код на колбэках", который позволяет оптимально загрузить железо ценой удобства разработки. И именно эта цена, которую пришлось заплатить, не устраивала значительное количество людей по всему миру, поэтому и появились async/awaitы, горутины и т.д, которые позволяли писать "как-бы" синхронный код, в котором I/O операции не требовали держать поток ОС.
В Java аналога такой функциональности "как-бы" синхронного кода с оптимальной загрузкой потоков ОС долго не было, пока не появился Loom. Его основное преимущество по сравнению с другими языками, например C# async/await в том, что никаких дополнительных ключевых слов использовать не нужно и JVM всё делает за вас, просто беря ваш код и понимая, в какие моменты его выполнение нужно "отцепить" от потока ОС (например, на операции ввода/вывода) и когда "прицепить" обратно.
Концептуально великолепно, но то, что ушло в 21 версии в релиз к сожалению не умеет правильно обрабатывать synchronized блоки/методы и поскольку значительное количество (в первую очередь старых) библиотек их используют, то это приводит к таким вот ситуациям, которая описана в статье. Проблема с synchronized непростая, но не нерешаемая и ее скоро решат. И вот тогда, действительно можно будет говорить о том, что "всё" проблемы многопоточности (применительно к конкретной ситуации оптимального использования железа для выполнения обычного синхронного кода) действительно будут решены.
Опыт автора и академический тон статьи должны как будто убедить нас, что всё написанное нужно всем. Пользуйтесь и всё у вас будет хорошо. Если прочитав эту статью вы уже идёте душить своего монолита и разделять базу данных, не торопитесь.
Для начала то о чём забыл написать автор (преклонный возраст или нежелание портить благостную картинку) - КАЖДЫЙ пункт этого набора имеет свои недостатки. Например. Вот, руководствуясь Decompose By Business Capability и Database Per Service вы вынесли покупки пользователей в одну базу, а профили пользователей в другую. Вдруг к вам прибегает окрыленное руководство и говорит - ребята срочно, у нас есть бизнес идея, для проверки нам нужно сгруппировать покупки по городам пользователей и посчитать их количество. Адрес пользователя в базе профилей, покупки в базе покупок, простой join не сделать. Как быть? В этот момент обычно приходят умные дяди с 30 летним опытом и говорят, что нам нужно data strategy, data warehouse, etl и т.д. Получается, что для того, чтобы сделать простой аналитический join в мире микросервисов вам теперь нужно иметь дополнительный тяжелый, дорогостоящий, требующий обслуживания слой. Иногда это неизбежно, но мне кажется в 90% случаев этого можно избежать.
Или же паттерн Сага. Вот вы делаете транзакцию и просходит ошибка, нужно откатиться. Ничего страшного, говорит Сергей Громов, достаточно запустить серию(sic!) компенсирующих транзакций и все вернется на свои места. Но вот в этой серии из 10 компенсирующих транзакций, восьмая упала с эксепшеном. Что теперь? Компенсируем компенсирующие транзакции? Или просто забиваем, оставляем неконсистентный стейт и называем это progressive eventual consistency?
Я уже не говорю про курьезы и перегибы, когда на 15 человек команды в компании написана сотня микросервисов. Time2market и delivery speed падают практически до 0.
Сергей как мне кажется начал не с того. Главный вопрос современности, не как удушить ваш монолит, а в каком случае вам вообще стоит использовать микросервисы и для чего они нужны. Из своего 18 летнего опыта могу сказать, что единственное, когда микросервисы действительно помогают, а не мешают - это когда у вас МНОГО разработчиков. Как в Гугле, Яндексе и прочих Майкрософтах.
Если же у вас весь отдел разработки до 50 человек, я бы порекомендовал использовать модульный монолит и сэкономить огромное количество времени и сил. Как справедливо замечает Сергей, в случае необходимости потом его всегда можно "удушить".
Забавное наблюдение: генерики в Java появились через 8 лет после релиза 1.0, генерики в Go через 13 лет.
Случайно обнаружил эту статью после сегодняшней "Готовьтесь к росту цен". Статья не о том, как стать хорошими, а о том, как быть плохими. Рувдс, даже если вы сделаете виртуалки бесплатными, я лучше всё-же заплачу кому-нибудь другому.
Статья неплохая, но как мне кажется робкая и с оговорками. "За деревьями не видеть леса" - явно не про автора, но ведь можно описать лес просто как набор деревьев погуще, чтобы никого не волновать раньше времени. Как классифицировать статью? Мне кажется лучше всего ей подходит древняя как мир категория: Elephant in the room, с подкатегорией: "слон прикреплен цепями к полу, ключ не у нас"
Про ассемблер с отцом в детстве не знаю, но точно знаю, что наличие профильного высшего образования (или процесс его получения) обычно отличает кандидата в лучшую сторону, даже если он был далеко не отличником в не самом топовом вузе. За 12 лет найма мне только один раз попадался самородок, который смог достойно пройти интервью без высшего образования и в целом удивить меня кругозором и глубоким пониманием предмета. Во всех остальных случаях человек с образованием выгодно отличался от тех, у кого его не было. Думаю, что разачаровавшиеся кандидаты вполне могли бы назвать меня гейткипером.
Казалось бы возможность сделать форк - это тот самый open source, который никто у вас не отнимает. А какие права и кому раздавать - это дело владельца репозитория, которое к "open source" как таковому прямого отношения не имеет.
Публиковать такие статьи, нужна недюжинная смелость 😀. Уважу автора и напишу комментарий по-существу. Автору или гпт кажется, что рынки позиционируют себя как штуку, которая гарантирует процветание. Это не так. Даже на языковом уровне участник рынка - это игрок, т.е. человек, который играет в игру с непредвиденным результатом. Конечно, различные стратегии поведения на рынке имеют разные шансы на успех, но никогда этот шанс не 100%. Почему? Потому что рынки постоянно подстраиваются под изменяющуюся реальность и то, что вы продавали/покупали вчера одним образом, может иметь совершенно другие рыночные параметры сегодня. Будущее, как бы люди не пытались его предсказать до сих пор штука в абсолютном смысле непредсказуемая, поэтому реальность всегда идет какой-то своей дорогой. Рынки находятся в состоянии перманентной адаптации к постоянно изменяющейся реальности, поскольку обычно идут снизу, от реальных потребностей людей, которые в этой реальности существуют. Когда же рынки "заигрываются" и начинают планировать чуть больше и/или чуть дальше, чем нужно, это приводит к той или иной форме кризиса, которая в свою очередь смывает пену и возвращает рынок обратно к реальности. Плановая экономика идет сверху. Она конечно же в некотором моменте будет очень точна и актуальна. Но реальность движется вперед, а те, кто давят на рычаги плана, в какой-то момент начинают отставать. И вот когда реальность уже далеко, когда плановая экономика "заигрывается", то заигрывается она по-крупному, потому что "не может же начальник/плановый отдел/лидер красно-солнышко ошибаться?" И вместо того, чтобы получить пусть и болезненный, но не смертельный удар, нажав кнопку reset, она продолжает плодить неэффективные, нереалистичные, а главное ненужнык планы дальше. В какой-то момент любая плановая экономика начинает внедрять рынок в той или иной форме и разумеется не от хорошей жизни. Те кто преуспел на этом пути, остаются жить и могут даже гордо продолжать называть себя плановыми, хотя от плана там остаются обычно рожки да ножки. Некоторые даже продолжают называть себя комустическими или народными, хотя от комунизма и народности там обычно тоже рожки да ножки, и политическое устройство обычно превращаются в некоторую форму авторитарного персоналистского режима.
Верно - говорите. ПОЧЕМУ? ИГНОРИРОВАЛИ? ОБРАЩЕНИЯ? ВЛАСТЕЙ?
Всё верно дискорд виноват и разумеется умирает. И линкедин. И гугл. Мало что-ли их?
Мне статья понравилась. Сразу вспомнилось, как я сам в 2011 году велосипедил di для андроида, а в 2007 писал свою СУБД на файликах и sax парсер xmlя по-честному на грамматиках, без всякого antlra. Ностальгия, так что как забавное чтение перед сном вполне. В остальном вопрос только к уровню - почему он сложный?..
Если один файл будут менять много разработчиков - вы будете постоянно страдать от конфликтов. Современные ide отлично справляются с большим количеством файлов и разработчики за счет этого работают в разных частях проекта и не толкаются. Кроме того, системы вроде гитлаба давно отображают изменения как простыню, как будто это один большой файл, в которой всё как на ладони. Рабочее место разработчика должно очевидно соответствовать моменту с точки зрения ресурсов.
Скорее не надо из классика делать второй сорт и выпихивать в плагин. Хотят привлекать зумеров с vscode, пожалуйста, но примерять зумерское платье на старичках, плативших последние 15 лет кажется несколько неприлично особенно для компании, традиционно славившейся заботой о своих пользователях.
Я имел ввиду, что не думали о решении такой проблемы: как бы нам сделать так, чтобы синхронно написанный код работал асинхронно. Green Threads эту проблему не решали.
Сейчас идёт активная дискуссия, о том, как решить эту проблему технически, например вот один из тредов на эту тему: https://mail.openjdk.org/pipermail/loom-dev/2024-February/006433.html . Лично у меня нет сомнений, что эту проблему решат, поскольку с одной стороны, проблема действительно большая, а с другой Loom больше не preview фича и что-то сделать им точно придётся. Я предполагаю что следующий LTS уже будет выпущен с решением этой проблемы.
А чему ломаться, если ресурсы позволяют? https://github.com/smallnest/C1000K-Servers вот пожалуйста люди еще 9 лет назад экспериментировали и разгоняли на одной машинке 1.2 миллиона вебсокет конекшенов в том числе на Jvm и всё в порядке. Вот только на код там без слез нельзя смотреть и без мануала разобраться, это да. Идея Loom в том, что можно обойтись и без слёз при этом не сильно меняя свой код.
Казалось бы причем здесь интерфейсы?... То о чем мы говорим - это не вопрос использования/не использования абстракций, а вполне конкретный вопрос о том, как сделать так, чтобы программа выглядела синхронной (с использованием интерфейсов или без них), но при этом не занимала потоки ОС в моменты ожидания. Раньше такого действительно не было, может только если какой-нибудь Erlang так умел, но в Java да и в других языках 20+ лет назад о таком даже не думали, потому что проблемы и приоритеты были другие.
Это не оптимизм, а реализм. Во-первых Loom уже сейчас работает вполне неплохо и если у вас везде используются только lockи, без synchronized вы уже прямо сейчас можете наблюдать то самое "повышение производительности" (а если точнее, более оптимальное использование железа при большом количестве I/O операций). Во-вторых ничего сверхсложного в том, чтобы synchronized тоже "починился" нет, поскольку в конечном счете его можно на уровне Jvm "свести" к операциям с локами, которые даже текущий Loom поддерживает.
Да и в целом если вы задумаетесь про Loom на концептуальном уровне - есть ли у JVM в рантайме вся информация для того, чтобы понять, что ваш поток сейчас чего-то ждёт и процессор не занимает? Конечно есть! В реализации могут быть нюансы, первый блин комом, но концептуально здесь всё довольно просто. Вспомните parallel Streamы, которые на релизе в J8 работали значительно медленнее, чем в J9.
Так что я стараюсь реалистично смотреть на эту ситуацию.
Когда решится проблема с synchronized, а она решится в ближайшем будущем, то это действительно будет так.
Попробую чуть более развернуто ответить, если вы не до конца меня поняли.
Вполне вероятно, что ваш код 20+ лет был обычным кодом на потоках ОС. Многопоточный код на потоках ОС - это ОК. Но если таких потоков создать много, то программа дальше функционировать не сможет, поскольку ресурсы закончатся. А много их создать хочется, потому что значительную часть времени потоки находятся в процессе выполнения I/O операций, а процессор простаивает. Т.е. естественным желанием является увеличить количество потоков обработки, чтобы загрузить процессор, но в классической модели так сделать не получится.
Именно эту проблему решает "жуткий асинхронный код на колбэках", который позволяет оптимально загрузить железо ценой удобства разработки. И именно эта цена, которую пришлось заплатить, не устраивала значительное количество людей по всему миру, поэтому и появились async/awaitы, горутины и т.д, которые позволяли писать "как-бы" синхронный код, в котором I/O операции не требовали держать поток ОС.
В Java аналога такой функциональности "как-бы" синхронного кода с оптимальной загрузкой потоков ОС долго не было, пока не появился Loom. Его основное преимущество по сравнению с другими языками, например C# async/await в том, что никаких дополнительных ключевых слов использовать не нужно и JVM всё делает за вас, просто беря ваш код и понимая, в какие моменты его выполнение нужно "отцепить" от потока ОС (например, на операции ввода/вывода) и когда "прицепить" обратно.
Концептуально великолепно, но то, что ушло в 21 версии в релиз к сожалению не умеет правильно обрабатывать synchronized блоки/методы и поскольку значительное количество (в первую очередь старых) библиотек их используют, то это приводит к таким вот ситуациям, которая описана в статье. Проблема с synchronized непростая, но не нерешаемая и ее скоро решат. И вот тогда, действительно можно будет говорить о том, что "всё" проблемы многопоточности (применительно к конкретной ситуации оптимального использования железа для выполнения обычного синхронного кода) действительно будут решены.
Спасибо переводчику за хорошую статью, так бы я ее конечно не нашел... но читать лучше в оригинале, простите.