🎪 Hype vs. Sustentabilidade
Toda tecnologia passa pelo Gartner Hype Cycle: trigger de inovação, pico de expectativas infladas, vale da desilusão, rampa de esclarecimento e platô de produtividade. Adotar no pico é arriscado (tecnologia imatura, bugs, falta de documentação). Adotar no platô é seguro mas tardio. O sweet spot é a rampa de esclarecimento.
💡 Boring Technology Theory
Dan McKinley (Etsy) propôs que cada time tem um “budget de inovação” limitado:
- •Boring technology: PostgreSQL, Redis, Linux, HTTP. Conhecida, documentada, previsível. Bugs já foram encontrados e corrigidos
- •Innovation tokens: Cada time tem ~3 tokens para tecnologias novas. Use-os onde geram vantagem competitiva real
- •Lindy Effect: Tecnologias que existem há 20 anos provavelmente existirão por mais 20. PostgreSQL (1996) é aposta mais segura que qualquer NewDB (2024)
📊 Caso Real: GraphQL
GraphQL é um caso perfeito do Hype Cycle em ação:
- 2015 (trigger): Facebook libera como open source. Promessa de resolver todos os problemas de REST
- 2017-2018 (pico): “REST está morto!” Conferências lotadas, adoção em massa sem critério
- 2019-2020 (vale): Problemas reais emergem: N+1 queries, caching complexo, segurança (query depth attacks)
- 2023+ (platô): Usado onde faz sentido (mobile-first, apps com muitas entidades relacionadas) e ignorado onde não faz (APIs internas simples, CRUD básico)
💡 Dica Prática
Consulte o ThoughtWorks Technology Radar antes de adotar qualquer tecnologia nova. Ele classifica em: Adopt (seguro), Trial (experimente), Assess (avalie) e Hold (evite). Se a tecnologia está em “Hold”, pense duas vezes. Se está em “Adopt”, provavelmente já passou pelo vale da desilusão.
⚠️ Alerta: Resume-Driven Development
Cuidado com decisões de stack motivadas por “quero aprender X” em vez de “X resolve nosso problema”. Um dev que escolhe Rust para uma API CRUD interna não está otimizando para o projeto — está otimizando para o próprio currículo. O projeto paga o custo.
👥 Fit com o Time
A melhor tecnologia é a que seu time domina. Stack que ninguém conhece é stack que ninguém mantém. O conhecimento existente do time é a restrição mais importante e mais ignorada na escolha de tecnologia. Contratar para uma stack exótica é caro, demorado e arriscado.
💡 Framework de Avaliação de Fit
- •Hiring Funnel: Quantos devs no mercado conhecem essa tecnologia? Se a resposta é “poucos”, o custo de contratação dispara
- •Ramp-up Time: Quanto tempo um dev novo leva para ser produtivo? Go = 2 semanas. Haskell = 3 meses
- •Bus Factor: Se a única pessoa que conhece Elixir sair, o projeto sobrevive?
- •Training vs. Hiring: É mais barato treinar o time atual ou contratar especialistas?
📊 Caso Real: Etsy e PHP
A Etsy deliberadamente escolheu PHP quando muitos o consideravam “inferior”:
- Razão: Maior pool de desenvolvedores disponível no mercado. Contratação rápida
- Resultado: Time de 200+ devs contratados rapidamente, todos produtivos em semanas
- Comparação: Empresas que escolheram Scala ou Clojure gastaram meses encontrando candidatos e pagaram 30-50% a mais em salários
- Lição: PHP “inferior” com 200 devs produtivos > Scala “superior” com 20 devs difíceis de encontrar
✓ O que FAZER
- ✓Fazer skills matrix do time antes de escolher stack
- ✓Pesquisar vagas abertas para a tecnologia na sua região/faixa salarial
- ✓Considerar polyglot pragmatism: use linguagens diferentes onde faz sentido
✗ O que NÃO fazer
- ✗Escolher stack que só o CTO conhece
- ✗Assumir que devs “aprendem rápido” sem investir em treinamento
- ✗Ter 5 linguagens diferentes para 3 devs
🔗 Ecossistema e Comunidade
Uma linguagem ou framework é tão boa quanto seu ecossistema. Bibliotecas maduras, documentação abundante, comunidade ativa — isso determina se você resolve problemas em minutos (npm install) ou em dias (reinventando a roda). O ecossistema é o moat competitivo de uma tecnologia.
💡 Como Avaliar um Ecossistema
- •Package Manager: Quantos pacotes? Qual a qualidade média? npm (2M+), PyPI (500K+), Go modules (crescendo rápido)
- •Community Health: GitHub stars são vaidade. Olhe para: issues respondidas, PRs mergeados, release frequency
- •Documentação: Docs oficiais são completos? Existem tutoriais, cursos, livros? Stack Overflow tem respostas?
- •Vendor Backing: Tem empresa grande por trás? Google (Go, Angular), Meta (React), Vercel (Next.js) — menos risco de abandono
📊 Caso Real: Python domina IA
Python não é a linguagem mais rápida, mais elegante nem mais segura. Mas domina IA e Data Science por uma razão:
- Ecossistema: NumPy, Pandas, TensorFlow, PyTorch, scikit-learn, Hugging Face — anos de investimento comunitário
- Comunidade: Milhões de data scientists que compartilham notebooks, modelos e tutoriais
- Alternativas: Julia é tecnicamente superior para computação científica, mas tem 1/100 do ecossistema. Mojo promete performance, mas é recém-nascido
- Lição: O ecossistema vence a linguagem. Sempre
💡 Dica Prática
Antes de adotar uma biblioteca, verifique: (1) Último commit < 3 meses? (2) Issues respondidas em < 1 semana? (3) Mais de 1 maintainer? (4) Usada em produção por empresas conhecidas? Se a resposta para qualquer uma é “não”, busque alternativa.
⚠️ Alerta: left-pad Syndrome
Em 2016, um dev removeu o pacote left-pad (11 linhas de código) do npm e quebrou milhares de projetos incluindo React e Babel. Dependência excessiva de pacotes triviais é risco real. Regra: se a função tem menos de 20 linhas, escreva você mesmo.
💸 Total Cost of Ownership
O custo real de uma tecnologia vai muito além da licença. TCO inclui infraestrutura, treinamento, contratação, manutenção e custo de oportunidade. Um banco “gratuito” pode custar mais que um pago se exigir DBA dedicado. “Open source é grátis como um cachorro é grátis” — sempre há custos ocultos.
💡 Os 6 Custos de uma Tecnologia
- •Licença: Gratuito, freemium, enterprise. Cuidado com mudanças de licença (Redis, Elastic, HashiCorp)
- •Infraestrutura: Servidores, storage, rede. Managed services custam mais mas economizam tempo de ops
- •Pessoas: Treinamento do time atual + custo de contratação de especialistas
- •Migração: Custo de sair da tecnologia se não funcionar. Vendor lock-in premium
- •Manutenção: Updates, patches de segurança, monitoração, troubleshooting
- •Oportunidade: O que você deixa de fazer enquanto implementa/mantém essa tecnologia
📊 Caso Real: Oracle → PostgreSQL
A migração de Oracle para PostgreSQL parece óbvia, mas o TCO conta outra história:
- Licença Oracle: US$50.000/ano. Caro, mas inclui suporte 24/7 e patches automáticos
- PostgreSQL “grátis”: Licença = $0. Mas: 3 meses de migração (US$150K em salários), treinamento do time (US$30K), DBA com experiência em PG (US$180K/ano), tuning e troubleshooting sem suporte enterprise
- TCO no ano 1: PostgreSQL pode custar MAIS que manter Oracle. A partir do ano 2, a economia começa
- Lição: “Grátis” não significa “sem custo”. Calcule o TCO em 3 anos antes de decidir
💡 Dica Prática
Crie uma planilha de TCO de 3 anos para cada tecnologia considerada. Inclua: licença, infra, pessoas (salários * tempo), migração, treinamento. Compare o total, não apenas o item mais visível. Managed services (RDS, Cloud SQL) frequentemente vencem self-hosted quando você inclui o custo de ops.
✓ O que FAZER
- ✓Calcular TCO de 3 anos incluindo custos ocultos
- ✓Incluir custo de saída (vendor lock-in) na análise
- ✓Avaliar managed vs. self-hosted honestamente
✗ O que NÃO fazer
- ✗Decidir baseado só no custo de licença
- ✗Ignorar mudanças de licença (Redis BSL, Elastic SSPL)
- ✗Subestimar o custo de operar software open source
🏗️ Stack INEMA
A stack da INEMA é um caso prático de escolhas calibradas para contexto real: time pequeno, produtos educacionais, automações com IA, custo mínimo. Nada de React, nada de Kubernetes, nada de microsserviços — porque o contexto não exige.
💡 A Stack na Prática
- •n8n (orquestração): Workflows visuais para automações. Conecta APIs, webhooks, schedule. Substitui backend custom para 80% dos casos
- •Claude Code (geração): Gera páginas, conteúdo, código. Humano revisa e aprova. 10x mais rápido que escrever do zero
- •Supabase (dados): PostgreSQL + Auth + Storage + Realtime. Um serviço para tudo que seria 4 serviços separados
- •HTML estático (front): Tailwind CSS, zero JavaScript obrigatório. Servido via CDN. Performance máxima, custo zero de hosting
📊 Por que essa Stack Funciona
- Custo mensal: ~US$50 (Supabase Pro + n8n self-hosted). Comparado a US$500+ para stack enterprise equivalente
- Time-to-deploy: Novas páginas em minutos, não dias. Claude gera, humano revisa, push para CDN
- Dependências: Zero build tools, zero bundlers, zero node_modules. Edite HTML, faça push, está no ar
- Escala: HTML estático via CDN suporta milhões de page views sem configuração adicional
💡 Dica Prática
Pergunte-se: “Preciso REALMENTE de um SPA (React/Vue/Angular)?” Para conteúdo estático, blogs, documentação, landing pages e cursos, HTML estático com Tailwind é mais rápido de desenvolver, mais rápido de carregar e infinitamente mais simples de manter. Reserve SPAs para apps com interação complexa em tempo real.
⚠️ Quando essa Stack NÃO Funciona
A stack INEMA é otimizada para conteúdo e automação. Não serve para: apps com estado complexo (Figma, Google Docs), real-time collaboration, jogos, sistemas financeiros com transações ACID complexas. Reconhecer onde sua stack não funciona é tão importante quanto saber onde funciona.
🔄 Estratégias de Migração
Trocar o motor com o avião voando. Reescritas big-bang falham 70% das vezes (Standish Group). Migração gradual é a única abordagem confiável para mudar de stack sem parar o sistema.
🛠️ Padrões de Migração
Strangler Fig Pattern
Novas features vão para o novo sistema. Sistema antigo encolhe gradualmente. Nome inspirado em figueiras que estrangulam a árvore hospedeira. O LinkedIn usou este padrão por 3 anos para migrar do monolito Java para microsserviços.
Parallel Run
Sistema novo roda em paralelo com o antigo. Compara resultados. Quando a confiança é alta, redireciona tráfego. Ideal para migrações de banco de dados onde consistência é crítica.
Canary Migration
1% do tráfego vai para o novo sistema. Monitore métricas. Se OK, aumente para 5%, 10%, 25%, 50%, 100%. Feature flags como kill switch para rollback instantâneo.
Blue-Green Deployment
Dois ambientes idênticos. Blue (atual) serve tráfego enquanto Green (novo) é preparado. Switch instantâneo via load balancer. Rollback = voltar para Blue.
📊 Caso Real: LinkedIn
O LinkedIn migrou de monolito Java para microsserviços usando Strangler Fig:
- 2011-2014: Cada nova feature era um novo serviço. O monolito não recebia código novo
- Proxy Layer: Um API gateway roteava requests entre monolito e novos serviços de forma transparente
- Resultado: Migração completa em 3 anos, zero downtime, zero big-bang
- Lição: “A melhor migração é aquela que o usuário não percebe”
💡 Dica Prática
Sempre tenha um kill switch para migrações: feature flags que redirecionam tráfego de volta para o sistema antigo em segundos. Se algo der errado às 3h da manhã, você quer um botão, não um rollback de 4 horas.
⚠️ Alerta: Big-Bang Rewrite
A reescrita big-bang é a forma mais sedutora e mais perigosa de migração. Parece simples (“vamos refazer tudo do zero”), mas na prática: o novo sistema nunca atinge paridade com o antigo, o business não espera, e você acaba mantendo dois sistemas por anos. O Netscape é o caso clássico — reescreveram o browser do zero e perderam o mercado para o Internet Explorer.
📋 Checklist de Decisão de Stack
Decisão de stack sem framework vira debate emocional. “Vamos usar Rust!” — É rápido, sim. Mas alguém do time sabe Rust? Vamos contratar devs Rust? Em quanto tempo? A que custo? Estas 10 perguntas cortam a emoção e focam no que importa.
💡 As 10 Perguntas Antes de Escolher
- ☐1. O time conhece? — Quantas pessoas dominam essa tecnologia hoje?
- ☐2. Contratamos fácil? — Existe pool de candidatos na faixa salarial disponível?
- ☐3. Comunidade ativa? — Issues respondidas, releases frequentes, docs completos?
- ☐4. Resolve o problema principal? — Qual o problema específico que esta tecnologia resolve melhor?
- ☐5. TCO aceitável? — Custo total em 3 anos incluindo pessoas, infra e migração?
- ☐6. Lock-in gerenciável? — Se precisar sair, qual o custo e o prazo?
- ☐7. Escala para nosso horizonte? — Suporta 10x o tráfego atual? E 100x?
- ☐8. Segura o suficiente? — Atende os requisitos de compliance do setor?
- ☐9. Podemos migrar depois? — Se não funcionar, qual o plano B e quanto custa?
- ☐10. Testamos com PoC? — Fizemos um spike time-boxed de 2 semanas máx?
📊 Caso Real: Aplicando o Checklist
Um time de 8 devs precisa escolher entre Next.js e Astro para um portal de conteúdo:
- Next.js: 7/8 devs conhecem React (✓), contratação fácil (✓), ecossistema imenso (✓), mas SSR complexity para conteúdo estático (✗), hosting caro com Vercel em escala (✗)
- Astro: 2/8 devs conhecem (✗), contratação limitada (✗), mas perfeito para conteúdo estático (✓), hosting barato (✓), suporta React components (✓)
- Decisão: Next.js venceu no checklist (7 vs 5 checkmarks). O fit com o time pesou mais que a adequação técnica pura
- Lição: O checklist torna a decisão objetiva e documentável. Sem debates emocionais
💡 Dica Prática
Transforme o checklist em um stack scorecard: atribua pesos (1-5) para cada pergunta baseado no seu contexto, pontue cada tecnologia (1-5), multiplique peso x pontuação e some. A tecnologia com maior score ganha. Documente o scorecard no ADR. Quando alguém perguntar “por que escolhemos X?”, aponte para o scorecard.
✓ O que FAZER
- ✓Sempre fazer PoC time-boxed (2 semanas máx) antes de decidir
- ✓Definir kill criteria antes do PoC: o que invalida essa opção?
- ✓Envolver todo o time na avaliação, não só o tech lead
✗ O que NÃO fazer
- ✗Escolher baseado em “eu li um blog post”
- ✗Fazer PoC de 3 meses (não é mais PoC, é projeto)
- ✗Ignorar a pergunta “e se não funcionar?”
📋 Resumo do Módulo
Próximo Módulo:
2.4 - 📝 ADRs e Documentação de Decisão — Architecture Decision Records: a memória do projeto