Flyte System Context Diagram
This system context diagram illustrates the high-level architecture of the Flyte Overview backend service and its interactions with users and external systems.
The central component is the Flyte Backend Service, which is implemented as a unified service (as seen in the manager package) providing a gRPC/Connect API for all operations. Users interact with this service primarily through the FlyteConsole (UI) and the flytectl (CLI).
The service maintains its state and workflow metadata in a relational Database (supporting both PostgreSQL and SQLite). Workflow artifacts, including inputs and outputs, are stored in Cloud Storage (supporting AWS S3, Google Cloud Storage, and Azure Blob Storage via the stow library).
Workflow execution is orchestrated on a Kubernetes Cluster, where the Workflow Executor (part of the backend service) manages the lifecycle of tasks, often leveraging specialized operators for Spark, Ray, and Dask.
For performance and security, the system integrates with Redis for caching and external Secret Managers (AWS, GCP, or Azure) for sensitive credentials. Observability is provided through integration with Prometheus for metrics and Jaeger/OTLP for distributed tracing.
Key Architectural Findings:
- The Flyte backend is structured as a unified service (Manager) that bundles multiple sub-services like RunService, AppService, and DataProxy.
- The system uses the Connect RPC framework, making its API compatible with both gRPC and standard HTTP/1.1 clients.
- Database support is flexible, with PostgreSQL used for production and SQLite available for local development and testing.
- Cloud storage abstraction (via the
stowlibrary) allows Flyte to work across AWS, GCP, and Azure. - The Workflow Executor component uses the Kubernetes controller-runtime to manage task execution as native Kubernetes resources.
- Secret management is delegated to cloud-native services like AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault.