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

Platform Engineering - Lessons Learned

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/

Fernando ike

March 27, 2023
Tweet

More Decks by Fernando ike

Other Decks in Technology

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