Key decisions (for Cloud Automation)

This is an evolving initiative. This document holds our rough notes on principles and preferences on Cloud Automation strategy. Contact @Nouman Memon for details. Or ping us on Slack.

`Infra As Code`

Recomendation: Terraform ✅

Qualities: 
  🔘 Provisioning (Docker is taking care of configuration management already)
  🔘 Cloud Agnostic / support
  🔘 Immutable infrastructure
  🔘 Declarative language
  🔘 Client-only architecture (Masterless, Agentless)
  🔘 Large communitiy support
  
🔰 Options
  → Terraform ✅
  → CloudFormation
  → Ansible

`Identity Provider`

Recomendation: Keycloak ✅

Qualities: 
  🔘 Multi-tenancy support
  🔘 Cost
  🔘 Flexible 

🔰 Options (starting with AWS)
  → Keycloak ✅
    + Better Multi tenant support as compared to Cognito
    + Cloud Agnostic
    + Better MFA
    + Flexible
    + OpenSource
    + Community capibilities
    - Complex setup (we could still use it as AWS service)
  → AWS Cognito
    + Free 50K identity
    + Better integration with STS, Lambdas for events etc
    + Fully managed
    - Not much Flexible
    - Limitation on 1000 user pool per AWS account (hard for SaaS model)
    - LImitation in MFA (supports SMS)
    - AWS only
    - Cant scale for Multi-tenant
  → Ory (Hydra + Kratos)
    + Open source
    + Mature documenation and easy to setup
    - Setting up IDP integrated (OAuth + Identity) is difficult and limited
    - Have SaaS option (beta + bit pricy)

`Container Management`

Recomendation: EKS (EC2) ✅

Qualities: 
  🔘 Portability
  🔘 Simple
  🔘 Flexible
  🔘 Future proof
  🔘 Cost

🔰 Options (starting with AWS)
  → EKS (EC2) ✅ - with minikube for dev
    + Portable: Cloud agnostic platform investment (almost)
    + Flexibility
    + Future proof
    + High Abstraction: better expererience for development
    - Complex (needs experience)
    - Need configuration for integrating with AWS services (not complex though)
    - Might be a bit expensive (need to validate) e.g. control plane is not free (API server and etcd)

  → ECS (FARGATE)
    + Initial setup is very simple
    + Free control plane
    + Built in integration with AWS services
    - AWS only
    - Limiting for complex SaaS setup
    - Abstraction: Coupling with AWS services due to its out-of-box integration

`Docker Registry`

Create BahmniIndia account on dockerhub
Keep bahmni space on dockerhub for global

`AWS Services`

Qualities
  🔘 Cost and ability to optimise
  🔘 OpenSoruce (Community support and contributions)
  🔘 Cloud provider agnostic
  🔘 Flexibility

Services options
⭕️ RDS (managed) vs self managed on EC2 via EKS
⭕️ CloudWatch (managed) vs EFK stack (same or seperate EKS cluster) for centralise logging
⭕️ FARGATE vs EC2 for EKS

`Helm Charts`

Qualities
  🔘 reduces the complexity of deploying microservices
  🔘 simplifies deployment scripts and files (all defined in YAML)
  🔘 improves the productivity of the deployments and rollback
  🔘 provides a way of versioning the Kubernetes resources as a single unit.

🔰 Options:
  - Can use configmaps

`Kubernetes Packaging Structure`

🔰 Options:
  ⭕️ Helm with Umbrella Charts
      Directory Structure:
        --- bahmni    (openmrs-module-bahmniapps repo)
          - package
              - docker
                  - Dockerfile
                  - ....
              - helm
                  -- Chart.yaml  --> holds the chart definition
                  -- values.yaml  --> default values, secret ref
                  - templates
                      -- deployment
                      -- service
      
        --- openmrs    (openmrs-module-bahmni-distro repo)
            - package
                - docker
                    - Dockerfile
                    - ...
                - helm
                    -- Chart.yaml  --> holds the chart definition
                    -- values.yaml  --> default values, secret ref
                    - templates
                        -- deployment
                        -- service
        
        --- package   (bahmni-k8s repo)
                - Chart.yaml
                - clinic
                    - dev.yaml
                    - qa.yaml
                    - demo.yaml
                    - prod.yaml
                - hospital
                    - dev.yaml
                    - qa.yaml
                    - demo.yaml
                    - prod.yaml

`CI/CD tools`

tfsec:
tfsec uses static analysis of your terraform code to spot potential misconfigurations.

Its is an ADOPT in TW tech Radar.
https://www.thoughtworks.com/en-gb/radar/tools/tfsec
 
🔘 tfsec uses static analysis of your terraform code to spot potential misconfigurations.
🔘 Checks for misconfigurations across all major (and some minor) cloud providers
🔘 Hundreds of built-in rules
🔘 Scans modules (local and remote)
🔘 Evaluates HCL expressions as well as literal values
🔘 Evaluates Terraform functions e.g. concat()
🔘 Evaluates relationships between Terraform resources
🔘 Compatible with the Terraform CDK
🔘 Applies (and embellishes) user-defined Rego policies
🔘 Supports multiple output formats: CLI, JSON, SARIF, CSV, CheckStyle, and JUnit.
🔘 Configurable (via CLI flags and/or config file)
🔘 Very fast, capable of quickly scanning huge repositories
🔘 Plugins for popular IDEs available (JetBrains, VSCode and Vim)
🔘 Community-driven

Since, it is a recommended tool from TW and
also widely used in projects we will be going ahead with tfsec.

🔰 Options
  → tfsec ✅
  → checkov

`Monitoring and Alerting`

Recommendation: Prometheus & Grafana ✅

🔰 Options
  🔘 Prometheus & Grafana ✅
    - Portable: Cloud agnostic tools
        Can run on cloud(k8s), also with docker-compose
    - Most widely used tool for monitoring & alerting

    ⭕️ Setup Methods:
        → In the same cluster under a separate namespace ✅
          Pros:
            - Low cost and simple setup
            - Lesser configuration definitions needed
          Cons:
            - Monitoring would be unreachable if the node/cluster goes down 

        → In a different cluster
          Pros:
            - Monitoring will always be available for the application cluster since 
              hosted in a separate cluster. 
          Cons:
            - Increased cost and management overhead
            - Cluster intercommunication needs to be setup

    ⭕️ Pipeline Setup:
        - A separate workflow for deploying monitoring stack.

    ⭕️ User Management for Grafana:
        - Use Github Oauth Integration and restrict access to members of Bahmni / BahmniIndiaDistro Oraganisation

    ⭕️ Metrics:
        - To be discussed

    ⭕️ Alerts:
        - To be discussed

  🔘 Cloudwatch
    - Specific to AWS
    - Could not support local installations

Topics to be discussed

Secrets manager
Monitoring and Alerting (Prometheus-Grafana)