Platform Engineering - Lessons Learned

Apresentação para o evento Platform Engineering Days São Paulo sobre algumas lições aprendidas de construir e implementar plataformas nos últimos anos.

https://www.linkedin.com/events/7043629247650770944/comments/

Transcript

1. Platform Engineering
   Lessons Learned
   Platform Days Sao Paulo - 2023
   

   View Slide

2. Fernando Ike
   // linkedin.com/in/fernandoike
   // hachyderm.io/@fernandoike
   // pontocafe.fernandoike.com
   

   View Slide

3. O que são Plataformas?
   ●
   Plataformas?
   

   View Slide

4. 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
   

   View Slide

5. 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/
   

   View Slide

6. “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."
   

   View Slide

7. 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”
   

   View Slide

8. View Slide

9. 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
   

   View Slide

10. 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
    

    View Slide

11. 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.
    

    View Slide

12. 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)
    

    View Slide

13. https://xkcd.com/2347/
    

    View Slide

14. 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
    

    View Slide

15. https://www.latimes.com/archives/la-xpm-1999-oct-01-mn-17288-story.html
    

    View Slide

16. 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
    

    View Slide

17. Feedbacks
    

    View Slide

18. 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 > NPS
    

    View Slide

19. Ciclo de desenvolvimento da plataforma
    Etapas de desenvolvimento definida
    Política de Deploy
    Semantic Version
    WIP Limit
    Classe de Serviço (SLAs)
    

    View Slide

20. View Slide

21. View Slide

22. Cumulative Flow Diagram
    

    View Slide

23. 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.
    

    View Slide

24. Platform as Product/Product
    Um Technical Product Manager pode acelerar
    adoção e valor
    Migrações de funcionalidades pouco "maduras"
    exigem um custo de coordenação alto (considerar
    um Technical Project Management)
    Evite concorrência de adoção ou migração de
    funcionalidades (Death March) de pouca ou
    nenhuma abstração
    

    View Slide

25. Indicadores
    % de uso
    % de aderência aos padrões
    % Champions/Ambassadors
    % de suporte
    % novas funcionalidades
    DORA Metrics (Capabilities Metrics)
    SPACE Framework
    

    View Slide

26. 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
    

    View Slide

27. Fernando Ike
    // linkedin.com/in/fernandoike
    // hachyderm.io/@fernandoike
    // pontocafe.fernandoike.com
    

    View Slide