что мешает использовать JWT токен и проверять авторизацию локально?

а как же SRP?

а читали? http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp

Почему-то все упираются в то, что микросервисы - это обязательно "по сети, распределенно". Хотя никто не мешает делать монолит по принципу микросервисов. Тогда нет проблем с быстрым стартом и деплоем и выносом на отдельные машинки(или кластера) бутылочных частей

Почему-то все упираются в то, что микросервисы - это обязательно "по сети, распределенно". Хотя никто не мешает делать монолит по принципу микросервисов. Тогда нет проблем с быстрым стартом и деплоем и выносом на отдельные машинки(или кластера) бутылочных частей

нормально делай - нормально будет! (с)

Почему-то все упираются в то, что микросервисы - это обязательно "по сети, распределенно". Хотя никто не мешает делать монолит по принципу микросервисов. Тогда нет проблем с быстрым стартом и деплоем и выносом на отдельные машинки(или кластера) бутылочных частей

когда у тебя есть 50 команд то коммитить в один монолит становится тяжело. микросервисы весьма помогают разруливать подобные вещи

что мешает использовать JWT токен и проверять авторизацию локально?

jwt избавит меня от сервиса авторизации отдельного или что?

когда у тебя есть 50 команд то коммитить в один монолит становится тяжело. микросервисы весьма помогают разруливать подобные вещи

как это противоречит тому, что я написал?

когда у тебя есть 50 команд то коммитить в один монолит становится тяжело. микросервисы весьма помогают разруливать подобные вещи

чем помогают?

jwt избавит меня от сервиса авторизации отдельного или что?

избавит от прямой зависимости на сервис авторизации. тебе прислали токен, ты проверил локально подпись и либо даешь либо не даешь доступ

приходит требование, которое затрагивает несколько сервисов. между ними нужна согласованность, а это доп коммункации между командами и их лидами, это лишняя бюрократия

как это противоречит тому, что я написал?

в теории может работать, а на практике весьма тяжело

в теории может работать, а на практике весьма тяжело

ты сейчас ерунду болтаешь. я про мягкое, ты про соленое

ты сейчас ерунду болтаешь. я про мягкое, ты про соленое

я бы сказал что микросервисы больше помогают решать организационные проблемы чем технические. монолит тоже можно масштабировать, но это требует больше дисциплины

запустил 3 монолита на разных серверах. чем не масштабирование?

и "микросервисы" на jvm сожрут куда больше памяти как бы

еще раз, можно хоть 10 монолитов запустить, никто не запрещает. но когда в компании много разработчиков и много команд, писать один монолит не очень целесообразно. например чувакам из датасайнса не особо хочется коммитить в джава монолит, так как у них все на питоне.

я бы сказал что микросервисы больше помогают решать организационные проблемы чем технические. монолит тоже можно масштабировать, но это требует больше дисциплины

ты как и все упираешься в то, что считаешь "монолит" и "микросервисы" - антагонистами

еще раз, можно хоть 10 монолитов запустить, никто не запрещает. но когда в компании много разработчиков и много команд, писать один монолит не очень целесообразно. например чувакам из датасайнса не особо хочется коммитить в джава монолит, так как у них все на питоне.

о кстати о датасайнсе. вот у тебя 10 микросервисов, там скажем сервис юзеров, ордеринга, каталог продуктов и тд есть команда дата сайнса или аналитики, им нужно сделать репорты. как они будут брать себе данные? идти напрямую в базы данных других сервисов? или напрягать все подряд команды, чтобы им делали специальные методы в api, по которым можно получать небольшой кусок данных?

по api конечно

и что мешает в монолите сделать эндпоинты для выгрузки данных в питон?

о кстати о датасайнсе. вот у тебя 10 микросервисов, там скажем сервис юзеров, ордеринга, каталог продуктов и тд есть команда дата сайнса или аналитики, им нужно сделать репорты. как они будут брать себе данные? идти напрямую в базы данных других сервисов? или напрягать все подряд команды, чтобы им делали специальные методы в api, по которым можно получать небольшой кусок данных?

делаем центальный ивентбас на какой-нибудь кафке, и пишем все туда. напрямую никуда не идем. все кому интересно будут подписываться на топики и брать инфу

@gurinderu А Вы мне фримонадки, фримонадки. Lagom !, вот где массовое внимание

Привет всем. В сложившуюся команду java разработчиков ищу скаланов для медленного и плавного мягкого обращения в нашу веру. Компания Сбертех. Разрабатываемая система движок, похожий на bpmn и прикладные скрипты выполнения оркестрации бизнес процессов. Технически akka, java, kafka. Готов посмотреть и пообучать scala джуниоров, а так же мидлов. По деньгам с учетом 25% квартальной премии джуны 60-90, мидлы 90-140. Если есть желающие гуру, тоже можно неспеша индивидуально пообщаться на предмет навыков и зп одиданий

Фу

Что не так?

и что мешает в монолите сделать эндпоинты для выгрузки данных в питон?

проблема в том, что каждому сервису нужно делать много коннекторов. в результате кол-во коннекторов и апи будет O(n^2) от количества сервисов

делаем центальный ивентбас на какой-нибудь кафке, и пишем все туда. напрямую никуда не идем. все кому интересно будут подписываться на топики и брать инфу

т.е сервис аналитики опирается только на те ивенты которые ему дали?

поэтому проще писать в одно центрально место, а все оттуда будут писать

поэтому проще писать в одно центрально место, а все оттуда будут писать

чоткие микросервисы

т.е сервис аналитики опирается только на те ивенты которые ему дали?

да, почему бы и нет.

чоткие микросервисы

я имею ввиду писать в очередь сообщений

или ивентлог

как назовешь

чоткие микросервисы

Матом у нас нельзя

проблема в том, что каждому сервису нужно делать много коннекторов. в результате кол-во коннекторов и апи будет O(n^2) от количества сервисов

Прикольно наверно трулоеикостью количество коннекторов считать

Я если честно не понимаю, что есть коннектор

Я если честно не понимаю, что есть коннектор

апи или другая ручка за которую тебя могут дергать

я имею ввиду писать в очередь сообщений

Эт собственно убийство всей идеи микросервисов

я имею ввиду писать в очередь сообщений

не слишком много проблем на команду аналитиков падает? им всего то нужно собрать статистику, а не проигрывать весь твой ивентлог чтобы воспроизвести реальную картину. какой-то CQRS/ES гибрид выходит

не слишком много проблем на команду аналитиков падает? им всего то нужно собрать статистику, а не проигрывать весь твой ивентлог чтобы воспроизвести реальную картину. какой-то CQRS/ES гибрид выходит

они не проигрывают весь ивентлог

Привет всем. В сложившуюся команду java разработчиков ищу скаланов для медленного и плавного мягкого обращения в нашу веру. Компания Сбертех. Разрабатываемая система движок, похожий на bpmn и прикладные скрипты выполнения оркестрации бизнес процессов. Технически akka, java, kafka. Готов посмотреть и пообучать scala джуниоров, а так же мидлов. По деньгам с учетом 25% квартальной премии джуны 60-90, мидлы 90-140. Если есть желающие гуру, тоже можно неспеша индивидуально пообщаться на предмет навыков и зп одиданий

хорошая попытка. Как получить хорошего джависта - взять скалиста - переучить на Java (обратно?) -...... - Profit !!!

он используется только для передачи данных

они не проигрывают весь ивентлог

ну вот им нужно сделать статистику за последний год

их действия?

чтобы небыло прямых зависимостоей на сервисы

сервисы в вакууме?

Эт собственно убийство всей идеи микросервисов

мне кажется нет

хорошая попытка. Как получить хорошего джависта - взять скалиста - переучить на Java (обратно?) -...... - Profit !!!

нет, ну а что, не всем же нравится скала.

их действия?

сохраняют в свои хранилища и процессят как хотят

хорошая попытка. Как получить хорошего джависта - взять скалиста - переучить на Java (обратно?) -...... - Profit !!!

хороший повод свичнуться обратно. и не так стыдно перед коллегами)

хорошая попытка. Как получить хорошего джависта - взять скалиста - переучить на Java (обратно?) -...... - Profit !!!

Ровно на оборот, взять скалистов. Дообучить джавистов. И таки да, профит

нет, ну а что, не всем же нравится скала.

я и написал, что идея с некоторых точек зрения вполне себе ок

Ровно на оборот, взять скалистов. Дообучить джавистов. И таки да, профит

так разработка на scala будет?

Ровно на оборот, взять скалистов. Дообучить джавистов. И таки да, профит

тогда надо как-то веру уточнить, пока звучит на java

сохраняют в свои хранилища и процессят как хотят

вот я и говорю. им нужно будет все проигрывать у себя. скажем в одном из бизнес модулей поменялась логика, эту бизнес логику нужно в модуле аналитики тоже реализовывать тогда к примеру, юзерам дали возможность архивировать ордера и доставать из архивов. как аналитикам посчитать количетсво юзеров, которые пользуются этим?

вот я и говорю. им нужно будет все проигрывать у себя. скажем в одном из бизнес модулей поменялась логика, эту бизнес логику нужно в модуле аналитики тоже реализовывать тогда к примеру, юзерам дали возможность архивировать ордера и доставать из архивов. как аналитикам посчитать количетсво юзеров, которые пользуются этим?

Обычно для этого, есть полностью настроенное окружение.

Не сразу. Сначала на скала тесты, если все ок, можно мигрировать основной код на скалу

ну дык пусть публикуют события при каждом использовании а аналитики подписываются

А в проде собирается стата и логи

ну дык пусть публикуют события при каждом использовании а аналитики подписываются

ты не понял. изменяться могут сами события и их значения. типичные проблемы ES

если события меняются, то что-то не так

событие это иммутабельный факт

он произошел и точка

я тебе конкретный пример привел - архивация

ERROR: S client not available

вот пришло аналитикам событие об архивации, они не знают что это такое и что оно делает

Идеи "взять и все переписать сразу на технологию / язык Х" только потому что это "круто" не наш стиль

вот пришло аналитикам событие об архивации, они не знают что это такое и что оно делает

как же они тогда собираются считать статистику юзеров раз они не знают свою предметную область?

Если вы ненавидите java, не готовы на ней дорабатывать существующий код, а только все с нуля и на scala, не обращайте внимания на эту вакансию

как же они тогда собираются считать статистику юзеров раз они не знают свою предметную область?

в этом то и проблема. все задачи должны дублироваться и выполняться в логике модуля аналитики? аналитикам как бы надо работать с данными, а не заниматься работой разрабов

подсадите пару разрабов в команду аналитиков

подсадите пару разрабов в команду аналитиков

занавес

в чем проблема то?

в том что как ты говоришь этот модуль на питоне

а все приложение на джаве

какие преимущества получил проект от перехода на такое решение?

гибкость и скорость внедрения новых фич

куча небольших команд со своим кодом работает быстрее чем разные команды пишущие один монолит

пробовали с монолитом, оказалось совсем не гибко

поэтому перешли на микросервисы

Еще дополнение - москва, офис в районе м. Нагатинская, удаленка невозможна

Еще дополнение - москва, офис в районе м. Нагатинская, удаленка невозможна

График работы какой и сколько раз кушать можно? ?

Еще дополнение - москва, офис в районе м. Нагатинская, удаленка невозможна

ну вооооот, опять удаленщиков обделяют

гибкость и скорость внедрения новых фич

ты себе противоречишь. вместо одной команды работающей над фичей, нужно как минимум 2(одна на джаве, другая на питоне повторяет всю логику за джавистами), а это менее гибко и быстро

ты себе противоречишь. вместо одной команды работающей над фичей, нужно как минимум 2(одна на джаве, другая на питоне повторяет всю логику за джавистами), а это менее гибко и быстро

если комания небольшая, то да, будет оверхед. когда команд больше 200, то монолит не очень удобен.

"повторяя всю логику", пользуясь чьим-то апи - ты повторяешь чужую логику. Вот это я понял.

Если вы ненавидите java, не готовы на ней дорабатывать существующий код, а только все с нуля и на scala, не обращайте внимания на эту вакансию

я честно говоря не очень понимаю хейтеров каких либо языков. Проблемы начинаются когда микроскопом гвозди пытаются вкручивать. А так с точки зрения бизнеса java во многих сферах очень даже ок.

Еще дополнение - москва, офис в районе м. Нагатинская, удаленка невозможна

В РТС что-ли? ?

График работы какой и сколько раз кушать можно? ?

График фиксированный, начало рабочего дня по договоренности 8-11. Кушать, курить и др без ограничений. Главное задачи делайте вовремя и качественно

ну вооооот, опять удаленщиков обделяют

Увы.

В РТС что-ли? ?

Да, РТС. В обозримой перспективе переезд на Кутузовский проспект

Да, РТС. В обозримой перспективе переезд на Кутузовский проспект

соседи значит, я в калейдоскопе ?

я честно говоря не очень понимаю хейтеров каких либо языков. Проблемы начинаются когда микроскопом гвозди пытаются вкручивать. А так с точки зрения бизнеса java во многих сферах очень даже ок.

Соглсен. Если часть кода на java и делает свое дело, то мигрировать просто так - нецелесообразно

Если кто-то хочет знать, почему я ушёл из Сбертеха, пишите

Почему я и моя жена ушли