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

Неочевидный, но весьма интересный факт: хаскель - язык, который умеет чуть ли не во все парадигмы

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

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

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

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

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

(потому что bpmn не может сделать лучше)

а, ты там работал/работаешь?

сходили к сервису верификации, скинули ему пачку данных, получили результаты. сходили к сервису скоринга, вкинули немного данных, получили в ответ обогащённые данные и расчёты. в таком духе

работал. повторюсь, особо эта многостековость пугать не должна. и вообще, вполне можно к ним идти ящитаю. там неидеально (а где вообще идеально?), но в целом вполне ок

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

Наверное стоит внести ясность, этот стек не в одной команде, а просто на всю компанию

+, разумеется. в конкретной команде ты будешь сталкиваться максимум с двумя стеками, но чаще даже с одним

Мне все равно на чем коллеги пишут, пока я получаю от них данные в удобном мне формате

так меня не множество стеков смущает, а то, какими разными способами можно реализовать стейт-машину на микросервисах

+++, о чём я и говорю. не всё ли равно, как тебе json-ы генерят

если стейтмашина в оркестраторе - это уже неплохо

я видел в этом плане некоторое дерьмо

стейт-машина там приципиально не сильно сложнее условного aasm в рельсе. грубо говоря, ряд шагов, которые выполняются или нет в зависимости от некой логики. но эликсирщики с этим работать с вероятностью 99% всё равно не будут, так что можно вообще забить :)

ну, у нас эликсирщики со стейтмашинами точно не работают, но это пока. В рубишных командах появляются свои эликсирщики, что и как они будут делать - пока неизвестно :)