A governança adaptativa dá aos desenvolvedores de APIs a autonomia de que precisam

NGINX | 10 de novembro de 2022

As empresas atuais geralmente são formadas por equipes distribuídas globalmente, que desenvolvem e implantam APIs e microsserviços, normalmente em mais de um ambiente de implantação. De acordo com o Relatório sobre o Estado da Estratégia de Aplicações da F5, 81% das organizações operam em três ou mais ambientes, incluindo nuvem pública, nuvem privada, infraestrutura local e edge.

Garantir a confiabilidade e a segurança dessas arquiteturas complexas de múltiplas nuvens é um grande desafio para as equipes de Operações de Plataforma responsáveis por sua manutenção. Segundo os líderes de engenharia de software entrevistados no relatório da F5, a visibilidade (45%) e a segurança consistente (44%) estão no topo da lista de desafios de múltiplas nuvens enfrentados pelas equipes de Operações de Plataforma.

Com o crescente número de APIs e microsserviços atualmente, a governança de APIs está rapidamente se tornando um dos temas mais importantes para o planejamento e a implementação de uma estratégia de APIs em toda a empresa. Mas o que é governança de APIs e por que ela é tão importante para a sua estratégia de APIs?

O que é governança de APIs?

Em termos mais básicos, a governança de APIs envolve a criação de políticas e a execução de verificações e validações para garantir que as APIs sejam fáceis de encontrar, confiáveis, observáveis e seguras. Ela proporciona visibilidade sobre o estado dos sistemas complexos e dos processos de negócios que sustentam suas aplicações modernas, permitindo orientar a evolução da sua infraestrutura de APIs ao longo do tempo.

Por que você precisa de governança de APIs?

A importância estratégica da governança de APIs não pode ser subestimada: é por meio dela que você concretiza a estratégia geral de APIs da sua organização. Sem uma governança adequada, não é possível garantir a consistência no design, na operação e na transformação das suas APIs em produtos.

Quando mal implementada, a governança costuma impor requisitos onerosos que tornam as equipes mais lentas. Quando bem implementada, porém, a governança de APIs reduz o trabalho, agiliza as aprovações e permite que diferentes equipes da sua organização atuem de forma independente, ao mesmo tempo que contribuem para os objetivos gerais da sua estratégia de APIs.

Quais tipos de APIs você precisa governar?

A criação de um plano eficaz de governança de APIs como parte da sua estratégia de APIs começa pela identificação dos tipos de APIs que você tem em produção e das ferramentas, políticas e diretrizes necessárias para gerenciá-las. Atualmente, a maioria das equipes corporativas trabalha com quatro tipos principais de APIs:

  • APIs externas – Disponibilizadas a consumidores e desenvolvedores externos para permitir integrações de autoatendimento com dados e funcionalidades
  • APIs internas – Usadas para conectar aplicações internas e microsserviços e disponíveis apenas para os desenvolvedores da sua organização
  • APIs de parceiros – Facilitam relacionamentos comerciais estratégicos ao compartilhar o acesso aos seus dados ou aplicativos com desenvolvedores de organizações parceiras
  • APIs de terceiros – Consumidas como serviço de fornecedores terceirizados, geralmente para processar pagamentos ou permitir o acesso a dados ou aplicações

Cada tipo de API na empresa deve ser gerenciado para garantir que seja seguro, confiável e acessível às equipes e aos usuários que precisam utilizá-lo.

Quais modelos de governança de APIs você pode usar?

Há muitas maneiras de definir e aplicar a governança de APIs. Na NGINX, normalmente vemos os clientes adotarem um destes dois modelos:

  • Centralizado – Uma equipe central analisa e aprova as alterações; dependendo da escala das operações, essa equipe pode se tornar um gargalo que retarda o progresso
  • Descentralizado – As equipes individuais têm autonomia para criar e gerenciar APIs; isso reduz o tempo de lançamento no mercado, mas compromete a segurança e a confiabilidade gerais

No entanto, à medida que as empresas avançam em suas jornadas API-first, ambos os modelos começam a apresentar problemas conforme aumenta o número de APIs em produção. Os modelos centralizados geralmente tentam implementar uma abordagem única para todos, que exige várias revisões e aprovações ao longo do processo. Isso reduz a velocidade das equipes de desenvolvimento e gera atritos — frustrados, os desenvolvedores às vezes chegam a encontrar maneiras de contornar os requisitos (a temida “TI invisível”).

O outro modelo — a governança descentralizada — funciona bem para os desenvolvedores de APIs no início, mas, com o tempo, a complexidade aumenta. A menos que as diferentes equipes responsáveis pela implantação das APIs se comuniquem com frequência, a experiência geral se torna inconsistente entre as APIs: cada uma é projetada e funciona de maneira diferente, as mudanças de versão causam interrupções entre os serviços e a segurança é aplicada de forma inconsistente entre equipes e serviços. Para as equipes que desenvolvem APIs, o trabalho e a complexidade adicionais acabam reduzindo o ritmo de desenvolvimento a quase zero, assim como no modelo centralizado.

Os aplicativos nativos da nuvem dependem de APIs para que os diferentes microsserviços se comuniquem entre si e enviem respostas de volta à origem da solicitação. À medida que as empresas continuam adotando microsserviços por sua flexibilidade e agilidade, a proliferação de APIs não vai desaparecer. Em vez disso, é preciso adotar uma abordagem diferente para a governança de APIs nesses ambientes complexos e em constante mudança.

Use a governança adaptativa para capacitar os desenvolvedores de APIs

Felizmente, há uma maneira melhor. A governança adaptativa oferece um modelo alternativo que dá autonomia aos desenvolvedores de APIs e, ao mesmo tempo, proporciona às equipes de Operações de Plataforma o controle necessário para garantir a confiabilidade e a segurança das APIs em toda a empresa.

No cerne da governança adaptativa está o equilíbrio entre controle (a necessidade de consistência) e autonomia (a capacidade de tomar decisões locais), a fim de promover a agilidade em toda a empresa. Na prática, o modelo de governança adaptativa descentraliza e distribui a tomada de decisões entre as equipes.

As equipes de Operações de Plataforma gerenciam a infraestrutura compartilhada (gateways de API e portais de desenvolvedores) e definem políticas globais para garantir a consistência entre as APIs. No entanto, as equipes que desenvolvem APIs atuam como especialistas no assunto para seus serviços ou linhas de negócios. Elas têm autonomia para definir e aplicar políticas locais às suas APIs — controle de acesso baseado em função (RBAC), limitação de taxa para seus serviços etc. — a fim de atender aos requisitos de seus contextos de negócios específicos.

A governança adaptativa permite que cada equipe ou linha de negócios defina seus fluxos de trabalho e equilibre o nível de controle necessário, ao mesmo tempo que utiliza a infraestrutura compartilhada da organização.

Implemente a governança adaptativa para suas APIs com o NGINX

Ao começar a planejar e implementar sua estratégia de APIs, siga estas práticas recomendadas para implementar uma governança adaptativa em sua organização:

Vamos ver como você pode implementar esses casos de uso com o API Connectivity Manager, parte do F5 NGINX Management Suite.

Forneça uma infraestrutura compartilhada

As equipes de toda a sua organização estão criando APIs e precisam incluir funcionalidades semelhantes em seus microsserviços: autenticação e autorização, criptografia mTLS e muito mais. Elas também precisam disponibilizar documentação e controle de versões aos consumidores de suas APIs, sejam eles equipes internas, parceiros de negócios ou desenvolvedores externos.

Em vez de exigir que as equipes criem suas próprias soluções, as equipes de Operações de Plataforma podem fornecer acesso à infraestrutura compartilhada. Assim como ocorre com todas as ações no API Connectivity Manager, você pode configurar isso em apenas alguns minutos usando a interface do usuário ou a API REST totalmente declarativa, que permite integrar o API Connectivity Manager aos seus pipelines de CI/CD. Neste artigo, usamos a interface do usuário para ilustrar alguns fluxos de trabalho comuns.

O API Connectivity Manager oferece suporte a dois tipos de Workspaces: infraestrutura e serviços. Os Workspaces de infraestrutura são usados pelas equipes de Operações de Plataforma para integrar e gerenciar a infraestrutura compartilhada na forma de Clusters de Gateway de API e Clusters de Portal do Desenvolvedor. Os Workspaces de serviços são usados por desenvolvedores de APIs para publicar e gerenciar APIs e documentação.

Para configurar a infraestrutura compartilhada, primeiro adicione um Workspace de infraestrutura. Clique em Infraestrutura na coluna de navegação à esquerda e, em seguida, no botão + Adicionar, no canto superior direito da guia. Dê um nome ao seu Workspace (neste exemplo, team-sentence — uma equipe fictícia que está criando uma API simples de “Olá, mundo!”).

Figura 1: Adicionar workspaces de infraestrutura

Em seguida, adicione um Ambiente ao Espaço de Trabalho. Os Ambientes contêm Clusters do API Gateway e Clusters do Portal do Desenvolvedor. Clique no nome do seu Espaço de Trabalho e, depois, no ícone … na coluna Ações; selecione Adicionar no menu suspenso.

O painel Criar ambiente é aberto conforme mostrado na Figura 2. Preencha o campo Nome (e, opcionalmente, Descrição), selecione o tipo de ambiente (produção ou não produção) e clique no botão + Adicionar da infraestrutura que deseja adicionar (clusters do API Gateway, clusters do Portal do Desenvolvedor ou ambos). Clique no botão Criar para concluir a configuração do ambiente. Para obter instruções completas, consulte a documentação do API Connectivity Manager.

Figura 2: Criar um ambiente e integrar a infraestrutura

Dê autonomia às equipes

Faz sentido separar logicamente as equipes por linha de negócios, região geográfica ou outro limite lógico, desde que isso não as prive do acesso às ferramentas necessárias para alcançar o sucesso. O acesso à infraestrutura compartilhada não deve fazer com que as equipes tenham de se preocupar com atividades em nível global. Em vez disso, o ideal é que elas se concentrem em definir seus próprios requisitos, traçar um roteiro e desenvolver seus microsserviços.

Para ajudar as equipes a se organizarem, as equipes de Operações de Plataforma podem disponibilizar Workspaces de serviços para que elas organizem e operem seus serviços e sua documentação. Esses Workspaces criam limites lógicos e fornecem acesso a diferentes ambientes — desenvolvimento, teste e produção, por exemplo — para o desenvolvimento de serviços. O processo é semelhante à criação do Workspace de infraestrutura que fizemos na seção anterior.

Primeiro, clique em Serviços na coluna de navegação à esquerda e, em seguida, no botão + Adicionar, no canto superior direito da guia. Dê um nome ao seu Workspace (neste caso, api-sentence para o nosso serviço “Olá, mundo”) e, opcionalmente, forneça uma descrição e informações de contato.

Figura 3: Criar um Workspace de serviços

Neste ponto, você pode convidar os desenvolvedores de API para começar a publicar proxies e documentação no Workspace que você criou para eles. Para obter instruções completas sobre como publicar proxies e documentação de API, consulte a documentação do API Connectivity Manager.

Equilibre políticas globais e controle local

A governança adaptativa exige um equilíbrio entre a aplicação de políticas globais e a autonomia das equipes para tomar decisões que aumentem a agilidade. É necessário estabelecer uma separação clara de responsabilidades, definindo as configurações globais aplicadas pela equipe de Operações de Plataforma e estabelecendo “limites de segurança” que determinem as ferramentas usadas pelos desenvolvedores de APIs e as decisões que eles podem tomar.

O API Connectivity Manager oferece uma combinação de políticas globais (aplicadas à infraestrutura compartilhada) e controles granulares gerenciados no nível do proxy de API.

As políticas globais disponíveis no API Connectivity Manager incluem:

  • Formato da resposta de erro – Personalize o código de erro e a estrutura da resposta do gateway de API
  • Formato do log – Habilite o registro de acesso e personalize o formato das entradas de log
  • OpenID Connect – Proteja o acesso às APIs com uma política do OpenID Connect
  • Cabeçalhos de resposta – Inclua ou exclua cabeçalhos na resposta
  • Tamanho do corpo da solicitação – Limite o tamanho dos payloads de API recebidos
  • TLS de entrada – Defina a política para conexões TLS com clientes de API
  • TLS de backend – Proteja a conexão com os serviços de backend usando TLS

As políticas de proxy de API disponíveis no API Connectivity Manager incluem:

  • Métodos HTTP permitidos – Defina quais métodos de solicitação podem ser usados (GET, POST, PUT, etc.)
  • Controle de acesso – Proteja o acesso às APIs usando diferentes técnicas de autenticação e autorização (chaves de API, autenticação HTTP Basic, JSON Web Tokens)
  • Verificações de integridade do backend – Execute verificações contínuas de integridade para evitar falhas nas solicitações aos serviços de backend
  • CORS – Permita o acesso controlado a recursos por clientes de domínios externos
  • Cache – Melhore o desempenho do proxy de API com políticas de cache
  • Cabeçalhos de solicitação do proxy – Encaminhe cabeçalhos selecionados aos serviços de backend
  • Limitação de taxa – Limite as solicitações recebidas e proteja as cargas de trabalho de API

No exemplo a seguir, usamos a interface do usuário para definir uma política que protege a comunicação entre um proxy de gateway de API e os serviços de back-end.

Clique em Infraestrutura na coluna de navegação à esquerda. Depois que você clicar no nome do Ambiente que contém o Cluster do API Gateway que deseja editar, a guia exibirá os Clusters do API Gateway e os Clusters do Portal do Desenvolvedor desse Ambiente.

Figura 4: Configurar políticas globais para clusters do API Gateway e clusters do Portal do Desenvolvedor

Na linha do Cluster do API Gateway ao qual você deseja aplicar uma política, clique no ícone … na coluna Ações e selecione Editar configuração avançada no menu suspenso. Clique em Políticas globais na coluna à esquerda para exibir uma lista de todas as políticas globais que você pode configurar.

Figura 5: Configurar políticas para um cluster do API Gateway

Para aplicar a política de TLS de backend, clique no ícone … à direita da linha correspondente e selecione Adicionar política no menu suspenso. Preencha as informações solicitadas, carregue seu certificado e clique em Adicionar. Em seguida, clique no botão Salvar e enviar. A partir de agora, o tráfego entre o cluster do API Gateway e os serviços de backend estará protegido por TLS. Para obter instruções completas, consulte a documentação do API Connectivity Manager.

Resumo

Planejar e implementar a governança de APIs é uma etapa crucial para garantir o sucesso da sua estratégia de APIs. Ao adotar um modelo distribuído e contar com uma governança adaptativa para atender aos requisitos específicos de diferentes equipes e APIs, você pode ampliar e aplicar uma governança uniforme sem comprometer a velocidade e a agilidade que tornam as APIs e os ambientes nativos da nuvem tão produtivos.

Comece agora

Inicie uma avaliação gratuita de 30 dias do NGINX Management Suite, que inclui acesso ao API Connectivity Manager, ao NGINX Plus como gateway de API e ao NGINX App Protect para proteger suas APIs.


Compartilhar

Publicações relacionadas no blog

Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
NGINX | 10/10/2024

Como o F5 NGINX One aprimora o gerenciamento e a observabilidade

Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.

Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
NGINX | 17/06/2024

Do OpenAPI ao NGINX como gateway de API usando uma API declarativa

Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.

Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
NGINX | 14/07/2021

Como gerenciar picos repentinos de tráfego e sobrecarga do servidor

Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.

Distribuição segura de chaves privadas SSL com o NGINX
NGINX | 02/04/2019

Distribuição segura de chaves privadas SSL com o NGINX

Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.

Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
NGINX | 24/05/2018

Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX

O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.

Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
NGINX | 19/04/2016

Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus

Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.