Orchestration design pattern – Part 0 – Intro
In my career I have been involved 2 times into creating architecture of software, which could be called Orchestration. 3 years ago I worked on project, which has a goal to be a top application controlling huge production line and monitoring materials on many stages. This real-time application orchestrates all sub-systems controlling all parts of production line. Nowadays I am designing an Orchestration systems, which is sort of scheduler running on trigger (time, manual, …) jobs or tasks. Even they both are technically different, there is some similarity and pattern I have used in both.
Let me spend a little time of describing of both systems.
The simple business requirement was controlling production line running 24/7 full time. The production line is huge about 1000 square meters and it should be supported by just a few operators. Production line could be cut to several machines smaller or bigger, simpler or complex. The complex machines have Programmable Logic Controller which has a set of commands for remote control. The complex machines have several sub-machines and semi-automated logistic system, which needs to be also controlled remotely. The complex machines are the most tricky part of control software, since it musts be fully automated, there a lot of logistic logic and operator positions are only on the beginning and the end.
The whole production line is designed to produce many kind of similar products. Each product has a recipe, how to produce a product, defined in separated information system. The recipe defines the chain, which machine are involved in to the production process, in which order. There are also the parameters, which must be setup on the each machine, before a product is processed on them. The process time on the machines differs from 1h to 20h. Products are moved between machines manually.
The number of operators, currently present on the line, will much less then number of operator positions. So they will operate more machines at the time. They do not have time to think a lot, so their work should be automated as much as possible.
It could take a long day, just describing the system. To summarize the involved externals we have been built a software integrated set of machines (simple or complex), information system (recipes), human interfaces (for operators). All should work real-time 24 hours per 7 days.
Otherwise the scheduler has very simple goal(s). It should be an autonomy system, which will run scheduled periodic tasks. The main goal is to prepare good abstract framework for developers, which will develop the jobs/tasks, so they can focus only on functionality itself and do not care about infrastructure code around. The tasks should be easy to integrate into orchestration in the way of plugins.
Both systems can be compared and we can find the similarities. Both are orchestrations, orchestrate many independent similar sub-systems. Both are required to be fully automated. On other hand both are required to have a management console, so the administrators are able to configure and manage the system. If there is an error occurred, the system is required to automatically recover and try to continue the disrupted process. Some parts of software can be designed similarly, but because of different behaviours of subsystems the final designs vary.
In following articles of the series I would like to share some of interesting design decisions I made during the development.
That’s all, now go write some code.