@doist/doistbot-cli 1.0.12 → 1.0.14

package/sandbox/src/review/prompts/which-cloud-and-where-to-deploy.md

@@ -1,344 +0,0 @@
-# Platform Standard: Which Cloud & Where to Deploy
-
-| 📄 Document Type | Platform Standard                                                                                                                                            |
-| :--------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 🎯 Status        | Approved                                                                                                                                                     |
-| 👤 Owner         | Luciano Facchinelli                                                                                                                                          |
-| 📅 Last Reviewed | 2026-03-06                                                                                                                                                   |
-| 🗂️ References    | [AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/), [GCP Architecture Framework](https://cloud.google.com/architecture/framework) |
-| 📌 Version       | 1.0                                                                                                                                                          |
-
-# Workload types
-
-## Remote State Services
-
-- **Definition**: Services that either store state in external systems (databases, caches, object storage) and don't require persistent local disk or doesn't have a state at all.
-  Containers are disposable and can be recreated without data loss.
-- **Typical use cases**:
-    - REST APIs
-    - Web applications
-    - Backend microservices
-
-## No State / Local State Services
-
-- **Definition**: Services that require persistent local disk storage and expect data to survive container restarts. These need node affinity and persistent volumes.
-- **Typical use cases**:
-    - Analytics database (i.e ClickHouse)
-    - Observability tool (i.e Langfuse)
-    - Self-hosted databases
-    - Message brokers with persistence
-- Runs a database or database-like system
-- Benefits from node affinity control for performance
-
-## Event-Driven / Short-Lived Tasks
-
-- **Definition**: Sporadic, short-duration tasks triggered by events that must complete within 15 minutes
-- **Typical use cases**:
-    - Webhooks
-    - Scheduled jobs
-    - Queue processors
-    - Glue code between services
-    - File processing triggers
-- Code must be small and optimized to reduce consumption from a resource perspective.
-- Cold starts can impact latency for infrequent calls
-- Not suitable for long-running or high-memory processes
-
-## Preview / Ephemeral Environments
-
-- **Definition**: Temporary, short-lived environments designed for testing, demos, and validation with a clear expiration
-- **Typical use cases**:
-    - PR preview deployments
-    - Demo environments
-    - Temporary test instances
-    - Feature branch testing
-- Excellent developer experience for fast iterations
-
-## Internal Tools (Low Traffic)
-
-- **Definition**: Internal-facing utilities and dashboards with low, predictable usage patterns accessed only by team members
-- **Typical use cases**:
-    - Admin dashboards
-    - Internal utilities
-    - Analytics dashboards
-    - Configuration management UIs
-    - Reporting tools
-- Low and predictable traffic patterns
-- Users are internal team members only
-- May or may not require access to production resources
-- Simpler reliability requirements than user-facing services
-
-## Batch Processing / ML Training
-
-- **Definition**: Large-scale data processing or machine learning workloads that run for extended periods, often on a schedule or ad-hoc basis
-- **Typical use cases**:
-    - Large batch data jobs
-    - ML model training
-    - Data pipeline processing
-    - One-off data migrations
-    - ETL jobs
-- Variable duration — can run for hours or days
-- Often requires burst compute capacity
-- May need GPU resources for ML workloads
-- Clear distinction between experimentation and production
-- **Note: Requires case-by-case evaluation based on requirements**
-
-# 1\. Purpose
-
-"Where should I deploy this?" and "Can I use GCP for this?" shouldn't require a Platform team consultation. This standard provides clear defaults so teams can move fast while maintaining operational consistency.
-
-These two decisions are tightly coupled—your cloud choice often constrains your compute options, and vice versa. We're treating them as one standard.
-
-## 2\. Scope
-
-This standard applies to:
-
-- All new services, tools, and workloads
-- Migrations of existing services to new compute platforms
-- Any infrastructure that runs production or production-adjacent workloads
-
-This does **not** prescribe:
-
-- How to configure specific services (separate runbooks)
-- Database or storage choices (separate standard)
-
----
-
-# Part A: Which Cloud
-
-## 3A. Standard
-
-### Default: AWS
-
-**All new production workloads MUST be deployed to AWS unless there's a documented exception.**
-
-AWS is our primary cloud. This means:
-
-- All production databases, queues, and storage
-- All user-facing services
-- All internal services that modifies production data
-
-### When GCP is Acceptable
-
-GCP may be used for:
-
-| Use Case                    | Rationale                                        | Examples                                    |
-| :-------------------------- | :----------------------------------------------- | :------------------------------------------ |
-| **BigQuery analytics**      | Best-in-class data warehouse, existing pipelines | Data team experiments, analytics dashboards |
-| **ML/AI experimentation**   | Vertex AI, Colab integration                     | Prototype ML models before productionizing  |
-| **One-off data processing** | Cost-effective for burst compute                 | Large batch jobs with clear end dates       |
-| **Cloud Run previews**      | Fast, cheap preview environments                 | PR preview deployments for web apps         |
-
-GCP is **NOT acceptable** for:
-
-- Services that need to access production databases directly
-- Anything requiring low-latency connections to AWS resources
-- User-facing production services
-- Long-running local state services
-
-### Multi-Cloud \= Complexity Tax
-
-Every service in GCP means:
-
-- Separate IAM, networking, and monitoring
-- Cross-cloud latency and data transfer costs
-- Split operational knowledge on the team
-- Harder incident response
-
-The bar for GCP should be: "AWS genuinely can't do this well" — not "GCP has a nicer UI for this."
-
-## 4A. Rationale
-
-**Why default to AWS?**
-
-- Operational consistency: one set of tools, dashboards, runbooks
-- Network topology: VPCs, peering, and security groups are already configured
-- Cost visibility: unified billing, tagging, and attribution
-- Team knowledge: everyone knows AWS; GCP expertise is spotty
-
-**Why allow GCP at all?**
-
-- BigQuery is genuinely better for our analytics use cases
-- Cloud Run is excellent for preview environments (fast, cheap, ephemeral)
-- Forcing everything into AWS would be dogmatic, not practical
-
----
-
-# Part B: Where to Deploy (Compute)
-
-## 3B. Standard
-
-### Decision Tree
-
-```mermaid
-%%{init: {'flowchart': {'curve': 'linear'}}}%%
-flowchart TB
- subgraph PartA["Part A: Cloud Selection"]
-        AWS[/"✅ AWS<br>(Primary Cloud)"/]
-        Q1{"Which Cloud?"}
-        GCP_Check{"GCP Use Case?"}
-        GCP[/"☁️ GCP Acceptable"/]
-  end
- subgraph GCP_No["🚫 GCP NOT Acceptable For"]
-    direction TB
-        N1["Production DB Access"]
-        N2["Low-latency to AWS"]
-        N3["User-facing Production"]
-        N4["Long-running local state"]
-  end
- subgraph PartB["Part B: Compute Platform Selection"]
-        ECS[/"📦 ECS Fargate<br>(Default)"/]
-        Q2{"What Type<br>of Workload?"}
-        EKS[/"☸️ EKS Kubernetes"/]
-        Lambda[/"⚡ Lambda"/]
-        Platform[/"🤝 Consult Platform Team"/]
-        CloudRun[/"🏃 Cloud Run"/]
-        Q3{"GCP Compute?"}
-  end
- subgraph Examples["📋 Examples"]
-    direction TB
-        Ex1["REST API → ECS Fargate"]
-        Ex2["ClickHouse → EKS"]
-        Ex3["Langfuse → EKS"]
-        Ex4["Webhooks → Lambda"]
-        Ex5["PR Previews → Cloud Run"]
-  end
- subgraph Exceptions["⚠️ Exception Process"]
-    direction TB
-        E1["1. Document rationale"]
-        E2["2. Post in Platform channel"]
-        E3["3. Get Platform approval"]
-  end
-    Start(["🚀 New Service/Workload"]) --> Q1
-    Q1 -- Default --> AWS
-    Q1 -- Exception Cases --> GCP_Check
-    GCP_Check -- BigQuery Analytics --> GCP
-    GCP_Check -- ML/AI Experimentation --> GCP
-    GCP_Check -- "One-off Data Processing" --> GCP
-    GCP_Check -- Preview Environments --> GCP
-    GCP_Check -- None of above --> AWS
-    GCP -. Check Restrictions .-> GCP_No
-    AWS --> Q2
-    GCP --> Q3
-    Q2 -- remote state<br>(API, Web App) --> ECS
-    Q2 -- local state<br>(Persistent Storage) --> EKS
-    Q2 -- "Event-driven<br>(under 15 min)" --> Lambda
-    Q2 -- Batch/ML Training --> Platform
-    Q3 -- Previews/Internal Tools --> CloudRun
-    ECS -.-> Ex1
-    EKS -.-> Ex2 & Ex3
-    Lambda -.-> Ex4
-    CloudRun -.-> Ex5
-    E1 --> E2
-    E2 --> E3
-    Q2 -- Doesn't fit? --> Exceptions
-
-     AWS:::aws
-     Q1:::decision
-     GCP_Check:::decision
-     GCP:::gcp
-     ECS:::aws
-     Q2:::decision
-     EKS:::aws
-     Lambda:::aws
-     CloudRun:::gcp
-     Q3:::decision
-    classDef aws fill:#FF9900,stroke:#232F3E,color:#232F3E
-    classDef gcp fill:#4285F4,stroke:#174EA6,color:white
-    classDef decision fill:#f9f,stroke:#333,stroke-width:2px
-    classDef compute fill:#90EE90,stroke:#228B22
-```
-
-### Compute Platform Characteristics
-
-| Platform             | Best For                                   | Avoid When                                   | Notes                                                  |
-| :------------------- | :----------------------------------------- | :------------------------------------------- | :----------------------------------------------------- |
-| **ECS Fargate**      | remote state services, APIs, web apps      | Need persistent local storage, need GPU      | Our default. Good tooling, well-understood.            |
-| **EKS (Kubernetes)** | local state workloads, complex deployments | Simple local state services (overkill)       | Higher operational overhead. Worth it for local state. |
-| **Lambda**           | Event-driven, short tasks, glue code       | Long-running processes, high-cpu needs       | Cold starts matter. Keep functions small.              |
-| **Cloud Run**        | Previews, internal tools, experiments      | Production services, AWS-dependent workloads | Great DX, but it's GCP (see Part A).                   |
-
-## 4B. Rationale
-
-**Why ECS as default?**
-
-- Simpler than Kubernetes for most use cases
-- Fargate \= no EC2 instance management
-- Good integration with AWS services (ALB, CloudWatch, Secrets Manager)
-- Lower cognitive overhead for teams
-
-**Why Kubernetes for local state?**
-
-- local stateSets, persistent volumes, and operators
-- Better control over scheduling and node affinity
-- Community ecosystem for databases and local state apps
-- We're investing in EKS anyway; leverage it where it shines
-
-**Why Lambda for event-driven?**
-
-- Pay-per-invocation is cost-effective for sporadic workloads
-- Built-in scaling, no capacity planning
-- Native integration with SQS, SNS, EventBridge
-- Forces good practices (small, focused functions)
-
-**Why Cloud Run for previews?**
-
-- Deploys in seconds, scales to zero
-- Cheap for low-traffic ephemeral environments
-- Great developer experience
-- Isolated from production (GCP \= natural boundary)
-
----
-
-## 5\. How to Apply
-
-### Example: New API Service
-
-You're building a new internal API that serves data to the mobile apps.
-
-1. **Which cloud?** → AWS (it's production, needs DB access)
-2. **What compute?** → ECS Fargate (local state API)
-3. **How to deploy?** → CloudFormation stack, GitHub Actions workflow
-
-### Example: Analytics Dashboard
-
-You're building an internal dashboard that queries BigQuery and displays charts.
-
-1. **Which cloud?** → GCP (BigQuery-native, no prod DB access)
-2. **What compute?** → Cloud Run (internal tool, low traffic)
-3. **How to deploy?** → Cloud Run from container registry
-
-### Example: New Observability Tool (like Langfuse)
-
-You're deploying a self-hosted observability tool that needs persistent storage.
-
-1. **Which cloud?** → AWS (needs to ingest data from AWS services)
-2. **What compute?** → EKS (local state, needs persistent volumes)
-3. **How to deploy?** → Helm chart, ArgoCD
-
-## 6\. Exceptions
-
-### Requesting an Exception
-
-If your use case doesn't fit the decision tree:
-
-1. Document: What you're building, why the default doesn't work
-2. Post in Platform channel
-3. Get sign-off before proceeding
-
-Common valid exceptions:
-
-- Vendor-specific requirements (e.g., "only runs on GCP")
-- Cost optimization for specific workload patterns
-- Experimentation with explicit time bounds
-
-### Grandfathered Services
-
-We should apply the [Gartner’s TIME framework](https://unstoppablesoftware.com/understanding-gartners-time-model-maximizing-business-value-with-software-portfolio-management/#:~:text=1%2E%20Tolerate%20%28Low%20Value%2C%20Low%20Cost%2FRisk) when deciding. After that, we may realize some existing services don't follow this standard. We're not migrating them unless there's a compelling reason. Document them, but don't use them as precedent for new services.
-
-## 7\. References
-
-- [ECS Service Setup Runbook](https://file+.vscode-resource.vscode-cdn.net/Users/arod/work/doist/twist-threads/work/20260114-platform-standards-analysis/TBD)
-- [EKS Deployment Guide](https://file+.vscode-resource.vscode-cdn.net/Users/arod/work/doist/twist-threads/work/20260114-platform-standards-analysis/TBD)
-- [Lambda Best Practices](https://file+.vscode-resource.vscode-cdn.net/Users/arod/work/doist/twist-threads/work/20260114-platform-standards-analysis/TBD)
-- [Cloud Run Setup for Previews](https://file+.vscode-resource.vscode-cdn.net/Users/arod/work/doist/twist-threads/work/20260114-platform-standards-analysis/TBD)
-- \[Cost Tagging Standard\](TBD \- Group 3\)