Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Platform Engineering - Lessons Learned - Cloud Native Experience 2024

Platform Engineering - Lessons Learned - Cloud Native Experience 2024

Apresentação sobre algumas lições aprendidas na construção de plataformas internas.

Fernando ike

May 21, 2024
Tweet

More Decks by Fernando ike

Other Decks in Technology

Transcript

  1. Plataformas “... é uma fundação de APIs, ferramentas, serviços, conhecimento

    e suporte de forma self-service no qual eles são organizados como um produto interno atrativo. Equipes autônomas podem usar a plataforma para entregar as funcionalidades em ritmo acelerado e com redução da coordenação” Evan Bottcher - https://martinfowler.com/articles/talk-about-platforms.html
  2. Plataformas “Platform Engineering é uma disciplina que envolve o que

    seja necessário para construir, manter e fornecer uma experiência de plataforma com uma curadoria para toda comunidade que está usando” Nikki Watt - https://www.infoq.com/articles/platform-engineering-as-community-service/
  3. Trusted Advisor • Serem “guardiões” dos conceitos, práticas e aplicados

    pelas equipes • Ser guardião é não ser dono mas “governar” • Capacitação dos usuários ◦ Treinamentos ◦ Workshops ◦ Office-Hours ◦ Documentação
  4. Trusted Advisor • Suporte (Dê atenção aos seus usuários): ◦

    Nāo despreze perguntas de recorrentes ◦ Muito suporte ocorrendo pode significar falta de conhecimento do(s) usuário(s) ◦ Muito suporte pode ser baixa qualidade ou pouca abstração ◦ Uma boa UX/UI diminui a carga cognitiva • Ser a referência em Engenharia de Software da organização
  5. “Usuários não precisam saber (se não quiserem) o que está

    relacionado ao(s) conceito(s), técnicas e regras (guard-rails) para usar a plataforma. Devem saber quais são as regras básicas de uso e sentir que agrega valor ao que ele precisa fazer."
  6. Usuários da(s) “plataforma(s)” Não precisam saber tudo da(s) plataforma(s) que

    utilizam Irão querer saber o necessário (para eles) Quando desenvolver funcionalidades é “caro”, priorize entregas de curto prazo que impactem o longo prazo (Network Effect) Saber quem são seus usuários e como se comportam é mais importante do que acreditar que está fazendo “a coisa certa” Seus usuários não são “idiotas”
  7. Uma boa fundação da(s) plataforma(s) construída, potencialmente, pode aumentar a

    produtividade, resiliência e segurança de forma exponencial ao longo dos anos.
  8. Foundation • Curadoria ou influência em frameworks de linguagens de

    programação • Um framework de decisão arquitetural • SDKs, Libs, integrações e templates para os principais frameworks da organização • Microservice chassis specification • Domain-Driven Design (responsabilidades e limites claros) • Modular (Building Blocks)
  9. Foundation Uma decisão ruim de arquitetura, integração, interface, tecnológica pode

    ter impacto de anos na produtividade das pessoas, novas funcionalidades e competitividade
  10. Contratos Fortes • JSON, Protobuf, YAML, CLI, UI… • SDKs,

    bibliotecas, wrappers, scaffolders, templates… • Logs, Métricas e Traces • Recursos computacionais ◦ Instance Types ◦ CPUs, Memory, Disk ◦ Databases Types ◦ Guard-rails • SLAs
  11. Guard-Rails das Plataformas São mecanismo, processos de contenção, mitigação e

    proteção das plataformas para evitar uso inadequado pelos workloads e usuários, mantendo uma boa experiência, atendendo o regulatório e eficiência operacional, como também financeira.
  12. Comparação antes e depois - Área de Escape Revista de

    Engenharia e Pesquisa Aplicada, v., n. 1, p. 1-10, 2022 - Análise comparativa do aumento na segurança dos usuários da rodovia BR-376/PR com a implantação das áreas de escape
  13. Feedback dos "usuários" Feedbacks rápidos ou pontuais (IDP, PR/MR, Slack,

    Teams, IRC…) Feedbacks quantitativos, vide formulários (Chats, Mailist, etc.) Feedbacks qualitativos (Entrevistas) Quantidade de bugs reportados ou suporte Fit for Purpose, CSAT, NPS…
  14. Ciclo de desenvolvimento da plataforma Etapas de desenvolvimento definida Política

    de Deploy Semantic Version WIP Limit Classe de Serviço (SLAs)
  15. Engineering stuff Refactoring > substituição de projeto/serviço Excelência em desenvolvimento,

    operações, segurança Tenha testes de regressão Tenha testes de integração SBOM, SAST, WAF, etc.
  16. Platform as Product/Product Um Technical Product Manager acelera adoção e

    valor Migrações de funcionalidades pouco "maduras" exigem um custo de coordenação alto demanda papel dedicado de Technical Project Management Evite concorrência de adoção ou migração de funcionalidades (Death March) de pouca ou nenhuma abstração Communicação (as)síncrona com stakeholders, usuários, entusiastas e toda comunidade tech
  17. Indicadores % de uso % de aderência aos padrões %

    Champions/Ambassadors % de suporte % novas funcionalidades DORA Metrics (Capabilities Metrics) SPACE Framework
  18. Eficiência “Econômica” Custo da(s) plataforma(s) por mil/milhão de transações %

    da(s) plataforma(s) no CAPEX/OPEX em Tecnologia Impacto financeiro da(s) plataforma(s) num incidente Platform(s) com seu próprio “unit economic”
  19. Referências DORA Research Program Domain-Driven Design Distilled Continuous Delivery Kanban

    DevOps Capabilities Conway Law The Goal PixBay CNCF Landscape XKCD Platform Revolution Fit for Purpose Death March Platform Engineering Maturity