[Série] Governança de API: Centralização

Dando continuidade a nossa serie sobre Governança de API, vamos falar de Centralização. Quando queremos organizar a bagunça sempre lembro dessa fala do Deming:

Não se gerencia o que não se mede,
não se mede o que não se define,
não se define o que não se entende,
e não há sucesso no que não se gerencia
-- William Edwards Deming

Olhando atentamente essa fala, é possível inferir que para alcançar o sucesso é de extrema importância entender o contexto do problema e sua nuances. Não será diferente com o assunto desse artigo, afinal vivemos em um tempo complexo. A cada minuto que passa surge uma nova tecnologia, um novo serviço e uma nova forma de pensar, antigamente era mais simples, os sistemas eram todos construido para atender todas as necessidades, vulgo monolito, e todas as regras de negócios podiam ser extraídas de um único local. Atualmente estamos implementando microserviços, mesmo que não seja preciso leia mais sobre aqui. A quantidade de API ou serviços no meio corporativo só tem aumentado. Imagina quando começar a ser tudo (serverless)[https://aws.amazon.com/pt/serverless/] 🤪.

Sem levantar as nuances de certos contextos bem específicos do seu sistema. A forma mais simples pra iniciar o processo de entendimento do seu ambiente é criar uma lista com todas as APIs internas e externas. Informando uma breve descrição sobre características chaves para que qualquer ser humano consiga entender qual a utilidade e quando precisa consumir sua API. Essa descrição deve conter pelo menos os campos abaixo:

• Recurso: descreve o motivo dessa API ter sido projetada, e o que ela consegue entregar, usando uma linguagem que os seres humanos, leigos, possam digerir;
• Estrutura: uma descrição esquemática das APIs, incluindo URIs, estruturas de dados, segurança, etc. Podemos citar como exemplo aqui o OpenAPI;
• Capacidade: qual a quantidade de requisições que essa api deve suportar, quantas requisições seu cliente já consumiu;
• Sensibilidade: a API consome ou expõe dados que possam estar sujeitos a restrições regulatórias ou de privacidade, como dados de cartão de pagamento, dados de identificação pessoal e assim por diante.

Para tal inventario é dado o nome de Catalogo de API (vou usar esse termo daqui pra frente) ou Registro de API. Como exemplo de catalogo de API bem feito cito o ProgrammableWeb e o RapidAPI como exemplo a ser copiado.

O catalogo de API também ajuda a equipe de governança a criar e aplicar políticas. Existem alguns modelos para a construção dessa equipe, todos com o intuito de chegar no estado da arte em Governança de API.

• Centralizado: Toda alteração arquitetural, desde a implementação de novos recursos até a aplicação ou introdução de novos elementos no cenário arquitetônico, sempre são revisadas e aprovadas por uma equipe centralizada. Esse modelo tem um grande problema de escalabilidade, já que isso pode fazer com que a equipe se torne um gargalo devido ao alto nível de demandas impostas a elas.
• Descentralizado: Similar ao modelo anterior, mas formado por mais de uma equipe, menor, e essa possuindo autonomia para avaliar e validar certos aspectos da arquitetura, seja para um aplicativo específico ou para um conjunto de aplicativos relacionados. Agora o problema desse modelo é coordenar essas equipes, evitando que mudanças de uma equipe afete a outra equipe.
• Distribuído: Formado por equipes especialistas em um conjunto de produtos e, portanto, responsáveis ​​por eles. O conhecimento comercial e os aspectos de governança são cruciais para garantir que os controles corretos estejam em vigor.

Aqui eu indico o vídeo da Sensedia com o tema Repensando a Governança de APIs

Tenha um certo cuidado ao escolher o melhor modelo para sua organização. Como foi falado no post anterior, comece devagar e vai adaptando a sua realidade, reforçando as boas práticas e mudando o que não deu certo para o seu contexto.

Tome cuidado para não confundir catalogo de API com o portal do desenvolvedor, sob a ótica da governança todas as APIs são importantes, se é interna ou externa, ela deve estar no inventario. E o acesso a esse inventario deve ser divulgado para toda a empresa, principalmente para a área de negócio. Eles podem visualizar o que já existem e definir uma estratégia para consumir essas APIs de acordo com suas necessidades.

Mas um portal do desenvolvedor pode ser um produto, e como produto precisamos entender qual o seu publico alvo. Aqui é possível distinguir 3 tipos de publico alvo que uma organização geralmente possui:

• Equipes internas: O objetivo inicial é permitir que suas equipes internas criem novas funcionalidades e aplicativos sobre suas APIs. Ao pensar no catalogo de API para equipes internas é importante pensar como que essas equipes vão consumir suas APIs, a experiência do desenvolvedor aqui é muito importante para ganhar escala.

  

  The Wiz way to build technological solutions

  Lucas Mindêllo ・ Jul 7 '20 ・ 3 min read

  #microservices #governance #agile #devops

• Parceiros e/ou Clientes: Seus parceiros de negócios e clientes são as próximas partes interessadas que podem fornecer mais valor agregado a sua organização por meio de APIs. A API do seu parceiro pode integrar-se ao aplicativo de RH de um cliente para otimizar as informações dos funcionários ou fornecer um benefício diferenciado para o seu cliente.

• Desenvolvedores de terceiros: A etapa final é disponibilizar suas APIs para o público em geral e monetizar com isso 🤑. Se ainda não parou para pensar em ganhar dinheiro. Gaste um tempo e o explore esses sites aqui ProgrammableWeb e o RapidAPI.

Mantendo a inovação constante

É possível manter um fluxo de inovação constante, e apoiar a estratégia da sua organização? Para chegar nesse nível de maturidade é fundamental oferecer sustentação para tipo de público alvo, e manter uma alta taxa de inovação nesses portais, talvez até uma equipe dedicada exclusivamente na entrega dessas inovações.

Construir esses portais ajudam a entregar diferencial para os desenvolvedores que procuram APIs com o intuito de agregar valor no seu produto. A inovação e o diferencial desse produto aparece em como você pensa na forma que seu publico vai solicitar acesso, gerar suas chaves de API ou tokens OAuth. Como o desenvolvedor vai consumir sua API se será através de um contrato como Swagger ou usando um SDK feito por você.

Não fique preso apenas no inventario para o catalogo de APIs. Pense em como será a experiência do desenvolvedor, como esse produto vai ajudar nas entregas do dia a dia desse desenvolvedor. Só uma sugestão, é possível disponibilizar SDKs para qualquer tipo de linguagem de programação, um canal de ajuda, suporte, informações dos logs de alterações, mudança de contrato ou quando essa API vai deixar de ser suportada pela organização.

Agora que possui essas informações centralizadas é possível realizar uma analise do impacto de uma determina alteração, visualizar as dependências de cada API e conseguir enxergar a como estão sendo expostos os campos mais sensíveis. Existem ferramentas como o Stoplight, que entrega de uma forma visual essas visualizações. Para conseguir extrair o máximo dessas ferramentas será preciso entender o conceito de Contrato da API, e este é o assunto do próximo artigo dessa serie.

1. Introduçao
2. Centralização
3. Contrato da API
4. Diretrizes de estilo
5. Reutilização
6. Automação
7. Versionamento
8. Política de descontinuação
9. Rastreamento / Observabilidade
10. Descoberta de API

Referencial

• API Governance: How Important Is It for API Strategy?
• Best Practices in API Governance
• [Série] Governança de API
• The API Economy
• What to Consider When Building Your API Strategy

Pode me chamar de Juscélio Reis

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #