5 ms·

Conductor – A microservices orchestration engine that runs in the cloud

71 points by Nimsical 10y ago

deleted 10y ago
[deleted]
sergioisidoro 10y ago
I found the title a bit misleading. As I understood this is more of a workflow engine, using microservices for each step of the workflows. Quite interesting, seeing this join Airlfow, Luigi, and other task orchestration tools, with a different approach to the deployment.
- plandis 10y ago
  I read orchestration in the sense that the owner of the business process (the person who is defining tasks) doesn't necessarily own the micro services being called.
flurdy 10y ago
Oh no, Thats the name for my microservice orchestration https://github.com/flurdy/philharmonic/tree/master/conductor https://github.com/flurdy/philharmonic/tree/master/conductor Ok, not a total surprise that other projects will pick that name for orchestration. Though more upsetting is that theirs is probably near complete and actually well made, as opposed to mine which was mostly hacked out in anger at current orchestration tools. :(
- johnhenry 10y ago
  Perhaps you and Netflix are one-in-the-same in some sort of FightClub/Mr. Robot like twist?
jjoonathan 10y ago
I get that they were trying to avoid this: > Process flows [were] “embedded” within the code of multiple application. But why did they choose a "JSON DSL" (which fortunately seems to mean JSON and not a DSL) as the best way to accomplish that? Seems to me that a builder pattern could have achieved the same thing without dropping compile time checks in probably the one place where they are most useful.
- virenb77 10y ago
  A builder pattern will still be implemented within the code. It does make it easier to define flows but does not solve the problem of embedding flows inside the apps. Having an external DSL and keeping the flow definition outside the application scope into a central registry provides better control and visibility into flows - not to mention being able to change the wiring without recompiling or deploying apps.
daddykotex 10y ago
The name is really close to Lightbend's ConductR : https://conductr.lightbend.com/ https://conductr.lightbend.com/
the_gastropod 10y ago
I'm a bit conflicted in how I feel about how much attention tools like this get. While it's absolutely a really neat tool, I think it gives a largely false idea that it's normal to need tools like this. The huge majority of companies aren't dealing with 1% of the traffic and complexity that Netflix handles. And for that vast majority of these companies, microservices and their orchestration tools are unnecessary.
deleted 10y ago
[deleted]
the_arun 10y ago
The workflow here -Isn't it similar to AWS Lambda Step functions?
deleted 10y ago
[deleted]
adamfeldman 10y ago
How does this compare to what's possible with Celery?
- nikolay 10y ago
  I don't think Celery has a built-in workflow orchestration... or does it?

71 points by Nimsical 10y ago

deleted 10y ago

[deleted]

I found the title a bit misleading. As I understood this is more of a workflow engine, using microservices for each step of the workflows. Quite interesting, seeing this join Airlfow, Luigi, and other task orchestration tools, with a different approach to the deployment.

plandis 10y ago
I read orchestration in the sense that the owner of the business process (the person who is defining tasks) doesn't necessarily own the micro services being called.

flurdy 10y ago

Oh no, Thats the name for my microservice orchestration https://github.com/flurdy/philharmonic/tree/master/conductor https://github.com/flurdy/philharmonic/tree/master/conductor Ok, not a total surprise that other projects will pick that name for orchestration. Though more upsetting is that theirs is probably near complete and actually well made, as opposed to mine which was mostly hacked out in anger at current orchestration tools. :(

johnhenry 10y ago
Perhaps you and Netflix are one-in-the-same in some sort of FightClub/Mr. Robot like twist?

jjoonathan 10y ago

I get that they were trying to avoid this: > Process flows [were] “embedded” within the code of multiple application. But why did they choose a "JSON DSL" (which fortunately seems to mean JSON and not a DSL) as the best way to accomplish that? Seems to me that a builder pattern could have achieved the same thing without dropping compile time checks in probably the one place where they are most useful.

virenb77 10y ago
A builder pattern will still be implemented within the code. It does make it easier to define flows but does not solve the problem of embedding flows inside the apps. Having an external DSL and keeping the flow definition outside the application scope into a central registry provides better control and visibility into flows - not to mention being able to change the wiring without recompiling or deploying apps.

daddykotex 10y ago

The name is really close to Lightbend's ConductR : https://conductr.lightbend.com/ https://conductr.lightbend.com/

the_gastropod 10y ago

I'm a bit conflicted in how I feel about how much attention tools like this get. While it's absolutely a really neat tool, I think it gives a largely false idea that it's normal to need tools like this. The huge majority of companies aren't dealing with 1% of the traffic and complexity that Netflix handles. And for that vast majority of these companies, microservices and their orchestration tools are unnecessary.

deleted 10y ago

[deleted]

the_arun 10y ago

The workflow here -Isn't it similar to AWS Lambda Step functions?

deleted 10y ago

[deleted]

adamfeldman 10y ago

How does this compare to what's possible with Celery?

nikolay 10y ago
I don't think Celery has a built-in workflow orchestration... or does it?