Uma das preocupações constantes de arquitetos corporativos e líderes de TI é com a arquitetura iPaaS.
Isso, porque muitos estão considerando ter a plataforma para reduzir a complexidade, os custos e o tempo de seus processos de integração. Mas não só para isso: para alavancar o uso e o valor obtido de tecnologias como microsserviços, IoT, analytics, entre outras.
E fazem bem. O segmento está em plena evolução, com alternativas capazes de atender diversas necessidades de integração, incluindo infraestrutura on-premise, cloud e híbrida, nichos de mercado e empresas de qualquer porte. A APIPASS é uma delas.
Mesmo assim, a preocupação com a arquitetura não se dá por acaso. Um iPaaS permite que dados sejam levados de soluções para outras. Além das integrações serem críticas em muitos casos para a eficiência operacional, questões como segurança, desempenho e disponibilidade estão em jogo.
Por isso, neste artigo, vamos mostrar o que está debaixo dos panos da APIPASS. Você vai entender como é a arquitetura do nosso iPaaS, assim como os motivos para ela ter sido criada dessa forma.
Desenho de arquitetura APIPASS
Infraestrutura do APIPASS
Todas as aplicações do iPaaS da APIPASS estão na nossa nuvem privada na AWS e seguem as melhores práticas de segurança recomendadas pelo provider.
Os servidores estão localizados na região Norte da Virgínia. Nem a APIPASS nem nossos clientes têm acessos a essa máquinas. Quaisquer serviços externos que precisem ser acessados por nossas aplicações passam por um NAT gateway, assim como comunicações externas com nossas aplicações passam por um API gateway e load balancer.
Temos dentro da plataforma APIPASS dois principais componentes que rodam de maneira completamente independente:
1. Flow core e flow trigger
São os serviços responsáveis por executar os fluxos de integração. Tudo que nossos clientes ou que as squads que atuam para nossos clientes configuram em termos de fluxo é o trigger e o core que executam.
Entre os triggers que nossa aplicação suporta estão REST API, scheduler, Kafka, SQS, Webhook, e-mails, polling, entre outros. Já no flow estão as ferramentas para desenvolvedores, para leitura e escrita de dados, para file operations e sistemas de mensageria.
Trigger e core são a parte crítica do iPaaS, portanto. Se eles falharem, os fluxos param de funcionar. Daí a importância de adotar uma infraestrutura robusta. Na APIPASS, os clientes têm liberdade de escolha. Trigger e core podem rodar:
- na nuvem privada da APIPASS na AWS:
- na nuvem já adotada pelo cliente; ou
- na infraestrutura on-premise do cliente.
Quando é a APIPASS que faz a montagem das máquinas na AWS, damos resiliência aos cores tornando-os serviços dedicados. Cada empresa tem instâncias para rodá-los separadamente. Com isso, garantimos que as integrações de um cliente não sejam impactadas por fluxos de outros clientes.
Além disso, as instâncias de cada cliente também são customizadas. O motivo é que cada tipo de integração consome um recurso de máquina diferente. Quando temos um volume grande de requests em uma integração só, precisamos de mais RAM. Quando temos muitas integrações rodando ao mesmo tempo, precisamos de mais processador. Fluxos muito pesados vão exigir uma máquina maior, seja em termos de RAM ou de CPU.
2. Web application
Portal que os usuários acessam para configurar os fluxos e autorizações e para acompanhar execuções e o dashboard.
A web app, diferentemente do core, é uma instância única, compartilhada para todos os clientes desde a nuvem da APIPASS na AWS. Ou seja, todos acessam a mesma instância. Então, no caso de clientes que têm o core rodando dentro da infraestrutura interna, eles terão uma operação híbrida, já no os que hospedam o core em outro cloud provider terão uma multicloud.
Para garantir a resiliência, cada componente da web app é um microsserviço, isto é, roda completamente separado. Desse modo, o funcionamento de um não interfere no de outro e, no caso de uma falha em um, os outros se mantêm.
Como web app e core se comunicam
No APIPASS, core e web app são serviços que rodam completamente desacoplados. Na prática, a web app não sabe que existe um core e vice-versa. Como se dá a comunicação entre ambos?
Eles se comunicam por mensageria. Quando um usuário do iPaaS APIPASS configura um fluxo na web app e o salva, uma mensagem é enviada ao flow trigger e outra para o flow core daquele cliente, via sistema de filas. Dentro da mensagem tem um JSON.
Como comunicações externas entram no ambiente APIPASS
Comunicações externas entram no ambiente da APIPASS de duas formas:
1. API gateway
O API gateway centraliza a comunicação com as APIs da web app, levando diretamente a elas. Além de centralizar as APIs, ele também valida os acessos às APIs e direciona cada tipo de chamada para o microsserviço correspondente.
3. Load balancing
Esse recurso faz a conexão com os cores. Toda vez que algo é executado dentro do core é o load balancing que está recebendo essa chamada e enviando para o core.
Além de direcionar chamadas, o load balancing também é o responsável pelo autoscaling. Ele mede o uso da aplicação flow core e, se para manter a performance, os fluxos precisam de mais RAM ou mais CPU, sobe automaticamente uma nova instância no core e começa a distribuir a carga. Ao cair a demanda, ele vai desligando uma a uma as instâncias provisionadas.
Como o iPaaS APIPASS se comunica com sistemas externos
No caso de ser o iPaaS APIPASS que se comunica com sistemas externos, como é o caso de sistemas on-premise, temos um NAT gateway e três formas de acessá-los:
- Firewall: cliente libera um IP nosso, para a APIPASS conectar-se aos serviços que rodam on-premise, sejam webservices, API, banco de dados ou legados como FTP.
- VPN
- Híbrido: caso de quando o core do APIPASS está rodando dentro da infraestrutura do cliente, que não exige liberação de acessos. Assim, apenas a configuração do fluxo na web app fica na nuvem APIPASS.
O papel do NAT gateway
O iPaaS APIPASS roda em uma rede privada. É esse isolamento que garante boa parte da segurança de nosso core. Como as máquinas não têm acesso à internet, para acessar itens via internet, saindo da nossa aplicação, precisamos de um NAT gateway.
O NAT gateway faz com que possamos conectar desde uma nuvem privada serviços externos, como internet, outra nuvem privada ou redes on-premise, sem que possamos receber conexões não solicitadas desses outros ambientes.
Arquitetura iPaaS APIPASS: escolha a melhor plataforma
Conhecer a arquitetura por baixo do iPaaS que você vai adotar é fundamental para entender se e como a ferramenta responde a requisitos de segurança, desempenho e resiliência de sua operação.
Na APIPASS, nós sabemos disso. Por isso, montamos uma arquitetura para atender a todos os desafios de integrações complexas.
Então, para saber mais detalhes e para respondermos diretamente à suas dúvidas, entre em contato com um de nossos consultores.