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)