Projetos de integração falham por falta de monitoramento! Por quê com APIs seria diferente?

Projetos de integração falham por falta de monitoramento! Por quê com APIs seria diferente?

Nos vários projetos e conversas com clientes sobre integrações utilizando APIs, sempre surgem várias dúvidas e discussões sempre focadas em características como criar, publicar, gerenciar, transformar, autenticar, monetizar entre tantas outras perguntas sobre APIs, mas monitoramento é raramente o foco desta conversa.

O fato de desconsiderar o monitoramento para focar em outras funcionalidades é algo comum, já que naturalmente pensamos no famoso "caminho feliz", aquele caminho onde não há falhas. Alguns focam tanto na API, que esquecem que a mesma consome informação de um possível ponto de falha, a fonte de dados.

Todo projeto de integração sendo por arquivos, chamadas remotas ou APIs sempre envolvem dois ou mais sistemas, e o fato de integrá-los naturalmente já cria pontos naturais de possíveis falhas. Bons projetos de integrações não focam em evitar todas as falhas, mas focam em monitorar os pontos que podem falhar.

Integração bem feita não é a que não têm falhas - esta não existe no mundo real - é a que consegue identificar falhas e gerar alertas pró-ativos para correção.

Este assunto é tão verdadeiro que na vida real falamos em tolerância a falha, isto é, falhas ocorrem mas os sistemas devem ter condições de tolerá-las ou contorná-las.

Os projetos mais simples de APIs envolvem no mínimo um backend e um frontend. O backend normalmente será o datasource como um banco de dados contendo dados de um usuário, e o frontend ´é a interface de interação com o usuário que servirá de visão aos dados requisitados do backend.

Os projetos mais complexos envolverão além de dois ou mais backends, a conexão com outras APIs ou microserviços com a necessidade de orquestração das informações para gerar dados consolidados e processados para o frontend.

Todos estes projetos necessitarão de conversão de protocolos, conectores com o backend, autenticação, identificação, entre outras atividades para governança das APIs. A API estará pronta e transacionando com os diversos sistemas, mas no primeiro incidente haverá um time operacional correndo atrás das entranhas da integração para descobrir o que deu errado, o que deve ser arrumado, e se possível como poderia ser evitado.

 Projetos com APIs podem se tornar tão complexos com microserviços e backends conectados, que criam situações complexas de monitoramento.

Recentemente conversava com um colega que implementa projetos de integração com APIs, e este contava a história das mil mensagens de alerta disparados durante a madrugada devido a orquestração de diversos microserviços. O monitoramento foi eficiente, mas gerou muita informação devido a complexidade da integração. Após alguns acertos, um eficiente alerta chegava ao responsável a cada dez minutos até que o problema fosse resolvido.

O monitoramento nestes casos podem se basear em alertas pela ocorrência de uma situação de falha, ou de nível de serviço quando temos uma situação onde esperamos obter um número mínimo de respostas em sucesso, mas obtemos uma quantidade maior de situações de falha. Nas APIs costumamos verificar tempo de resposta, erro de conexão e erros HTTP como alertas de nível de serviço.

Monitore, monitore e monitore! APIs fazem parte de sistemas distribuídos.

Em 2008 desenvolvi um sistema para envio dos dados da Nota Fiscal Paulista para a SeFaz-SP para dois grandes varejistas. O envio dos dados ocorria via um WebService SOAP da SeFaz-SP que tinha um conceito simples, que era carregar e enviar o payload das transações fiscais do dia com o CFP dos clientes. Já o processo do backend era um pesadelo, com dados sendo coletados de milhares de pontos de venda de acordo com o processo fiscal diário.

Lembro que de 2008 a 2010 visitei vários outros varejistas que também passavam pelo pesadelo de monitorar o backend, identificando não só o que era enviado a SeFaz-SP, mas principalmente o que não era enviado. A cada cupom fiscal identificado pelo cliente e não enviado a SeFaz-SP o varejo enfrentava dois problemas de negócio, o cliente insatisfeito por não recuperar seus créditos e não participar de sorteios de prêmios, e das ameaças da SeFaz-SP em aplicar multas.

Portanto a experiência em monitoramento e mapeamento dos processos de integração para rastreamento das atividades que ocorreram, ou deixaram de ocorrer, são extremamente importantes para evitar projetos falhos de integração com APIs. Outro cuidado é entender que não existe uma ótima API se o backend não entrega os dados ou o processamento necessário. A analogia é a API como a ponte e o backend como os pilares da ponte, se o pilar que é o backend falhar, não haverá mais a ponte que é a API.

Entre para ver ou adicionar um comentário

Outros artigos de Julio Cesar Campos Fernandes

Outras pessoas também visualizaram

Conferir tópicos