System Orchestrator Architecture

This post is part of the "Automation-Orchestration" architecture series. Posts of this series together comprise a whitepaper on Automation and Orchestration for Innovative IT-aaS Architectures.

This final chapter addresses architecture components for typical system orchestrators; comparing these with the blueprints for high-grade innovative automation solutions mentioned previously in this paper will reveal the close resemblance between automation and system orchestration patterns in a very obvious way.

The first figure below is system deployment architecture diagram describing the main physical components for a system orchestrator:

Note, that:

1. the database normally needs to be setup in a clustered mode for high availability. Most orchestrator solutions do rely fully on the database (at least at design time).
2. the Management Server’s deployment architecture is depending on availability requirements for management and control.
3. the Runtime server nodes should be highly distributed (ideally geographically dispersed). The better this is supported by the product architecture the more reliable orchestration will support IT operations.
4. the Web service deployment is depending on availability and web service API needs (product and requirement dependent)

Logical architecture

The logical architecture builds on the previous description of the deployment architecture and outlines the different building blocks of the orchestration solution. The logical architecture diagram is depicted in the following figure:

Notes to “logical architecture” figure:

1. The Orchestrator DB holds runtime and design time orchestration flows, action packs, activities, plugins, logs, …
2. Management Server controls access to orchestration artefacts
3. Runtime Server provides execution environment for orchestration flows
4. Orchestration designer (backend) provides environment for creation of orchestration flows using artefacts from the database (depending on specific product architecture the designer and management components could be integrated)
5. Web Service exposes the Orchestrator’s functionality to external consumers (ideally via REST)
6. Action packs or plugins are introduced through installation at the design time (normally integrated into the DB)
7. The Orchestrator’s admin console is ideally implemented as web service, hence accessible via browser
8. The Design Client UI could either be web-based or a dedicated client application to be installed locally and using a specific protocol for backend communication

Of course, these building blocks can vary from product to product. However, what remains crucial to successful orchestration operations (more or less in the same way as with automation) is to have lightweight, scalable runtime components capable of supporting a small scale, low footprint deployment equally efficient to a large scale, multi sight, highly distributed orchestration solution.