
Conductor – A microservices orchestration engine that runs in the cloud - Nimsical
http://netflix.github.io/conductor/
======
the_gastropod
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.

------
sergioisidoro
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
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
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
Perhaps you and Netflix are one-in-the-same in some sort of FightClub/Mr.
Robot like twist?

------
jjoonathan
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
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.

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

------
daddykotex
The name is really close to Lightbend's ConductR :
[https://conductr.lightbend.com/](https://conductr.lightbend.com/)

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

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

