Serverless with orchestration and choreography

Serverless with orchestration and choreography

What's better? It really depends!

Building Serverless on AWS would be using multiple AWS Services which are building either following an event-driven architecture or a microservice architecture which needs either orchestrated or a choreographed architecture so that execution happens smoothly! Sometimes, it also involves using a hybrid of orchestration and choreography.

Orchestration

Orchestration of music GIF from the internet

Just as an orchestration looks, there is a concertmaster or lead who is part of the band would controls how each musician plays their instrument; in the orchestration pattern in Serverless architecture, the orchestrator controls the flow and execution of different tasks and processes based on the workflow that is defined.

Why do you need orchestration?

Perks of orchestrations

Orchestration as a pattern promotes Serverless applications to execute in a structured and less chaotic.

  • Centralized control - With centralized control and a defined workflow for task flow and execution, orchestration assists in promptly adhering to the workflow definition. Furthermore, error-handling techniques for both the workflow and each task can be integrated into the workflow definition.

  • Scalability - In the orchestration pattern, it enables scaling individual tasks within the same workflow, simplifying the scaling of the entire workflow and only the tasks that require scaling up or down. These tasks could include Lambda Functions, ECS tasks, or the implementation of asynchronous tasks.

  • Monitoring - The centralized control enhances visibility into individual tasks and the workflow as a whole. This improves monitoring capabilities for each iteration of the execution, including the state and data passed between tasks. This makes debugging easier and provides a better understanding of the workflow's execution.

AWS Step Functions

In the AWS ecosystem, it is AWS Step Functions that enable orchestration of a workflow (State Machine in Step Functions terminology) with the execution of different tasks in the workflow.

A State Machine for User sign-up and it's related process

Serverless orchestration of workflows

AWS Step Functions helps with different kinds of flows - parallel, map, pass, choice and more which allows the flexibility to define a workflow with a combination of flows and state.

Step Functions is Serverless by nature as there isn't any infrastructure management or provision resources for the execution. Pricing for Step functions is based on the types of workflows offered -

  • Standard workflow - for longer-running workflows, which are priced with each state transition.

  • Express workflow - for shorter workflow duration where the pricing is based on number of requests for the workflow and it's duration.

The State Machine or the workflow is defined with Amazon States Language (ASL) that is a JSON-based definition. The State Machine could be used in the application's Infrastructure as Code (IaC) definitions.

Step Functions supports error-handling techniques and the JitterStrategy. Additionally, Step Functions integrates with over 1000 API actions from 200+ AWS Services using SDK Integrations and intrinsic functions. These features can enhance integrations and improve how data is accessed and processed with Step Functions.

Choreography

Choreography GIF from the internet

In the world of Event-Driven Architecture (EDA), the choreography pattern works well to ensure that microservices or architectural components are coordinated based on events. It's like a dance choreography where you wait for the right music beats and cues from your dance partner to make the next move.

Why do you need choreography?

Perks of choreography

In Event-Driven Architecture (EDA), the application relies on real-time events and reactive responses, choreography allows individual microservices to reach independently to the event.

  • Loosely-coupled - The microservices and independent services are decoupled to ensure they operate independently, even though they are triggered by events and share events to communicate with other services. Keeping the microservices loosely coupled also enhances fault tolerance. If one microservice goes down, the system remains operational because the other microservices are still running as intended.

  • Scalability - Microservices can scale independently according to the need to scale up or down, promoting efficient resource utilization.

  • Flexibility - Since microservices can scale based on the need and are loosely coupled, the architecture allows for more flexibility in making updates and rolling out upgrades while the system continues to operate as usual.

Amazon EventBridge

Amazon EventBridge enables Event-Driven Architecture (EDA) in the AWS Serverless with the EventBridge Bus offering making it easier to route events between a source and destination. EventBridge can scale up and down to support the routing of millions of events in a production-grade system.

Here is a blog about why EventBridge is a missing piece to your Serverless application -

Choreographing with EventBridge

  • Asynchronous messaging - EventBridge decouples services by allowing them to post events to a shared event bus. This bus then directs the events to specific destinations, enabling the source to post the message and proceed with the rest of the execution.

  • Event rules and filters - EventBridge works with event buses that use event rules to determine which events should be sent to which destination. When creating these intelligent rules, filters can be applied to the event payloads for more detailed routing of specific events.

  • Archive and replay - EventBridge Bus also supports archiving and replaying events. This feature allows events to be stored for later reproduction, aiding in debugging processes.

  • SaaS integrations - EventBridge supports SaaS integrations with AWS partners where the events from the AWS partner's SaaS products can be targeted to a specific SaaS Bus to process the events.

Orchestration v/s Choreography

OrchestrationChoreography
ControlCentralized control for workflow execution but has its dependencies making it coupledNo central control instead a bus for the flow of events and also loosely coupled
ComplexityWorks for both simple and complex workflowsSimple event-driven process
Error Handling and RetrySupports native error handling and retryDistributed error handling at the microservice level
ScalabilityHighly scalable but needs to adhere to different limitations during the workflowHighly scalable as each service can scale independently
LatencyPossible latency because of dependenciesLow latency with direct event routing and Pipes P2P integrations.
Cost EfficiencyDepends on the workflow and type of workflowPay only for the usage of resources

Best of orchestration and choreography

The choice between Orchestration and Choreography is hard to choose as it depends on the use-case and architectural pros and trade-offs!

One such example is when EventBridge SaaS Event bus can integrate with AWS partners such as Freshworks events choreographed into the AWS account to route the events to trigger a State Machine execution to process the events from Freshworks product - Freshdesk.

Wrap up!

Serverless architecture on AWS includes orchestration and choreography patterns for structured execution. Orchestration offers centralized control, scalability, and monitoring using AWS Step Functions, while choreography enables loosely coupled, event-driven coordination with Amazon EventBridge. Each pattern has its advantages and trade-offs, so the decision between them depends on the specific use case.

In the "Build on Weekly" episode 12 by Darko Mesaroš and Rohini Gaonkar, Orchestration, Dancing, or big blocks of code discusses these patterns of orchestration, choreography, and monoliths, highlighting the benefits of each pattern.