/
Key decisions (for Cloud Automation)

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)

 

Related content

The Bahmni documentation is licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)