diff --git a/doc/source/graph/svcOrch1.png b/doc/source/graph/svcOrch1.png new file mode 100644 index 0000000000..e039679767 Binary files /dev/null and b/doc/source/graph/svcOrch1.png differ diff --git a/doc/source/graph/svcorch.md b/doc/source/graph/svcorch.md index a48fdb83bf..3407990792 100644 --- a/doc/source/graph/svcorch.md +++ b/doc/source/graph/svcorch.md @@ -7,18 +7,58 @@ The service orchestrator is a component that is added to your inference graph to - Provide Tracing via Open Tracing - Add CloudEvent based payload logging -The current service orchestrator is a GoLang implementation. There is a previous Java implementation which is now deprecated post 1.0 releases of Seldon Core. +The current service orchestrator is a GoLang implementation. There is a previous Java implementation which will be deprecated in 1.2 release of Seldon Core. -Post 1.0 of Seldon Core you can specify the protocol and transport for the data plane of your inference graph. At present we allow the following combinations: +In 1.1+ of Seldon Core you can specify the protocol and transport for the data plane of your inference graph. At present we allow the following combinations: * Protocol: Seldon, Tensorflow * Transport: REST, gRPC You can see basic examples for all options in the [protocol examples notebook](../examples/protocol_examples.html). +## Design + +The service orchestrator's core concern is to manage the request/response flow of calls through the defined inference graph. Given a graph shown below: + +``` +apiVersion: machinelearning.seldon.io/v1 +kind: SeldonDeployment +metadata: + name: fixed +spec: + name: fixed + protocol: seldon + transport: rest + predictors: + - componentSpecs: + - spec: + containers: + - image: seldonio/fixed-model:0.1 + name: classifier1 + - image: seldonio/fixed-model:0.1 + name: classifier2 + graph: + name: classifier1 + type: MODEL + children: + - name: classifier2 + type: MODEL + name: default + replicas: 1 +``` + +The service orchestrator component is added to the graph and manages the request flow as shown below: + +![svc-orch](./svcOrch1.png) + +The initial request (1) reaches the service orchestrator which forwards it to the first model (2) and the response is captured by the service orchestrator (3) which then forwards to second model (4) before the response is again captured by service orchestrator (5) before being returned to caller (6). + +For more complex inference graphs the service orchestrator will handle routing components which may decide which of a subset of child components to send the request or aggregation components to combine responses from multiple components. + + ## Using the Java engine -You can continue to use the Java engine Service Orchestrator but this will be deprecated in the next release. +You can continue to use the Java engine Service Orchestrator but this will be deprecated in release 1.2. * For Helm installs `--set executor.enabled=false` * For Kustomize - update [manager.yaml](https://github.com/SeldonIO/seldon-core/blob/master/operator/config/manager/manager.yaml) env with `USE_EXECUTOR: "false"`