Если ваша ремарка апеллирует к сложности такого кода — не согласен
это же кошмар как нечитабельно и многословно. Ну да, да написать в принципе возможно, но мы же не об этом ) В этом видео только игрушечные примерчики, и уже они выглядят ужасно. А что будет если писать ВСЮ бизнес логику так (это риторический вопрос, если что) и когда объёмы кода написанного вот так, начнут исчисляться десятками и сотнями тысяч строк
это всегда сложно
конечно, только в разной степени для разных подходов ))
Таки Pg умеет в реактивщину. Вероятно, вы имели ввиду, что у данной СУБД нет асинхронного API.
я в оригинальном посте уже всё написал. Да, нет асинхронного апи. Это оверлэй. Если на базу пойдёт нагрузка, эта разница какраз проявится
1) Потому что деньги — зло.
2) Потому что не хотеть нагружать себя всё больше и больше за те же деньги — грех.
Мне кажется как-то так.
в этом нет логики. «пьяный инженер» какраз говорил о том что не имеет смысл давать себя эксплуатировать больше за те же деньги и что проще уйти в другую компанию. На что «трезвый инженер» сказал что эти рассуждения чепуха потому что «Работа в нашей отрасли полностью построена на порочных стимулах.»
1 Работа в нашей отрасли полностью построена на порочных стимулах.
2 Лучший способ продвинуться по карьерной лестнице — это смена компании. Компании, в которых вы работаете, будут вознаграждать хорошую работу большей работой и ответственностью, а не большим количеством времени и/или денег. Компании, в которые вы переходите, вознаградят вашу предыдущую хорошую работу в других компаниях большими деньгами. На самом деле это не имеет смысла… См. Пункт №1.
можно кэпа? Каким образом короткая фраза «работа построена на порочных стимулах» объясняет почему переход на +50% не имеет смысла? Все пункты ссылаются на 1, но он звучит как «потому что гладиолус»
А CompletableFuture? .NET async/await по сути красивый сахар
этот красивый сахар позволяет писать код на порядок удобнее и чище. Писать в 2021 году трэш на коллбэках — это не поддержка
UPD в качестве примера попробуйте набросать на CompletableFuture код который выполняет асинхронный ввод-вывод, ждёт результатов не съедая время потока (т.е. неблокирующе) и написать продолжение обработки после получения результатов. И таких например несколько шагов — запрос на удалённый ресурс -> получил-обработал. А потом можете поделиться прикидками что будет если такое писать регулярно и на уровне всего проекта
Единственно с чем соглашусь очень мало реализаций асинхронных либ для доступа к БД, но и они есть худо бедно)
асинхронные либы решают проблему с асинхронностью только частично. Если субд не поддерживает настоящего реактивного драйвера то на стороне вызывающего всё неплохо, но только не для базы в случае нагрузки. Если субд не поддерживает реактивный драйвер, то эти библиотеки — просто овэрлэй над обычным апи субд. Некоторые базы поддерживают настоящую реактивность, но скажем Постгрес — нет
В Java более прозрачная работа с асинхронностью: когда пишешь код действительно приходится о многом думать
это должно быть шутка? Никакой поддержки асинхронного программирования на уровне языка java НЕТ. Всё что есть — это библиотеки где можно писать отвратительную колбасу с коллбэками. «приходится о многом думать» — круто-то как, надо такого побольше и везде, а то ж мало о чем думать и без этого! Надо полагать что те кто пытаются уменьшить интеллектуальную сложность систем и инструментов — просто ленивые дураки
интересно, увидим ли мы когда-то нормальную поддержку асинхронного программирования на уровне языка java… Говорили что Project Loom облегчит жизнь, но прошло уже несколько лет и по прежнему неизвестно не просто когда этот проект станет частью JDK, а станет ли вообще. Такое ощущение что java 2021 года будет соответствовать дотнету пятилетней давности…
2.1. Web service — сложно, надо думать проектировать. Давайте выкинем «не нужное» и быстро налепим WebAPI\REST. Вышло убогенько (по началу), проблем кардинально не решило ни с версионность, ни с самоописанием, ни с масштабированием. Ну прикрутили метаописание Swagger\OpenAPI. Надо ресурсы, поднял инстанс. Проблемы с масштабируемостью тоже не решило.
я свичнулся в серверную разработку когда REST уже уверенно шагал (т.е. я немного не в конктексте). Но есть ощущение что REST для микросервисов очень неудобен — много ручного хозяйства, которое как кажется можно было бы переложить на инструмент. Например валидация контрактов между сервисами выглядит как костыль над отсутствием четкого контракта из коробки. Если нужно что-то сделать — нужно мыслить в терминах сущностей, и часто REST представляет собой грязную версию RPC — об этом есть наверное не одна статья. Ретраи, circuit breaker-ы -тоже выглядит так что это должно настраиваться просто и без написания логики на уровне приложения. Ну и самое главное напоследок — если уж система распределённая, то напрашивается сделать работу с удалёнными сервисами по возможности похожей на работу с локальными сервисами (в том же инстансе) и RPC смотрится навскидку лучше. Возможно старые варианты RPC имели какие-то недостатки, но нынешний gRPC кажется неплохим решением для вызовов между микросервисами. Наружу можно пробросить REST а внутри за gateway работать по gRPC
Почему shared database является антипаттерном можно почитать там же microservices.io/patterns/data/shared-database.html TLDR: расшаренная база повышает взаимосвязь сервисов и предположения друг о друге, сложно деплоить и создаёт проблемы с безопасностью
ну часто говорят что микросервисы — это масштабирование разработки (я не смотрел но думаю это тоже часть определения). Предположим ситуацию: cервис большой, логики в нём много, и решили чтоб масштабировать разработку, разделить этот сервис на 2 — не суть важно по какому признакму, может отдельно рид и райт, может разделили по доменной логики. Но например с точки зрения данных — это одни и те же данные и смысла делить их на две базы нет, а может даже и невозможно. Тогда, следуя логике этого же определения, нужно для 2-го сервиса завести отдельную базу (даже если эта база будет точной копией базы другого сервиса)? По-моему тут уже есть конфликт двух максим из одного и того же определения.
У многих вообще есть эти чистые в вакууме микросервисы? По-моему у большинства гибриды
У вас в примере распределённый монолит, а не микросервис. Особенностью микросервиса является независимый деплой и хранилище. А у вас хранилище одна. Два сервиса зависит друг от друга через схему хранилища. Это никак не микросервисы.
думаю это верное замечание, но насколько я понял, автор немного о другом — если затык в базе то микросервисами его нельзя преодолеть. Что например делать если разбивка правильная но на микросервис идёт такой объём который не держит база позади него?
Ещё, хм, есть некоторое сомнение по части вот этой труёвости разбивки. Мне кажется что на практике такое случается что разные микросервисы работают с одной и той же субд. Я не уверен что все контраргументы против определённой технологии или подхода можно парировать говоря «это просто не тру-реализация». Т.к. в таком случае это софистическая ловушка, т.к. это не учитывает что на практике невозможно всегда выполнить 100% идеальное проектирование, где-то будут компромиссы, и если идеологическую труёвость сложно достичь — это тоже можно отнести к недостаткам технологии/подхода, и он бы прямо так и звучал: «сложно выполнить правильно, а если неправильно — преимущества существенно нивелируются»
Микросервисы — не способ масштабироваться
(заголовок статьи)
ну в теории считается что после разбивки монолита отдельные его части (микросервисы) можно масштабировать по разному. Если на 1 функцию монолита нагрузка 1Х а на другую 40Х то можно вынести тот кусок что 40Х и скейлить его до нужного capacity. Если конечно получится обеспечить это на уровне субд.
«Некоторые рекрутёры считают «красным флагом» то, что у программиста слишком много лет опыта работы с определённым языком программирования, а в портфолио нет рабочего опыта.»
что это значит? "… много опыта… нет рабочего опыта"
если имеется в виду проект на гитхаб то многие опытные программисты их не имеют. Насколько такие портфолио актуальны сейчас?
Я лично всегда сичтал что это порорчная практика, т.к. чаще всего при таком перескоке получается яма: мы теряем хорошего технаря (а плохого не «повысили» бы) и приобретаем херового руководителя (т.к. опыта не так чтобы и много).
а кого тогда брать в управленцы? Выпускника факультета психологии или общепита?
да, бывает так что хороший технарь не становится хорошим руководителем, может и нередко. Но кто сказал что из нетехнарей хорошие руководители?
я видел немало примеров руководства менеджеров-нетехнарей. Ничего хорошего. Решения принимают люди которые не понимают последствий этих решений, ориентируясь на то похвалил клиент на митинге, или не похвалил, если у него нет настроения.
не хотел как-то оскорбить, потому вытер ) Извините. Я имел в виду что покорный человек «в системе» мыслит только паттернами покорности системы и игры по правилам которые система (те кто похитрее) навязывает, вместо того чтобы начать мыслить вне рамок
Все же вопрос рождается сам собой: откуда берутся руководители? откуда появляются лиды? почему разработчики становятся синьорами? Как Рокфеллер становится Рокфеллер? Как Тинькоф становится Тинькофф? Федор Овчинников становится Додо Пиццей?
ну вы сами и ответили ниже, вот
Можно взять дополнительную работу и клепать приложеньки или сайтики или что угодно, а можно найти человека который сделает это за тебя и ты получишь разницу за счет правильной организации процесса
вы же сами это и сказали: нужно менять парадигму, а не просто «заваливать мясом» и работать больше. Я думаю что те кто пробиваются наверх, думают не о том как работать больше, а наоборот — думают о том как не работать.
Потом, допустим вы начинаете пахать больше, но то же делают и другие. Пусть не все, конечно, но вы всё равно ввязываетесь в гонку.
пробовали проанализировать почему так происходило?
Если видно что инженер делает 150% того что то него требуется, будут сделаны соответствующие выводы.
Нужно стараться делать добавочную стоимость своей работой сверх привычного уклада, тогда работодатель будет ценить такой вклад
это компании выгодно чтобы все так думали. Можно сменить место работы и получить даже больше бенефитов. Вот эти «ты главное херач а мы потом оценим» это ерунда. Я лично видел людей которые херачили, и сам таким был, а повышали других, и прямо на одном и том же проекте работали люди один из которых херачил, а второй делал в 2 раза меньше, а получал в 2 раза больше. Да и вообще, в мире много людей которые много и усердно работают, и что, они все стали богатыми?
Может раньше так и было, человек приходил в компанию молодым после вуза, и работал там пока аж не сдавал бэйджик уже пенсионером. Компания давала рост, зп, и тд. Сейчас парадигма поменялась. Сейчас отношения компаний и сотрудников стали кратковременными, и ни сотрудники ни компании не хотят вкладываться в друг друга.
мне как разработчику важно знать и понимать как и что мне делать что бы расти профессионально и материально
мне как руководителю нужны инструменты которые бы помогали разделять материальную часть на людей действительно заслуживающих этого, что бы подогреть интерес, чтобы не ушли, чтобы был пример и тд.
так вы разработчик или руководитель? Думаю что имеет смысл высказываться от лица кого-то одного, а второй стороне предоставить самим решать что для них лучше.
в общем всё так или иначе зависит от софт скиллов: умение нравиться людям, подвешенный язык, умение себя подавать, короче нужно быть своего рода политиком.
Если ваши сервисы хорошо изолированы, то чаще всего вы и работать будете с одним. И поставить точку останова вы сможете. К сожалению очень часто путают (микро-)сервисную архитектуру и распределенный монолит. А трейсинг как раз поможет понять в каком из сервисов искать проблему.
и что покажет трейсинг? что какой-то сервис в цепочке вернул 500-ку или 400-ку? А если они вернули 200 но результат неправильный? Трейсинг это же не дебаг ) А в логах могут не печататься респонзы ) А причина неправильно посчитанного значения может быть как в одном сервисе так и в нескольких и даже в их взаимодействии. И чтобы это понять, нужно реально продебажить. Ну или добавлять логи в несколько сервисов и деплоить и смотреть )
Вы упорно делаете вид будто бы отладка системы из кучи компонентов и связей между ними это тоже самое что и отладка одного приложения. Так это же просто неправда, и что мы тут обсуждаем вообще?
Микро-сервисы намного проще разрабатывать чем монолит, как раз за счет сильно ограниченного контекста.
отдельный микросервис проще разрабатывать чем монолит, а всю систему — сложнее.
А так Jaeger \ DataDog вполне позволяют легко отлаживать систему в сборе
это разве отладка? Дистрибютед трейсинг это разве тоже самое как если бы я поставил точку останова в приложении?
Отдельные же сервисы отлаживаются точно так-же как и монолитные приложения.
чтобы запустить локально, нужно воссоздать на локальной машине не только сам сервис но и другие сервиса с которым этот микросервис общается. А ещё это могут быть AWS ресурсы, не на все из которых есть докер аналоги. И даже если это возможно, это куда более накладно. Ничего себе «точно так же» ))
По поводу изменений в сервисах, да может быть такое, что нужно что-то менять. Но снова, не нужно добавлять в сервис новые обязанности, только потому, что на первый взгляд не понятно кто должен эту новою работу выполнять. Придерживайтесь того же SRP, Low coupling/High cohesion как и при написании кода, делайте сервисы слабо связанными и сфокусированными на одной бизнес-задаче и не создавайте себе дополнительных сложностей.
открыл на днях Фаулера, его статью о микросервисах. В разделе «Микросервисы это будущее?» он пишет что пока рано говорить, т.к. сейчас недостаточно данных судить об успешной адаптации кроме тех. гигантов.
то что вы говорите, конечно верно, но проблемы отладки (более широко — удобства разработки), тестирования и особенно простоты интеграции остаются и пока что видятся фундаментальными ограничениями технологии как таковой, которые возможно нельзя обойти в принципе. Вот эти вещи «SRP, Low coupling/High cohesion» скорее облегчают жизнь, но интеграция и масштабный девопс никуда не деваются, потому что микросервисы это распределённая система со всеми вытекающими сложностями
это же кошмар как нечитабельно и многословно. Ну да, да написать в принципе возможно, но мы же не об этом ) В этом видео только игрушечные примерчики, и уже они выглядят ужасно. А что будет если писать ВСЮ бизнес логику так (это риторический вопрос, если что) и когда объёмы кода написанного вот так, начнут исчисляться десятками и сотнями тысяч строк
конечно, только в разной степени для разных подходов ))
я в оригинальном посте уже всё написал. Да, нет асинхронного апи. Это оверлэй. Если на базу пойдёт нагрузка, эта разница какраз проявится
в этом нет логики. «пьяный инженер» какраз говорил о том что не имеет смысл давать себя эксплуатировать больше за те же деньги и что проще уйти в другую компанию. На что «трезвый инженер» сказал что эти рассуждения чепуха потому что «Работа в нашей отрасли полностью построена на порочных стимулах.»
можно кэпа? Каким образом короткая фраза «работа построена на порочных стимулах» объясняет почему переход на +50% не имеет смысла? Все пункты ссылаются на 1, но он звучит как «потому что гладиолус»
есть ссылка или название этого драйвера?
этот красивый сахар позволяет писать код на порядок удобнее и чище. Писать в 2021 году трэш на коллбэках — это не поддержка
UPD в качестве примера попробуйте набросать на CompletableFuture код который выполняет асинхронный ввод-вывод, ждёт результатов не съедая время потока (т.е. неблокирующе) и написать продолжение обработки после получения результатов. И таких например несколько шагов — запрос на удалённый ресурс -> получил-обработал. А потом можете поделиться прикидками что будет если такое писать регулярно и на уровне всего проекта
асинхронные либы решают проблему с асинхронностью только частично. Если субд не поддерживает настоящего реактивного драйвера то на стороне вызывающего всё неплохо, но только не для базы в случае нагрузки. Если субд не поддерживает реактивный драйвер, то эти библиотеки — просто овэрлэй над обычным апи субд. Некоторые базы поддерживают настоящую реактивность, но скажем Постгрес — нет
это должно быть шутка? Никакой поддержки асинхронного программирования на уровне языка java НЕТ. Всё что есть — это библиотеки где можно писать отвратительную колбасу с коллбэками. «приходится о многом думать» — круто-то как, надо такого побольше и везде, а то ж мало о чем думать и без этого! Надо полагать что те кто пытаются уменьшить интеллектуальную сложность систем и инструментов — просто ленивые дураки
я свичнулся в серверную разработку когда REST уже уверенно шагал (т.е. я немного не в конктексте). Но есть ощущение что REST для микросервисов очень неудобен — много ручного хозяйства, которое как кажется можно было бы переложить на инструмент. Например валидация контрактов между сервисами выглядит как костыль над отсутствием четкого контракта из коробки. Если нужно что-то сделать — нужно мыслить в терминах сущностей, и часто REST представляет собой грязную версию RPC — об этом есть наверное не одна статья. Ретраи, circuit breaker-ы -тоже выглядит так что это должно настраиваться просто и без написания логики на уровне приложения. Ну и самое главное напоследок — если уж система распределённая, то напрашивается сделать работу с удалёнными сервисами по возможности похожей на работу с локальными сервисами (в том же инстансе) и RPC смотрится навскидку лучше. Возможно старые варианты RPC имели какие-то недостатки, но нынешний gRPC кажется неплохим решением для вызовов между микросервисами. Наружу можно пробросить REST а внутри за gateway работать по gRPC
ну часто говорят что микросервисы — это масштабирование разработки (я не смотрел но думаю это тоже часть определения). Предположим ситуацию: cервис большой, логики в нём много, и решили чтоб масштабировать разработку, разделить этот сервис на 2 — не суть важно по какому признакму, может отдельно рид и райт, может разделили по доменной логики. Но например с точки зрения данных — это одни и те же данные и смысла делить их на две базы нет, а может даже и невозможно. Тогда, следуя логике этого же определения, нужно для 2-го сервиса завести отдельную базу (даже если эта база будет точной копией базы другого сервиса)? По-моему тут уже есть конфликт двух максим из одного и того же определения.
У многих вообще есть эти чистые в вакууме микросервисы? По-моему у большинства гибриды
думаю это верное замечание, но насколько я понял, автор немного о другом — если затык в базе то микросервисами его нельзя преодолеть. Что например делать если разбивка правильная но на микросервис идёт такой объём который не держит база позади него?
Ещё, хм, есть некоторое сомнение по части вот этой труёвости разбивки. Мне кажется что на практике такое случается что разные микросервисы работают с одной и той же субд. Я не уверен что все контраргументы против определённой технологии или подхода можно парировать говоря «это просто не тру-реализация». Т.к. в таком случае это софистическая ловушка, т.к. это не учитывает что на практике невозможно всегда выполнить 100% идеальное проектирование, где-то будут компромиссы, и если идеологическую труёвость сложно достичь — это тоже можно отнести к недостаткам технологии/подхода, и он бы прямо так и звучал: «сложно выполнить правильно, а если неправильно — преимущества существенно нивелируются»
(заголовок статьи)
ну в теории считается что после разбивки монолита отдельные его части (микросервисы) можно масштабировать по разному. Если на 1 функцию монолита нагрузка 1Х а на другую 40Х то можно вынести тот кусок что 40Х и скейлить его до нужного capacity. Если конечно получится обеспечить это на уровне субд.
что это значит? "… много опыта… нет рабочего опыта"
если имеется в виду проект на гитхаб то многие опытные программисты их не имеют. Насколько такие портфолио актуальны сейчас?
а кого тогда брать в управленцы? Выпускника факультета психологии или общепита?
да, бывает так что хороший технарь не становится хорошим руководителем, может и нередко. Но кто сказал что из нетехнарей хорошие руководители?
я видел немало примеров руководства менеджеров-нетехнарей. Ничего хорошего. Решения принимают люди которые не понимают последствий этих решений, ориентируясь на то похвалил клиент на митинге, или не похвалил, если у него нет настроения.
не хотел как-то оскорбить, потому вытер ) Извините. Я имел в виду что покорный человек «в системе» мыслит только паттернами покорности системы и игры по правилам которые система (те кто похитрее) навязывает, вместо того чтобы начать мыслить вне рамок
ну вы сами и ответили ниже, вот
вы же сами это и сказали: нужно менять парадигму, а не просто «заваливать мясом» и работать больше. Я думаю что те кто пробиваются наверх, думают не о том как работать больше, а наоборот — думают о том как не работать.
Потом, допустим вы начинаете пахать больше, но то же делают и другие. Пусть не все, конечно, но вы всё равно ввязываетесь в гонку.
готов послушать ваш вариант
это компании выгодно чтобы все так думали. Можно сменить место работы и получить даже больше бенефитов. Вот эти «ты главное херач а мы потом оценим» это ерунда. Я лично видел людей которые херачили, и сам таким был, а повышали других, и прямо на одном и том же проекте работали люди один из которых херачил, а второй делал в 2 раза меньше, а получал в 2 раза больше. Да и вообще, в мире много людей которые много и усердно работают, и что, они все стали богатыми?
Может раньше так и было, человек приходил в компанию молодым после вуза, и работал там пока аж не сдавал бэйджик уже пенсионером. Компания давала рост, зп, и тд. Сейчас парадигма поменялась. Сейчас отношения компаний и сотрудников стали кратковременными, и ни сотрудники ни компании не хотят вкладываться в друг друга.
так вы разработчик или руководитель? Думаю что имеет смысл высказываться от лица кого-то одного, а второй стороне предоставить самим решать что для них лучше.
и что покажет трейсинг? что какой-то сервис в цепочке вернул 500-ку или 400-ку? А если они вернули 200 но результат неправильный? Трейсинг это же не дебаг ) А в логах могут не печататься респонзы ) А причина неправильно посчитанного значения может быть как в одном сервисе так и в нескольких и даже в их взаимодействии. И чтобы это понять, нужно реально продебажить. Ну или добавлять логи в несколько сервисов и деплоить и смотреть )
Вы упорно делаете вид будто бы отладка системы из кучи компонентов и связей между ними это тоже самое что и отладка одного приложения. Так это же просто неправда, и что мы тут обсуждаем вообще?
отдельный микросервис проще разрабатывать чем монолит, а всю систему — сложнее.
это разве отладка? Дистрибютед трейсинг это разве тоже самое как если бы я поставил точку останова в приложении?
чтобы запустить локально, нужно воссоздать на локальной машине не только сам сервис но и другие сервиса с которым этот микросервис общается. А ещё это могут быть AWS ресурсы, не на все из которых есть докер аналоги. И даже если это возможно, это куда более накладно. Ничего себе «точно так же» ))
открыл на днях Фаулера, его статью о микросервисах. В разделе «Микросервисы это будущее?» он пишет что пока рано говорить, т.к. сейчас недостаточно данных судить об успешной адаптации кроме тех. гигантов.
то что вы говорите, конечно верно, но проблемы отладки (более широко — удобства разработки), тестирования и особенно простоты интеграции остаются и пока что видятся фундаментальными ограничениями технологии как таковой, которые возможно нельзя обойти в принципе. Вот эти вещи «SRP, Low coupling/High cohesion» скорее облегчают жизнь, но интеграция и масштабный девопс никуда не деваются, потому что микросервисы это распределённая система со всеми вытекающими сложностями