O ITPA foi criado pois os Centros de Operações de Rede (Network Operations Centers - NOCs) precisavam de meios confiáveis para automatizar tarefas recorrentes, executadas para corrigir problemas de rede e infraestrutura detectados por sistemas de monitoramento.
Antes disso, o passo-a-passo para se fazer isso eram escritos em folhas de papel armazenadas em fichários de 3 argolas. Conhecidos como “Run Book Scripts”, eles continham uma lista de ações que um administrador de sistema executaria para confirmar se ocorreu uma interrupção e coletar diagnósticos ou reiniciar um servidor.
As primeiras versões do ITPA, então conhecidas como Run Book Automation (RBA), foram produzidas por empresas como Opsware, RealOps e Opalis. Embora suas arquiteturas sejam diferentes, a partir da perspectiva do usuário todas fornecem um método visual de construção de um conjunto interconectado de ações (conhecido como fluxos).
As ações dentro dos fluxos podem ser integrações com outros sistemas (diretamente ou por meio do OS shell), bem como construções de programação comuns, como instruções condicionais ou loops.
O objetivo de criar fluxos era fornecer uma maneira repetível de executar processos comumente exigidos, semelhante ao objetivo de criar Run Book Scripts nos NOCs das primeiras empresas de tecnologia. Esses fluxos, que foram criados por “Citizen Integrators” ou uma equipe de TI de desenvolvedores para processos mais complexos, poderiam então ser facilmente executados por meio de uma API exposta ou de uma interface de linha de comando (Command Line Interface – CLI).
Como isso se compara ao iPaaS?
Resumindo a seção anterior em seus fundamentos, o ITPA pode:
Construir visualmente grupos de ações chamados fluxos;
Integra-se com outros sistemas diretamente ou usando comandos através do sistema operacional via shell;
Invocar fluxos por meio de uma API ou algum outro mecanismo comumente utilizado;
Ser usado tanto por “Citizen Integrators” quanto por desenvolvedores.
Não fique surpreso caso isso lhe parece familiar – esses recursos também são os mesmos que se espera encontrar em uma plataforma iPaaS como a Anypoint Platform da MuleSoft.
As diferenças entre uma solução ITPA e uma plataforma iPaaS, no entanto, são mais profundas do que isso. Enquanto as soluções ITPA se referem estritamente à execução de um processo muito parecido com scripts de shell Unix ou arquivos CMD do Windows, um iPaaS oferece esse recurso e muito mais:
Execução flexível: ao invés de limitar a execução aos momentos em que o fluxo foi explicitamente invocado por outro aplicativo que “chama” uma API, os fluxos do iPaaS também podem usar mecanismos pub/sub, execução baseada em cronograma e execução baseada em eventos.
Design reutilizável: os ITPAs se posicionam como um meio de criar soluções táticas para usar problemas específicos de caso: seu servidor está inativo? Projete um fluxo para isso. Você precisa provisionar um servidor? Projete um fluxo para isso. Em contraste, um iPaaS adota a filosofia de que os ativos criados dentro dele devem ser reutilizáveis o máximo possível para evitar ter que “reinventar a roda” se um requisito de processo semelhante surgir no futuro.
Focado na integração: Todas as soluções ITPA oferecem formas de integração com outras soluções. A amplitude de sistemas com os quais eles podem se integrar, entretanto, não é tão ampla quanto um iPaaS, para o qual esta é uma competência central.
Construído com a governança em mente: as soluções de ITPA não se destinam a fornecer recursos robustos na área de governança (ou seja, controlar quem deve ser capaz de executar um processo). Isso não quer dizer que o RBAC (Role-Based Access Control) não exista, mas as soluções ITPA normalmente não vão mais fundo do que isso quando se trata de controlar o acesso ou exigir autenticação/autorização (usando OAuth2 ou algo semelhante) em para executar um fluxo.
A questão que imediatamente vem à mente é a seguinte: pode um iPaaS ser usado no lugar de uma solução ITPA? A resposta é sim! Como discutido, um iPaaS fornece um superconjunto do que uma solução ITPA provê – além de ter vários outros recursos que o último não oferece.
Interessado em aprender mais? Saiba mais sobre nossa oferta de produto mais recente – MuleSoft Composer for Salesforce – que torna mais fácil conectar qualquer aplicativo e dados ao Salesforce, de maneira semelhante às soluções ITPA.
Este artigo foi escrito por Larry Salomon e publicado originalmente em Prensa.li.