# Revisiting Flyte Deployment Options

## Context

Flyte can be deployed through various ways. Listed below are the ones currently supported (i.e. in master):

1. [Helm](https://artifacthub.io/packages/helm/flyte/flyte)
Flyte publishes a single helm chart that encapsulates flyte and its dependencies.
1. [Kustomize](https://github.com/flyteorg/flyte/tree/master/kustomize)
Flyte comes with a kustomize template that installs flyte and its depedencies and give full flexibility into picking and choosing what depedencies and what configuration they should use.
1. [Opta](https://docs.flyte.org/en/latest/deployment/aws/opta.html)
Opta offers an infrastructure as yaml tool to deploy not only flyte (through helm) but also the infrastructure needed (DB, k8s,... etc.) abiding by the best practices.
1. Manual ([AWS](https://docs.flyte.org/en/latest/deployment/aws/manual.html))
Flyte docs also offer an extensive guide into creating and configuring infrastructure needed to install Flyte as well as a recommended installation path for Flyte (helm).

Between these installation modes Flyte makes it extremely flexible to choose the way that suits your organization. On the flip side, there is a cost of having great flexibility; we have heard certain complaints from customers/potential customers:

1. It's overwhelming to navigate.
Having multiple ways to install Flyte might seem overwhelming to an outsider looking into installing Flyte for the first time.
1. Too many different docker images!
While Flyte contains 5-6 distinct docker images, if bundled with all depdencies in the recommended installation, there are about 15 distinct docker images [some with `F` security rating](https://artifacthub.io/packages/helm/flyte/flyte?modal=security-report).
1. How can I split the control and data planes?
Flyte follows a microservice architecture, and while there is a clear separation of concerns when it comes to the design, it doesn't translate nicely to the different installation modes listed above.

## Goals

Define a deployment structure and a story that makes it easier for users to navigate, choose the one that suits them and guides them through it.

## User Scenarios

1. Flyte can be deployed through a single Helm chart with no assumptions about infrastructure
1. Flyte can be deployed batteries-included that come with best practices and

## Proposal

1. Breakdown Helm charts into:
- flyte-data-plane
This should deploy `flytepropeller`
- flyte-control-plane
This should deploy `flyteadmin`, `flyteconsole`, `datacatalog`
- flyte-core
This should take both charts above as dependencies.
- flyte-cluster (or just flyte for backward compatibility)
This should take `flyte-core` as a dependency and pull in all external dependencies needed (redis, ingress controllers,... etc.)
1. `flyte-data-plane`, `flyte-control-plane` and `flyte-core` should be maintained at `A`-security rating.
1. Publish a Helm chart for each backend plugin
Each backend plugin should have a published helm chart that pulls in any dependencies the plugin needs (e.g. Distributed Pytorch should pull in the Pytorch Operator helm chart... etc.)
1. Write a Heml Chart doc that goes over this breakdown and how should users choose a Helm Chart and how to configure each.
1. Opta as the recommended way to deploy on AWS & GCP.
Update existing doc to:
1. Add GCP support
1. Explain how to modify it to choose a different helm chart or a different values file.
1. Manual deployment guides for AWS, GCP and Azure
AWS Guide exists. We need to write one for GCP and another for Azure.

# PR
- https://github.com/flyteorg/flyte/pull/1360
- https://github.com/flyteorg/flyte/pull/1366
- https://github.com/flyteorg/flyte/pull/1376