Introdução

Para empresas modernas, proporcionar experiências agradáveis baseadas na obsessão do cliente tornou-se uma atividade comum. Um relatório da pesquisa da Forrester, de junho de 2021, mostra empresas com obsessão pelo cliente relatando um crescimento de receita 2,5 vezes maior e uma retenção de clientes 2,2 vezes melhor. O Gartner prevê que, nos próximos dois anos, os canais digitais de autoatendimento, juntamente com a análise preditiva do comportamento do cliente, serão em breve os recursos mais valiosos para as organizações que prestam serviços.

No entanto, a implementação de sistemas que colocam o cliente no centro exige o aproveitamento de todos os recursos da organização de uma forma maior do que a soma de suas partes. Assim, a conectividade é uma parte fundamental de qualquer infraestrutura de TI moderna. Antigamente, o Enterprise Service Bus (ESB) era o principal provedor de conectividade para uma Arquitetura Orientada a Serviços (SOA).

Contudo, os tempos estão mudando. As organizações estão caminhando para a descentralização, substituindo monolitos por microsserviços e abandonando a ideia de se ter empresas inteiras usando várias tecnologias a favor de uma diversidade de linguagens, plataformas e soluções.

Elas estão liberando dados em silos e modernizando aplicações legadas, e estão usando APIs nesse processo. Além disso, as organizações estão migrando seus serviços e aplicações para a nuvem.

Em meio a tudo isso, a conectividade que fornece experiências mais interligadas aos clientes é ainda mais crítica do que antes.

Gateways de API são uma solução moderna de conectividade e seu uso permite que equipes foquem em inovação e eficiência, atendendo às principais exigências das empresas modernas.

Neste ebook, veremos primeiro por que a conectividade está se tornando mais importante a cada dia, e, a seguir, abordaremos o ESB — o que é, como surgiu e onde foi usado. Assim, analisaremos outra solução de conectividade, o gateway de API, e vamos compará-lo com o ESB. Por fim, discutiremos como as organizações atuais podem evoluir.

Conectividade para experiências encantadoras

O mundo está se tornando cada vez mais digital. A transformação digital, ou a integração da tecnologia digital em todas as áreas de uma empresa, continua em expansão. Não é mais simplesmente a integração de uma nova peça de software ou hardware, mas uma mudança cultural

cultural que afeta fundamentalmente como as organizações operam e o que visam.

Um desses novos alvos é a obsessão pelo cliente. Não basta simplesmente dizer que você é uma empresa que o prioriza. A obsessão pelo cliente vem de um foco e comprometimento de toda a organização em colocar as necessidades dele no centro de tudo. De vendas e marketing a operações e suporte, todos os departamentos precisam compartilhar desse compromisso.

A partir daí, torna-se possível gerar experiências prazerosas para seus clientes. Na era da mídia social, as organizações que vão além da mera satisfação de necessidades e procuram encantar seu público ativamente vão ganhando uma influência e uma mentalidade descomunais.

Embora nada disso seja novo, estão sendo atingidos novos patamares. O foco e os dados necessários para conduzir tudo isso são implacáveis e exigem que a organização os persiga incansavelmente. A conectividade desempenha um papel fundamental no fornecimento dessa experiência prazerosa.

A importância da conectividade

Para proporcionar aos clientes ótimas experiências digitais, é importante conectar a soma de todas as interações que uma organização tem com o público. Essa capacidade de conectar marketing, vendas, TI e todos os seus

departamentos com o cliente também é conhecida como “visão 360º”. Ao vincular e sincronizar suas informações a partir de diferentes ângulos, a organização tem uma compreensão mais holística- histórico de pedidos, informações demográficas, dados de fidelidade, histórico de reclamações e muito mais.

Os dados dessa visão 360º são usados para fornecer uma experiência digital omnichannel. A organização pode então fornecer uma experiência agradável, personalizada e adequada ao momento do cliente, que, por sua vez, não sente mais que está representando apenas uma pessoa física, está enfim sendo tratado como um ser humano.

Para gerar essa visão 360º e uma experiência omnichannel, a conectividade é fundamental. Todos os sistemas e processos de negócios dentro da empresa devem estar conectados e atualizados para que o cliente tenha uma experiência perfeita e prazerosa.

O ESB e a conectividade

A conectividade sempre foi importante. No entanto, no passado, o foco estava na eficiência organizacional. O Enterprise Service Bus (ESB) foi originalmente concebido como um conector para todos os diferentes tipos de serviços existentes. Em uma arquitetura orientada a serviços (SOA)– que ainda estava crescendo e evoluindo –, o desafio de conectar diferentes serviços com diferentes padrões e protocolos era significativo, e o ESB surgiu para enfrentar esse desafio.

Em um ambiente centralizado, o ESB tornou-se uma parte significativa, já que possibilita uma arquitetura empresarial monolítica. Para atender a necessidade de conectar grandes aplicações e bancos de dados locais, o ESB foi muito importante. Vejamos como ele realizou essa tarefa.

O Barramento de Serviço Corporativo (ESB)

O que é um ESB?

Um ESB é um intermediário que conecta aplicações em um SOA. Em vez de comunicação direta ponto a ponto ou cliente-servidor, o ESB se integra com todos os terminais. Teve seu destaque no início dos anos 2000 e, desde então, cresceu e se tornou uma parte importante da infraestrutura de TI de grandes empresas.

Como não há um padrão único a ser seguido por todos os ESBs, este ebook se refere aos recursos dos ESBs em geral. Uma determinada implementação pode não conter todos os recursos, mas há grandes similaridades ao longo do espaço do ESB.

O papel do ESB

Um ESB serve para desacoplar os vários serviços e aplicações que existem em um ambiente de TI baseado em SOA. Cada serviço deve configurar apenas uma única integração com o ESB. A partir daí, o ESB disponibiliza esse serviço para todos os outros serviços conectados a ele, geralmente lidando com transformação de formatos, negociação de protocolo, enfileiramento e, em alguns casos, até lógica de negócios adicional.

Ao fazer isso, o ESB se apresenta como um balcão único para qualquer aplicação ou serviço que pretenda consumir ou publicar dados.

O ponto aqui é que o ESB é um intermediário para toda a comunicação serviço a serviço, normalmente oferecendo os melhores benefícios.

Arquitetura centralizada no local

Em seu papel de negociador e mediador da comunicação entre serviços, o ESB tende a se tornar um hub central da infraestrutura de TI. Ele fornece muitos recursos que permitem a integração com praticamente todos os serviços disponíveis, incluindo serviços legados.

À medida que mais serviços passam pelo ESB, o impulso para trazer cada novo serviço aumenta. Há um “efeito de rede” semelhante aos de grandes aplicações de redes sociais, como o Facebook. Quanto mais pessoas estiverem na rede, mais ela atrairá outras pessoas.

Assim sendo, o ESB eventualmente se torna um serviço monolítico essencial próprio. Cada integração com o ESB tende a ir um pouco além e conter um pouco mais de lógica. Em pouco tempo, a lógica de negócios deixou de residir nos serviços individuais e passou a estar no ESB.

A equipe de ESB – TI central

À medida que o ESB cresce, naturalmente requer mais manutenção e atenção. Essa responsabilidade normalmente vai para uma equipe de TI dedicada, encarregada da manutenção do ESB.

Como o ESB atua como um hub centralizado para todas as comunicações serviço a serviço, sua equipe deve funcionar de maneira semelhante, trabalhando e se comunicando com as diversas equipes de aplicações. A coordenação de novos recursos e lançamentos evita a quebra de dependências downstream.

Vantagens e desvantagens de um ESB

Agora que temos uma compreensão geral do ESB, vamos dar uma olhada nos desafios específicos que eles resolvem, seus benefícios e algumas desvantagens.

Quais desafios os ESBs resolvem?

Em uma época em que os formatos de serviço e até mesmo os protocolos não eram padronizados, o ESB forneceu uma maneira de centralizar essas integrações. Considere um contexto empresarial onde se tinha cinco serviços. Sem um ESB, seriam necessárias 10 integrações ponto a ponto para cada um desses serviços se comunicarem entre si. Adicione mais um serviço e o total salta para 15.

Com cada novo serviço, o número de integrações necessárias cresce exponencialmente, assim como os recursos necessários para desenvolvimento e manutenção iniciais. Com um ESB, cada novo serviço requer apenas uma nova integração, diretamente com o ESB.

Além disso, como os ESBs têm acesso centralizado a todos os serviços, eles oferecem benefícios de orquestração, ou seja, a capacidade de agregar dados de vários serviços e apresentá-los como um único. À medida que o número de serviços cresce e as necessidades das aplicações se tornam mais complexas, a orquestração permite o desenvolvimento e a interface de aplicações mais simples.

Benefícios do ESB

Um dos principais benefícios de um ESB é a descoberta de serviços. Como os serviços devem se conectar ao ESB para acessar outros, ele também serve como um diretório de serviços na organização. Este é um dos benefícios do efeito de rede do ESB: além de integrações simples, ele pode servir como uma fonte contínua e atualizada de documentação sobre qualquer serviço. Ele contém não apenas informações gerais sobre o serviço, mas também detalhes técnicos de como consumir e usar seus dados. Obviamente, essas informações são voltadas para o desenvolvedor, fornecendo um entendimento em nível de engenharia em vez de nível de negócios. Os ESBs também adicionam resiliência à arquitetura de serviço. Como um intermediário para a comunicação de serviço, os ESBs podem adicionar funcionalidades semelhantes a um middleware a essa comunicação.

Muitos ESBs servem como uma fila de mensagens, permitindo o desacoplamento de serviços, pois não precisam mais estar online ao mesmo tempo para se comunicar. Isso torna a comunicação entre serviços mais resiliente, menos propensa a interrupções de rede e capaz de resistir à falha de qualquer serviço individual.

Além das mensagens, os ESBs também adicionam balanceamento de carga e transações. O balanceamento de carga permite maior disponibilidade de serviço e as transações permitem executar operações complexas como unidades atômicas com capacidade de reversão.

Finalmente, à medida que os ESBs cresceram em destaque, foram sendo adicionados ainda mais recursos. Alguns incluem regras e lógica de negócios de forma centralizada — com soluções sem código e low-code disponíveis para os membros da organização — e geram modelagem gráfica da arquitetura.

Além disso, mais adaptadores foram introduzidos para consumir grandes aplicações corporativas e até mesmo comunicação EDI (troca eletrônica de dados). Embora cada um desses recursos tenha agregado valor, eles também aumentaram o escopo e a complexidade da aplicação ESB.

O futuro dos ESBs

Com essas questões, o que o futuro reserva para os ESBs? Vamos dar uma olhada no cenário moderno de TI e como os ESBs se encaixam.

O papel da conectividade de serviço no cenário moderno de TI

Em um cenário moderno de TI, o desenvolvimento de serviços mudou para uma abordagem API-first. Não estamos mais no mundo SOA e as APIs se tornaram muito mais padronizadas em relação aos protocolos.

Além disso, o desenvolvimento da API moderna mudou para uma abordagem spec-first. Isso significa que as equipes que desejam consumir e integrar um determinado serviço não precisam mais esperar que ele seja desenvolvido antes de trabalhar na sua própria aplicação. Com o contrato técnico já em vigor, o desenvolvimento pode acontecer em paralelo.

A TI está caminhando para equipes separadas e distribuídas. À medida que as organizações continuam em busca de agilidade e inovação, times pequenos de desenvolvimento exigem quantidades cada vez maiores de autonomia.

As organizações não estão mais on-premise ou apenas na nuvem; em vez disso, elas estão trabalhando com ambientes de nuvem híbrida e multicloud. Não pode mais haver pontos de integração que funcionem apenas em um determinado ambiente; esses pontos de integração devem ser capazes de abranger vários tipos de ambientes.

Desafiando as velhas formas de conexão via ESB

Finalmente, o movimento em direção aos microsserviços está fundamentalmente em desacordo com o ESB monolítico tradicional. Ao dividir o monolito ESB em vários serviços focados, isso mantém muitas das vantagens, além de aumentar a flexibilidade e a agilidade.

Com uma compreensão dos ESBs e das mudanças que estão ocorrendo na empresa moderna, é hora de olhar para um novo modelo de integração: o gateway de API.

O gateway de API

O que é um gateway de API?

É um componente da infraestrutura moderna, que intermedia clientes e serviços, atuando como um único ponto de entrada para os clientes. Isso contrasta com um ESB, que lida com toda a comunicação entre serviços.

Da mesma forma que os ESBs, os gateways de API servem para conectar serviços distintos e integrar essas informações. No entanto, com o surgimento das APIs, a conectividade passa a ser mais focada.

Mudando de service-first (exibição ESB) para API-first

As APIs fornecem o contrato padronizado que faltava no ambiente SOAP. Em sua forma original, os ESBs eram uma solução técnica para um antigo problema de padrões, e, com o advento do desenvolvimento de APIs spec-first, o contrato entre o cliente e o serviço não precisa mais esperar que o serviço seja desenvolvido, dissociando ainda mais as equipes de desenvolvimento.

Além disso, essa abordagem se concentra nos requisitos de negócios, priorizando os resultados e clientes, em vez de apenas montar uma spec para um sistema de back-end. O design API-first leva a uma melhor reutilização e relevância dos “produtos” liderados por negócios.

Por que o gerenciamento de APIs é tão importante para a empresa moderna?

Com o advento das arquiteturas baseadas em microsserviços, o número de serviços para gerenciar e supervisionar aumentou drasticamente. É aqui que o gerenciamento de APIs entra em jogo: ele simplifica essa tarefa de supervisão para você, considerando todo o ciclo de vida de uma API – design, documentação ou um portal do desenvolvedor, implantação, descoberta e conectividade com um gateway de API, e outros detalhes.

Qual é a função de um gateway de API?

Um gateway de API permite simplificar a tarefa de se conectar a qualquer API. Ele lida com preocupações secundárias, como autenticação, registro e monitoramento. Além disso, também pode manipular a orquestração para reduzir as viagens de ida e volta. Por fim, um gateway de API pode fornecer a API correta para cada cliente.

Quais benefícios um gateway de API oferece?

Agora que temos uma compreensão geral do que é um gateway de API, vamos examinar mais de perto seus benefícios e casos de uso.

1) Microsserviços mais enxutos

Primeiro, os gateways de API permitem a centralização de funções comuns para reduzir a sobrecarga. Em vez de reinventar a roda com cada serviço, preocupações secundárias como autenticação, registro e monitoramento podem ser tratadas no nível do gateway. Isso torna cada serviço mais enxuto e reduz o tempo de desenvolvimento, permitindo que os desenvolvedores se concentrem na lógica de negócios real e no diferencial competitivo de cada serviço. Também diminui a complexidade geral do sistema, pois essas preocupações secundárias podem ser implementadas uma vez no gateway.

2) Clientes e serviços desacoplados

Os gateways de API também dissociam os clientes dos detalhes de implementação dos serviços. Isso permite a orquestração de vários microsserviços em uma API de cliente. Da mesma forma, diferentes clientes podem receber diferentes APIs adaptadas às suas necessidades, em uma variação do padrão “back-end para front-end”.

3) Descoberta de API

Os gateways de API servem como um local natural para descobrir APIs. Isso acelera o desenvolvimento de novos clientes e funcionalidades. Um portal do desenvolvedor que trabalha junto com um gateway de API promove a adoção e a reutilização de APIs, garantindo que elas sejam altamente detectáveis, bem documentadas e fáceis de consumir.

4) Diminuição do número de solicitações necessárias

Os gateways de API também podem aumentar o desempenho reduzindo o número de solicitações e viagens de ida e volta necessárias para uma determinada chamada de API. Por meio da orquestração, há várias chamadas de API no back-end que podem ser agregadas em uma viagem de ida e volta do cliente para o gateway de API e vice-versa. Isso pode melhorar a experiência do usuário.

Por meio do armazenamento em cache, os gateways de API podem determinar quais solicitações podem receber respostas em cache com dados recentes, reduzindo assim a carga desnecessária nos serviços.

5) Registro, monitoramento e análise

Devido à sua posição como intermediário de atendimento ao cliente, o gateway de API está bem posicionado para fornecer dados de registro, monitoramento e análise. Novamente, isso é semelhante a um ESB, embora os ESBs forneçam isso para todas as comunicações serviço a serviço. Os gateways de API fazem isso apenas para solicitações entre o cliente e eles.

6) Consistência através de plugins

Um gateway de API pode cuidar de fornecer práticas mais consistentes de governança, segurança e observabilidade e tratar de todas as outras preocupações secundárias. Isso é feito mais facilmente através de plugins e políticas aplicadas no nível do gateway. Os aspectos que um gateway de API gerencia incluem:

• Autenticação e autorização
• Controle de tráfego e modelagem
• Transformação de solicitação e resposta
• Segurança
• Logging
• Roteamento

Como os gateways de API se comparam aos ESBs?

Ao comparar gateways de API com ESBs, as semelhanças são claras. Ambas as soluções ocupam um lugar semelhante na arquitetura: o intermediário centralizado para a comunicação com os serviços. No entanto, os gateways de API oferecem vantagens, bem como uma abordagem mais moderna para obter essas vantagens.

A principal vantagem é que os gateways de API têm um escopo claro. Os ESBs foram concebidos como a solução definitiva para a comunicação entre todas as aplicações e serviços. Conforme eles cresceram nesse papel, recursos adicionais foram acrescentados, permitindo que regras e lógica de negócio fossem incorporadas ao sistema. Sendo assim, o ESB tornou-se muito conveniente; o que começou como um projeto para reduzir a complexidade do sistema evoluiu para um sistema próprio massivamente complexo.

Por outro lado, os gateways de API desempenham um papel mais focado. Primeiro, um gateway não é responsável por transformação e negociação de protocolo. À medida que os padrões de API amadureceram, o gateway de API pode ser mais enxuto do que um ESB, focado especificamente em questões secundárias. Além disso, o gateway é focado principalmente na comunicação cliente-serviço, em vez de toda a comunicação serviço a serviço.

Mais uma vez, este foco permite que ele permaneça enxuto e especializado.

Essa especificidade de escopo permite que os gateways evitem a sua extensão, para que não se tornem outro monolito a ser quebrado. Ao selecionar um gateway de API, é importante encontrar um produto com uma identidade clara ao invés de um extenso conjunto de recursos.

Em contraste com a natureza centralizada e altamente acoplada dos ESBs, os gateways de API permitem descentralização e distribuição. Esse aspecto capacita os dois tipos de empresas— aquelas que estão migrando para a nuvem e aquelas que adotam uma abordagem híbrida.

Quando usar um gateway de API?

Os gateways de API são uma boa opção para os negócios modernos focados em evoluir mais rapidamente e permitir inovação. Vamos entender por que a cultura organizacional é importante para isso.

Por que a cultura certa é tão importante para a empresa moderna?

Na empresa moderna, o foco é aumentar a agilidade e fomentar a inovação. Isso ocorre por meio de equipes distribuídas com independência e capacidade de realizar seu trabalho. Em geral, a mudança para a descentralização não é apenas técnica, mas também cultural. Assim, torna-se fundamental selecionar a ferramenta certa para o trabalho – não apenas por suas especificações técnicas, mas também pelo alinhamento da cultura que a empresa deseja promover.

Os ESBs falham nesse padrão, pois são monolitos grandes e centrais, levando a um aumento do acoplamento entre as equipes e à diminuição da independência. Por outro lado, os gateways de API, graças à sua especificidade de escopo, deixam as equipes se concentrarem em suas tarefas individuais. Ao lidar com as preocupações secundárias, os gateways de API permitem que as equipes sejam mais enxutas e especializadas.

Os gateways de API — com portais do desenvolvedor — também promovem uma abordagem design-first para APIs e uma de consumo guiada pela descoberta. Ao fornecer a API certa para cada cliente, os gateways de API podem permitir maior adoção, reutilização e velocidade de interação.

Isso também facilita o consumo e a descoberta de APIs em toda a organização e permite o uso de ferramentas sem código ou low-code. Novamente, o foco está na capacitação de equipes independentes, em vez de acoplar à própria equipe de gateway de API.

Como selecionar o gateway de API em 4 passos?

Ao considerar a adoção de um gateway de API, a seleção é crítica, envolvendo vários critérios a serem considerados.

1) Complexidade de implantação

Primeiro, considere os requisitos técnicos do gateway. Quantas peças devem ser configuradas para chegar a uma instalação minimamente viável? Muitos exigem a configuração de um banco de dados adicional.

A complexidade inicial da implantação também é relevante ao considerar os requisitos de manutenção futuros. Sua complexidade de implantação também depende de sua abordagem de infraestrutura: seus sistemas estarão na nuvem, on-premise ou híbridos? Você aproveitará plataformas de orquestração de containers como o Kubernetes?

2) Proprietário versus open source

Considere a extensibilidade da plataforma, bem como a probabilidade de suporte de longo prazo. A introdução de um gateway de API em seu ambiente é uma mudança significativa no nível da arquitetura que afeta muitas equipes, e isso não é algo que você deseja ser forçado a mudar.

3) Facilidade de escalar

Como o gateway de API estará na rota crítica para cada interação cliente-serviço, a escalabilidade é fundamental. Considere seus planos de crescimento e se o gateway de API pode escalar horizontalmente e verticalmente. O gerenciamento de escala é melhor alcançado ao fornecer suporte para abordagens modernas, orquestradas e declarativas, como o Kubernetes.

4) Conjunto de recursos

Um gateway de API, no mínimo, deve suportar todo o ciclo de vida da API. Além disso, no entanto, se um gateway de API tem ou não mais recursos, deve ser uma preocupação secundária. Como vimos na jornada do ESB, o aumento do escopo e o excesso de recursos levam a um produto menos eficaz.

Considere cuidadosamente a função do gateway de API e procure um produto focado especificamente em cumprir essa função, independentemente do tamanho do conjunto de recursos.

Gateways de API na arquitetura corporativa moderna

Na arquitetura corporativa moderna API-first, os gateways de API são um ajuste feito propositadamente. A proliferação de microsserviços significa que há um número infinito de serviços que precisam ser identificados, descobertos, documentados, protegidos, controlados e garantidos. Os gateways de API fornecem uma âncora e um ponto de referência que permite que os clientes interajam com inúmeros serviços de maneira gerenciável.

Ao evitar a natureza monolítica dos ESBs, os gateways de API também fornecem algumas eficiências semelhantes à centralização, permitindo que suas equipes de microsserviços operem de maneira mais rápida e enxuta.

Um gateway de API permite que as equipes de desenvolvimento tenham mais foco, aumentando sua independência e velocidade.

Por fim, ao evitar a centralização da lógica de negócios, os gateways de API permitem que essa lógica seja distribuída mais perto dos serviços que a requerem. Isso, novamente, aumenta a independência da equipe.

Juntando tudo

Agora que temos uma compreensão clara de ESBs e gateways de API, vamos juntar tudo. Talvez você já tenha um ESB e esteja pensando em adotar um gateway de API, ou talvez já esteja introduzindo um gateway de API em sua arquitetura. Como você avança a partir daqui?

O poder do ESB + gateway de API para a empresa moderna

A jornada da empresa moderna envolve mover-se em direção à agilidade e à inovação rápida para encantar o cliente. Ao aumentar a independência das equipes e permitir que elas permaneçam enxutas e focadas, essa jornada é possível. Para fazer isso, as organizações de TI devem se tornar tecnicamente heterogêneas e diversificadas, em vez de homogêneas.

Elas devem adotar a melhor solução para cada caso. Isso requer diversidade em soluções e abordagens técnicas. Afinal, a mudança de direção é multifacetada. Aqui estão alguns exemplos:

• On-premise ou apenas na nuvem → Ambientes de nuvem híbrida e/ou multicloud
• Centralizado → Distribuído
• Arquitetura monolítica → Microsserviços
• Servidores → Sem servidor; funções; Kubernetes; containers
• Idiomas da organização → Equipes e organizações poliglotas

No que diz respeito às plataformas de integração, o foco deve passar agora para as APIs. A conectividade é o novo campo de batalha competitivo e os gateways de API são uma solução específica para essa finalidade.

Na maioria das situações, uma abordagem híbrida gradual é o melhor ponto de partida. Comece implementando um gateway de API com novas APIs e, lentamente, traga mais serviços conforme a oportunidade e o tempo permitirem. Com o tempo, essa abordagem gradual quebrará o monolito ESB. Aproveite para extrair a lógica de negócios dentro do ESB e distribuí-la em novos microsserviços.

O objetivo não é necessariamente substituir totalmente o ESB, pois ele ainda tem um espaço dentre os serviços legados que podem nunca ser atualizados. No entanto, o foco está em tirar o ESB do caminho crítico para um novo desenvolvimento.

Além disso, concentre-se nessas novas APIs e nos recursos de gerenciamento de APIs desbloqueados pelo gateway. Gere valor por meio da conectividade, e a implementação subjacente deve mudar naturalmente para o local com mais valor.

A perspectiva de longo prazo

Todo negócio de TI deve focar em gerar valor para o cliente mais do que qualquer implementação específica. Isso ocorre porque as necessidades do negócio irão evoluir e mudar ao longo do tempo. Os sistemas aos quais você se conecta e os dados que consome também mudarão.

No entanto, a médio prazo, o contrato de API será mais duradouro, criando dependências a nível de negócio sobre eles. Assim, o foco na conectividade de APIs gerará valor para a empresa moderna.

Referências

Esse ebook é uma tradução do ebook original escrito pela equipe da Kong.

Para ter acesso a outros conteúdos da Kong e implementar integração de APIs dentro da sua empresa, entre em contato com o time técnico da Vertigo Tecnologia. Estamos prontos para te ajudar!