DEV Community: Fabricio_Gonçalves

REST Não Basta Mais: Por que suas APIs precisam de "Contexto" na era da IA

Fabricio_Gonçalves — Wed, 21 Jan 2026 00:40:45 +0000

A evolução das APIs parece ter estagnado nos últimos anos. Enquanto as ferramentas de inteligência artificial e os agentes autônomos evoluem a uma velocidade absurda, a forma como nossas APIs entregam dados continua rígida e engessada.

Se você trabalha com desenvolvimento, já deve ter percebido: estamos tentando conectar máquinas a sistemas que ainda dependem de manuais feitos para humanos. E é aqui que o problema começa.

O gargalo: APIs feitas para humanos, usadas por agentes

Quando criamos uma API tradicional, projetamos tudo esperando que um humano esteja no controle. Partimos do princípio que o desenvolvedor do outro lado vai ler a documentação, compreender as nuances de funcionamento do sistema e ter o bom senso de respeitar os limites para não quebrar nada, por exemplo.

O problema é que as LLMs (modelos de linguagem) não possuem essa intuição. Elas são literais. Se você der um endpoint para um agente de IA e pedir uma tarefa em massa, ele vai executar da forma mais rápida e bruta possível, sem saber que aquela "pancada" de requisições pode derrubar o seu servidor por falta de um direcionamento claro sobre o comportamento esperado.

O perigo da falta de contexto: O script "destruidor"

Imagine o seguinte cenário: você pede para uma IA ler 1.000 objetos de uma API e clonar esses dados em outro endpoint. É algo trivial.

Sem contexto: A IA gera um loop for simples e dispara os 1.000 pedidos em milissegundos.
O resultado: Para muitos sistemas, isso é um ataque DoS involuntário. A IA entregou o que você pediu, mas o sistema caiu porque ela não sabia que precisava "segurar a onda".

A Ideia: O método `CONTEXT`

Inspirado no método OPTIONS (que os navegadores já usam para entender permissões), por que não criar um padrão voltado especificamente para agentes de IA? A ideia é explorar um conceito de um método chamado CONTEXT.

O fluxo funcionaria assim: antes de o agente fazer qualquer GET, POST ou DELETE, ele faria uma consulta rápida ao endpoint usando esse "método" de contexto.

Como isso muda o jogo na prática

Ao consultar esse metadado, a API retornaria um JSON com as "regras de etiqueta" do sistema. Exemplo:

{
  "endpoint": "/v1/clonar-objetos",
  "rules": {
    "rate_limit_advice": "Nunca faça mais de 5 requisições por segundo",
    "criticality": "high",
    "side_effects": "Este comando gera carga pesada no banco de dados"
  }
}

Com essa informação em mãos, a IA muda o comportamento na hora. Em vez de um script agressivo, ela gera um código com um sleep (pausa) entre as chamadas, respeitando a saúde da infraestrutura sem que você precise dizer isso explicitamente no prompt inicial.

O futuro é padronizar o contexto

Precisamos parar de criar scripts e "peripécias" por fora para tentar controlar as IAs. O ideal é que as APIs forneçam, de forma padronizada e natural, o contexto necessário para que os agentes trabalhem com segurança.

Fornecer contexto deveria ser o padrão, não a exceção. Assim como verificamos permissões de CORS, deveríamos verificar o "comportamento esperado" de uma API antes de qualquer interação.

Quer ver a explicação completa e como essa ideia foi testada na prática? Assista ao vídeo: REST Não Basta Mais: O Problema do Contexto nas APIs

O que você acha dessa abordagem? Acredita que um padrão de metadados para agentes facilitaria o desenvolvimento de integrações mais seguras ou prefere controlar tudo no prompt?

Cursor | AI Infused SDLC - Potencializando o Desenvolvimento com Inteligência Artificial

Fabricio_Gonçalves — Sun, 24 Aug 2025 03:32:56 +0000

Cursor | AI Infused SDLC

O Ciclo de Desenvolvimento de Software (SDLC) é a espinha dorsal de qualquer projeto de tecnologia, mas por décadas seguimos suas fases de forma manual e, frequentemente, desconectada. E se pudéssemos infundir cada etapa com inteligência artificial, transformando a IA de uma ferramenta pontual em uma verdadeira parceira estratégica?

Neste artigo, vou mostrar como uma abordagem "AI Infused SDLC" utilizando o Cursor IDE pode mudar a maneira como planejamos, projetamos e codificamos software.

A Ferramenta Central: Cursor e suas "Rules"

Antes de mergulhar nas fases do SDLC, é fundamental entender a peça central desta abordagem: o Cursor IDE, um editor de código projetado especificamente para trabalhar com IA. Sua principal força reside na capacidade de injetar contexto de forma precisa através das "Cursor Rules".

As "Cursor Rules" funcionam como uma memória contextual estruturada para o modelo de IA, organizamos as informações em camadas hierárquicas da seguinte forma:

Regras genéricas de time: Padrões de arquivo, boas práticas de desenvolvimento e abordagens metodológicas.
Regras específicas do projeto: Stack tecnológico, padrões de código e convenções internas.
Informações organizacionais: Canais de comunicação, ferramentas utilizadas e processos estabelecidos.
Regras de negócio: Requisitos específicos do domínio, como regras de repasse ou validações particulares.
Arquitetura do sistema: Organização física e semântica do projeto.

O resultado é um contexto enriquecido que permite à IA gerar PRDs, implementações e documentação perfeitamente alinhadas ao projeto, frequentemente de forma transparente para o usuário.

Fase 1: Planning — Planejamento Inteligente

O Planning é a fase inicial onde definimos objetivos, escopo e viabilidade do projeto. Com o Cursor IDE, essa etapa ganha uma dimensão analítica mais profunda através do processamento inteligente de informações.

A IA pode consolidar dados de múltiplas fontes para apoiar decisões estratégicas:

Análise de Mercado: Processamento de documentos de pesquisa e tendências
Avaliação Técnica: Revisão de arquiteturas similares e tecnologias disponíveis
Estimativas de Esforço: Baseadas em projetos anteriores e complexidade identificada

O resultado é um roadmap de projeto fundamentado que serve como base sólida para as fases seguintes.

Fase 2: Análise Inteligente de Requisitos

A análise de requisitos é tradicionalmente uma das fases mais críticas do SDLC, onde a clareza dos objetivos determina o sucesso do projeto. O grande diferencial desta abordagem é que o piloto da IDE não precisa ser necessariamente um desenvolvedor. Com o Cursor e suas regras contextuais bem configuradas, um product owner pode conduzir essa fase com eficiência.

Utilizando o Model Context Protocol (MCP), a IA ganha acesso autorizado a múltiplas fontes de conhecimento, construindo um entendimento profundo e multidimensional do desafio:

Cenário prático conduzido por um Product Owner:

Análise de Código: A IA examina o repositório para mapear a arquitetura atual, identificar padrões existentes e possíveis pontos de impacto.
Consulta a Bancos de Dados: Investigação de esquemas e dados para compreender como uma nova funcionalidade afetará a estrutura existente.
Revisão Documental: Processamento de transcrições de reuniões, especificações técnicas e documentos de design para extrair requisitos essenciais.

O resultado final é uma tarefa detalhada gerada automaticamente no Jira, completa com resumo técnico, análise de impacto e critérios de aceitação preliminares. Tudo isso sem interromper o fluxo de trabalho dos desenvolvedores.

Fase 3: Design Colaborativo e Prototipação

Com a tarefa inicial estruturada, avançamos para a fase de Design — momento em que resistimos à tentação de "sair codificando" e priorizamos o refinamento da solução. Aqui, o time de desenvolvimento assume o protagonismo, utilizando a IA como parceira de brainstorming e prototipação.

O objetivo central desta fase é criar um plano de desenvolvimento detalhado, frequentemente materializado como uma task list dentro do próprio repositório. Este artefato funciona como uma ponte crucial: traduz necessidades de negócio em um roteiro técnico executável.

Como a IA do Cursor contribui:

Gera exemplos de código para ilustrar abordagens propostas: "Para o novo endpoint, poderíamos seguir este padrão de DTO"
Sugere estruturas de função: "A lógica de cálculo de juros pode ser encapsulada nesta função específica"
Propõe padrões arquiteturais adequados ao contexto do projeto

Importante: Todos esses exemplos são inseridos na task list como referência e orientação, mas nenhum código de produção é alterado nesta fase. É um momento de planejamento estratégico e alinhamento de expectativas.

Fase 4: Codificação Estratégica — A Escalada Controlada

Com um roadmap técnico claro, iniciamos a fase de codificação seguindo uma filosofia de "escalada controlada": subimos degrau a degrau, tarefa a tarefa, sempre com validação contínua. Esta abordagem substitui a corrida desordenada por um processo metodológico e seguro.

O processo se estrutura em três momentos distintos:

1. Preparação — Elaborando o Guia de Execução

O desenvolvedor cria um documento .md detalhado que serve como "manual de instruções" para a IA. Este guia lista as tarefas da task list, fornece contexto adicional e inclui exemplos específicos para implementação. É o momento crucial de "planejar antes de executar".

2. Definição — Estabelecendo o Diálogo

Com o guia preparado, o desenvolvedor inicia uma conversa estruturada no chat do Cursor, descrevendo precisamente a mudança desejada e referenciando o documento .md. A IA processa essas informações e apresenta a task list de forma organizada e pronta para execução.

3. Execução — Implementação Iterativa e Refinada

Esta é onde a metodologia se destaca. O desenvolvedor trabalha rigorosamente item por item:

Solicita à IA a implementação da primeira tarefa
Analisa criteriosamente o código gerado e seus impactos
Solicita refinamentos quando necessário: "Excelente estrutura, mas vamos extrair essa lógica para uma função separada para melhorar a testabilidade"
Só avança para o próximo item quando o atual está 100% validado

Esta disciplina garante solidez em cada etapa, eliminando retrabalho e mantendo a qualidade do código em padrões elevados.

Escopo deste Artigo

É importante destacar que neste artigo focamos especificamente nas quatro primeiras fases do SDLC: Planning, Análise, Design e Codificação. As demais etapas — Testes, Deploy e Manutenção — também possuem potencial significativo para serem revolucionadas com IA, mas merecem um tratamento detalhado que será abordado em artigos futuros.

Cada uma dessas fases restantes apresenta desafios únicos e oportunidades específicas para integração inteligente que justificam uma análise dedicada.

Desafios e Cuidados Essenciais

A adoção de IA no SDLC não é um mar de rosas. Novos desafios emergem e exigem atenção constante:

Context Rot (Degradação de Contexto): Excesso de tokens pode comprometer a precisão do modelo. É fundamental ser seletivo sobre quais informações fornecer à IA.
Overreliance (Dependência Excessiva): O código gerado sempre necessita validação humana criteriosa. Erros não detectados podem causar sérios problemas em produção. A IA é uma parceira poderosa, jamais uma substituta infalível.
Documentação Redundante: A IA pode gerar documentação excessiva e desorganizada. É essencial implementar processos de curadoria para manter apenas conteúdo relevante e atualizado.

O mantra fundamental: seja paciente e meticuloso. Todo output deve ser registrado, estruturado e, principalmente, revisado com rigor técnico.

Lições Aprendidas na Prática

Mesmo ainda em fase experimental, alguns insights valiosos já emergiram:

Nivelamento de Desenvolvedores: Profissionais menos experientes ganham significativa confiança e segurança, utilizando a IA como um "senior pair programmer" sempre disponível.
Aceleração para Especialistas: Desenvolvedores seniores conseguem acelerar drasticamente tarefas repetitivas, liberando tempo para se concentrar em desafios arquitetônicos complexos e decisões estratégicas.
Qualidade do Input é Crítica: Todo contexto fornecido é fundamental. Conversas de equipe, decisões arquiteturais e regras de negócio devem estar meticulosamente documentadas e acessíveis para maximizar a eficácia da IA.

Conclusão: Rumo a um SDLC Inteligente

Um SDLC infundido com IA, especialmente através de ferramentas como o Cursor IDE, representa uma evolução natural do desenvolvimento de software. Não se trata de substituir a expertise humana, mas de amplificá-la exponencialmente.

Esta abordagem transforma cada fase — desde a análise inicial até a entrega final — em um processo mais inteligente, orientado por dados e focado na estratégia. Ao adotar essa mentalidade, transcendemos o papel de "codificadores" para nos estabelecermos como verdadeiros arquitetos de soluções digitais.

O futuro do desenvolvimento de software não está na competição entre humanos e máquinas, mas na colaboração sinérgica entre ambos.

Qual sua experiência com IA no desenvolvimento? Compartilhe nos comentários como você tem usado ferramentas como o Cursor em seus projetos!

Evoluindo a Segurança de Transações em Apps Mobile: Da Senha ao Device Binding

Fabricio_Gonçalves — Mon, 09 Jun 2025 00:25:57 +0000

Salve, pessoal! Depois de iniciar minha trilha de gestão, tem me faltado tempo pra experimentar algumas coisas no mundo de desenvolvimento, mas essa semana me deparei com um problema que para alguns deve ser algo rotineiro, mas que para mim não é.

Estou falando simplesmente de garantir uma transação segura por meio de aparelhos móveis. Fácil, não é mesmo? 😅

Me dei conta que poderia não ser... por isso resolvi fazer um POC e entender melhor como podemos fazer uma transação de forma segura. Claro, não é um problema do meu dia a dia, posso no final estar falando groselha, e se for, fique à vontade para aparecer nos comentários ;)

Pois bem. Ainda que seja para falar de um tema cabeludo aqui, o objetivo não é entrar nas profundezas desse tema falando de criptografia quântica e o escambau, mas somente ilustrar um fluxo evolutivo de uma forma que, pra mim, parece aceitável de se lidar com esse problema.

Disclaimer: Este post foca em conceitos didáticos para iniciantes. Em produção, sempre consulte especialistas em segurança e siga as melhores práticas da sua organização.

🎯 O Que Vamos Abordar

Por que senhas simples não bastam
Evolução progressiva de segurança (do jeito que fui entendendo)
JWT, biometria e device binding na prática
Implementação de múltiplos fatores de autenticação
Fallbacks para dispositivos sem biometria

❌ Tentativa 1: O Básico Inseguro (Meus Tempos de Inocência)

No passado muito distante, quando nem sabia o que era um JWT, era muito comum pensar que um fluxo onde o app faz a autenticação pra logar no aparelho e depois, no máximo, colocando novamente a senha, já estaria apto a fazer uma transação.

O cenário que eu achava suficiente:

🔓 Usuário faz login
🔓 Para cada transação: digita senha novamente
💸 Executa transação

Mas isso tem alguns riscos bem graves que só fui perceber depois:

Alguém com acesso ao aparelho pode facilmente reutilizar a sessão
Nenhuma prova é exigida na hora da transação de que quem está enviando é realmente o dono da conta
Vulnerabilidade a shoulder surfing: Senhas podem ser observadas
Sem contexto: Nenhuma informação sobre dispositivo ou localização

⚠️ Tentativa 2: Melhorando com JWT (Descobrindo Tokens)

Não muito diferente da primeira, mas já com a evolução de usar o JWT. Então o usuário loga no sistema, recebe seu JWT, e usa esse JWT (mais a senha, talvez) para efetuar a transação.

O fluxo que pensei ser mais esperto:

🔐 Login → recebe JWT
🔐 Transação → envia JWT + (opcional) senha
💸 Servidor valida e executa

Ganhos em relação à tentativa 1:

✅ Token curto, com validade controlada
✅ Possibilidade de usar claims no JWT para indicar escopos ou expiração específica para transações
✅ Stateless (servidor não precisa armazenar sessões)

Ainda assim, há problemas sérios:

O JWT pode ser interceptado se não houver HTTPS (ou se tiver alguma falha na implementação)
Não há fator de prova adicional no momento da transação
Não está claro se quem usa o JWT é realmente o dono do aparelho
Falta de contexto transacional: JWT não está vinculado à transação específica

🛡️ Tentativa 3: Adicionando Biometria (Achando que Resolvi Tudo)

A abordagem agora, um pouco mais elaborada, pode ser dividida em 2 frentes, que depois podem se completar:

3.1 Biometria

Os aparelhos móveis evoluíram bastante. Não é difícil encontrar aparelhos com a capacidade de usar biometria para reconhecer o "dono" do aparelho. Adicionando isso no fluxo, garantimos que só o dono do aparelho possa autorizar uma transação.

O que achei que seria a solução final:

🔐 Login → recebe JWT
👤 Biometria local confirma identidade
🔐 Transação → envia JWT
💸 Servidor executa

Melhorias:

✅ Prova local de identidade
✅ Experiência do usuário melhorada
✅ Segurança adicional contra uso não autorizado

Mas, calma... 🤔

A biometria por si só não protege contra sequestro de token (JWT), por exemplo. O servidor não tem como saber se a transação realmente passou pela verificação biométrica. Ou seja, a autenticação local não garante integridade da transação.

Um atacante pode simplesmente interceptar o JWT e fazer a requisição diretamente, contornando completamente a biometria.

🔐 Tentativa 4: Device Binding + Desafio (Agora Sim Ficou Sério!)

3.2 Device Binding + Desafio

Uma nova etapa é adicionada no fluxo: a autorização do aparelho (device binding).

Aqui começamos a ficar sérios! Introduzimos o conceito de device binding com challenge-response.

Aqui, um "desafio" (challenge) é gerado pelo servidor e enviado para o app. Esse desafio é:

Assinado pelo dispositivo (com uma chave privada que está segura no aparelho e protegida por biometria)
Devolvido para o servidor, que valida com a chave pública

O que isso traz de ganho?

O desafio é algo que expira, é único e não reutilizável
Somente o aparelho autorizado consegue responder corretamente
A transação fica atrelada a um contexto: quem, quando, de qual dispositivo, e com qual fator de autenticação

Como Funciona:

Registro do Dispositivo:

   📱 App gera par de chaves (pública/privada)
   🔑 Chave privada fica protegida no dispositivo (TEE/Secure Enclave)
   📤 Chave pública é enviada e registrada no servidor

Fluxo de Transação:

   🔐 Login normal → recebe JWT
   💸 Usuário inicia transação
   🎲 Servidor gera challenge único
   👤 App solicita biometria para liberar chave privada
   ✍️ App assina o challenge com chave privada
   📤 Envia JWT + challenge assinado + dados da transação
   ✅ Servidor valida assinatura com chave pública registrada
   💸 Transação aprovada

Ganhos Significativos:

✅ Prova criptográfica de que a requisição veio do dispositivo específico
✅ Challenge único previne replay attacks
✅ Biometria integrada ao processo de assinatura
✅ Contexto completo: quem, quando, de onde e com qual fator

Implementação Prática:

React Native - Gerando chaves seguras:

import Keychain from 'react-native-keychain';
import TouchID from 'react-native-touch-id';

// Gera e armazena chaves do dispositivo
const generateDeviceKeys = async () => {
  const biometryType = await TouchID.isSupported();

  if (biometryType) {
    const { publicKey, privateKey } = await generateKeyPair();

    // Armazena chave privada protegida por biometria
    await Keychain.setInternetCredentials(
      'transaction_key', 'device_key', privateKey,
      { accessControl: Keychain.ACCESS_CONTROL.BIOMETRY_ANY }
    );

    return publicKey; // Enviar ao servidor
  }
};

// Assina challenge com biometria
const signChallenge = async (challenge: string) => {
  await TouchID.authenticate('Confirme a transação');

  const credentials = await Keychain.getInternetCredentials('transaction_key');
  return await signWithPrivateKey(challenge, credentials.password);
};

🏆 Tentativa 5: Juntando Tudo (e Mais Um Pouco)

Agora sim, o fluxo começa a ganhar cara de algo minimamente robusto!

Antes de realizar a transação, introduzimos um novo tipo de token: o token de autorização. Até agora, o JWT que usamos era um token de autenticação, usado para identificar quem está fazendo a requisição. Mas ele não diz muita coisa sobre a intenção de fazer uma transação específica.

O token de autorização vem para preencher essa lacuna. A versão mais robusta adiciona uma camada extra: tokens de autorização específicos para transação.

Diferença Entre Tokens (Que Eu Finalmente Entendi):

JWT de Autenticação: "Eu sou o usuário X"
Token de Autorização: "Eu tenho permissão para fazer ESTA transação específica AGORA"

Ele pode ter:

Um tempo de expiração curtíssimo (ex: 30 segundos)
Ser vinculado a uma transação específica (ex: ID do pagamento ou valor envolvido)
Ser liberado somente após a autenticação biométrica + assinatura do desafio, e gerado no lado do servidor

O app envia esse token ao backend como parte da requisição da transação, e o backend só valida a operação se esse token de autorização estiver presente, válido e íntegro.

Assim, conseguimos aplicar os três pilares da segurança:

Autenticação (JWT de login)
Autorização (token específico para a transação)
Prova de posse (biometria + assinatura criptográfica do desafio)

Fluxo Completo:

1. 🔐 Login → JWT de autenticação
2. 💸 Usuário inicia transação (valor: R$ 1000)
3. 🎲 Servidor gera challenge + token de autorização temporário
   - Válido por 30 segundos
   - Vinculado ao valor exato e destinatário
   - Só é liberado após validação completa
4. 👤 App solicita biometria
5. ✍️ App assina challenge + dados da transação
6. 📤 Envia: JWT + token de autorização + challenge assinado
7. ✅ Servidor valida TUDO:
   - JWT válido?
   - Token de autorização válido e não expirado?
   - Assinatura do challenge correta?
   - Dados da transação batem?
8. 💸 Transação aprovada

Implementação do Token de Autorização:



// Gera token específico para transação
func generateTransactionToken(userID string, data TransactionData, challengeID string) (string, error) {
    claims := TransactionClaims{
        UserID:      userID,
        Amount:      data.Amount,
        Recipient:   data.Recipient,
        ChallengeID: challengeID,
        RegisteredClaims: jwt.RegisteredClaims{
            ExpiresAt: jwt.NewNumericDate(time.Now().Add(30 * time.Second)),
        },
    }

    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    return token.SignedString(secretKey)
}

// Valida transação completa
func validateTransaction(authJWT, authToken, signature string, data TransactionData) error {
    // 1. Valida usuário
    user, err := validateAuthJWT(authJWT)
    if err != nil {
        return err
    }

    // 2. Valida token de autorização
    claims, err := validateAuthToken(authToken)
    if err != nil {
        return err
    }

    // 3. Verifica dados
    if claims.Amount != data.Amount || claims.Recipient != data.Recipient {
        return errors.New("dados não conferem")
    }

    // 4. Valida assinatura do challenge
    return verifyChallenge(claims.ChallengeID, signature, user.PublicKey)
}

🔄 Fallbacks e Considerações Práticas

Para Dispositivos Sem Biometria:

Senha de Transação: Como bancos tradicionais
SMS/Email OTP: Segundo fator via comunicação externa
App Authenticator: TOTP (Time-based One-Time Password)

// React Native - Escolha do método de autenticação
import TouchID from 'react-native-touch-id';

const getAuthenticationMethod = async () => {
  const biometrySupported = await TouchID.isSupported();

  if (biometrySupported && userPreferences.biometry) {
    return 'biometric_challenge';
  } else if (userPreferences.transactionPassword) {
    return 'transaction_password';
  } else {
    return 'sms_otp';
  }
};

🛡️ Os Três Pilares Implementados

Nossa solução final atende aos três pilares fundamentais da segurança:

1. Autenticação (Quem é?)

JWT de login válido
Identidade confirmada

2. Autorização (Pode fazer?)

Token específico para a transação
Escopo limitado e temporal

3. Prova de Posse (Está realmente aqui?)

Biometria + assinatura criptográfica
Device binding comprovado

⚡ Resumo dos Benefícios

✅ Múltiplas camadas de segurança
✅ Proteção contra replay attacks

✅ Device binding criptográfico
✅ Tokens com escopo limitado
✅ Fallbacks para diferentes cenários
✅ Experiência do usuário fluida
✅ Detecção de anomalias

🚀 Próximos Passos

Para quem quer se aprofundar:

Estude criptografia aplicada (curvas elípticas, RSA)
Implemente rate limiting e throttling
Adicione logging e auditoria detalhados
Considere WebAuthn/FIDO2 para web
Teste com pen testing profissional

📚 Referências Técnicas

Segurança Geral

React Native

Golang

Go Crypto Packages - Cryptography in Go
JWT Go - JWT implementation
Go Security - Security best practices
OWASP Go Cheat Sheet

💬 Conclusão

Juntando tudo, parece que agora temos uma transação minimamente segura:

Temos a identidade do usuário (login)
Temos a confirmação de que é ele mesmo, e que está no aparelho certo (biometria + device binding)
Temos a autorização contextual, com tempo curto e uso único (token da transação)

Em cenários onde não há suporte à biometria, usar uma senha específica para transações (como já é feito em bancos) também é totalmente aceitável - desde que seja tratada com o mesmo cuidado de um fator sensível.

Esse post não pretende esgotar o assunto - longe disso - mas sim mostrar que, mesmo para quem não lida com isso todo dia, é possível montar soluções coerentes, seguras e evolutivas.

Este guia apresenta uma evolução didática para implementar transações seguras em mobile. Em produção, sempre:

Consulte especialistas em segurança
Faça pen testing regular
Monitore logs de segurança
Mantenha-se atualizado com vulnerabilidades
Implemente gradualmente e teste muito

Segurança não é um destino, é uma jornada contínua de melhorias e adaptações.

Se você já implementou algo parecido ou tem sugestões, manda nos comentários! Estou aprendendo também. 😉

💡 Observação Importante

Na prática, considere soluções como OAuth 2.0, Auth0, Firebase Auth ou AWS Cognito que já implementam esses fluxos de forma segura e testada.

O aprendizado aqui é válido para entender os conceitos, mas em produção, "não reinvente a roda" 🛞

Arquitetura Viva: Moldando Sistemas para Mudanças

Fabricio_Gonçalves — Fri, 06 Dec 2024 21:52:39 +0000

Por vezes, ainda me pego conversando sobre arquitetura de software com algumas pessoas. Apesar de já ter escrito umas ideias aqui e ali, senti que faltava colocar no papel uma visão que vai além das “badaladas” clean architecture, ports and adapters e DDD. Ou talvez, pensando bem, essa visão esteja exatamente entre essas abordagens, porque todas bebem de fontes parecidas.

No fim, pode até não ser nada novo. Mas talvez seja algo que o curso “zero to hero” nunca mencionou. Então, resolvi deixar aqui mais uma peça desse quebra-cabeça que é a arquitetura de software.

Domínio

No contexto de Domain-Driven Design (DDD), o domínio é, essencialmente, o coração do sistema. É a área de atuação ou o problema que o software foi criado para resolver. Pense no domínio como aquela parte do mundo real que o software tenta modelar e onde executa suas operações.

Parece simples, né? E é um conceito que você vai encontrar em muitos livros e artigos. Mas, na prática, a aplicação desse conceito é tudo menos… linear.

Entre livros e a realidade do dia a dia

Uma das imagens mais famosas do DDD é a divisão clara entre subdomínios, cada um com seus próprios times (ou time) e sistemas bem organizados. Por exemplo:

Time A: cuida de Optimal Acquisition, Purchasing, Inventory e Resource Planning.

No mundo ideal, tudo estaria tão bem definido que o sistema rodaria como um relógio, com sinergia total entre os times e os domínios.

Agora, vamos temperar isso com um pouco de realidade. Imagine que, na segunda semana do projeto, a empresa percebe que o Time A está sobrecarregado. Então, dividem o trabalho assim:

Time B: assume Purchasing.
Time C: fica com Resource Planning.

Algumas semanas depois, alguém do Time C sai da equipe, e eles precisam se fundir com o Time B, formando o Time BC. Para complicar ainda mais, o Time A transfere parte de Inventory para o Time BC.

E aí fica a pergunta: seus sistemas aguentariam essas mudanças de time sem colapsar? A forma como você constrói software permite flexibilidade para reorganizar partes do sistema sem muito esforço?

O que vejo por aí

Embora a ideia de separar pastas em “models”, “views” e “controllers” esteja caindo em desuso, ainda vejo muitos projetos seguindo essa abordagem — só que com nomes diferentes. Uma unica pasta infrasctructure, com tudo dentro, por exempl.

Mesmo que as literaturas mais famosas sobre DDD e clean architecture não sejam muito prescritivas sobre organização de pastas, muitos desenvolvedores tentam copiar essas estruturas diretamente, sem considerar se elas realmente fazem sentido no contexto do projeto.

O sistema não é só seu (e nem do seu time)

Mudanças são inevitáveis. E, pensando nisso, gosto de construir sistemas baseados em módulos plug 'n play. Esses módulos devem ser coesos, com baixo acoplamento e fáceis de mover ou até mesmo deletar, se necessário.

Para alcançar essa flexibilidade, é essencial entender que boa parte do código de infraestrutura deve se alinhar às necessidades do domínio. Essa relação próxima faz com que infraestrutura e domínio funcionem juntos como uma unidade lógica.

Mas, além da infraestrutura e do domínio, há outro elemento importante no design dos meus sistemas: as bibliotecas (ou libs, cross cutting libs).

O papel das libs

As libs são componentes standalone, ou seja, não dependem do domínio. Isso significa que elas podem ser reutilizadas em qualquer projeto, tornando o sistema mais modular e sustentável a longo prazo.

No modelo básico, podemos visualizar assim:
https://miro.medium.com/v2/resize:fit:640/format:webp/1*2Yx38jXKm4wTRUqVCSE8ZQ.png

Porém, como frisei até aqui, gosto de mais uma camada separando as coias, camada de módulo.

Modulos

Os módulos desempenham um papel fundamental na estruturação de projetos, pois permitem agrupar funcionalidades relacionadas, promovendo coesão e encapsulamento. Eles facilitam a manutenção, tornam o código mais reutilizável e ajudam a manter a separação de responsabilidades clara e bem definida.

Em um sistema maior, onde existem vários módulos, o desenho evolui para algo assim:

Regra de ouro: nada é compartilhado diretamente entre módulos. Isso mantém o sistema modular e reduz a complexidade de dependências.

Por que essa abordagem?

Com essa organização, garantimos que:

Flexibilidade: É fácil mover ou reaproveitar partes do sistema.
Reutilização: Libs podem ser usadas em múltiplos projetos, economizando esforço.
Isolamento: Problemas em um módulo não afetam outros diretamente.

Essa mentalidade ajuda a construir sistemas que acompanham as mudanças organizacionais e evoluem sem virar uma bola de neve técnica.

Conclusão

No fim, não mostrei muito código aqui, mas tentei compartilhar uma visão sobre como as abordagens que escolhemos para estruturar nossos sistemas não são apenas técnicas: elas impactam diretamente e são impactadas pelo nosso dia a dia de trabalho.

Cada decisão de design, desde a organização dos módulos até a reutilização de libs, reflete nas facilidades e nos desafios que enfrentamos em um projeto. Então, pensar na arquitetura como algo vivo e que deve acompanhar as mudanças da equipe e do negócio é o que nos ajuda a construir sistemas mais sustentáveis e adaptáveis.

Espero que essa reflexão te inspire a olhar para suas escolhas arquiteturais com uma perspectiva prática e estratégica. Afinal, arquitetura de software é menos sobre diagramas e mais sobre preparar o terreno para evoluir sem perder o controle. 🚀

GO — Estrutura de projetos

Fabricio_Gonçalves — Tue, 18 Jun 2024 20:39:08 +0000

Comecei a programar usando golang de verdade esse ano (2022), e a coisa que logo fiz foi procurar referências de como seria a melhor forma de evoluir minha estrutura para o projeto. Esse post será só mais um dentre tantos outros que falam do mesmo assunto, e, talvez até por isso, resolvi escrevê-lo.

Primeiro que golang já é todo diferentoso na forma que lida com pastas/packages, e, pra melhorar, tem uma essência bastante opinativa, com muitas docs oficiais informando como seria o “goway” de se fazer algo (cheio de não me toque), entretanto, na forma que você vai organizar seus arquivos e pastas, não tem bem um direcionamento, então, meio que cada um dá a sua interpretação de mundo pra essa parte.

Irei dividir esse post em 3 referências e depois mostrar como ficou a mistura dessas referências no projeto.

Primeira referência

Um sistema complexo que funciona invariavelmente evoluiu de um sistema simples que funcionou.
-- Lei de Gall

Para pequenas aplicação a estrutura do projeto deve ser simples.

https://innovation.enova.com/gophercon-2018-how-do-you-structure-your-go-apps/

Segunda referência

A “comunidade” fez um levantamento de um conjunto de padrões de layout de projeto históricos e emergentes comuns no ecossistema Go. Nesse levante tem muita coisa bacana, mas o que me chamou a atenção foram as pastas /cmd e /internal.

/cmd

Principais aplicações para este projeto.
O nome do diretório para cada aplicativo deve corresponder ao nome do executável que você deseja ter(ex.: /cmd/myapp).

/internal

Aplicativo privado e código de biblioteca. Este é o código que você não quer que outros importem em seus aplicativos ou bibliotecas. Observe que esse padrão de layout é imposto pelo próprio compilador Go.

Terceira referência

Arquiteturas que separam melhor os “detalhes” do que realmente entrega valor.

Resultado

Para aplicação simples tento manter simples, contudo, quando o escopo fica um pouco maior, tento fazer uma leve diferenciação do que é “core”/domain do que é detalhe/infrastructure.

Notem que no cmd não tenho a pasta tuttipet, como sugere o projeto de referência. No começo eu tentei usar o padrão sugerido, mas como esta API já saiu com uma interface de linha de comando e um provider para terraform resolvi deixar desta forma.

Dando um rápido zoom no core. Tento ser simplista aqui e não criar pastas. Mantenho somente 1 ponto de contato com o mundo externo (main.go), o que for generalizado tem seu próprio arquivo e o que não for fica dentro do seu contexto, simples.

Com o tuttipet.New (curto, conciso e evocativo) a camada “suja” consegue interagir com os usecases (acho a palavra usecase mais fácil de assimilar que interactor)

Dando um rápido zoom nos detalhes. Aqui simplesmente estão as ferramentas pelas quais o domínio vai conseguir o seu sucesso.

Conclusão

Ainda sou pimpolho nos caminho que golang oferece, ainda tateando o que dá pra fazer com ele, no entanto, mesmo sem gostar do jeitinho Go de fazer algumas coisa, o mesmo tem se mostrado bastante simples e robusto.

Resumo, tentando deixar simples quando dê e se ficar complexo de mais … volto pra prancheta.

Outras referências

https://dev.to/booscaaa/implementando-clean-architecture-com-golang-4n0a
https://github.com/golang-standards/project-layout
https://blog.boot.dev/golang/golang-project-structure/
https://github.com/bnkamalesh/goapp
https://www.wolfe.id.au/2020/03/10/how-do-i-structure-my-go-project/
https://blog.logrocket.com/flat-structure-vs-layered-architecture-structuring-your-go-app/
https://developer20.com/how-to-structure-go-code/
https://dev.to/jinxankit/go-project-structure-and-guidelines-4ccm
https://github.com/bxcodec/go-clean-arch
https://golangexample.com/example-go-clean-architecture-folder-pattern/
https://www.calhoun.io/flat-application-structure/
https://go.dev/doc/effective_go#names
https://go.dev/blog/package-names

Post original: https://medium.com/@espigah/go-layout-do-projeto-18aacce8089d

On-Call Cookbook

Fabricio_Gonçalves — Mon, 03 Jun 2024 12:23:28 +0000

On-Call Cookbook

Objetivo

Este cookbook fornece diretrizes práticas para a organização de um esquema de on-call(guardião, plantão, motorista da rodada e etc) eficiente e resiliente, com base nas melhores práticas de Site Reliability Engineering (SRE).

Se você quiser saber mais sobre On-Call, sugiro a leitura do post anterior.

Definição e Escopo

O on-call durante o expediente refere-se a períodos em que os membros da equipe estão disponíveis para responder a incidentes e alertas durante o horário de trabalho normal. Isso difere de sobreaviso ou plantão, que geralmente envolvem disponibilidade fora do horário de trabalho.

Coisas que uma Pessoa de On-Call Deve Fazer

Monitoramento de Sistemas: Verifique painéis de monitoramento e responda a alertas de desempenho, disponibilidade e erros.
Responder a Incidentes: Responda prontamente a alertas e chamados, diagnostique e resolva problemas rapidamente.
Comunicação: Mantenha uma comunicação clara e eficiente com a equipe, stakeholders e outros departamentos afetados pelos incidentes.
Documentação: Documente os incidentes e as ações tomadas para resolvê-los, para referência futura e aprendizado.
Análise de Logs: Analise logs de servidores, aplicações e redes para identificar causas raiz de problemas.
Escalonamento de Problemas: Saiba quando e como escalar problemas para níveis superiores ou outras equipes especializadas.
Manutenção Preventiva: Realize verificações regulares de sistemas e infraestrutura para prevenir problemas antes que eles ocorram.
Atualizações e Patches: Aplique atualizações e patches de segurança para manter o ambiente seguro e estável.
Backup e Recuperação: Garanta que os backups estejam sendo feitos corretamente e teste os processos de recuperação.
Revisão Pós-Incidente: Participe de revisões pós-incidente para analisar o que aconteceu e como melhorar no futuro.

Formas de Organizar o On-Call

Escalas Rotativas: Crie um cronograma de on-call rotativo para distribuir a carga de trabalho de maneira justa entre todos os membros da equipe.
Ferramentas de Monitoramento e Alerta: Utilize ferramentas para gerenciar alertas e escalonamentos de forma eficiente.
Runbooks e Playbooks: Desenvolva e mantenha runbooks e playbooks detalhados para guiar a equipe de on-call em diferentes tipos de incidentes.
Reuniões Regulares: Realize reuniões regulares de revisão de on-call para discutir incidentes recentes, melhorias no processo e feedback.
Treinamento e Desenvolvimento: Prover treinamentos contínuos para a equipe de on-call, incluindo simulações de incidentes e workshops de novas tecnologias ou processos.
Documentação Centralizada: Mantenha uma base de conhecimento centralizada onde todos os procedimentos, runbooks e documentação de sistemas estejam acessíveis.
Balanceamento de Carga: Analise a carga de incidentes e ajuste as escalas de on-call para garantir que nenhum membro da equipe fique sobrecarregado.
Ferramentas de Comunicação: Utilize ferramentas de comunicação eficientes para coordenar a resposta a incidentes.
Feedback Contínuo: Implemente um sistema de feedback contínuo para que os membros da equipe possam sugerir melhorias e relatar problemas com o processo de on-call.
Automatização: Automatize tarefas repetitivas e processos de monitoramento para reduzir a carga de trabalho manual durante os períodos de on-call.

Hands-On / Hands-Off

Transferência de Conhecimento: No período de hands-off, compartilhe informações detalhadas sobre quaisquer problemas em andamento ou potenciais riscos.
Documentação Atualizada: Assegure que toda a documentação relevante está atualizada e acessível antes de finalizar o turno.
Briefing de Transferência: Realize um briefing rápido para o próximo on-call, destacando pontos críticos e status atual.
Evitar o Término no Último Dia da Semana: Planeje o término do on-call para o meio da semana, como quarta ou quinta-feira, para facilitar a transição de responsabilidades e permitir tempo para resolver problemas em andamento antes do final de semana.

Conclusão

Seguindo estas práticas, você poderá criar um ambiente on-call eficiente e resiliente, garantindo que sua equipe esteja bem preparada para lidar com incidentes e manter a alta disponibilidade dos sistemas.

Definindo SLO - "Let Go!"

Fabricio_Gonçalves — Tue, 21 May 2024 15:11:54 +0000

Let Go!

Na trajetória da Engenharia de Confiabilidade (SRE), uma dificuldade inicial pode residir na evangelização das práticas, em especial na definição de Objetivos de Nível de Serviço (SLO). Com base na inspiração proporcionada pelo modelo VALET da The Home Depot, apresento a proposta do padrão “Let Go!” como uma opção acessível para aqueles que estão iniciando e necessitam de uma abordagem simplificada para que todos possam assimilar.

Antes que qualquer projeto seja lançado, é imprescindível conquistar o selo mínimo de aprovação “Go!”. Para atingir esse marco, é essencial definir e docuemntar o “Let”.

L — Latency

O serviço responde rapidamente quando eu o uso? Quão rápido meu serviço tem que ser?
O que faremos se o serviço estiver demorando mais que o esperado?

E — Errors

O serviço gera um erro quando eu o uso?
O que faremos se o serviço estiver com mais erro que o esperado?

T — Traffic

Quanto volume de negócios meu serviço pode suportar?
O que faremos se o volume for maior (ou muito menor) que o esperado?

A adoção do padrão "Let Go!" pode ser um ponto de virada na implementação eficaz da Engenharia de Confiabilidade (SRE), proporcionando uma estrutura clara e concisa para novos projetos. Estabelecer e documentar parâmetros de Latency, Errors e Traffic permite não apenas a medição objetiva da performance do serviço, mas também a definição de ações proativas para manter a confiabilidade. Com este padrão, equipes podem navegar com mais segurança nas etapas iniciais de um projeto, garantindo que cada serviço lançado atenda aos requisitos mínimos de desempenho e resiliência. Assim, o "Let Go!" não apenas simplifica a complexidade inicial, mas também estabelece uma base sólida para a evolução contínua das práticas de SRE dentro da organização.

Desvendando o Mundo do On-call: Desafios e Estratégias para uma Operação Eficiente

Fabricio_Gonçalves — Wed, 22 Nov 2023 12:03:12 +0000

Estar de on-call, também conhecido como plantão, guardião ou suporte, é uma atividade crucial para assegurar a disponibilidade e confiabilidade dos sistemas de produção. Embora essencial, essa prática complexa e desafiadora pode ter um impacto significativo na vida pessoal e profissional dos envolvidos.

Evolução nas Responsabilidades e Distribuição de Tarefas

Tradicionalmente, administradores de sistemas e engenheiros de operações eram encarregados do on-call, com o desenvolvimento "jogando" o projeto para o time de operações. Contudo, a abordagem "you build, you run it" ganhou força, exigindo que os desenvolvedores assumam a responsabilidade pela manutenção do que entregam. Em alguns casos, equipes plantão(NOC, SRE e etc) podem fazer triagens, seguindo runbooks antes de escalar para o time principal.

A Essência de Estar de Plantão

Estar de on-call vai além de simplesmente corrigir problemas de produção. Alinhado com práticas DevOps, inclui a automação de tarefas, diagnóstico, mitigação, correção e escalonamento de incidentes. A pessoa de on-call não apenas lida com o ciclo de vida do incidente, mas também realiza tarefas de produção não urgentes, promovendo oportunidades de aprendizado e compartilhamento de conhecimento com a equipe.

Modus Operandi na Prática

Ao receber um alerta ou chamado, a pessoa de on-call tria o problema e trabalha para sua resolução, sendo a primeira linha de defesa para garantir interrupções mínimas. Contudo, estar de on-call não implica ser um herói; a configuração ideal envolve uma abordagem colaborativa, onde a triagem inicial é seguida por escalonamentos conforme necessário. Além disso, é crucial aprimorar continuamente o trabalho diário (DevOps), onde a pessoa responsável pelo plantão (on-call) desempenha um papel fundamental para garantir que o amanhã seja ainda melhor do que o hoje.

Manter-se Bem e Ponderado

Para desempenhar efetivamente, é crucial manter a calma e a clareza mental. Embora existam duas abordagens de pensamento - ação intuitiva e funções cognitivas racionais - em sistemas complexos, a segunda tende a produzir melhores resultados. Portanto, estar em um estado calmo e racional é fundamental para resolver problemas de forma eficaz.

Reduzindo a Carga Cognitiva com Diretrizes Claras

Diretrizes precisas são essenciais para as responsabilidades de on-call, desde a leitura do handoff anterior até a escalada de incidentes após um tempo pré-determinado. Procedimentos bem definidos abrangem o gerenciamento de incidentes, escalonamento, redação de post-mortems, execução de runbooks e trocas de on-call a curto prazo.

Rotação Eficiente e Seus Benefícios

Uma rotação eficaz proporciona maior transparência, responsabilidade e confiabilidade nos serviços. Isso resulta em respostas rápidas a alertas, clientes mais satisfeitos e uma equipe mais coesa.

Desafios e Estratégias de Atenuação

Além dos benefícios, o on-call apresenta desafios, como impactos na vida pessoal, exigências técnicas e pressão psicológica. Estratégias para atenuar esses desafios incluem mensuração da sobrecarga operacional, controle de alertas e garantia de tempo adequado para lidar com incidentes, evitando atropelos.

Conclusão: Um Mundo Desafiador, Mas Gerenciável

Estar de on-call é uma responsabilidade complexa, mas com estratégias claras, comunicação eficaz e uma abordagem colaborativa, é possível enfrentar os desafios e garantir a estabilidade dos sistemas críticos. A busca contínua por melhores práticas e o equilíbrio entre trabalho e bem-estar são fundamentais para uma operação de on-call eficiente e sustentável.

E aí, curtiu? Eu adoraria saber: como você e sua equipe superam os desafios e contratempos?

vlw!

Mantenha o foco em entregar valor com DevOps, SRE e FinOps

Fabricio_Gonçalves — Sun, 26 Feb 2023 11:43:33 +0000

Nesse texto irei trazer algumas coisas que demorei a aprender na trilha que segui de desenvolvimento de software, talvez por não ter seguido um caminho mais “tradicional”, ou talvez porque não se vê tantos holofotes/clickbaits sobre esses assuntos para quem escolheu o caminho de transformar café em código.

Quantos blogs sobre a melhor forma de usar a memória na tecnologia X você já viu? Um vídeo sobre melhor estrutura de dados para o problema Y? Alguém falando no passarinho azul que você deveria prestar atenção nas melhorias assintóticas?

Mas quantos falam sobre confiabilidade? Ou sobre maximizar o retorno sobre o investimento? Que te ensinam a transformar o seu ambiente para que todos trabalhem focados em entregar valor?

Talvez o que tenha me levado a ser um programador um cado melhor não foi saber extrair até a última gota de suco que um framewok pode dar, talvez tenha sido algo mais simples, talvez até mais obvio, talvez tenha sido o fato de eu ter aprendido que devemos resolver o problema considerando a perspectiva do usuário/cliente e a perspectiva de quem paga para manter o sistema de pé.

Aqui entra o kit de ferramentas que no início costumamos deixar para trás, e, estranhamente, depois temos um certa resistência em voltar para buscar esse tal kit, ou simplesmente, talvez por conta de como a mídia/mercado lida com ele, não damos a devida atenção, apesar disso, esse kit é o que traz a transformação. Aqui entram as ferramentas que vem com a cultura DevOps, as práticas de SRE e os princípios do FinOps.

A cultura DevOps

Muito se fala em DevOps, mas colocar toda a teoria em pratica não é trivial. Você facilmente verá vagas DevOps que estarão pedindo conhecimentos em alguma FERRAMENTA de CI/CD, FERRAMENTA disso e FERRAMENTA daquilo. Talvez por isso que essa “cultura”, quase que ironicamente, tem ficado distante do mundinho das pessoas desenvolvedoras, onde muitas vezes ainda se joga o pacotinho por cima do muro e o detentor do conhecimento sobre a FERRAMENTA de sustentação que acaba ficando com a carga da operação.

O DevOps até pode ser isso sim, todavia, como cultura, deve ajudar a alinhar pessoas, processos e ferramentas para um foco mais direcionado ao cliente. Como cultura, não deve ser de um time, não deve ser de uma pessoa. Você, todos os dias, pode praticar essa cultura, você pode ser a pessoa que está em busca de aumentar a transparência, a comunicação e a colaboração.

Algumas das principais práticas de DevOps incluem:

Colaboração: DevOps enfatiza a necessidade de as equipes trabalharem juntas de forma integrada, quebrando silos e promovendo uma cultura de colaboração entre os departamentos.
Automação: DevOps enfatiza o uso de ferramentas e processos de automação para agilizar o desenvolvimento, teste e implantação, reduzindo a probabilidade de erro humano e melhorando a eficiência.
Integração Contínua: DevOps promove a integração contínua de alterações de código, permitindo que as equipes detectem e resolvam problemas no início do processo de desenvolvimento.
Entrega contínua: o DevOps enfatiza a importância da entrega contínua, permitindo que as equipes lancem software com rapidez e confiança.
Continuous Deployment: DevOps promove o uso de continuous deploy, permitindo que as equipes liberem alterações de código de forma automática e contínua, sem a necessidade de intervenção humana.
Teste: DevOps enfatiza a necessidade de testes completos durante todo o ciclo de vida do desenvolvimento de software, garantindo que o software seja confiável, seguro e de alta qualidade.
Monitoramento: o DevOps enfatiza a importância do monitoramento de software na produção, permitindo que as equipes detectem e resolvam rapidamente os problemas à medida que surgem.
Segurança: DevOps coloca uma forte ênfase na segurança em todo o ciclo de vida do desenvolvimento de software, garantindo que o software esteja seguro e protegido contra ameaças potenciais. (DevSecOps é quase um pleonasmo)
Aprendendo com as falhas: DevOps promove uma cultura de aprendizado e melhoria contínua, incentivando as equipes a aprender com as falhas e fazer melhorias iterativas ao longo do tempo.
Melhoria do trabalho diário: DevOps incentiva as equipes a melhorar continuamente seus processos de trabalho diários, buscando maior eficiência e eficácia em todos os aspectos do ciclo de vida do desenvolvimento de software.

Referências:

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win

The Unicorn Project

As práticas de SRE

SRE vai no mesmo caminho de DevOps, dado que o próprio Google inicia o livro com class SRE implements interface DevOps não seria surpresa esse caminho, contudo não se trata de manter FERRAMENTAS de observabilidade ou FERRAMENTA XPTO, tampouco pra ser a operação com uma nova roupagem. SRE emerge das práticas de engenharia para mudar todo o ciclo de vida de desenvolvimento de sistemas (SDLC). No kit de ferramentas de SRE você vai ter o seu usuário/cliente no centro da discussão. Você vai aprender que a esperança não é uma estratégia, então, com isso, você precisa responder a seguinte pergunta:

Com que seus usuários/clientes se importam?

Se você não tem esse resposta, não adianta nenhum código, não adianta nenhuma metodologia ágil hypada. Sem essa resposta é tiro no escuro. Em suma, aqui você vai adquirir ferramentas para construir o projeto confiável e manter-lo saudável em produção.

SLA

Se alguma demanda chegou para ser feita sem que fique claro a volumetria, tempo máximo que uma operação pode ser executada e quantidade de erros máximos tolerados (existem muitos outros SLIs para seus SLAs, mas não é o foco aqui), provavelmente não estamos com um SLA bem definido, ou seja, provavelmente não estamos nos esforçando para ter uma métrica que corresponda, mesmo que de forma imprecisa, a satisfação do nosso usuário/cliente. Sem SLA não estaremos prontos para criar mecanismos de defesa(SLO) para que os problemas não impactem negativamente a receita.

Algumas das principais práticas do SRE incluem:

Objetivos de nível de serviço (SLOs): defina objetivos claros e mensuráveis para a disponibilidade, latência e desempenho de seus sistemas.
Orçamentos de erro: Use SLOs para definir orçamentos de erro, que definem o nível aceitável de degradação do serviço que pode ocorrer sem afetar os usuários.
Automação: Automatize o máximo possível para reduzir o risco de erro humano e melhorar a confiabilidade.
Monitoramento: Monitore seus sistemas continuamente para detectar e diagnosticar problemas rapidamente.
Resposta a incidentes: Desenvolva um processo de resposta a incidentes claro e bem documentado para minimizar o tempo de inatividade e mitigar o impacto das falhas.
Revisão pós-incidente: Conduza revisões completas pós-incidente para identificar as causas principais das falhas e evitar que elas ocorram novamente no futuro.

Referências:

Engenharia de Confiabilidade do Google: Como o Google Administra Seus Sistemas de Produção

The Site Reliability Workbook: Practical Ways to Implement SRE

Seeking Sre: Conversations about Running Production Systems at Scale

Database Reliability Engineering: Designing and Operating Resilient Database Systems

Microsserviços Prontos Para a Produção: Construindo Sistemas Padronizados em uma Organização de Engenharia de Software

Os princípios do FinOps

É uma prática comum no mercado que a gestão do custo da nuvem seja centralizada em uma área. Essas informações de custo são passadas ao setor financeiro, que tenta se manter atualizado sobre o custo dos próximos meses da nuvem.

Assim como na era Dev vs Ops, já ficou claro que essa fluxo não é sustentável, precisamos nos conscientizar que nossas aplicações são (ou deveriam ser) da responsabilidade de quem constrói, lembra “you build it, you run it”?, então por que a responsabilidade sobre custos e de como maximizar o retorno sobre o investimento não deveria ficar com quem desenvolve?

Mudança cultural

Existe toda uma jornada FinOps para ser aplicada, e assim como DevOps, também há uma barreira cultural. FinOps trata de remover silos e bloqueadores, capacitar os times de engenharia para fornecer melhores recursos, aplicativos e migrações com mais eficiência; também traz uma conversa multifuncional sobre onde e quando investir, deixando claro para todos porque estão tomando essas decisões.

Aqui estão alguns dos princípios-chave do FinOps:

Responsabilidade: Cada equipe e indivíduo deve ser responsável pelos custos que incorrer.
Responsabilidade: Equipes e indivíduos devem ser responsabilizados por seus gastos e devem ter visibilidade do impacto de suas decisões no orçamento geral.
Proatividade: é importante identificar e resolver possíveis problemas de custo antes que eles se tornem um problema.
Eficiência: Otimize os gastos usando os recursos mais econômicos e eliminando o desperdício.
Transparência: tornar os custos visíveis e compreensíveis para todos na organização.
Colaboração: promova a colaboração entre as equipes para garantir que os custos sejam gerenciados de forma eficaz em toda a organização.

Referências:

FinOps Foundation — What is FinOps?

AWS Cloud Financial Management

Cost Optimization Pillar — AWS Well-Architected Framework

Extreme programming (XP) [bônus]

XP é uma metodologia ágil de desenvolvimento de software que se concentra na entrega rápida e contínua de software de alta qualidade. A metodologia XP enfatiza que o software atenda às necessidades do cliente e seja desenvolvido de forma eficiente. A metodologia XP já está meio fora de moda, eu sei, mas justamente por isso que escolhi colocá-la nessa lista. Pra tentar mostrar que quase todas as soluções, em algum ponto, passam pelo cliente.

Práticas da XP:

Cliente presente: O cliente está envolvido no processo de desenvolvimento do início ao fim, trabalhando de perto com a equipe de desenvolvimento para garantir que o software atenda às suas necessidades.
Comunicação constante: A comunicação é uma parte essencial do XP, com desenvolvedores trabalhando em pares e se comunicando regularmente com o cliente para garantir que os requisitos do projeto sejam compreendidos.
Desenvolvimento iterativo e incremental: O desenvolvimento é feito em pequenas iterações, com cada iteração resultando em um software funcional que pode ser testado pelo cliente.
Testes contínuos: A equipe de desenvolvimento escreve testes automatizados para cada parte do código, garantindo que o software seja testado continuamente.
Integração contínua: As atualizações de código são integradas continuamente ao projeto principal, permitindo que a equipe de desenvolvimento monitore as alterações e corrija quaisquer problemas que surgirem.
Design simples: O design do software é mantido simples e fácil de entender, com a equipe de desenvolvimento se concentrando em criar um software funcional em vez de recursos complexos.
Refatoração de código: O código é continuamente refinado e melhorado para garantir sua qualidade e manutenibilidade.
Propriedade coletiva do código: Todos os membros da equipe têm responsabilidade pelo código, permitindo que qualquer pessoa faça alterações e melhorias quando necessário.
Entrega contínua: O software é entregue regularmente em pequenos incrementos, permitindo que o cliente teste e forneça feedback sobre o produto em tempo hábil.

Conclusão:

Devemos lembrar que a programação é uma forma de resolver problemas, e não um fim em si. Se ficarmos presos na obsessão pela otimização prematura e pelo conhecimento técnico detalhado, podemos perder de vista o objetivo principal: entregar valor para o usuário/cliente. As práticas DevOps, SRE e FinOps podem nos ajudar a manter o foco nesse objetivo, trabalhando em equipe, criando soluções eficientes e com custos controlados.

Por fim, gostaria de deixar um último pensamento:

“O software é uma arte. É algo que requer habilidade, paciência e dedicação. É um processo contínuo de aprendizado, erro e correção. E acima de tudo, é um processo colaborativo, que exige a contribuição de muitos para alcançar o sucesso.” — Linus Torvalds

Espero ter contribuído com algumas ideias para a sua jornada como pessoa desenvolvedora. Lembre-se sempre de manter o foco no usuário/cliente, trabalhar em equipe e buscar o aprendizado constante. E acima de tudo, não se esqueça de tomar um café de vez em quando para manter as ideias fluindo!

Observando sistemas distribuídos

Fabricio_Gonçalves — Sat, 27 Aug 2022 20:54:46 +0000

Esse blogpost emergiu com a necessidade que tive de juntar o que li sobre observabilidade. Adianto que não será uma abordagem muito profunda sobre o assunto, interessando, sugiro fortemente que leia as referências =)

Agradeço aqui também o Sr. André e meu caro Will por terem me ajudado com esse conteúdo <3. Vlw, pessoal!

Uma realidade em nossos sistemas e que as coisas irão falhar - pequenas alterações podem resultar em muitos resultados inesperados, incluindo interrupções e falhas globais que impactam todos os clientes. Essa é a realidade dos sistemas complexos.

O estudo Microsoft Operations Framework (MOF) de 2001 (veja como já tem tempo) descobriu que empresas de alto desempenho usavam uma abordagem disciplinada para resolver problemas, empregando telemetria em produção a fim de entender os possíveis fatores contribuintes para focar na solução do problema.

Já em 2015 no state of DevOps Report, tivemos uma “revelação”, neste relatório ficou claro que empresas de alto desempenho podiam resolver incidentes de produção muito mais rápido que seus pares tendo como prática o uso de controle de versão e telemetria junto com monitoramento proativo para conseguirem MTTR rápido

O que é Observabilidade?

Segundo a teoria de controle, a observabilidade é uma medida que descreve quão bem podem os estados de um sistema ser inferidos a partir do conhecimento de suas saídas externas¹. A observabilidade e a controlabilidade são conceitos oriundos da matemática e da engenharia e tratam de criação e manutenção de sistemas.

Com microsserviços, a observabilidade pode ser difícil de alcançar devido à grande complexidade do contexto. Seja em data centers ou na nuvem, para atingir a excelência operacional e atender aos objetivos de negócios, você precisa entender e aprimorar o desempenho dos seus sistemas. As soluções de observabilidade permitem que você colete e analise dados de aplicativos e infraestruturas para que seja possível entender os seus estados internos e ser alertado, solucionar e resolver problemas com disponibilidade e performance de aplicativos para melhorar a experiência do usuário final.

Monitoramento == Observabilidade?

Há uma pequena, porém pertinente, diferença nas palavras monitorar que é um verbo, algo que você faz e observabilidade que é um substantivo, o atributo de um sistema, ou seja, podemos dizer que observabilidade de um sistema é a extensão como que podemos compreender o estado interno desse sistema a partir de suas saídas.

A monitoração, por outro lado, é algo que fazemos. Nós monitoramos o sistema. Nós observamos.

Pilares da observabilidade

Registros (logs)

Um log de evento é um registro imutável com carimbo de data/hora de eventos discretos que aconteceram ao longo do tempo. Os logs de eventos em geral vêm em 3 formas, mas são fundamentalmente os mesmos: um carimbo de data/hora e uma carga útil de algum contexto. As três 3 formas são: Texto, Estruturado e Binário.

Métricas

As métricas são uma representação numérica de dados medidos em intervalos de tempo. Como os números são otimizados para armazenamento, processamento, compactação e recuperação, as métricas permitem uma retenção de dados mais longa, bem como consultas mais fáceis. Isso torna as métricas perfeitamente adequadas para a construção de painéis que refletem tendências históricas.

Rastreamento (tracing)

Um rastreamento (trace ou tracing) é uma representação de uma série de eventos distribuídos, causalmente relacionados, que codificam o fluxo de requisição de ponta a ponta através de um sistema distribuído.

O que precisamos

Agregação de logs

Você deve encarar a implementação de uma ferramenta para agregação de logs como um pré requisito para implementar uma arquitetura de microsserviços
uma abordagem que pode ser útil é utilizar ids de correlação nos logs
Os logs são um modo fácil e incrível de obter informações de seus sistemas, porém, a medida que houver mais microsserviços e mais requisições, você acabará gerando muitos dados.

Agregação de métricas

Assim como o desafio de observar logs de diferentes lugares, precisamos encontrar maneiras melhores de coletar e visualizar dados de nossos sistemas.

Tracing distribuído

Basicamente, uma arquitetura de microsserviços é um conjunto de processos que atuam em colaboração para executar algum tipo de tarefa, então, faz sentido, quando queremos entender como nosso sistema realmente se comporta em um ambiente de produção, que sejamos capazes de ver os relacionamentos entre os nossos microsserviços. Aqui sugiro fortemente o estudo de OpenTelemetry (antigo OpenTracing).

SLAs e SLOs

SLA é um acordo entre as pessoas que criam o sistema e as pessoas que o utilizam.
Os slos definem o que a equipe se compromete a oferecer, logo, atingir o SLO é satisfazer os requisitos de um SLA, de forma simplista podemos pensar nos slos como o que uma equipe precisa fazer para que a empresa atinja seus slas. Você pode se aprofundar um pouco mais nesse assunto aqui.

Alertas

Alertas são problemas. Precisamos notificar alguém para que seja tomada alguma ação. O desafio em um ambiente de microsserviços é descobrir exatamente quais tipos de problemas devem fazer com que uma pessoa seja acordada às três da manhã. Você pode se aprofundar um pouco mais nesse assunto aqui.

Monitoração semântica

Na monitoração semântica definimos um modelo para a semântica aceitável em nosso sistema. Nosso objetivo não é apenas garantir que estamos gerando telemetria em torno da saúde do aplicativo, mas também medir até que ponto estamos atingindo nosso objetivo organizacional. Quais são as propriedades que o sistema deve ter para que achemos que ele está funcionando com médias aceitáveis? Em boa medida, a monitoração semântica exige uma mudança em nosso comportamento. Em vez de verificar a presença de erros, precisamos fazer constantemente a pergunta: o sistema está se comportando do modo como esperamos? Exemplos de perguntas que podem ajudar:

Novos clientes podem se cadastrar?
Estamos despachando pedidos a uma taxa considerada normal?

Um dos maiores desafios é chegar a um consenso acerca de como será esse modelo. Como podemos ver, não estamos falando de algo no baixo nível como "o uso de CPU não deve exceder 95%"; estamos fazendo afirmações de nível alto sobre o nosso sistema. É nessa hora que o dono do produto (product owner) deve entrar em cena - mas talvez seja sua tarefa como operador garantir que a discussão como o dono do produto realmente ocorra.

Possibilitar a criação de métricas como parte do trabalho diário

Você precisa que todos criem métricas facilmente. Para isso, devemos ter a infraestrutura e as bibliotecas necessárias para facilitar o máximo possível alguém de criar telemetria para qualquer funcionalidade. Ao gerar telemetria de produção como parte do trabalho diário, temos cada vez mais capacidade não apenas de ver o problemas quando ocorrem, mas também de projetar nosso trabalho, de modo que problemas em projetos e operações possam ser revelados com antecedência.

Conclusão

Conforme vimos, há muitos aspectos em que devemos pensar. É preciso garantir que será possível usar as informações para fazer perguntas sobre seu sistema. Você é capaz de dizer com confiança que o sistema está funcionando de modo adequado aos seus usuários? Com o tempo será necessário coletar mais informações e aprimorar as ferramentas para melhorar a observabilidade das aplicações.

Sistemas distribuídos podem ser complicados de entender e quando mais distribuídos forem, mais difícil será a tarefa de resolver os problemas que emergem por esta natureza. À medida que sua arquitetura de microsserviço se torna mais complexa, será mais difícil saber como anteceder os problemas que poderiam ocorrer. Desse modo será essencial mudar sua maneira de pensar, afastando-se das atividades que, em sua maior parte, são de monitoração, e avançar em direção a deixar o seu sistema mais observável.

Considere fortemente adotar SLOs e alertas com base nesses preceitos a fim de reduzir a fadiga de alertas e manter sua atenção com um foco apropriado. Assegure-se de investir em telemetria de nível empresarial, de aplicativo, de infra estrutura, de software cliente (frontend), de pipeline de implementação…

Acima de tudo, trata-se de aceitar que nem tudo será conhecido antes de o sistema chegar ao ambiente produtivo. Melhore sua capacidade de lidar com o desconhecido

Referências

[1] https://en.wikipedia.org/wiki/Observability
The Site Reliability Workbook (cap 2)
The DevOps Handbook (cap 14)
Building Microservices: Designing Fine-Grained Systems (cap 10)

Adaptive Throttling — Lidando com sobrecarga

Fabricio_Gonçalves — Tue, 04 Jan 2022 21:55:04 +0000

Um throttle “auto regulado” no lado do client até a leitura do capítulo ‘Handling Overload’ do livro SRE do Google era uma abordagem desconhecida pra mim, então, resolvi fazer alguns testes, durante esse processo descobri que não tinha muito material sobre esse tema e nem uma lib para fazer exatamente o que eu queria, então resolvi escrever esse post.

Client-Side Throttling

Não importa o quão eficiente seja sua política de balanceamento de carga, eventualmente alguma parte do seu sistema ficará sobrecarregada. O tratamento adequado das condições de sobrecarga é fundamental para o funcionamento de um sistema de serviço confiável — SRE-Book

Existem várias maneiras de lidar com sobrecarga, dependendo da parte da aplicação com a qual você está trabalhando, entretanto, achar que algo, ou algum estratégia, será 100% à prova de falhas, um equivoco . Você pode tornar sua infra melhor escalável, pode empregar limite de carga para rejeitar solicitações adicionais que você sabe que não pode lidar imediatamente, customer quotas e etc. Embora todas essas sejam ótimas abordagens para resolver o problema, fazer mais perto do client (na origem) para tentar não repassar o tráfego quando o back-end está tendo dificuldades, será um caminho para melhorar o funcionamento de outras estratégias.

Como aplicar a Client-Side Throttling

Quando um client detecta que uma parte significativa de suas solicitações recentes foi rejeitada, ele começa a se autorregular e limitar a quantidade de tráfego de saída que gera, o que é chamado de Adaptive throttling. A ideia original para a implementação vem do capítulo ‘Handling Overload’ do livro SRE do Google.

O Adaptive throttling é calculado da seguinte forma:

(Por Google)

Porém, de acordo com Rafael Capucho, existe um possível problema com esta abordagem.

Minha preocupação com essa probabilidade é que, se o servidor ficar inativo por mais de 2 minutos, o valor P0 ficará em 1, rejeitando localmente cada nova solicitação ao servidor, de modo que o aplicativo cliente não será capaz de configurar um nova conexão. Como resultado disso, o aplicativo cliente nunca terá outra solicitação chegando ao servidor.
Gostaria de sugerir uma nova medida de probabilidade, P 1 , que limita em 90%… — Rafael Capucho

(Por Rafael Capucho)

Esta foi a abordagem usada na biblioteca adaptive-throttling. Onde você passa sua requisição é ela autorregula os limites de saidá. Segue um exemplo de uso:


const { AdaptiveThrottling } = require('adaptive-throttling');
const axios = require('axios');

const adaptiveThrottling = AdaptiveThrottling();

adaptiveThrottling
  .execute(() => {
    return axios.get('/user?ID=12345');
  })
  .then((response) => {
    console.log('success', response.data);
  })
  .catch((error) => {
    // Se o servidor estiver com dificuldades 
    // erros "The request was throttled." podem ser lançados, nem indo no servidor, ajudado assim a aliviar a sobrecarga.
console.log('error', error.message);
});

Fiz um desenho tentando evidenciar onde o cenário com Adaptive Throttling complementa algumas outras soluções de contorno.

Enfim, como não existe uma solução mágica, considere fundamental garantir que as tarefas individuais sejam protegidas contra sobrecarga e Adaptive throttling vem pra ser mais um ferramenta com esse propósito.

Bônus

Neste mesmo capítulo temos uma parte que aborda quando aplicar retry e como, aproveitando que estava com a mão na massa, fiz uma “extensão”
para a lib influenciado pela parte sobre “per-client retry budget request”, porém, no meu caso, usei a própria probabilidade de rejeitar request, que vimos em Client-Side Throttling, como limitador das retentativas.
(adaptive-throttling-with-retry)

Princípios da jornada de SRE

Fabricio_Gonçalves — Mon, 25 Oct 2021 12:26:31 +0000

O que faz um SRE?

E, de uma forma bem alto nível são somente dois: Medir e Garantir. E para isso existe uma série de princípios que devem ser compreendidos. Além de auxiliar no ciclo de vida do produto.

Principios para SRE

    * Aceitando os riscos

    * Níveis de serviço (SLx)

    * Eliminando Toil

    * Monitoração

    * Automação

    * Engenharia de Release

    * Simplicidade

    * Design de Sistema (Grandes) Não Abstrato (NALSD)

Aceitando os riscos

Aceitar o risco significa estabelecer um nível aceitável de confiabilidade, que pese os custos do que está sendo assumido em relação ao risco. E para aceitar o risco a filosofia de usar error budget precisa estar bem establecida para que funcione.

Níveis de serviço (SLx)

Coração da engenharia de confiabilidade, os SLOs, SLIs e SLAs e Error Budgets. o SLA, a promessa feita para o cliente, é o mínimo disposto em contrato, os SLOs são os objetivos que você quer atingir além desse contrato, e os SLI são os indicadores que você vai utilizar pra acompanhar como estão o andamento desses objetivos.

Eliminando Toil

Reduzir as tarefas repetitivas para gastar energia em coisas urgentes com automação e um meta importante para o SRE. Simplesmente se estamos querendo reduzir nosso TOIL precisamos automatizar coisas, mas com o devido planejamento porque algo automatizado erradamente gera ainda mais pŕobelamas. O objetivo de qualificar algo como TOIL justamente indica para onde o esforço com automação deve ir, ou seja, problemas no fluxo de valor não devem ser, a priori, qualificados como TOIL.

Monitoração

que seu serviço produz as métricas de que você precisa. Alguns padores como 4 golden signals, RED E LEV podem fornecer o template inicial para algumas métricas.

Automação

Automatize tudo que possa ser automatizado, mas certifique-se de garantir, como qualquer outro código, a qualidade/confiabilidade por meio de testes.

Engenharia de Release

Tenha padrões de lançamento. Monitore as estatísticas sobre seus lançamentos. Entenda bem como continuous integration (CI), continuous delivery(CD) e continuous deployment (CD) funcionam de verdade.

Simplicidade

Sistemas simples tendem a ser confiáveis e fáceis de operar, porem, medir a complexidade dos sistemas não será uma tarefa fácil. Saber com quanto tempo alguém leva para fazer mudanças, ou o tempo que alguém leva pra ter uma visão abrangente de alto nível do serviço pode ajudar.

Design de Sistema (Grandes) Não Abstrato (NALSD)

to de manutenção dos sistemas que projetam. Pratique a capacidade de aferir, projetar e avaliar (grandes) sistemas, não deixe nada "abstrato" antes de implementar algo. Deixar de construir um plano de falha para alguma ponta solta pode custar caro, isso não significa implementar, mas sim que evite ser pego de surpresa se algo falhar. Na fase de concepção use perguntas como:

É possível?
Isso é viável?
É resiliente?
Podemos fazer melhor?

Desta forma estaremos mais perto de construir sistemas saudáveis e duradouros.

DEV Community: Fabricio_Gonçalves

REST Não Basta Mais: Por que suas APIs precisam de "Contexto" na era da IA

O gargalo: APIs feitas para humanos, usadas por agentes

O perigo da falta de contexto: O script "destruidor"

A Ideia: O método CONTEXT

Como isso muda o jogo na prática

O futuro é padronizar o contexto

Cursor | AI Infused SDLC - Potencializando o Desenvolvimento com Inteligência Artificial

Cursor | AI Infused SDLC

A Ferramenta Central: Cursor e suas "Rules"

Fase 1: Planning — Planejamento Inteligente

Fase 2: Análise Inteligente de Requisitos

Cenário prático conduzido por um Product Owner:

Fase 3: Design Colaborativo e Prototipação

Como a IA do Cursor contribui:

Fase 4: Codificação Estratégica — A Escalada Controlada

O processo se estrutura em três momentos distintos:

1. Preparação — Elaborando o Guia de Execução

2. Definição — Estabelecendo o Diálogo

3. Execução — Implementação Iterativa e Refinada

Escopo deste Artigo

Desafios e Cuidados Essenciais

Lições Aprendidas na Prática

Conclusão: Rumo a um SDLC Inteligente

Evoluindo a Segurança de Transações em Apps Mobile: Da Senha ao Device Binding

🎯 O Que Vamos Abordar

❌ Tentativa 1: O Básico Inseguro (Meus Tempos de Inocência)

⚠️ Tentativa 2: Melhorando com JWT (Descobrindo Tokens)

Ganhos em relação à tentativa 1:

Ainda assim, há problemas sérios:

🛡️ Tentativa 3: Adicionando Biometria (Achando que Resolvi Tudo)

Melhorias:

Mas, calma... 🤔

🔐 Tentativa 4: Device Binding + Desafio (Agora Sim Ficou Sério!)

O que isso traz de ganho?

Como Funciona:

Ganhos Significativos:

Implementação Prática:

🏆 Tentativa 5: Juntando Tudo (e Mais Um Pouco)

Diferença Entre Tokens (Que Eu Finalmente Entendi):

Fluxo Completo:

Implementação do Token de Autorização:

🔄 Fallbacks e Considerações Práticas

Para Dispositivos Sem Biometria:

🛡️ Os Três Pilares Implementados

1. Autenticação (Quem é?)

2. Autorização (Pode fazer?)

3. Prova de Posse (Está realmente aqui?)

⚡ Resumo dos Benefícios

🚀 Próximos Passos

📚 Referências Técnicas

Segurança Geral

React Native

Golang

💬 Conclusão

💡 Observação Importante

Arquitetura Viva: Moldando Sistemas para Mudanças

Domínio

Entre livros e a realidade do dia a dia

O que vejo por aí

O sistema não é só seu (e nem do seu time)

O papel das libs

Modulos

Por que essa abordagem?

Conclusão

GO — Estrutura de projetos

Primeira referência

Segunda referência

/cmd

/internal

Terceira referência

Resultado

Conclusão

Outras referências

On-Call Cookbook

On-Call Cookbook

Objetivo

Definição e Escopo

Coisas que uma Pessoa de On-Call Deve Fazer

Formas de Organizar o On-Call

A Ideia: O método `CONTEXT`