Зачем локально надо иметь все сервисы для пунктов 1 и 2?
Тесты у вас должны бегаться в Дженкинсе каком то и у команды тестировщиков свои инеграционные тесты должны быть.
Демо какое то надо проводить в отдельной песочнике или замороженном на время стейджинге. Иначе что то происходит с ноутбуком и демо накрылось.
И как вы собираетесь локально подымать пару сотен микросервисов и все их датасорсы локально. У вас банально не хватит памяти на компьютере.
Мое утверждение что если вам для разработки одного микросервиса надо подымать локально все остальные микросервисы то у вас на самом деле просто размазанный монолит.
Если вам для того чтобы протестировать локально что-то в одном микросервисе надо поднять все остальный так же локально, то у вас большие проблемы и неверная архитектура.
Релизы целую эпоху делались без VCS. Связь VCS (в основном git) и версионирования — довольно недавно распространившаяся практика.
Вот я дурак и не знал этого. И зачем то мучался на CSV еще :((
Те же люди, кто это решает про интеграционные тесты при множестве репозиториев.
если у вас люди решают что то мы запускаем тесты то нет, то запускаем только эти а теперь вот эти — то у вас проблемы. CI тем и хорош что вы тестируете все и на раннем этапе видите где что сломалось.
Какая разница, есть у меня опыт или нет, я же не буду это доказывать.
Большая — одно дело рассуждать чисто теоретически, а другое дело набить шишек и точно знать, что теория хороша но на практике получается вот так то.
Вы же только что говорили, что я могу делать что угодно, пока публичный контракт сохраняется.
Да, только когда у вас инфраструктура на джава и пхп то запилить сервис на хаскеле выйдет времени ого-го как больше. Посколько в джаве у вас уже есть готовое ядро которое и логирует куда надо и авторизация прикручена. А в хаскеле это все придется реализовывать. Соответственно вам надо будет убедить остальных членов команды и бизнес, что вместо Х времени и понятный язык остальным членам команды, вам надо будет 5Х времени и хаскель на который потом никого не найти. И если вы это сделаете, то конечно пишите на хаскеле.
Не нужно. Собираете то, что изменилось.
а ты жил с монорепо или это чисто теоретическое? А так чтобы еще и несколько языков в этом монорепо было?
Можно делать релиз и без VCS, и зависеть от этого релиза, например.
опять таки — насколько эти слова сочетаются с практикой? Потому что иначе это уже не монорепо.
Для остальных можно запустить что-нибудь интеграционно-функциональное, если есть и если надо.
слишком много слов если есть и если надо. кто решает?
А почему бы и нет если покажете почему его надо делать на хаскеле, а так же заинтегрируетесь в существующую архитектуру — например логи, авторизации и тд.
И вы понимаете, что ваш вопрос простая провокация, тк одно то, что пойди найди людей на Хаскель уже заводит компанию в тупик.
Что вы в цифрах хотите померять? Или вы хотите, чтобы я описал все случаи когда нам может понадобиться использовать новую версию какой либо библиотеки?
П.С. Попробуйте найти людей кто захочет идти на легаси проект с ангулар v1
ну да ну да :)
у нас есть N микро сервисов а чтобы собрать один надо собрать все.
Меняешь зависимость, она меняется глобально во всех сервисах и потом сиди и ковыряй все модули.
Один сервис при тестах упал — все забудь про релиз своего сервиса.
Новую версию библиотеки — легко, если есть хорошее покрытие.
нет — потому что окажется, с новым подходом идет библиотека v2, у вас используется v1 и пока вы весь монолит не перенесете вы не сможете мигрировать на нее. А чтобы перенести надо чтобы все люди которые пилят свои модули взяли и нашли для этого время одновременно. И как показывает практика это очень тяжело выполнимое условие.
Но проблема в том, что и другую парадигму и на микросервисах впихнуть не так просто, как кажется.
Это просто было бы желание. В чем есть наглядный пример на текущей работе.
Большинству бизнесов надо фичи деливерить, а не хотелки разрабов удовлетворять.
Вы передергиваете. Почему вы например считаете что переход например с мемкеша на редис который уменьшил в несколько раз время ответа это хотелки девелоперов?
Или изменения архитектуры и уход с стандартной thread per action на реактивный стек позволил уменьшить потребляемую память с 5Гб до 1Гб тем самым экономя деньги на каждом инстансе плюс всплески трафика обрабатываются без проблем это тоже хотелки девелоперов?
Их тоже надо обслуживать, мигрировать, реплицировать и т.д. Затраты на это огромны.
Я не знаю откуда вы набрались таких сказок, я лично делал миграцию без даунтайма с монги в постгрес, с динамодб в постгрес. А в монолите вы фиг это сделаете легко для кого то одного модуля посколько окажется что Хибернейт решение автоматически сохраняет связи, все завязано на одну большую транзакции и тд.
И масштабирование зачастую упирается в эти хранилища
ну так и будете маштабировать высоко нагруженную Базу на отдельный большой инстанс а остальные будут себе спокойно жить в общем сервере на разным schemas.
а если что то легко выносится схема на свой инстанс и никто не замечает разницы.
Вообще не согласен с вами. Наоборот оверхед есть на монолите, в который вы не впихнете новую версию библиотеки или какую нибудь реактивщину, посколько другие модули за которе ответственны другие разработчики просто либо заняты либо ленивые.
Вы можете делать что угодно в рамках своего микросервиса если это не меняет публичный контракт и это действительно классно и только ускоряет разработку из моего опыта.
CI/CD будет потреблять меньше тк в случае изменения в одном сервисе не надо заново пересобирать и тестировать весь проект. По инфраструктуре вы можете поднять много инстансов сервиса который потребляет много ресурсов, а другие пусть живут на двух инстансах с небольшим кол-ом ресурсов. В то время как на монолите вы будете плодить инстансы для всего сервиса целиком.
Ну и в проектах, где я участвовал, было море языков: dsl для Gradle, Sql для базы, shell скрипты для разных ОС.
Это вы уже перекручиваете. так можно сказать и JSON и YAML записать в языки :)
Cмысл на бэкенде с ЖДК 11 или 14 использовать Котлин для меня не понятен. Под Андроид это да — must have. А бэкенде нет смыла — тк особо не укоротишь ничего и отовсюду торчат уши стандартной джавы от используемых библиотек. Просто так взять и хибернейт засунуть в корутины не получится.
Да и язык не такой сложный, чтобы можно было бы оправдать идею "не будем еще и на нем кодить" (как мне кажется).
Дело не в сложности, а в целесообразности.
Основной мой посыл выше — плюсы Kotlin отнюдь не заканчиваются на data class.
А где он делает действительное что то уникальное? Кроме давайте сократим на пару символом джава код. Используя ЖС(какой нить Vue+Node) я понимаю плюсы такого подхода, берем Раст и тоже понятно, даже Го обладает уникальными свойствами ради которых их можно использовать. А Котлин как не кручу, ну не вижу смысла.
Я могу наприводить примером с Ломбок, которые в Котлине не сможете сделать. Так же как и вы приведете свои. Те на самом деле позиции примерно равные.
который пишется теми, кто готов изучить +1 язык программирования.
И не надо Lombok'а и прочих таких вещей.
Для меня вопрос, почему вы считаете проект на нескольких языках как плюс. А использование Ломбок который не привносит ничего в рантайм и добавляется как одна зависимость в Мавене как минус.
Да, полностью согласен.
Зачем локально надо иметь все сервисы для пунктов 1 и 2?
Тесты у вас должны бегаться в Дженкинсе каком то и у команды тестировщиков свои инеграционные тесты должны быть.
Демо какое то надо проводить в отдельной песочнике или замороженном на время стейджинге. Иначе что то происходит с ноутбуком и демо накрылось.
И как вы собираетесь локально подымать пару сотен микросервисов и все их датасорсы локально. У вас банально не хватит памяти на компьютере.
Мое утверждение что если вам для разработки одного микросервиса надо подымать локально все остальные микросервисы то у вас на самом деле просто размазанный монолит.
нет — это всегда показатель неверного подхода.
У вас просто получается размазанный монолит.
Если вам для того чтобы протестировать локально что-то в одном микросервисе надо поднять все остальный так же локально, то у вас большие проблемы и неверная архитектура.
Вот я дурак и не знал этого. И зачем то мучался на CSV еще :((
Да, только когда у вас инфраструктура на джава и пхп то запилить сервис на хаскеле выйдет времени ого-го как больше. Посколько в джаве у вас уже есть готовое ядро которое и логирует куда надо и авторизация прикручена. А в хаскеле это все придется реализовывать. Соответственно вам надо будет убедить остальных членов команды и бизнес, что вместо Х времени и понятный язык остальным членам команды, вам надо будет 5Х времени и хаскель на который потом никого не найти. И если вы это сделаете, то конечно пишите на хаскеле.
слишком много слов
если естьиесли надо. кто решает?Вот статья про монорепо: https://medium.com/@mattklein123/monorepos-please-dont-e9a279be011b
А почему бы и нет если покажете почему его надо делать на хаскеле, а так же заинтегрируетесь в существующую архитектуру — например логи, авторизации и тд.
И вы понимаете, что ваш вопрос простая провокация, тк одно то, что пойди найди людей на Хаскель уже заводит компанию в тупик.
Что вы в цифрах хотите померять? Или вы хотите, чтобы я описал все случаи когда нам может понадобиться использовать новую версию какой либо библиотеки?
П.С. Попробуйте найти людей кто захочет идти на легаси проект с ангулар v1
ну да ну да :)
у нас есть N микро сервисов а чтобы собрать один надо собрать все.
Меняешь зависимость, она меняется глобально во всех сервисах и потом сиди и ковыряй все модули.
Один сервис при тестах упал — все забудь про релиз своего сервиса.
Не, монорепо это кошмар. Сперва все распилим, а потом свяжем в один репозиторий и получим опять монолит.
Интересно, кто топит за монолит, вы так же обожаете работать с monorepo :)
нет — потому что окажется, с новым подходом идет библиотека v2, у вас используется v1 и пока вы весь монолит не перенесете вы не сможете мигрировать на нее. А чтобы перенести надо чтобы все люди которые пилят свои модули взяли и нашли для этого время одновременно. И как показывает практика это очень тяжело выполнимое условие.
Это просто было бы желание. В чем есть наглядный пример на текущей работе.
Я не знаю откуда вы набрались таких сказок, я лично делал миграцию без даунтайма с монги в постгрес, с динамодб в постгрес. А в монолите вы фиг это сделаете легко для кого то одного модуля посколько окажется что Хибернейт решение автоматически сохраняет связи, все завязано на одну большую транзакции и тд.
ну так и будете маштабировать высоко нагруженную Базу на отдельный большой инстанс а остальные будут себе спокойно жить в общем сервере на разным schemas.
а если что то легко выносится схема на свой инстанс и никто не замечает разницы.
а затем :)
Вообще не согласен с вами. Наоборот оверхед есть на монолите, в который вы не впихнете новую версию библиотеки или какую нибудь реактивщину, посколько другие модули за которе ответственны другие разработчики просто либо заняты либо ленивые.
Вы можете делать что угодно в рамках своего микросервиса если это не меняет публичный контракт и это действительно классно и только ускоряет разработку из моего опыта.
CI/CD будет потреблять меньше тк в случае изменения в одном сервисе не надо заново пересобирать и тестировать весь проект. По инфраструктуре вы можете поднять много инстансов сервиса который потребляет много ресурсов, а другие пусть живут на двух инстансах с небольшим кол-ом ресурсов. В то время как на монолите вы будете плодить инстансы для всего сервиса целиком.
Потому Ломбок генерит бойлер плейт байткод на этапе компиляции.
Это вы уже перекручиваете. так можно сказать и JSON и YAML записать в языки :)
Cмысл на бэкенде с ЖДК 11 или 14 использовать Котлин для меня не понятен. Под Андроид это да — must have. А бэкенде нет смыла — тк особо не укоротишь ничего и отовсюду торчат уши стандартной джавы от используемых библиотек. Просто так взять и хибернейт засунуть в корутины не получится.
Дело не в сложности, а в целесообразности.
А где он делает действительное что то уникальное? Кроме давайте сократим на пару символом джава код. Используя ЖС(какой нить Vue+Node) я понимаю плюсы такого подхода, берем Раст и тоже понятно, даже Го обладает уникальными свойствами ради которых их можно использовать. А Котлин как не кручу, ну не вижу смысла.
Я могу наприводить примером с Ломбок, которые в Котлине не сможете сделать. Так же как и вы приведете свои. Те на самом деле позиции примерно равные.
Для меня вопрос, почему вы считаете проект на нескольких языках как плюс. А использование Ломбок который не привносит ничего в рантайм и добавляется как одна зависимость в Мавене как минус.
и вроде как разницы уже и нет :)
а можно еще посмотреть код на Котлине когда у вас есть 20 пропертей в классе и надо одно из них убрать из вывода
toString?