Wrangle API Sprawl com uma plataforma resiliente

Se você ainda não ouviu falar muito sobre a expansão de APIs, uma proliferação descontrolada de APIs e serviços, você ouvirá em 2024. De acordo com um relatório recente do F5 Office of the CTO, a expansão de APIs acontece quando as APIs se tornam amplamente distribuídas sem uma estratégia holística que inclua governança e melhores práticas. Com o surgimento de experiências baseadas em IA, veremos o número de APIs explodir ainda mais. Marco Palladino, CTO e cofundador da Kong, escreveu recentemente:

“Quando a IA interage com o mundo, fá-lo com APIs, o que fundamentalmente conduzirá a um aumento exponencial no número de APIs, à medida que mais e mais produtos e serviços desejam permitir-se serem consumidos pela IA.”

Se não for controlado, este aumento exponencial nas APIs criadas conduzirá inevitavelmente a uma forma perigosa de dívida técnica. Estamos todos acostumados a comprar e pagar dívidas de tecnologia. Afinal, é como qualquer outra forma de dívida: tentamos assumi-la por um motivo específico. Talvez precisemos de cumprir um prazo determinado pelo mercado ou tenhamos uma interrupção surpresa que precisamos de resolver, mas por uma razão ou outra, não conseguimos pagar essa dívida tecnológica durante alguns meses ou mesmo anos.

A expansão da API é uma forma perigosa de dívida técnica. Ela acarreta custos elevados com a hospedagem e o dimensionamento de uma frota de APIs, riscos reais de segurança e uma carga operacional maior devido ao grande número de APIs que as equipes de engenharia de plataforma precisam gerenciar. No entanto, em sua essência, a expansão da API é resultado de uma plataforma que não é resiliente.

Como saber se você tem uma plataforma de API resiliente? Aqui está um teste fácil. Se alguém se aproximasse de você amanhã e perguntasse o que seria necessário para oferecer suporte a uma nova experiência do cliente, você sentiria um aperto no estômago? Sua mente correria imediatamente para todas as dependências upstream, os melhores amigos que sua equipe já gerencia ou o processo de implantação de um novo conjunto de APIs? Nesse caso, sua plataforma API pode não ser resiliente.

Características de resiliência

Ao definir as características de uma estratégia de API resiliente, podemos abordar o problema da perspectiva da pressão sob a qual planejamos colocar nossa plataforma e então agrupá-los por atributos semelhantes. Por exemplo:

1. Como as equipes do cliente podem ser informadas sobre mudanças nas APIs?
2. Como as equipes do lado do servidor colaborarão com as equipes do lado do cliente?
3. Como podemos oferecer suporte e gerenciar diferentes tipos de APIs simultaneamente?
4. Como evitaremos alterações significativas acidentais quando uma dependência do servidor for alterada?
5. Como podemos adicionar novos clientes de apresentação sem implantar uma nova API de experiência?
6. Como podemos usar nossas APIs com mais eficiência?
7. Como podemos compreender completamente os dados em nosso sistema e quem os utiliza?
8. Como podemos aplicar uma abordagem baseada em princípios aos serviços que implantamos?

Tomados em conjunto, podemos agrupar estes atributos em quatro características principais que contribuem para a resiliência das nossas plataformas API: autoatendimento rápido, camadas isolantes, ampliação dos investimentos existentes e governança forte. Projetar e construir nossas plataformas de API com essas características é uma forma estratégica de gerenciar a expansão de APIs que já enfrentamos e evitá-la antes que piore.

Autoatendimento rápido

Construímos APIs com um propósito: serem usadas. Quando questionados sobre como definem o sucesso de sua plataforma, 58% dos entrevistados no relatório sobre o estado das APIs de 2023 disseram que mediram o sucesso pelo uso. Com a pressão para aumentar quem usa nossas APIs no centro de nossas estratégias de plataforma, precisamos de maneiras de tornar nossas APIs simples de serem descobertas e implementadas.

Quanto mais fácil for para as equipes de front-end e de produto descobrirem os serviços disponíveis por conta própria, mais rápido elas poderão projetar e entregar novas experiências e melhor poderão fazer perguntas informadas sobre possíveis lacunas na funcionalidade.

Camadas Isolantes

Nada que enviamos é perfeito na primeira vez. Mesmo que esteja próximo, a tecnologia, as equipes e os negócios que o cercam mudam e evoluem perpetuamente. Seja planejando uma nova experiência de apresentação, mapeando uma atualização de versão principal de um sistema de registro subjacente ou respondendo a um incidente de vulnerabilidades e exposições comuns (CVE), precisamos de uma maneira de planejar turbulências em diferentes camadas de nossa pilha e elaborar uma estratégia para acomodar mudanças sem atrapalhar outras equipes.

Com a iminência de atualizações em nossos serviços e experiências de apresentação, podemos criar uma estratégia para mitigar os riscos dessas migrações técnicas, buscando uma camada isolante que combine os benefícios do acoplamento flexível com contratos flexíveis.

Amplie os investimentos existentes

APIs são um investimento e um compromisso. Além do custo inicial para projetar e desenvolver um serviço, há anos de manutenção, atualizações e o aprisionamento interno de muitas equipes que possuem contratos de produção com qualquer serviço. Devemos encontrar formas de tornar ainda mais valiosos os nossos investimentos existentes nos serviços e APIs que já temos. Jogar fora o que já temos em favor de uma reescrita simplesmente não é prático.

Seja encontrando novas experiências de front-end para implementar os serviços que temos hoje ou identificando áreas de nível de serviço para reutilização, considerar maneiras de ampliar nossos investimentos existentes é uma característica crucial de uma estratégia de API resiliente.

Governança Forte

Ao considerar a governação das nossas plataformas API, podemos dividir a discussão em duas áreas principais de preocupação: governação de dados e governação de serviços. A governança de dados preocupa-se em responder perguntas como: “Quem tem acesso às PII?” e “Quais experiências estão implementando o serviço ‘Usuários’?” Por outro lado, a governança de serviços responde a perguntas como: “Qual é a nossa política para controlar a expansão de APIs?” e “Qual é o nosso processo para identificar e mitigar APIs Zombie?”

Qualquer estratégia de API que implementemos deve considerar a governança de dados e serviços necessária para garantir o futuro de nossas APIs sem comprometer a disponibilidade, a velocidade e a confiabilidade.

Projetando uma estratégia de API resiliente

Tal como acontece com a maioria das decisões arquitetônicas, não existe uma maneira única de projetar uma estratégia para nossas APIs que equilibre perfeitamente flexibilidade e estabilidade. No passado, tentamos gerenciar essa complexidade com táticas como orquestração do lado do cliente ou backends para frontends (BFFs). Infelizmente, isso levou à expansão das APIs que vemos hoje, sobrecarregando as equipes com um peso operacional que só ameaça crescer.

Essa expansão de APIs, sejam elas BFFs, APIs de experiência ou microsserviços personalizados, é um sintoma de uma plataforma rígida que não consegue suportar de forma sustentável novas solicitações das equipes de negócios ou de clientes. Na busca por plataformas API mais resilientes que possam expandir e contrair de forma sustentável, organizações em todo o mundo, incluindo Wayfair, Volvo e Netflix, estão recorrendo ao GraphQL. As equipes dessas organizações reconheceram que GraphQL é mais do que apenas mais uma API. Com os avanços nos padrões de arquitetura, como o GraphQL federado, é uma forma de codificar uma camada intermediária em suas pilhas de tecnologia entre as camadas de apresentação e de serviço que pode impulsionar a resiliência.

O GraphQL federado permite que as equipes forneçam os benefícios do GraphQL em maior escala, transformando o GraphQL de apenas mais uma API em uma camada em uma pilha que fica sobre os serviços existentes. Este gráfico de gráficos fornece acesso a qualquer número de serviços com um único terminal. Também permite que as equipes compartilhem entidades e modelos de domínio entre esses subgráficos.

Em vez de expor uma expansão de backends-para-frontends (BFFs) ou APIs de experiência, o GraphQL federado oferece às equipes de serviço uma plataforma central para contribuir com quaisquer serviços para o gráfico, impulsionando a resiliência da API e um caminho claro para gerenciar a expansão da API.

A postagem Wrangle API Sprawl com uma plataforma resiliente apareceu pela primeira vez em The New Stack.