O API Connectivity Manager ajuda as equipes de desenvolvimento e operações a trabalharem melhor juntas

NGINX | 03 de novembro de 2022

As aplicações nativas da nuvem são compostas por dezenas, centenas ou até milhares de APIs que conectam microsserviços entre si. Em conjunto, esses serviços e APIs proporcionam a resiliência, a escalabilidade e a flexibilidade que estão no cerne das aplicações nativas da nuvem.

Atualmente, essas APIs e esses microsserviços subjacentes costumam ser desenvolvidos por equipes distribuídas globalmente, que precisam operar com certo grau de autonomia e independência para disponibilizar recursos no mercado em tempo hábil.

Ao mesmo tempo, Operações de Plataforma são responsáveis por garantir a confiabilidade e a segurança gerais dos aplicativos e da infraestrutura da empresa, incluindo as APIs subjacentes. Essas equipes precisam ter visibilidade do tráfego das APIs e a capacidade de definir diretrizes globais para garantir segurança e conformidade uniformes, sem deixar de oferecer uma excelente experiência para desenvolvedores de APIs.

Embora os interesses desses dois grupos possam entrar em conflito, não acreditamos que isso seja inevitável. Desenvolvemos o API Connectivity Manager como parte do F5 NGINX Management Suite para permitir que as equipes de Platform Ops mantenham tudo seguro e funcionando sem problemas e, ao mesmo tempo, que os desenvolvedores de APIs criem e lancem novos recursos com facilidade.

Criando uma arquitetura para oferecer suporte à conectividade de APIs

Como um plano de gerenciamento de última geração, o API Connectivity Manager foi desenvolvido para aproveitar e ampliar o potencial do NGINX Plus como gateway de API. Se você já usou o NGINX, conhece sua escalabilidade, confiabilidade, flexibilidade e seu desempenho como gateway de API.

Ao projetarmos o API Connectivity Manager, desenvolvemos uma nova arquitetura para permitir uma melhor colaboração entre as equipes de Operações de Plataforma e os desenvolvedores. Ela usa os seguintes termos padrão do setor para seus componentes (alguns dos quais diferem dos nomes conhecidos por usuários experientes do NGINX):

  • Espaço de trabalho – Uma coleção isolada de infraestrutura destinada ao gerenciamento e uso exclusivos por uma única unidade de negócios ou equipe; geralmente inclui vários Ambientes
  • Ambiente – Uma coleção lógica de instâncias (clusters) do NGINX Plus que atuam como gateways de API ou portais de desenvolvedores em uma fase específica do ciclo de vida da aplicação, como desenvolvimento, teste ou produção
  • Cluster de Proxy do Gateway de API – Uma representação lógica do gateway de API do NGINX que agrupa instâncias do NGINX Plus e sincroniza o estado entre elas
  • Proxy de API – Uma representação de uma instância publicada de uma API que inclui roteamento, controle de versão e outras políticas
  • Políticas – Uma abstração global ou local para definir funções específicas do proxy de API, como resiliência de tráfego, segurança ou qualidade de serviço

O diagrama a seguir ilustra como os componentes são aninhados em um Workspace:

Diagrama dos objetos administrativos aninhados do API Connectivity Manager. Do mais externo para o mais interno: Espaço de trabalho, Ambiente, Cluster de proxies do API Gateway, Proxy de API, Políticas.

Essa hierarquia lógica viabiliza diversos casos de uso importantes que oferecem suporte à conectividade de APIs em toda a empresa. Por exemplo, os Workspaces podem incorporar vários tipos de infraestrutura (como nuvem pública e infraestrutura local), permitindo que as equipes acessem ambas e que os responsáveis pela infraestrutura tenham visibilidade do tráfego de APIs nos dois ambientes.

Analisaremos os componentes arquiteturais com mais detalhes em publicações futuras. Por enquanto, vamos ver como o API Connectivity Manager atende aos diferentes perfis que contribuem para o desenvolvimento e a entrega de APIs.

API Connectivity Manager para Operações de Plataforma

A equipe de Operações de Plataforma é responsável por criar e gerenciar o ciclo de vida da infraestrutura de cada organização. Ela fornece a plataforma na qual os desenvolvedores criam aplicações e serviços que atendem clientes e parceiros. As equipes de desenvolvimento costumam ser descentralizadas, trabalhando em vários ambientes e respondendo a diferentes linhas de negócios. Atender às necessidades desses grupos e ambientes dispersos e, ao mesmo tempo, manter padrões em toda a empresa é um dos maiores desafios enfrentados atualmente pelas equipes de Operações de Plataforma.

O API Connectivity Manager oferece maneiras inovadoras de separar as equipes e suas operações usando Workspaces como um limite lógico. Ele também permite que as equipes de Operações de Plataforma gerenciem o ciclo de vida da infraestrutura sem interferir nas equipes que criam e implantam APIs. O API Connectivity Manager inclui um conjunto integrado de políticas globais padrão para fornecer segurança e configuração básicas aos gateways de API e portais de desenvolvedores do NGINX Plus. As equipes de Operações de Plataforma podem então configurar políticas globais complementares para, opcionalmente, exigir mTLS, configurar formatos de log ou padronizar cabeçalhos de proxy.

A política global impõe uniformidade e proporciona consistência às APIs implantadas no cluster compartilhado de gateways de API. O API Connectivity Manager também oferece às organizações a possibilidade de executar clusters descentralizados do plano de dados para separar fisicamente os locais em que cada equipe ou linha de negócios implanta suas APIs.

Diagrama mostrando como o API Connectivity Manager permite que vários grupos gerenciem seus próprios Workspaces e Environments

Em um próximo artigo, exploraremos como as equipes de Operações de Plataforma podem usar o API Connectivity Manager para garantir a segurança e a governança das APIs e, ao mesmo tempo, ajudar os desenvolvedores de APIs a alcançar o sucesso.

API Connectivity Manager para desenvolvedores

Equipes de diferentes áreas de negócios são responsáveis por seus próprios conjuntos de APIs e os operam. Elas precisam ter controle sobre seus produtos de API para lançar suas aplicações e serviços no mercado dentro do prazo, o que significa que não podem esperar pela aprovação de outras equipes para usar a infraestrutura compartilhada. Ao mesmo tempo, é necessário estabelecer “mecanismos de proteção” para evitar que as equipes interfiram no trabalho umas das outras.

Assim como ocorre com o perfil de Operações de Plataforma, os desenvolvedores que atuam como proprietários de APIs têm seus próprios Workspaces, que separam suas APIs das de outras equipes. O API Connectivity Manager fornece políticas no nível do API Proxy para que os proprietários de APIs definam configurações no nível do serviço, como limitação de taxa e requisitos adicionais de segurança.

Diagrama que mostra como as políticas de API Proxy para serviços gerenciados por proprietários de APIs são criadas sobre uma base de políticas globais para a infraestrutura gerenciada pela equipe de Operações de Plataforma

Em um próximo artigo, exploraremos como os desenvolvedores podem usar o API Connectivity Manager para simplificar o gerenciamento do ciclo de vida das APIs.

Comece agora

Inicie uma avaliação gratuita de 30 dias do NGINX Management Suite, que inclui o API Connectivity Manager e o Instance Manager.


Compartilhar
Tags: F5 NGINX, Tech

Sobre o autor

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.