Скоро начнется большой (многолетний) проект (web сервис) с кучей народа, т.к. все программисты владеют разными языками/технологиями, а хочется задействовать всех максимально эффективно - рассматривается SOA, т.е. что-б продукт состоял из множества кусков (плагинов, модулей) написанных на разных языках, которые будут взаимодействовать друг с другом (может быть через некую шину). Например срабатывает событие “save” на конкретный объект, все плагины (python, js(nodejs), c#…) которые подписаны на это событие такого типа объектов вызовутся в порядке приоритета.

Какие подводные камни есть, какие альтернативы, что нужно поизучать, может есть что-то готовое на что можно посмотреть.

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

Может есть какие-нибудь другие методы/технологи для этой цели: задействовать всех максимально эффективно.

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

сам не сталкивался, но смотреть наверно на всякие шины из энтерпрайз мира аля openesb/fuse esb и ESB в целом

я б наверно с чем-то попроще повозился (REST и тп), чем вникать в “мир прекрасного” энтерпрайза В)

В большом проекте и с использованием одного языка/платформы/архитектуры со временем всё равно получается зоопарк. Зачем создавать его изначально?

Андрей Светлов
В большом проекте и с использованием одного языка/платформы/архитектуры со временем всё равно получается зоопарк.
Зачем создавать его изначально?

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

slav0nic
сам не сталкивался, но смотреть наверно на всякие шины из энтерпрайз мира аля openesb/fuse esb и ESB в целом

я б наверно с чем-то попроще повозился (REST и тп), чем вникать в “мир прекрасного” энтерпрайза В)

спс. почитаю.
я подумываю на счет zeromq или подобного, хотя тут ещё надо рассмотреть варианты.

Посмотрите еще на AMQP. Мы в свое время использовали, чтобы развязать компоненты достаточно большой системы. Использовали RabbitMQ http://www.rabbitmq.com/ и питоновые биндинги к нему от той же команды: http://pika.github.com/ ну и celery http://celeryproject.org/, как распределятель задач. celery показался тяжелым, но тоже работал в результате нормально.

Мое мнение: по крайней мере в рамках команды необходим единый стандарт. Команда — до дюжины программистов плюс сколько нужно всяких прочих тестеров.

Если смотрите в сторону Message Queue, то нужно решить, какие возможности вам нужны. Я не имею ввиду атомарность, кроссплатформенность и поддержку языков - это и так понятно.
Но, нужна ли отказоустойчивость или сохранение сообщений на диск?

0MQ - шустрая, простая в использовании и обслуживании, но без хранения на диске.

RabbitMQ - скорость приемлемая, но Erlang и установка, обслуживание немного усложнены (соблюдать соответствия версий и т.п.), код выглядит не таким простым, зато может хранить сообщения на диске и даже самом выбирать: хранить или нет.

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

Все они достаточно функциональны и масштабируемы.

ЗЫ
Если Питон-онли, тоесть PyMQ.

Lexander
AcitveMQ - скорость приемлемая, проста в обслуживания при условии заранее выбранной архитектуры, поддерживает REST и бинарный протокол, в зависимости от потребностей позволяет способ хранения сообщений, тем самым напрямую влияя на производительность.

Да, это впечатляет.

PooH
Ну, наращивать скорость можно и в RabbitMQ.
Разница именно в способе хранения очереди.
Использование аппенд-онли лога для обеспечения сохранности данных - известная штука.
Но это действительно самый быстрый способ.