Matthew Liste, vice-presidente executivo e presidente global de infraestrutura da American Express, considera que uma plataforma tecnológica bem-sucedida não é medida pelo número de seus componentes, mas por sua capacidade de ocultar a complexidade e oferecer uma experiência estável e clara aos desenvolvedores. Liste baseou sua apresentação no QCon San Francisco em mais de 20 anos dedicados à construção de plataformas e infraestruturas para sistemas críticos na Goldman Sachs, JPMorgan Chase e American Express.
As plataformas mencionadas por Liste atendem grandes números de desenvolvedores internos: cerca de 20 mil usuários na American Express e cerca de 60 mil na JPMorgan Chase. Embora a escala seja diferente da dos provedores de serviços em nuvem, ele considera que os mesmos princípios básicos se aplicam a qualquer equipe que construa uma camada da qual outras pessoas dependam.
Uma boa plataforma oculta a complexidade sem ocultar o que acontece
Liste começa definindo a plataforma como um conjunto integrado de tecnologias que constitui a base para construir aplicações sobre ela. Ele a compara aos serviços de abastecimento de água e saneamento: o usuário não pensa na infraestrutura por trás deles enquanto tudo funciona, mas percebe-a imediatamente quando ocorre uma falha.
Por isso, a experiência da plataforma deve ser intuitiva e utilizar componentes compartilhados e intercambiáveis, como bases unificadas de monitoramento, identidade e espaços de nomes. Essa capacidade de composição torna a plataforma mais parecida com blocos de Lego, em vez de um conjunto de serviços separados que só funcionam em conjunto com esforço adicional.
Estabilidade, segurança e escalabilidade não são recursos opcionais
Liste define o que chama de «três pilares»: estabilidade, segurança e escalabilidade. O nível de disponibilidade necessário varia conforme o valor do sistema; os sistemas de autorização de cartões de crédito da American Express operam, segundo sua apresentação, em níveis de até seis noves, enquanto outros sistemas podem tolerar uma quantidade maior de indisponibilidade.
Ele também enfatiza que o sucesso inicial pode ocultar problemas de escalabilidade. Uma plataforma que funciona bem no início pode enfrentar gargalos quando seu uso aumenta, o que afeta diretamente a estabilidade. Por isso, é preciso definir objetivos de nível de serviço (SLOs) com os consumidores e cumpri-los ao longo do tempo, não apenas no dia do lançamento.
Atualização contínua e redução do trabalho sem diferencial
Liste considera manter a plataforma atualizada uma das tarefas mais difíceis e mais sujeitas a adiamentos. O acúmulo de atualizações adiadas pode tornar cara a migração para uma versão mais recente e afetar os clientes. Ele propõe um padrão interno chamado 0114: zero pessoas para a manutenção periódica graças à automação, capacidade de atualizar todos os componentes da frota, conclusão da atualização em menos de um dia e realização de um ciclo de atualização a cada 14 dias ou menos.
Ele também defende não reconstruir aquilo que já está disponível com qualidade suficiente. Em vez de escrever um novo mecanismo PostgreSQL, cita como exemplo a construção de uma camada de controle que execute backups diários em um armazenamento de objetos, que é a parte necessária para atender aos requisitos regulatórios. A ideia é concentrar-se no valor de que a organização precisa, não na tarefa mais interessante do ponto de vista de engenharia.
Decisões claras e uma relação contratual com os consumidores
Os responsáveis pelas plataformas devem ouvir os clientes, mas não executar todos os pedidos. Os recursos são limitados, e manter recursos antigos sem aposentá-los acumula dívida técnica e impede o desenvolvimento do que é mais importante. Por isso, a plataforma deve ter uma posição clara: definir o que oferecerá, o que deixará de oferecer e o que atende à maioria dos usuários.
Isso inclui estabelecer limites formais de responsabilidades por meio de interfaces de programação, acordos de nível de serviço e processos. Não basta que a equipe saiba o que oferece; o consumidor também deve saber o que está sob sua responsabilidade e quais limites a plataforma não ultrapassa. Liste compara as plataformas a componentes com formatos fixos: uma equipe limitada não pode construir um produto personalizado para cada cliente.
Experiência prática: experimente cedo e use a abstração sem ocultar os detalhes
Liste recomenda falhar rápida e repetidamente depois de decidir construir, protegendo os clientes durante a transição. Ele cita experiências iniciais com contêineres Linux e diferentes ferramentas de orquestração que terminaram com a migração para Kubernetes; a experimentação precoce permitiu que a equipe aprendesse antes de esperar pela maturidade de uma única solução.
Por outro lado, as camadas de abstração não devem ocultar o que acontece abaixo delas. É possível oferecer uma interface de usuário, APIs e Infrastructure as Code, como o Terraform, mas deve haver visibilidade e detalhes suficientes para compreender as falhas e ajustar o comportamento quando necessário. Liste conclui enfatizando a construção sobre fontes abertas e padrões abertos, para que a equipe da plataforma se concentre na integração e no valor agregado, em vez de recriar cada camada do zero.
Por que esses princípios são importantes?
O principal valor da abordagem de Liste é transformar a construção de plataformas de um projeto para lançar um conjunto de ferramentas em um compromisso operacional de longo prazo. A plataforma afeta muitas equipes depois de ser adotada e, por isso, a capacidade de atualização, a clareza das responsabilidades e o gerenciamento da aposentadoria tornam-se mais importantes do que adicionar rapidamente um novo recurso. Esses princípios continuam sendo orientações baseadas em experiência prática, não um padrão unificado que garanta o sucesso; o nível de disponibilidade, o alcance da automação e as escolhas de abstração continuam relacionados à natureza do sistema e às necessidades de seus usuários.