Desburocratizando a Governança de APIs

Desburocratizando a Governança de APIs

Hoje em dia o uso de APIs está amplamente difundido, toda empresa que deseja nascer ou se tornar digital terá como requisito possuir uma estratégia ou arquitetura de APIs muito bem definida e controlada.

As APIs deixaram de ser apenas uma solução técnica para integração entre sistemas ou camadas e passaram a ser ativos de muito valor para os negócios das empresas. Através das delas as empresas podem aumentar suas receitas de forma direta cobrando por seu uso, ou de forma indireta gerando novos negócios, aumentando a exposição da marca, etc.

Para que uma empresa consiga atingir o maior nível de maturidade e que suas APIs estejam aderentes à estratégia de negócio é necessário adotar alguns padrões e políticas, bem como conseguir garantir que os desenvolvedores sigam esses padrões e políticas, ou como muitos conhecem, uma Governança de APIs.

Eu trabalhei durante 3 anos em uma squad responsável por fazer a governança de todas as APIs criadas na empresa, como um centro de excelência era nosso papel estabelecer padrões que se baseavam nas melhores práticas de mercado, evangelizar os desenvolvedores para adoção dessas práticas e garantir que eles seguissem os padrões e políticas de forma que lá na ponta saísse uma API aderente às estratégias de negócio da empresa. Para isso tivemos que criar um gate onde somente após aprovação dessa squad seria possível seguir com a publicação da API, na verdade, como adotamos a prática do contract first, nós validamos apenas o contrato e assim garantimos a aderência aos padrões. Inicialmente esse processo era todo manual e levava alguns dias até que a API conseguisse ser virtualizada no API Manager.

Você deve estar pensando, poxa mas isso é muito burocrático, ter que esperar uma pessoa pegar meu contrato olhar se tem erro de sintaxe, erro de semântica, se está aderente ao padrão REST ou qualquer outro e só depois permitir minha publicação? Isso se não tiver algum erro e eu tiver que corrigir e submeter novamente. Concordo com você! Como um centro de excelência temos que garantir que os padrões e políticas estejam sendo seguidos, mas por outro lado não podemos estar no caminho do desenvolvedor impactando seu lead time.

Para resolver esse problema, criamos um processo automatizado baseado em práticas e ferramentas de DevOps onde o desenvolvedor faz o commit de uma especificação em Open API (contrato) em um repositório e na outra ponta sai uma API Virtualizada em questão de segundos, com todos os padrões e políticas assegurados.

É possível implementar esse processo usando ferramentas de mercado com fornecedores pagos ou até mesmo construindo internamente com ferramentas open source.

Como exemplo, segue abaixo um processo de validação home made com uso do GitLab:

1 - Crie um repositório de contratos de APIs (Open APIs)

2 - Crie um pipeline no GitLab-CI que execute as validações abaixo em cada commit feito pelos desenvolvedores:

  • linter: validação de sintaxe;
  • validação de metadados: validação de metadados obrigatórios;
  • validação de quebra de contrato: validação que garanta que nenhum consumidor produtivo será impactado em caso de alteração;
  • validação semântica e de padrões (REST, gRPC, GraphQL): validação de padrões adotados por cada empresa, garantindo aderência às estratégias de negócio;

3 - Após passar por esse pipeline já é possível efetuar a virtualização desse contrato, dependendo da sua solução de API Gateway pode-se fazer a virtualização pelo próprio Gitlab-CI ou adotar outras ferramentas de CI/CD.

4 - Após o termino do processo, o endpoint da API estará virtualizado em um API Gateway bastando apenas que o desenvolvedor suba o backend da API. O API Gateway é uma peça muito importante pois nos permite endereçar questões relacionadas a segurança nas requisições.

Como podemos ver é possível se estabelecer uma governança de APIs que consiga garantir a criação delas seguindo padrões e atendendo às estratégias da empresa sem que o desenvolvedor tenha impacto no seu lead time de desenvolvimento.

Até mais!

Obs:. Esse artigo foi publicado anteriormente na APICON 2021 neste link:


Taiolor Morais

Diretor de Operações e Tecnologia na Youse Seguros | COO Chief Operating Officer and CIO Chief Information Officer | Operations and IT Director | Leader | Speaker | Coach | Writer | Mentor

3 a

Ricardo Marques parabéns! Excelente contribuição 👏🏻🔝🚀

Felipe Santos

IT Executive Manager @ Accenture | Solutions Architecture | Cloud | IT for Insurance | IT for Financial Industry

3 a

Parabéns pela materia Ricardo. Você teria como passar algum exemplo das ferramentas usadas para os 4 passos que o pipeline executa?

Walter Rodrigues

Founder & Distinguished Engineer at WRxTech Solutions

3 a

Vcs chegavam a tratar a questão dos domínios/ contextos ?

Entre para ver ou adicionar um comentário

Outros artigos de Ricardo Marques

  • Deployment - Rolling Update

    Deployment - Rolling Update

    A fase final de uma pipeline devops ou devsecops é o deploy, é também um dos momentos que geram maior apreensão, afinal…

    3 comentários
  • Uma história sobre resiliência

    Uma história sobre resiliência

    Olá pessoal, como vão? Espero que bem! Já faz um certo tempo desde o último artigo que escrevi então resolvi escrever…

    45 comentários
  • API REST ou gRPC? Qual adotar?

    API REST ou gRPC? Qual adotar?

    API é um acrônimo de Application Programming Interface, é um conjunto de rotinas e padrões de programação documentados…

    16 comentários
  • [Desmitificando Buzzwords] - Quarkus - Parte I

    [Desmitificando Buzzwords] - Quarkus - Parte I

    Olá Pessoal, Esse artigo faz parte da plataforma TechStage onde dedicaremos uma série especial para falarmos sobre os…

Outras pessoas também visualizaram

Conferir tópicos