When you’re first getting into the world of software, all software seems pretty similar. As you start building more and more projects, you’ll discover there are patterns to them. Different software architectures use different software patterns. In this post, we’ll be investigating the Orchestrator Pattern, a pattern for serverless microservice architectures.

In this post we will go over:

• What is an Orchestrator/Orchestration Pattern
• Why should I use an Orchestrator?
  • Orchestrator Pros
  • Orchestrator Cons
• When should I use an Orchestrator?
  • Monitoring
  • Asynchronous API Calls
  • Chaining Functions
• An example of a Python implementation of an Orchestrator Pattern

What is an Orchestrator/Orchestration Pattern?

In the simplest terms, an orchestrator or orchestration pattern uses an orchestrator to control function execution. This is a subtle difference from using a main function to execute functions. While orchestrators can be used to perform single tasks, they can also be used to connect multiple parts of your program together. Note that orchestrators are not only used for serverless microservice architectures, but are most commonly used in serverless microservice architectures.

Serverless lends itself to microservices very well. A serverless architecture typically spins up and spins down small servers to perform some small tasks on demand. Microservices are small tasks that don’t require maintaining state from execution to execution. As a result, these two are almost always coupled together. But why are orchestrators used in this architecture?

Why use an Orchestrator Pattern?

As the name suggests, orchestration is the process of getting multiple different parts moving together. In a serverless architecture we need to tie many different types of processes together in order to function. An orchestrator pattern helps tie things together. We use it as a top level function to access APIs, data access objects (DAOs), routing functions, business logic functions, and more.

Pros of Orchestrators

• Ties many types of functions together
• Can circumvent needing persistent states
• Handles integration with asynchronous API requests
• Flexibility of functions
• Allows encapsulation of functions
• Decoupled from logic layers

Cons of Orchestrators

• Added layer = added complexity
• Could be hard to debug if orchestrating functions from multiple packages

When should I use an Orchestrator?

Orchestration is ideal for large projects with complex microservice architectures. I recognize that is a VAGUE statement so let’s go over three use cases where an orchestrator would be ideal. The three use cases we’ll go over are for monitoring, asynchronous API calls, and chaining multiple functions.

Monitoring

Monitoring sounds pretty simple but it’s actually much more complex than it sounds. It requires scheduling functions, and retrieving, transforming, storing, and checking data. An orchestrator is perfect for this situation. Best practices would involve having different functions for each of these tasks as well as at least four different layers. One for scheduling CRON jobs or something of the like, one for retrieving data, one for transforming and checking data, and one for storing data. This doesn’t even take into account the exact structure of each of the layers.

Asynchronous API Calls

If you’re building a system that uses asynchronous API calls, an orchestrator is ideal. It’s especially useful if you need to create multiple sessions. Note that it’s best practice to split sessions for calls if you need different session variables like cookies. Having an orchestrator allows you to put together not just multiple API calls, but concurrently make asynchronous API calls and handle multiple sessions.

Chaining Functions

I think this is the most obvious usage for an orchestrator. In this case, we’re using an orchestrator much like a regular controller in the MVC architecture. As mentioned above, one of the differences here is the orchestrators are not tied to business logic. An orchestrator can chain many types of functions together. These can be business logic or logic agnostic functions. 

Example of an Orchestrator Pattern Program in Python

Many of the examples we’ve covered on this site show some simple form of a microservice architecture such as an NLP investigation of the Obama Presidency or seeing How Twitter Feels about Black Friday. The most recent fully fledged program we created on How to Create an AI Content Moderation System, uses an orchestrator. Below we can see an example of the system overview.

I won’t replicate all the code here, but you can see that there are multiple functions and an orchestrator. To see all the Python code, click here for the webscraper, here for the content moderator, here for the orchestrator, and here for all of it put together.

Further Reading

• Build Your Own AI Text Summarizer in Python
• How to Create a Low Level Design Document
• Named Entity Recognition (NER) in Python
• Natural Language Processing (NLP): What is Text Polarity?
• Text Sentiment Analysis and How to Do It

I run this site to help you and others like you find cool projects and practice software skills. If this is helpful for you and you enjoy your ad free site, please help fund this site by donating below! If you can’t donate right now, please think of us next time.