Gerenciamento de API: o que os CIOs devem saber

As interfaces de programação de aplicativos (APIs) estão provando ser ferramentas significativas na criação de valor de negócios para CIOs que embarcam em transformações digitais ou procuram desenvolver novos fluxos de receita.

As APIs podem traduzir texto, rotular imagens, enviar mensagens de texto, verificar se há fraudes, recuperar dados bancários abertos e lidar com uma variedade cada vez maior de transações comerciais. Em breve, uma API pode ser a maneira de pesquisar o status de vacinação contra a Covid. À medida que as APIs se tornam essenciais para seus processos de TI e desenvolvimento dentro da organização, os CIOs precisam pensar sobre gerenciamento, conformidade e acesso: quem tem acesso a quais dados da empresa com quais APIs por meio de qual modelo de governança?

Eles também precisam considerar o que a organização está efetivamente terceirizando – ou assumindo como dependências – por meio de APIs. Os desenvolvedores que escolhem uma API por motivos puramente técnicos podem tomar uma decisão de compra corporativa ou escolher uma direção estratégica que, de outra forma, estaria bem acima de seu nível salarial.

As políticas precisam manter o uso da API sob controle, sem afetar a agilidade. Isso requer uma visão clara de quais APIs internas e externas estão em uso na organização, para que são usadas, quanto custam e quão confiáveis ​​são. Estrategicamente, os CIOs precisam ser claros sobre como as APIs contribuem para os negócios.

Integração e composição

“Muitos de nossos clientes querem ir para este futuro onde eles realmente têm uma economia de API e um catálogo de API e expõem dados em todos os silos de sua empresa”, diz Charles Lamanna, Vice-Presidente Corporativo para Low-Code Application Platform (LCAP) da Microsoft.

Usar um gateway de API ou outras soluções de gerenciamento de API com uma plataforma low-code “abre muitas oportunidades, porque os desenvolvedores podem construir esses microsserviços e publicá-los para que outros desenvolvedores os consumam e os desenvolvedores cidadãos podem consumi-los por meio da plataforma Power”, diz Lamanna, a título de exemplo.

Mas ter uma “economia de API” vai muito além de low-code e no-code. Como Abhinav Asthana, CEO do Postman, aponta as organizações precisam pensar em APIs assim que começarem a especificar e projetar software, em vez de esperar até que o projeto seja concluído. “[No final é] onde você toma decisões abaixo do ideal, o que resulta em ainda mais riscos de conformidade e governança. Não há como, se você estiver criando um aplicativo hoje, ele não vai falar com o mundo exterior”, então planeje desde o início, diz ele.

APIs não são apenas para consumir serviços externos; as organizações geralmente criam suas próprias APIs para oferecer acesso de autoatendimento a dados comuns dentro da empresa ou para simplificar a troca de informações com fornecedores. Integrar um novo fornecedor ou lidar com uma consulta de pagamento é mais eficiente se as informações transacionais sobre pagamentos de faturas e status de envio estiverem facilmente disponíveis, mas muitas vezes estão bloqueadas em vários sistemas ERP. Criar APIs e publicá-las em um catálogo pode evitar muitos tíquetes de suporte.

“Pense nos dados ou recursos exclusivos da sua organização, que você espera vender para outras pessoas ou que simplesmente não estão disponíveis em nenhum outro lugar”, sugere Miles Ward, CTO dos consultores do Google SADA. “As APIs são a maneira de se conectar às informações, que só são realmente valiosas quando fluem. Se você tiver dados que não estão disponíveis por meio de uma interface central, programável e extensível, que não está fluindo para onde é útil, é hora de priorizar esse esforço”.

Alguns aplicativos serão construídos quase completamente com chamadas de API. O que o Gartner chama de “composable commerce” é um bom exemplo dessa tendência, diz Kelly Goetsch, Diretora de Produtos da Gmbh.

As tecnologias “composable” mudam a abordagem usual de desenvolvimento empresarial. “Você não precisa de uma equipe de 200 desenvolvedores offshore produzindo volumes de código Java; você deseja encanadores altamente qualificados que possam fazer com que esses diferentes aplicativos funcionem juntos, normalmente com uma arquitetura de eventos e chamadas de API. Quanto mais pessoas você joga em algo assim, mais lento e mais difícil é de fazer”, diz Goetsch.

O que os CIOs precisam, diz Goetsch, é um catálogo de APIs aprovadas e em uso e uma estratégia de governança abrangente que pode ser aplicada no gateway de API que os desenvolvedores usam para acesso, com uma estrutura de segurança comum. “Decida quais APIs você deseja construir e quais deseja escolher de fornecedores terceirizados, e o gateway é como você governa o acesso a essas APIs para seus desenvolvedores”, diz ele.

Os gateways de API costumam ser dispositivos de hardware, mas isso está mudando. Existem ferramentas bem conhecidas para gerenciamento de API e é um serviço de commodity em todas as principais nuvens com opções para composição de serviço, limitação de taxa e controle de acesso, incluindo endpoint e filtragem de instância – em muitos casos, até ações individuais em uma API – que pode fornecer uso, taxas de erro e outras métricas de observabilidade. Também existem serviços de terceiros, como APImetrics, que podem rastrear o desempenho e a disponibilidade de APIs públicas.

APIs em liberdade

A primeira etapa para estabelecer uma estratégia de API mais formal é auditar quais APIs estão disponíveis e em uso. Em seguida, certifique-se de que estão documentadas e detectáveis.

“Há muita repetição em diferentes setores de uma organização”, observa Asthana, sugerindo que os CIOs envolvam desenvolvedores em discussões de arquitetura para aumentar a conscientização sobre o gerenciamento de API.

Além disso, APIs já em uso podem ser facilmente ignoradas. Uma grande organização de saúde que construiu um catálogo de APIs começou com uma lista de 450 APIs em uso: os números finais estavam perto de 4.000. Ferramentas que examinam proxies e arquivos de log e outras análises forenses podem encontrar as APIs que já existem na empresa e gerar descrições OpenAPI.

Uma vez que um catálogo tenha sido estabelecido, ele deve ser usado não apenas para rastrear a publicação e o consumo de APIs, mas também para criar uma política mais estratégica de gerenciamento do ciclo de vida da API – uma que inclua lidar com a suspensão de uso no caso de um provedor externo de API tornar-se drástico muda ou corta seu serviço completamente.

Alguns CIOs estão começando a contratar arquitetos de API e construir centros de excelência em API ou grupos de governança para supervisionar a política de API. É especialmente importante acompanhar como o uso da API se espalha pela organização, para garantir que os sistemas que fornecem API interna tenham os recursos adequados (especialmente porque a automação de processos robóticos pode criar uma API a partir de uma planilha do Excel) e para protegê-los para evitar a exposição de dados, como aconteceu com serviços da Bumble e Equifax.

“As vulnerabilidades mostram o quanto os aplicativos modernos dependem de APIs e como pode ser complicado para uma empresa manter todas essas APIs privadas e bloquear todas elas”, disse Winston Bond, Diretor Técnico da EMEA da Digital.ai. “Um aplicativo desenvolvido a partir de um enxame de microsserviços baseados em nuvem, como o Bumble, expõe muitas conexões geralmente mantidas com segurança atrás de um firewall”.

Custo, confiança e conformidade

Outro motivo para estabelecer transparência em torno do uso da API: controle de custos. As APIs costumam ser tratadas como qualquer outro serviço em nuvem, mas as APIs costumam ser menos visíveis e seu uso costuma ser mais imprevisível, o que pode levar a estouros de custo.

“Como os modelos de precificação são complexos, eles são baseados no consumo e os CIOs não controlam como a empresa vai consumir o aplicativo, tudo o que você pode fazer é prever”, diz Eric Christopher, CEO da Zylo.

Os CIOs precisam saber quanto uma API custará em negócios perdidos e outras interrupções se ela não estiver disponível ou não estiver operando na velocidade normal e quem é responsável por quaisquer problemas que isso cause. Acordos de nível de serviço (SLAs) são a norma, mas precisam ser granulares o suficiente para cobrir as APIs que você usa. Objetivos de nível de serviço, experiência e acordos baseados em resultados podem ser mais adequados, porque são os resultados e não a conexão que importam.

O monitoramento de transações sintéticas mostrará problemas operacionais e de desempenho, mas muito poucos provedores de API oferecem contas de teste de produção ou verificam sua própria documentação, avisa David O’Neil, CEO da APImetrics. “Como você realmente verifica se isso funciona se você não pode testar alguma coisa na produção? Todo o seu ambiente de produção pode ficar inativo e você não saberá disso por cinco horas”.

OpenID Foundation está desenvolvendo o que chama de “estruturas de confiança” com base no tempo de atividade e velocidade em várias regiões para APIs em infraestrutura em nuvem, serviços financeiros e serviços bancários abertos, mas atualmente, “não há nada lá fora para pontuação pública e classificação que seja curada, que todos na indústria podem concordar ”, observa O’Neil.

Essas questões de descoberta, qualidade e conformidade são cada vez mais importantes para APIs em setores regulamentados, como bancos, saúde e serviços governamentais.

O’Neil espera que surja um consenso sobre como medir e monitorar APIs regulamentadas, desde medir a latência até avaliar a documentação e validar a qualidade e conformidade do esquema de API. “Deve haver algum tipo de métrica de scorecard e um grupo de políticas que defina isso em um nível de setor. Algumas das coisas que estão acontecendo com as APIs serão globais, transnacionais que precisam ter um conjunto de padrões acordado por trás delas”, diz ele.

Uma prioridade de 2021

O gerenciamento do ciclo de vida da API ainda é incipiente em muitas organizações, de acordo com Dion Hinchcliffe, Vice-Presidente e Analista Principal da Constellation Research. “O movimento nativo da nuvem está definitivamente transformando microsserviços e contêineres em cidadãos de primeira classe em TI e, no ano passado, foi um ponto de inflexão para o Kubernetes com TI, então 2021 está se preparando para um em que todas essas questões estão começando a ser feitas com seriedade e mais amplamente no nível do CIO”, diz ele.

Não é novidade que os setores regulamentados, como serviços financeiros e saúde, estão mais longe nesse caminho, diz Hinchcliffe. Uma das principais redes de saúde dos Estados Unidos já vê um quarto de sua receita proveniente de APIs e espera que isso cresça para mais da metade nos próximos dois anos. Com potencial de receita como esse, “design, seleção, gerenciamento e governança de API de repente se tornaram questões de alto nível”, diz ele.

Os CIOs que deixam os departamentos de negócios para gerenciar todo o seu próprio software e tecnologia terão menos visibilidade no uso da API, diz Christopher da Zylo. “Onde os CEOs estão dizendo: ‘Seu trabalho é saber tudo o que está acontecendo no negócio, entrar e fazer com que esses departamentos funcionem melhor por meio da tecnologia’; é aí que você está começando a ver a compreensão e a visibilidade da API”.

“Como CIO, gostaria de saber: ‘Essas são todas as minhas dependências externas, são todas as minhas dependências internas e é assim que elas se encaixam’”, afirma Asthana do Postman. “Ter isso dá uma grande vantagem: eu sei como formar minhas equipes de engenharia, sei quais blocos de construção estão disponíveis e posso definir o roteiro para essas coisas com muito mais eficácia”.

O inverso também é verdadeiro, Asthana avisa: “Minha crença é que se você ainda não entende que todas essas coisas estão por vir e a solução está em uma estratégia de API, então você pode ter muitos problemas. Você pode olhar para isso como um problema de produtividade do desenvolvedor, um problema regulatório ou um problema de privacidade: todas essas coisas têm soluções em uma estratégia de API”.