FlowDX Platform
Plataforma interna de desenvolvedor (IDP) em evolução, construída sobre uma base real em AWS com Terraform e CI/CD com foco em padronização, automação e self-service.
## Contexto
A FlowDX Platform nasce como um projeto autoral voltado a demonstrar, de forma prática, competências em Platform Engineering, Infrastructure as Code (IaC), automação de delivery e experiência do desenvolvedor.
O objetivo não é criar um produto comercial nem reinventar ferramentas já consolidadas. O foco é construir uma plataforma com narrativa clara, arquitetura coerente e valor real de engenharia, mostrando como uma base funcional pode evoluir para um modelo de self-service mais maduro.
Hoje, o projeto já possui um workload de referência com deploy automatizado em AWS, provisionamento via Terraform e integração contínua/entrega contínua com GitHub Actions.
## Estado Atual
O estado atual da FlowDX Platform já é executável e utilizável como base real.
O que já existe hoje
Foundation v0: uma base real que valida decisões de arquitetura e cria o ponto de partida para a evolução da plataforma.
## System Snapshot (v0)
Componentes já validados e operacionais na fundação atual.
Application
Workload frontend moderno com Astro + TypeScript.
Infrastructure
AWS com S3, CloudFront, Route 53, ACM e DynamoDB.
Delivery
Deploy automatizado via GitHub Actions.
Governance
Terraform como SSOT e drift detection como mecanismo de controle.
## Diagrama de Contexto
A FlowDX é uma experiência de alta performance e baixa latência (Edge Computing). A arquitetura atual foi desenhada para ser simples, reproduzível e fácil de evoluir. O mono-repo concentra a aplicação, infraestrutura e automação.
## Destaques da Arquitetura (v0 Foundation)
Edge-First Delivery
A utilização do AWS CloudFront não é apenas para cache; é uma decisão de design para garantir baixa latência e alta performance global. O workload Astro é servido a partir da Edge Location mais próxima do usuário, otimizando o TTFB (Time to First Byte).
Segurança por Design (OAC)
Diferente de setups tradicionais onde o bucket S3 fica exposto, implementei o Origin Access Control (OAC). Isso garante que a origem seja privada e que o conteúdo seja acessível estritamente através da CDN, com permissões de leitura assinadas.
Estratégia de Monorepo
Centralizei Aplicação, Infraestrutura (IaC) e Automação em um único repositório. Isso estabelece a "Single Source of Truth" (Fonte Única da Verdade), permitindo que mudanças no contrato de infraestrutura e no código do app sejam validadas em um ciclo de entrega unificado.
Arquitetura Evolutiva
Esse setup foi desenhado para ser simples e reprodutível. O que hoje é um workload de referência manual, amanhã servirá como o Blueprint (molde) para os templates de Self-Service da FlowDX, facilitando a transição para um modelo de IDP (Internal Developer Platform).
## Container & Ops
A camada de operações da FlowDX é construída sobre práticas robustas de segurança, automação e governança. Cada decisão de design foi orientada para eliminar fragilidade e garantir operação confiável.
## Destaques da Arquitetura (nível de contêiner)
Segurança Keyless (OIDC)
Estabeleci uma relação de confiança federada entre GitHub Actions e AWS via OIDC. Com isso, eliminei o uso de chaves estáticas (Access Keys), reduzindo a superfície de ataque e o risco de vazamento de credenciais.
Privilégio Mínimo (Least Privilege)
Segmentei a operação em IAM Roles granulares. Utilizo a infra-provisioner para gestão do ciclo de vida dos recursos e a app-deployer com permissões restritas a S3 Sync e invalidação de cache, garantindo isolamento entre aplicação e infraestrutura.
Estado com Terraform Backend
Implementei um backend remoto robusto utilizando S3 para armazenamento seguro do tfstate e DynamoDB para State Locking. Essa configuração evita concorrência e garante a integridade do estado durante execuções paralelas.
Detecção de Drift
Configurei um workflow dedicado de Drift Detection. Esta rotina diária valida se a infraestrutura real condiz com o código, assegurando que o meu repositório seja sempre a Única Fonte da Verdade (SSOT) e alertando sobre alterações manuais indevidas.
## O que ainda falta construir
A FlowDX Platform ainda não chegou ao estágio de self-service completo. O que existe hoje é a base sobre a qual essa experiência será construída. A evolução esperada é transformar esse fluxo ainda assistido em uma experiência mais padronizada, automatizada e orientada por templates.
## Visão de Evolução
A FlowDX é uma arquitetura viva, onde cada execução, pipeline e interação contribui para sua evolução contínua, garantindo que a plataforma permaneça adaptável, resiliente e alinhada às necessidades em constante mudança.
## Roadmap de Evolução
A evolução é incremental e intencional. Cada fase entrega valor real sem bloquear a próxima.
Foundation v0
Base real já existente: Workload de referência em produção-like setup, Terraform como infraestrutura declarativa, CI/CD automatizado e Drift detection diária.
Platform Building Blocks
Primeiras abstrações e padronizações: padronização da estrutura do mono-repo, extração de módulos e templates, início da CLI e primeiros fluxos de scaffolding.
Self-Service Experience
Experiência orientada por intenção: comando para criação de workloads, geração automática de estrutura, provisionamento e entrega integrados, subdomínios dinâmicos e padronizados.
Runtime Expansion
Evolução do ecossistema de execução: introdução de Kubernetes como runtime adicional, aprendizado inicial com Docker e clusters locais como kind/k3s, evolução posterior para EKS.
## Estrutura do Repositório
Embora organizado como mono-repo, o projeto é estruturado de forma lógica para separar responsabilidades e permitir evolução independente das partes.
Contém o workload de referência utilizado para validar o fluxo de entrega e as decisões de arquitetura.
Define a infraestrutura em AWS utilizando Terraform, incluindo recursos como S3, CloudFront, Route 53 e ACM.
Responsável pelos workflows de CI/CD com GitHub Actions, incluindo validações, deploy e detecção de drift.
Espaço destinado às capacidades de plataforma, como templates reutilizáveis, lógica de geração de projetos e automações mais abstratas. (em evolução)
Essa organização permite manter tudo no mesmo repositório sem comprometer clareza ou evolução, ao mesmo tempo em que facilita entendimento, versionamento e experimentação.
## Princípios de Arquitetura
A FlowDX Platform segue alguns princípios centrais que guiam todas as decisões de design e evolução.
Abstração sem perda de controle
A plataforma esconde complexidade operacional, mas mantém rastreabilidade, versionamento e governança.
Infraestrutura como código
Tudo que é relevante deve ser declarativo, auditável e reproduzível.
Evolução incremental
O projeto parte de uma base real e evolui por camadas, em vez de tentar nascer completo.
Self-service com guardrails
O objetivo é dar autonomia sem abrir mão de padrão e controle.
Mono-repo com desacoplamento lógico
A escolha do mono-repo favorece coesão, visibilidade e evolução coordenada entre app, infraestrutura e automação.
## Por que esse projeto existe
A FlowDX Platform existe para resolver problemas reais de entrega de software e, ao mesmo tempo, servir como demonstração prática de capacidade técnica.
Ela mostra não apenas a capacidade de implantar uma aplicação na AWS, mas também a capacidade de transformar esse fluxo em uma base de plataforma, com visão de longo prazo e decisões arquiteturais conscientes.
## Evidências Técnicas
O projeto apresenta um conjunto de decisões e implementações que podem ser observadas diretamente ao longo da estrutura e dos fluxos definidos.
Esses elementos estão refletidos tanto na estrutura do repositório quanto no fluxo de entrega implementado, permitindo análise direta da abordagem adotada.