In addition to defining computations, TFF provides tools for executing them. Whereas the primary focus is on simulations, the interfaces and tools we provide are more general. This document outlines the options for deployment to various types of platform.
NOTE: This document is still under construction.
There are two principal modes of deployment for TFF computations:
Native backends. We're going to refer to a backend as native if it is capable of interpreting the syntactic structure of TFF computations as defined in
computation.proto. A native backend does not necessarily have to support all language constructs or intrinsics. Native backends must implement one of the standard TFF executor interfaces, such as
tff.framework.Executorfor consumption by Python code, or the language-independent version of it defined in
executor.protoexposed as a gRPC endpoint.
Native backends that support the above interfaces can be used interactively in lieu of the default reference runtime, e.g., to run Jupyter notebooks or experiment scripts. Most native backends will operate in the interpreted mode, i.e., they will process the computation definition as it is defined, and execute it incrementally, but this does not always have to be the case. A native backend can also transform (compile, or JIT-compile) a part of the computation for better performance, or to simplify its structure. One example common use of this would be to reduce the set of federated operators that appear in a computation, so that parts of the backend dowstream of the transformation do not have to be exposed to the full set.
Non-native backends. Non-native backends, in contrast to the native ones, cannot directly interpret the TFF computation structure, and require it to be converted into a different target representation understood by the backend. A notable example of such a backend would be a Hadoop cluster, or a similar platform for static data pipelines. In order for a computation to be deployed to such a backend, it must first be transformed (or compiled). Depending on the setup, this can be done transparently to the user (i.e., a non-native backend could be wrapped in a standard executor interface such as
tff.framework.Executorthat performs transformations under the hood), or it can be exposed as a tool that allows the user to manually convert a computation, or a set of computations, into the appropriate target representation understood by the particular class of backends. Code that supports specific types of non-native backends can be found in the
tff.backendsnamespace. At the time of this writing, the only support type of non-native backends is a class of systems capable of executing single-round MapReduce.
More details coming soon.
More details coming soon.