AK
Заводим кабинет челиков, которые думают об архитектуре и высоких проблемах, чтобы никому не было скучно
давно пора, кстати. а то обычно имеем кабинеты челиков занятых пеерусложненнием кода на типовых задачах
Size: a a a
2021 March 30
(
давно пора, кстати. а то обычно имеем кабинеты челиков занятых пеерусложненнием кода на типовых задачах
Нужно только найти челиков, чьи материи приносят вэлью
AK
дима что ли говорил что не надо вообще его писать а взять готовый
можно и так. есть целые нашлёпки на кубер, со всей хурмой: контроллеры, acl, дискваери, различные прокси, телеметрии да логгирвоания итд, полный фарш под ключ. istio, например
VP
ну не добавляй его в спринг, перенеси аус на урвоень гейтвеев или ингресс контроллеров, выдели контроль доступа отдельный комопент который будет фильтровать запросы к апишкам. потом переиспользуешь его заодно где-то ещё
Вот он, подход архитекторов. А можно просто вместо spring-security воткнуть свой фильтр и реализовать пару методов. Внутри приложения, без усложнения обвязки вокруг него.
AK
Вот он, подход архитекторов. А можно просто вместо spring-security воткнуть свой фильтр и реализовать пару методов. Внутри приложения, без усложнения обвязки вокруг него.
Вот он, подход кодеров, лишь бы что-то где-то дописать. А потом самому руками дорабатывать отдельно каждый сервис в каждой команде, воктнуть фильтр, воткнуть телеметрию, воткнуть новый ACL, воткнуть сжатие, самим начать подкладывать серты. DRY? - та нафиг оно надо, переиспользуемые комопненты это же зло, единый подход упрощающий онбординг и поодержку - вообще не нужно.
Это работает, если речь только про один сервис, когда речь про большую компании и кучу сервисов, ты утонешь поддерживать и следить, кто там себе какие филтры нагородил.
Тебе же лучше как разрабу, только апишку делаешь, остальное за тебя сделают devOps и сами будут вести эту поодержку, потому-что ты катаешь только сервис с бизнес логикой, а все вопросы доступа, транспорта, квот и многие другие решают за тебя. Разделение труда и зон отвественности
Это работает, если речь только про один сервис, когда речь про большую компании и кучу сервисов, ты утонешь поддерживать и следить, кто там себе какие филтры нагородил.
Тебе же лучше как разрабу, только апишку делаешь, остальное за тебя сделают devOps и сами будут вести эту поодержку, потому-что ты катаешь только сервис с бизнес логикой, а все вопросы доступа, транспорта, квот и многие другие решают за тебя. Разделение труда и зон отвественности
ch
Вот он, подход архитекторов. А можно просто вместо spring-security воткнуть свой фильтр и реализовать пару методов. Внутри приложения, без усложнения обвязки вокруг него.
тема слишком серьезная, чтобы отдавать на откуп своим костылям
VP
Вот он, подход кодеров, лишь бы что-то где-то дописать. А потом самому руками дорабатывать отдельно каждый сервис в каждой команде, воктнуть фильтр, воткнуть телеметрию, воткнуть новый ACL, воткнуть сжатие, самим начать подкладывать серты. DRY? - та нафиг оно надо, переиспользуемые комопненты это же зло, единый подход упрощающий онбординг и поодержку - вообще не нужно.
Это работает, если речь только про один сервис, когда речь про большую компании и кучу сервисов, ты утонешь поддерживать и следить, кто там себе какие филтры нагородил.
Тебе же лучше как разрабу, только апишку делаешь, остальное за тебя сделают devOps и сами будут вести эту поодержку, потому-что ты катаешь только сервис с бизнес логикой, а все вопросы доступа, транспорта, квот и многие другие решают за тебя. Разделение труда и зон отвественности
Это работает, если речь только про один сервис, когда речь про большую компании и кучу сервисов, ты утонешь поддерживать и следить, кто там себе какие филтры нагородил.
Тебе же лучше как разрабу, только апишку делаешь, остальное за тебя сделают devOps и сами будут вести эту поодержку, потому-что ты катаешь только сервис с бизнес логикой, а все вопросы доступа, транспорта, квот и многие другие решают за тебя. Разделение труда и зон отвественности
Следи за руками: оформляешь всю эту хуйню в spring boot starter, а потом в своих 100500 сервисах подключаешь одну зависимость и у тебя вжух и всё есть
VP
Или ты думаешь, что без сайдкаров с девопсами кодеры не умеют в DRY?
ch
Следи за руками: оформляешь всю эту хуйню в spring boot starter, а потом в своих 100500 сервисах подключаешь одну зависимость и у тебя вжух и всё есть
еще скажи revere proxy не нужен
AK
Следи за руками: оформляешь всю эту хуйню в spring boot starter, а потом в своих 100500 сервисах подключаешь одну зависимость и у тебя вжух и всё есть
вжух не срабатывает, т.к. большинство крупных ИТ ландшавтов не является моностеком
VP
еще скажи revere proxy не нужен
На входе в облако - да. Внутри на каждый сервис - нахуй не нужен, если ты не собрался разводить зоопарк решений на разных языках.
VP
вжух не срабатывает, т.к. большинство крупных ИТ ландшавтов не является моностеком
Один хер будет больно, но да, с твоим подходом меньше
AK
Или ты думаешь, что без сайдкаров с девопсами кодеры не умеют в DRY?
ну.. зачастую - да. особенно если они сидят разных стеках. да даже в переделах одной платформы (например жвм) - иди убеди скалиста использовать spring boot starter.
VP
Антон, нужен охуенный стикер на тему k8s и обмазывания сайдкарами на каждый чих
AK
Антон, нужен охуенный стикер на тему k8s и обмазывания сайдкарами на каждый чих
это да, надо придумать. иногда оно выходит из под контроля и сложно остановиться
АВ
Бля профессор прости мы все проебали...
ch
то ли еще будет, вот когда начнут драйвера делать на js, вот тогда можно сказать, мы все просрали
AM
то ли еще будет, вот когда начнут драйвера делать на js, вот тогда можно сказать, мы все просрали
😱