Ferramentas de Gestão de APIs e Barramentos de Serviços: O que você precisa na sua Arquitetura para resolver suas integrações de maneira “Lean”


Baseado num estudo das soluções de API Management (API-M) de 5 fornecedores cheguei a conclusão que um Enterprise Service Bus (ESB) consegue suprir a necessidade de gerir APIs, mas que, obviamente,  depende de cada caso. Essa dependência está relacionada não somente à situação atual (As-is) da sua Arquitetura mas também aonde você quer chegar (To-be). Justifico abaixo alguns pontos que julgo relevantes e que podem favorecer o uso de um ESB com o papel de uma solução de API-M.

Em primeiro lugar, no meu caso, isso foi possível pois desde quando adotamos um ESB optamos por não trabalhar com SOAP. A maioria dos nossos serviços são baseados em REST+JSON para facilitar a vida dos consumidores uma vez que eles não necessitariam utilizar “frameworks de webservices” para gerar automaticamente classes que a maioria dos desenvolvedores não consegue entender e manter. Então, o discurso dos fornecedores de soluções de API-M de que suas soluções “modernizam a infraestrutura” possibilitando “padrões e formatos mais modernos e ‘democráticos’” não se encaixa no cenário que vivencio. Prova disso é que alguns serviços que tínhamos puderam ser acessados facilmente tanto por front-ends de aplicações web (JavaScript) quanto por aplicativos (tablets e celulares) sem nenhum esforço.

Um segundo ponto que tornou isso possível foi a existência, desde o início da minha trajetória com Arquitetura Orientada a Serviços (SOA), de 2 infraestruturas integradas para o ESB. Uma dessas infraestruturas tem como foco integrações internas tais como sistemas de gestão (CRM, ERP e Call Center). A outra, que inclusive fica hospedada em um data center diferente do outro ESB por ter uma dependência maior da Internet, tem como foco principal é atender a necessidade de sites web e aplicativos. Vale ressaltar que esses 2 ESBs funcionam  de maneira integrada se comunicando tanto através de serviços (um consome serviço do outro) quanto através de mensageria (JMS).

Voltando à questão do REST+JSON, um terceiro ponto que contribuiu no meu caso, foi a existência de uma documentação acessível e executável para uso dos serviços. Acessível por que, ao invés de documentos do MS Word que ficam “escondidos” em servidores de arquivos dificultando sua localização e navegação, optamos por criar sites que chamamos de Guias de Uso. E executável pois dentro desses sites usamos o Swagger, uma excelente ferramenta que quebra barreiras, permitindo que desenvolvedores possam conhecer e usar os serviços e APIs sem escrever nenhuma linha de código. Sites e o Swagger são justamente o que as soluções de API-M possuem.

Um quinto fator está relacionado à visualização de informações (incluindo estatísticas de acesso/uso) e monitoração. Alguns ESBs  não possuem funcionalidades adequadas nessas 2 áreas, e precisam de outras ferramentas para completar a solução. Isso, de certa forma, não acontece com as soluções de API-M pois, algumas (eu disse “algumas”!) já vem com essas capacidades “integradas” e você não precisa pagar mais (seja licença ou subscrição) para tê-las. Entretanto, é possível integrar ESBs com ferramentas tais como Splunk (Visualização e Dashboards) e Nagios (Monitoração), através da simples leitura de arquivos de liga gerados pelos sevicos/APIs e pela infraestrutura do ESB. É possível que a sua equipe de Infraestrutura já utilize essas ferramentas, o que ajudaria a viabilizar a solução.

Um sexto ponto está relacionado a questões de escalabilidade, mas que afetam tanto ESBs quanto soluções de API-M: Cache e Mensageria. Tanto ESBs quanto API-M geralmente não possuem capacidades de Cache e Mensageria embutidas e, por esse motivo, você tem que recorrer a outros produtos. Uma possibilidade é utilizar uma implementação de JMS open-source (existem várias confiáveis e amplamente utilizadas). Talvez os desenvolvedores da sua empresa estejam usando um desses produtos e sua equipe de Infraestrutura já dê suporte. Para o caso de Cache, também existem soluções open-source que possivelmente os desenvolvedores web da sua empresa já estejam utilizando. Uma que venho usando com bastante sucesso é o Memcached.

Do ponto de vista financeiro, um sétimo ponto está relacionado ao investimento necessário para se adquirir uma solução de API-M. Na maioria dos casos que analisei, tais soluções requereriam um investimento maior do que o feito para adotar um ESB. Então, podemos estar falando de investir em torno de milhão de Reais, tanto em software quanto hardware, em um momento de crise, sendo que praticamente tudo que uma solução de API-M faz pode ser feito com um ESB. Mas para isso deve-se pensar não com uma cabeça de EAI, mas sim com uma cabeça de API Economy.

Por que “praticamente tudo”? Por que geralmente as soluções de API-M possuem uma capacidade que é ausente em um ESB: o Portal ou Store. Apesar disso, é perfeitamente possível alocar uma equipe interna, composta por UX/Design e desenvolvedores web, para desenvolver um Portal e a Store que tenha a cara e os padrões da sua empresa ou produto. Ou seja, apesar de um ESB ganhar de lavada do Gateway em uma solução de API-M. O que falta é o Portal/Store que deveria ser um sites “simples”.

Um sétimo ponto, dá vantagem às soluções de API-M e referem-se à existência de funcionalidades como o controles de vazão, controle de acesso e, autenticação e autorização. Praticamente todas as soluções de API-M que avaliei já vem com essas capacidades e você pode usá-las facilmente com apenas alguns cliques. Isso é possível inclusive para quem precisa de OAUTH. No meu caso já havíamos desenvolvido no nosso ESB um framework para isso. Então, no meu caso, API-M seria uma solução para problemas que já foram resolvidos, ou que ainda não tínhamos. Se você está avaliando uma solução de ESB, vale avaliar se ela já vem com componentes que atendam tais requisitos. Esses pode ser um critério de avaliação importante.

Não estou querendo dizer que soluções de API-M não são adequadas. Estou levantando a bola e relembrando o motivo pelo qual geralmente se adota um ESB. Não foi para tornar a TI mais flexível e fácil de mudar? A API Economy representa uma dessas mudanças, no caso de negócio. Se você projetou corretamente o uso do seu ESB ele deveria suportar tal mudança, o que aumentaria consideravelmente o ROI de um ESB.

Acredito que soluções de API-M são muito mais adequadas àquelas organizações que não possuem uma arquitetura baseada em um componente central, como um ESB, ou que possuem serviços web espalhados por diversos sistemas e aplicações. Note que, ainda assim, talvez será necessário um orquestrador desses diversos serviços, coisa que as soluções de API-M não fazem. A propósito, um tipo de produto muito interessante para quem não tem um ESB e pensa em adotar uma solução de API-M é o chamado Data Services. Um excelente exemplo desse tipo de ferramenta é o WSO2 Data Services Server.

Isso tudo é possível e funciona? Parece que sim. É o que estamos praticando até momento com bastante sucesso. Conseguimos fazer tudo isso seguindo as práticas de Continuous Delivery e usando ferramentas como Jenkins, Nexus, SVN etc. A parceria entre as Equipes de Arquitetura, Integração, Infraestrutura e, principalmente, Qualidade são fundamentais para esse sucesso. Tudo isso, em momento de crise e orçamentos apertados – como estamos vivendo – se torna ainda mais atrativo.

E aí, o que você precisa?

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s