Skip to main content

12 posts tagged with "Conductor"

View All Tags

· 4 min read
Doug Sillars

I have had the opportunity in my career to work on a number of very exciting projects. I am really excited with my role at Orkes, and getting to share what I am learning about Netflix Conductor. In this post, I have dipped into my memory banks to a project that could have really benefited from the power of Conductor's workflow orchestration - simplifying and streamlining processes with the power of microservices.

In a previous role (it almost seems a lifetime ago), I worked on a project at AT&T called Video Optimizer. It is an open source tool that is used to test mobile apps and video for issues that can affect phone battery life and data usage. Working with mobile app developers, my team was able to make top mobile applications more efficient and save battery (and saved AT&T $250M in network costs!)

But what does this have to do with Microservices?

Our monolithic problem

After a few years of working with the team, our application (a monolithic Java app) had gone through several team leads and developers, and had become a mess of spaghetti code and patches. No one was really sure how it all worked, and everyone 'touched wood', grabbed a rabbits' foot, or said a silent prayer at build time. To call our code 'fragile' was a kindness.

After a very long refactor, things were better. New features were again being released, and we were moving ahead.

Manual testing

All of our application testing was done manually - by a team of very talented testers - and the analysis was done by my team. We were always the limiting factor in finding new issues in app releases. We longed for an automated analysis that could tell us when a change occurred in a mobile app.

Microservices to the rescue

In mid 2017, there was an internal push for breaking up large apps into microservices, and there was a big funding pot set aside in AT&T to aid teams in migrating applications to microservices in the cloud.

We saw this as an opportunity to achieve several of our team's goals - making the project more structured (as microservices), but also launching a cloud based version with automated testing and basic reporting. So, we set out to re-architect the application into cloud based microservices.

Getting funding

At AT&T, to get access to the big pot of funding, we had to demonstrate that our team had all of the right ideas on how to migrate Video Optimizer into microservices. The team created excellent PowerPoint presentations of how we'd break VO into a set of microservices - and actually did some basic 'orchestration' by drawing arrows indicating the way that data would make its way through the new architecture.

We were successful!

WE got the money to build the new version of Video Optimizer! But privately, I was asking the team - how are we going to build the connecting lines between our microservices - how are they going to communicate and make sure the data flows properly between these small apps?

Workflow orchestration - connecting the dots

Of course, the problem at hand was workflow orchestration - getting these fast, modular microservices to work together and produce the results we were used to seeing in our monolith.

The feedback from the dev team was "oh, don't worry - we'll figure something out." (which did not really bode well for the project). What we needed was a robust and off the shelf tool to "wire up" all of our microservices.

I've been at Orkes for two months now, and am learning about the power of Netflix Conductor's ability to connect microservice workflows - I realize that Conductor would have served this project.

So What happened?

I left AT&T soon after we received the funding for the project. I reached out to my old team - the project did get built, but was unfortunately built on a proprietary internal infrastructure - which soon broke, and was never fixed - ending the vision of a cloud based version of Video Optimizer.

I can only imagine that if given the flexibility of a better cloud, and the power of Conductor, that this project would be going strong today. Using a tool like our Playground would have allowed the team to quickly mock up the connections between the microservices, and see that communication was working as expected.

Do you have projects that you've worked on, that in hindsight, would have been more successful with workflow orchestration? Tell us about it in our Discord channel.

· 7 min read

I learned how to code and fell in love with it during freshman year in college. I still remember that the first few classes were around concepts and were mostly lectures. While I was still getting an idea of what this is all about, it wasn’t until I did the first hands-on lab (in C!) when everything just snapped together and I found my passion. Soon after, I switched my major from Physics to Computer Engineering.

This also happens to be how most developers want to learn new things - by trying it out! We see that everyday when we talk to customers who might not be deeply familiar with Conductor. Quick recap: Conductor is the microservices and workflow orchestration platform originally created and battle tested at Netflix before gaining a large adoption with developers building applications across the spectrum of scale and use cases.

During such conversations, the excitement and curiosity is clearly higher when someone has actually played with Conductor, whether it's on their own time or together with us on a call. It is usually followed up with a concrete discussion around their questions or deep dives on particular topics. The Conductor documentation is a great resource to show how any developer can quickly install Conductor on their laptop or their cloud environment and get started on playing with it.

But we wanted to make it even easier and frictionless!

Introducing the Conductor Playground

We are excited to introduce the Conductor Playground, a fully managed browser based sandbox environment for developers to try out Conductor with no installs or configurations needed. It is completely free and is fully featured so that you can just focus on exploring how everything is organized, creating different workflows, executing them, seeing the results and more. The playground shows you what all are possible with Conductor and you can let your imagination run wild on the things you could build!

The Conductor Playground is built by running Conductor as a multi-tenant cluster. When you use it, a dedicated namespace is created for you so that the tasks and workflows you create, and the executions you invoke against them are visible only to you. We also intend the playground to be a place where we can publish the latest features so that the community gets a chance to try them out early on and give us feedback. And please do give us feedback - we go through each of them in detail and it's absolutely the best way for us to keep making Conductor even better and give back to the community.

We have also included a set of pre-built workflows for everyone so that you have a starting point in your exploration. These show the different ways in which workflows are defined and the various Conductor operators that make it possible for you to describe your business logic in an intuitive way. You can just execute them to see them in action or you can add more logic on top of that to make your own workflow to play with.

It is also worth noting the scope we had in mind when we built the playground so that you can better plan your journey of learning (and loving!) Conductor. While the playground is a great place to test your workflows and understand how Conductor works, it is not intended for production usage. When you are ready for running your production workloads, we recommend using some of the other ways in which Conductor can be run as dedicated for your needs. We are here to help you with that, whether you want to get going on running the open source Conductor on your own or use the fully managed service from Orkes Cloud which can run on your cloud or be hosted by Orkes.

Using the Conductor Playground

Using the playground is easy - just go to and you will be presented with a simple login screen which allows us to create a dedicated namespace for you. Once you login, you will be dropped to the Conductor UI that organizes tasks, workflows and their executions for easy navigation. The Conductor documentation site has more details about the various components of the playground.

Running a pre-installed workflow

A great next step would be to explore the pre-installed workflows. You can do that by clicking on the Workflow Definitions link on the left navigation.

Let’s pick the PopulationMaxMin workflow. What it does is that it first queries the API to get the population of the different states in the United States. This is done by the get_population_data task which is an HTTP system task that makes an outbound call to a HTTP/S endpoints, gets the result and can hand it over to other tasks downstream.

What the workflow does next is to fork two parallel tasks, one to find the state with the minimum population and the other to find the one with the maximum population. These tasks are of type JQ_TRANSFORM system task where you can process the incoming JSON structured data using JQ (Conductor moves inputs and outputs through a workflow as JSON objects). Finally, it joins the results of both and presents that to the user.

Now that you know what it does, let's test it out by running it! Click on the Run Workflow button on the left navigation and you will be presented with the screen below. Select the PopulationMaxMin workflow from the Workflow Name drop down menu - you can optionally add a unique string to the Correlation ID field if you want to query off of that later. Click Run Workflow and you just invoked an execution of the PopulationMaxMin workflow!

Click on the link below the Run Workflow button and you can see the visual and other details about this execution!

Build and run your own workflow with external workers

There is so much more you can do with Conductor! Going along with our approach of learning by playing, a good next step would be to learn about how external workers (e.g. a microservice written in your language of choice) can execute tasks defined in a workflow. This complements the system tasks from the earlier example where the execution of tasks happens within Conductor.

You can do that by building your own workflow from scratch as shown in this tutorial. In addition to step by step guidance, you can also find on Github the code for the example shown there.

Keep going!

We hope that these examples with the playground have helped you in understanding more about Conductor. You can continue on this journey on playground by referring to our documentation which has various How-To guides and in-depth reference documentation about the different components and operators of Conductor. Below are some popular topics.

Getting help and providing feedback

There are many ways to get help as you are learning more about Conductor

We want to keep making this Conductor Playground even more useful for developers, and we need your help in doing that. If you have any questions or feedback, however simple or complex it is, we want to hear from you! There is a link on the left navigation bar to provide us your Feedback - we would highly appreciate it if you could use that to let us know or using this link.

Happy playing & learning!

· 4 min read
Altaf Alam Ansari


As the Introduction documentation shows, Netflix Conductor can be used for a variety of uses cases, solving complex workflow problems that plague many companies worldwide.

Let's now try to understand how we can use Conductor to solve a Lending problem that exists in the Banking and Fintech sector.

Use Case / Problem

In the new modern era of Fintech, bank customers are moving from traditional banking to digital banking. With that, there is an expectation that the processes that are run will be faster and more streamlined. Hence, in order to keep up with the customer demands various banks are trying to automate their banking processes. One common (and complicated) process that many banks are automating to its customers is the loan banking (lending) process.

Lending workflows can be very common and potential problem that can be solved by Conductor.

banking meme

· 4 min read
Doug Sillars

In early Feb 2022, we had our first meetup on Netflix Conductor: Using Conductor in Production. It was also co-hosted by the Netflix Conductor team.

We had two excellent talks from Maros Marasalek at FRINX and Nick Tomlin at Netflix.

After the two talks, we had 2 roadmap sessions. The first session was by the Netflix Conductor team - where they discussed recent releases, and walked through the Open Source roadmap for the coming months. The second session, by our own Viren Baraiya, introduced Orkes, and our plans for extending Netflix Conductor.

Conductor in FRINX

Maros' presentation showed how the FRINX team has integrated Conductor into their product, and how the FRINX tooling helps to build custom workflows.

Bridging human and system workflows with Conductor

Nick Tomlin works on the Finance team at Netflix, and his team has built a set of Conductor workflows that enable other Netflix teams to quickly build and share workflows.

Netflix Conductor roadmap

Our third talk was from the Netflix Conductor team - where they presented the roadmap for Netflix Conductor for the coming months.

Introducing Orkes

Finally, one of our founders (and the committer of the first line of Conductor code) Viren Baraiya presented Orkes and our roadmap:


Throughout the meetup, the attendees asked a number of great questions. They are reproduced here for visibility outside the meetup.

Hello, thanks for organizing such an event. I would like to know if there are any performance metrics for Conductor? We are planning to use it in a system with heavy traffic(multimillion requests each of them would trigger a workflow) and I would like to know if it’ll be reliable enough. Thank you :)

Conductor is horizontally scalable and we have known users scaling to handle workloads at the scale you mentioned. Here is a recent discussion on scale on Github, and a post from Netflix talking about the scale.

Conductor was built ground up for high reliability and performance. There are several companies that are running multi-million workflows on their core business flows.

I hear Netflix also is using which is cadence based. How do the two overlap at Netflix and the reason behind the use of Temporal?

Conductor is the default workflow orchestration tool of choice at Netflix. That said, engineers are free to choose the tool that’s best for their needs. The Spinnaker team at Netflix felt that Temporal is best aligned with their needs.

You mention CLI. Any thoughts about SDK as well?

Yes, we are working on that - stay tuned :) (Note: Check out the Orkes video above on things we are planning for next couple quarters)

Can AWS Lambda be hooked up as a task in workflow

AWS Lambda can be hooked up, but it's not available as a default task. There is an extension available that will allow integrating with AWS lambdas. We can send you details about this.

How often are conductor versions released to the community?

Frequent releases - upto twice per month. You can see the recent releases here:

From the previous presenter, what is the expected timeline for all those features to be released?

Most of the features we mentioned today will be released over the next 2-3 quarters in phases.

Any pointers about production level setup instructions of Dynomite (with the consideration of DR) on K8s cluster?

Please connect with us on our community slack channel or via Github discussions. Dynomite is not actively maintained anymore and is on its way towards being deprecated. There are alternatives that will offer similar features of Dynomite.

Thank you

Thank you to all the speakers for their incredible presentations, and also to our community for such great questions. This is our first of many meetups, and we hope to see all of you (and everyone else) at our next meetup.

In the meantime - don't forget to Star the Conductor repository.

For the latest updates on Conductor and Orkes, please subscribe to our YouTube channel, and follow us on Twitter.

· 5 min read
Doug Sillars

In our initial image processing workflow using Netflix Conductor, we initially built a workflow that takes one image, resizes it and uploads it to S3.

In our 2nd post, we utilized a fork to create two images in parallel. When building this workflow, we reused all of the tasks from the first workflow, connecting them in a way that allowing for parallel processing of two images at once.

In both of these workflows, two tasks are reused: image_convert_resize and upload_toS3. This is one great advantage of using microservices - we create the service once, and reuse it many times in different ways.

In this post, we'll take that abstraction a step further, and replace the tasks in the two forks with a SUB_WORKFLOW. This allows us to simplify the full workflow by abstracting a frequently used set of tasks into a single task.

· 5 min read
Doug Sillars

In recent posts, we have built several image processing workflows with Conductor. In our first post, we created an image processing workflow for one image - where we provide an image along with the desired output dimensions and format. The workflow output a link on Amazon S3 to the desired file.

In the 2nd example, we used the FORK System task to create multiple images in parallel. The number of images was hardcoded in the workflow - as FORK generates exactly as many paths as are coded into the workflow.

As number of images is hardcoded in the workflow - only 2 images are created. When it comes to image generation, there is often a need for more images (as new formats become popular) or sizes - as more screens are supported.

Luckily, Conductor supports this flexibility, and has a feature to specify the number of tasks to be created at runtime. In this post, we'll demonstrate the use of dynamic forks, where the workflow splitting is done at runtime.

Learn how to create a dynamic fork workflow in this post!

· 8 min read
Doug Sillars

In our previous post on image processing workflows, we built a Netflix Conductor workflow that took an image input, and then ran 2 tasks: The first task resizes and reformats the image, and the second task uploads the image to an AWS S3 bucket.

With today's varied screen sizes, and varied browser support, it is a common requirement that the image processing pipeline must create multiple images with different sizes and formats of each image.

To do this with a Conductor workflow, we'll utilize the FORK operation to create parallel processes to generate multiple versions of the same image. The FORK task creates multiple parallel processes, so each image will be created asynchronously - ensuring a fast and efficient process.

In this post, our workflow will create 2 versions of the same image - a jpg and webp.

· 2 min read

What is Conductor

Conductor is a Microservices orchestration platform from Netflix, released under Apache 2.0 Open Source License.

Design for failures

Failures and service degradation are the fact of any system, this is especially true with large interconnected systems running in cloud. Conductor is designed with principles that systems can and will go down, degrade in performance and any dependencies should be able to handle such failures.

Tasks in Conductor

Conductor workflows are orchestration of many activities known as task. Each task represents a (ideally) stateless worker that given a specific input does the work and produces output. The tasks are typically running outside of Conductor server and there are many factors that could effect their availability.

Designing for failures

Conductor allows you to define your stateful applications that can handle failures and temporary degradation of services and without having to write code for that.

Configuring tasks to handle failures

Each task in Conductor can be configured how it responds to availability events such as: 1) Failures 2) Timeouts and 3) Rate limits.

Here is a sample task definition:

"createdBy": "user",
"name": "sample_task_name_1",
"description": "This is a sample task for demo",
"responseTimeoutSeconds": 10,
"timeoutSeconds": 30,
"timeoutPolicy": "TIME_OUT_WF",
"retryCount": 3,
"retryLogic": "FIXED",
"retryDelaySeconds": 5,
"rateLimitPerFrequency": 0,
"rateLimitFrequencyInSeconds": 1

retry* parameters specify how to handle cases where the task execution fails and retries can be configured to be with fixed delay or exponential backoff. Similarly timeout* parameters specify how much time to give for task to complete execution and if the task should be marked as 'Timed Out' if it runs longer than that.

More Details

Follow us on for the source code and updates.

· 9 min read
Doug Sillars

There are many tools available to work with images - resizing, changing the format, cropping, changing colors, etc. Tools like Photoshop require a lot of manual work to create image. Online tools for image processing are also extremely popular. But, rather than doing the work manually, or paying for a service to modify your images, wouldn't it be cool to have a workflow that does image resizing for you automatically? In this post, we'll build just this using Conductor to orchestrate the microservices involved, and to create an API-like surface for image processing.

In this post, we'll run Conductor locally on your computer. The Conductor workflow consists of two tasks. The first task reads in an image and resizes it according to the parameters provided (labeled "image_convert_resize_ref" in the image below). The second task ("image_toS3_ref" below) takes the resized image and saves the it to an Amazon S3 bucket.

Diagram of our image processing workflow

Using a microservice architecture for this process allows for easy swapping of components, and allows for easy extension of the workflow - easily adding additional image processing steps (or even swapping in and out different processes for different workflows). We could also easily change the location of the saved file based on different parameters.

· 6 min read

Microservices have emerged as the dominant application development paradigm in the software world today. It has tremendous benefits both from a business and technical perspective due to its fundamental characteristics of agility, scalability, and resiliency.

However, implementing microservices are hard! The inherently distributed nature of this architectural pattern introduces complexity across multiple areas especially around Transaction Management, Data Consistency, and Process Automation. In a distributed system, Business Transactions can span across multiple services. Since we no longer have the ability to run a single ACID transaction, it requires careful coordination across these services to ensure that you have a consistent and reliable system at the end of a business process.

Solutions to solve this “coordination” problem have led to the rise of a new set of application patterns that can be broadly classified into two main groups - Choreography and Orchestration.