27 lines
1.5 KiB
Markdown
27 lines
1.5 KiB
Markdown
|
# 12. seperate service for each executor
|
||
|
|
|
||
|
|
Date: 2021-11-21
|
||
|
|
|
||
|
|
## Status
|
||
|
|
|
||
|
|
Accepted
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
Executors must receive tasks of different types and execute them. The executors could either all be implemented within one service or as multiple services, one for each type of executor.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
We will have a seperate service for each type of executor.
|
||
|
|
|
||
|
|
Firstly, execution time differs significantly between task types. Therefore, having seperate services will allow the executos to scale differently based on their tasks' specific needs.
|
||
|
|
|
||
|
|
Secondly, the systems functioning should not be disrupted in case an Executor fails. Having each type of executor in a seperate service will increase fault tolerance in this regard.
|
||
|
|
|
||
|
|
Lastly, extensibilty is one of the systems most important non-functional requirement and providers of executors need to be able to easily add executors to the executor pool. These factors are also positively impacted by having seperate services.
|
||
|
|
|
||
|
|
There should not be any shared data between the executors. Additionally, there should be no flow of information between them. Thus, there should be no issues due to workflow and data concerns due to this decision.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
Executors share a lot of functionality when it comes to connecting to the rest of the system. Therefore, this decision means that we will either have to duplicate the code that implements the common functionality, or we have to have a way to share the code (e.g. through a common library)
|