Потому что кубернетс сделали в Гугле, чтобы управлять своей флотилией серверов. Вряд ли автор работает в Гугле
Можно конечно настроить кубернетс для своих 1.5 микросервиса, но это как из пушки по воробьям. Кубернетс сам по себе - сложная штука. А даже простой переход на докеры - это кратный рост затрат на инфраструктуру и зарплаты дев опсов.
Интересно причем тут маркетолог? Это он типа решил в одно рыло сделать электромобиль и все его молча послушались? Или все же топ-менеджменту в голу пришла гениальная идея и назначили маркетолога козлом отпущения?
Так-то электромобиль и феррари с 6 литровыми атмосферными V12 - вызывает когнитивный диссонанс
Для баланса - однажды тоже довелось сделать поддержку двух бд - oracle и ms sql. Но был c# + nhibernate. Все прошло гладко, за 3 часа. Но было это 3000 лет назад.
И как я уже писал недавно в коментах - на том проекте еще был store procedure api (как rest api, только хранимки). Из-за того что следил, чтобы код держали близко к старому стандарту типа sql 92 - потребовались незначительные изменения.
Продукт был в банковской сфере, кодили его 5 программистов. Это чтоб примерно понимать сложность.
Хороший вопрос, так то DDD в принципе имеет проблемы с БД. Когда начинается борьба за производительность - и например логику начинают переносить в хранимки - это начинает нарушать DDD.
Конкретно у меня был опыт перехода на другую БД. Точнее задача стояла даже чуть по-другому - поддерживать ДВЕ БД одновременно. Но по правде сказать, ситуацию облегчало то, что обе были SQL. Но вместе с тем, усложняло то, что на том проекте был Store Procedure API, вот как REST API, только это на хранимках.
У меня были repository + nhibernate внутри репозиториев, наружу он не торчал. База была Oracle, а надо было MS SQL. Но ORM тут помогла в плане - она "переписала" за нас все SQL запросы. Ну то есть, если бы не было ORM - просто пришлось бы руками переписать, потратили бы больше времени. Бизнес слой и выше - не был затронут вообще.
И да, это было 3000 лет назад - там был банковско-содержащий продукт (в смысле это была не АБС, а попроще). У банков тогда был в основном oracle 10-ой версии, у некоторых 11-ый, а вот клиент, который пришел чуть позже - хотел MS SQL 2008.
А вот с Store Procedure API было чуть интересней. Так вышло, что я там заранее принял решение использовать в хранимках максимально старый и максимально общий SQL стандарт - ну типа 92 года и запретил использовать уникальные вещи конкретной БД (например в oracle 10 были интересные недокументированные функций по работе с иерархическими данными). И следил за этим.
В итоге мы отделили версию Store Procedure API для MS SQL, но там почти ничего не пришлось править, кроме вещей типа SELECT TOP N. И транзакции вроде сразу заработали, по крайней мере я не помню проблем. Даже если и были - решились легко значит.
но это противоречит принципам EF и приводит к неоптимальному коду
Ну на двух стульях не получится усидеть, либо классический репозиторий, где в потенциально можно абстрагироваться от хранилища (потому что репо возвращает бизнес объекты и DTO). Либо по максимуму использовать удобства конкретной ORM, в том числе, в мире C# - тот самый IQueryable.
Интересно, что народ в целом согласен, что IQueryable создает проблемы, но то что сама ORM тоже создает определенные проблемы - с этим типа мирятся. Ну хозяин барин.
Добавлю - пожалуй orm типа ef и репозиторий даже в какой то мере мешают друг другу.
Это хорошо видно на методе update. В классическом репозитории - туда приходит dto и внутри формируется sql запрос update. В случае с ef, если был включен трекинг - метод update вырождается до вызова save changes. А если еще есть транзакционная обвязка, то метод update вообще пустой, потому что save changes вызывается где-то выше по стеку, там где begin / commit transaction
А версия no sql была без ef? Как бы получается, что вопросы эти касаются именно ef. Грубо говоря, для get-by-id - если в первой реализации вы не трекали изменения, значит во второй используете as-no-tracking
Все же чистый репозиторий (в том числе без всяких дженериков) + unit of work дает больше гибкости, чем orm или связка репозиторий + orm внутри.
И никто не знает, как писать об этом в резюме. Да, карьерные консультанты скажут вам, что чтобы быть конкурентоспособным на рынке, вы должны уметь работать с ИИ. Можно у того же ИИ спросить, как это сделать
Я написал, что с помощью ЫЫ-шечки автоматизировал CI/CD для микросервисов и увеличил скорость доставки первой версии (с момента создания репозитория до деплоя) на 146% 🙃 A чат гпт убеждал меня что 146% невозможны
Постройте осознанный личный бренд, который основан не только на том, что вы говорите про свои 70% роста год к году, а на реальных историях, которые связывают вас с правильными людьми, которые будут готовы за вас поручиться, как за себя. На это нужно потратить 2–3 года до того, как оно вам понадобится
Уточнение - 2-3 лет тут, пожалуй, не хватит.
У меня отец такой, строил нетворк, начиная с 1988-1989 года в проектном институте, когда туда впервые завезли IBM компы, и продолжал строить по мере переезда в другие города. Когда меняет работу (последняя смена была лет 5 назад) - они нигде не откликается, просто говорит знакомым, что хочет поменять и у него сразу же несколько предложений. Но это была действительно колоссальная работа и часто за рюмочкой водки (это обратная сторона этого нетворкинга)
Это могло бы быть весомым аргументом, если бы не тот факт, что рядом работают другие и нормальные. Ну у автора статьи может и нет. Но у нас похожая проблема, компания из 100 человек примерно. Хорошо, что таких все таки увольняют, не сразу, после того как накопится критическая масса жалоб и / или косяков, но лучше так, чем никак.
Потому что кубернетс сделали в Гугле, чтобы управлять своей флотилией серверов. Вряд ли автор работает в Гугле
Можно конечно настроить кубернетс для своих 1.5 микросервиса, но это как из пушки по воробьям. Кубернетс сам по себе - сложная штука. А даже простой переход на докеры - это кратный рост затрат на инфраструктуру и зарплаты дев опсов.
Короче, сначала надо провести бизнес-анализ законов и разгрести легаси там. Ну а потом уже можно взяться за разработку софта /s
Интересно причем тут маркетолог? Это он типа решил в одно рыло сделать электромобиль и все его молча послушались? Или все же топ-менеджменту в голу пришла гениальная идея и назначили маркетолога козлом отпущения?
Так-то электромобиль и феррари с 6 литровыми атмосферными V12 - вызывает когнитивный диссонанс
Для баланса - однажды тоже довелось сделать поддержку двух бд - oracle и ms sql. Но был c# + nhibernate. Все прошло гладко, за 3 часа. Но было это 3000 лет назад.
И как я уже писал недавно в коментах - на том проекте еще был store procedure api (как rest api, только хранимки). Из-за того что следил, чтобы код держали близко к старому стандарту типа sql 92 - потребовались незначительные изменения.
Продукт был в банковской сфере, кодили его 5 программистов. Это чтоб примерно понимать сложность.
Кубернетс для геологов? Звучит как оверинжиниринг.
Не успел)
Зумеры в Гнусмасе придумали Nokia 7280 😄
А под фоткой отметились миллениалы и старше
Хороший вопрос, так то DDD в принципе имеет проблемы с БД. Когда начинается борьба за производительность - и например логику начинают переносить в хранимки - это начинает нарушать DDD.
Конкретно у меня был опыт перехода на другую БД. Точнее задача стояла даже чуть по-другому - поддерживать ДВЕ БД одновременно. Но по правде сказать, ситуацию облегчало то, что обе были SQL. Но вместе с тем, усложняло то, что на том проекте был Store Procedure API, вот как REST API, только это на хранимках.
У меня были repository + nhibernate внутри репозиториев, наружу он не торчал. База была Oracle, а надо было MS SQL. Но ORM тут помогла в плане - она "переписала" за нас все SQL запросы. Ну то есть, если бы не было ORM - просто пришлось бы руками переписать, потратили бы больше времени. Бизнес слой и выше - не был затронут вообще.
И да, это было 3000 лет назад - там был банковско-содержащий продукт (в смысле это была не АБС, а попроще). У банков тогда был в основном oracle 10-ой версии, у некоторых 11-ый, а вот клиент, который пришел чуть позже - хотел MS SQL 2008.
А вот с Store Procedure API было чуть интересней. Так вышло, что я там заранее принял решение использовать в хранимках максимально старый и максимально общий SQL стандарт - ну типа 92 года и запретил использовать уникальные вещи конкретной БД (например в oracle 10 были интересные недокументированные функций по работе с иерархическими данными). И следил за этим.
В итоге мы отделили версию Store Procedure API для MS SQL, но там почти ничего не пришлось править, кроме вещей типа SELECT TOP N. И транзакции вроде сразу заработали, по крайней мере я не помню проблем. Даже если и были - решились легко значит.
Ну на двух стульях не получится усидеть, либо классический репозиторий, где в потенциально можно абстрагироваться от хранилища (потому что репо возвращает бизнес объекты и DTO). Либо по максимуму использовать удобства конкретной ORM, в том числе, в мире C# - тот самый IQueryable.
Интересно, что народ в целом согласен, что IQueryable создает проблемы, но то что сама ORM тоже создает определенные проблемы - с этим типа мирятся. Ну хозяин барин.
Добавлю - пожалуй orm типа ef и репозиторий даже в какой то мере мешают друг другу.
Это хорошо видно на методе update. В классическом репозитории - туда приходит dto и внутри формируется sql запрос update. В случае с ef, если был включен трекинг - метод update вырождается до вызова save changes. А если еще есть транзакционная обвязка, то метод update вообще пустой, потому что save changes вызывается где-то выше по стеку, там где begin / commit transaction
А версия no sql была без ef? Как бы получается, что вопросы эти касаются именно ef. Грубо говоря, для get-by-id - если в первой реализации вы не трекали изменения, значит во второй используете as-no-tracking
Все же чистый репозиторий (в том числе без всяких дженериков) + unit of work дает больше гибкости, чем orm или связка репозиторий + orm внутри.
Один раз случайность, два - совпадение, три - … 😀
Но в случае с flannery_gold там сильнее заметно, а тут только одна эта последовательность выдала
А как становятся таким людьми, а? Как они все это придумывают?
«В гости со своим самоваром не ходят» 😀
Кажется этот комент написан чатом гпт
Никак, просто ирония над цифрами в резюме.
Я написал, что с помощью ЫЫ-шечки автоматизировал CI/CD для микросервисов и увеличил скорость доставки первой версии (с момента создания репозитория до деплоя) на 146% 🙃 A чат гпт убеждал меня что 146% невозможны
(но пока никто не оценил 😅)
Уточнение - 2-3 лет тут, пожалуй, не хватит.
У меня отец такой, строил нетворк, начиная с 1988-1989 года в проектном институте, когда туда впервые завезли IBM компы, и продолжал строить по мере переезда в другие города. Когда меняет работу (последняя смена была лет 5 назад) - они нигде не откликается, просто говорит знакомым, что хочет поменять и у него сразу же несколько предложений. Но это была действительно колоссальная работа и часто за рюмочкой водки (это обратная сторона этого нетворкинга)
Это могло бы быть весомым аргументом, если бы не тот факт, что рядом работают другие и нормальные. Ну у автора статьи может и нет. Но у нас похожая проблема, компания из 100 человек примерно. Хорошо, что таких все таки увольняют, не сразу, после того как накопится критическая масса жалоб и / или косяков, но лучше так, чем никак.
Кажется вот они все эти 1000 откликов
Не подсказывайте 🙃 они же все начнут, как под копирку, вставлять именно эту фразу.
И снова тех лид - два в одном с тим лидом, даже три в одном - еще и CTO, мда, а зп сколько?
https://spb.hh.ru/vacancy/133973171
Госпадя, еще и системный/бизнес аналитик. Вы там 30 чел наняли - кто тогда они и что они будут делать??