# Deployment concept

## Requirements
#### 1.1 Deployment should work for different use-cases, at least the following

#### 1.1.1 Backend Developer
As a backend developer I want to easily clone the BPA repository and launch BPA backend (database, acapy,..).
The java /micronaut part I want to launch from my IDE to allow debugging and so on.

#### 1.1.2 Frontend Developer
As a frontend developer I want to easily clone the BPA repository and launch BPA backend.
The frontend code I want to launch from my IDE to allow debugging and so on.

#### 1.1.3 Interested user
As an interested user I want to easily launch a playground environment with at least 2 BPAs.
Also an issuer should be present to interact with.

#### 1.1.4 Collaborator ("well-known friend")
As an collaborator I want to use a ready-prepared playground environment with at least 2 BPAs.
Also an issuer should be present to interact with.
I want to be able to interact with other BPAs / issuers from other collaborators/ companies.
I want to work on different ledgers, one for testing and IDunion.

#### 1.2 Configure different ledgers
See [1.1.3](#113-Interested-user)

#### 1.3 Consider deployment of "connectors"

### Out of scope

- Deployment of an own ( local ) ledger
We'll use our test ledger for the time being and IDunion
- Agency (with Frontend, self registration,...)

## Non-functional requirements

#### 2.1 Easy to use
At least for the non-developer users it should be easy to use / setup / configure an environment
For developers at least a simple setup should be straight forward to launch ( as it is currently done with docker-compose)

#### 2.2 Keep it simple and maintainable
The deployment concept should be easy to understand and maintain.
Not too many use cases are supported out of the box, but only the ones we (currently need)
Like this e.g. open source contributors understand it and we have avoid extensive tests (which we anyway won't do)

#### 2.3 Logging and monitoring concept
Logging framework should be applicable to allow debugging and failure analysis. Similar for monitoring.

#### 2.4 Configuration concept
Let's have an clearly understandable and resilient config. concept, trying to avoid too many different ways to configure the app.

#### 2.5 Database handling
The should be some kind of abstraction to handle databases differently in different use case. E.g. launch the databases very simple in a disposable way as developer but also make use of a full-fledged RDS in the later agency.
Keep license topic in mind.

#### 2.6 Launch different versions of the app
This will get more important when we start testing interaction with other BPAs deployed by someone else. We should be able to test not only with "latest" but defined versions.

### Out of scope / no priority
- Highly secure setup

## Concept

### Vision
#### Kubernetes as main target for deployments.
With the following advantages of a real orchestration tool:
- increased visibility of containers
[#23-Logging-and-monitoring-concept](#23-Logging-and-monitoring-concept)
- easier server management
[#21-Easy-to-use](#21-Easy-to-use) [#23-Logging-and-monitoring-concept](#23-Logging-and-monitoring-concept)
- simple installation of artifacts
[#21-Easy-to-use](#21-Easy-to-use)
- dashboards, monitoring integrated natively
[#23-Logging-and-monitoring-concept](#23-Logging-and-monitoring-concept)
- concepts regarding scalabitliy, resilience build-in
[#23-Logging-and-monitoring-concept](#23-Logging-and-monitoring-concept)
- and many other

#### Helm as deployment mechanism for the k8s deployments
- provides the ability to quickly define, cleanly manage and easily deploy the applications.
- deploying a helm chart into a cluster is quite easy. In our case it can be pulled from e.g. directly from the GitHub project
- chart values.yaml files  plus templating allows all kinds of configuration
[#24-Configuration-concept](#24-Configuration-concept)
- usage of third party charts possible (e.g. as dependencies like databases, monitoring tools)
[#26-Launch-different-versions-of-the-app](#26-Launch-different-versions-of-the-app)
- testing mechanism build in
- Kubernetes + Helm duo is more and more quasi standard for k8s deployments
- allowing one to declaratively manage releases (“GitOps” , see https://github.com/fluxcd/helm-operator)
[#26-Launch-different-versions-of-the-app](#26-Launch-different-versions-of-the-app)

#### Docker compose as alternative for well defined usecase
For the following usecases we should foresee a docker / docker-compose
- For open source guys who want to launch the BPA with minimal effort (only one BPA, optionally launched with shell script to install tools, setup tunnels and generate IDs)
- For developers.

## Next steps

### 1) a) Setup playground via helm

Playground consists of helm releases: alice, bob + a dummy bank

The 3 releases should be installed with few commands on the commandline (e.g. like in this [example here](https://github.com/fluxcd/helm-operator/blob/master/chart/helm-operator/README.md))

As well charts can be installed in the Top90 cluster via code, see [this repo.](https://dev.azure.com/economy-of-things/eot-common/_git/infrastructure-manifests?path=%2Fprojects%2Fmasterdata%2Fbpa.yaml)
This mechanism could be used for Collaborator (“well-known friend") - simlar to the current agency.

Out of scope: Installing cluster, Ingress controller

### 1) b) Discuss with Bosch IO (parallel to 1)a))

- What is their interest regarding building up an agency?
- Which users / usecases / markets shall be addressed?
- Only BPA or other usecases?
- What technologies do they use / do the prefer?
- What platforms do they already have?
- What could be a colaboration model?

### 2) Agency
After discussion with Bosch IO we can see:
- If they develop an agency on their own (in collaboration with us)
- Do we/they re-use the existing one, maybe bring it together with the helm idea from 1)
- ...

## Further reading

- [Host Helm chart on github](https://dev.to/jamiemagee/how-to-host-your-helm-chart-repository-on-github-3kd)
- [Local k8s Dev environment with K3s](https://codeburst.io/creating-a-local-development-kubernetes-cluster-with-k3s-and-traefik-proxy-7a5033cb1c2d)
- K8s apps for developers
- [Overview](https://medium.com/flant-com/kubernetes-apps-developers-tools-97cd6ccae7dd)
- [Skaffold - Idea: Fast and highly optimized development tool that does not require a cluster-side component](https://skaffold.dev/)
- [Telepresense - FAST, LOCAL DEVELOPMENT FOR KUBERNETES](https://www.telepresence.io/)
- [Werf - Build your Docker images efficiently and glue your CI with Kubernetes](https://werf.io/)
- [DevSpace - Idea: If you want to start using Kubernetes without a deep dive into its internals](https://devspace.cloud/)
- App / helm release / GUI
- [rancher](https://rancher.com/) - feature rich, including cluster management, log management,..
- [kubeapps](https://github.com/kubeapps/kubeapps) - focuses on helm / operator deployment