Repositórios e padronização podem ajudar a resolver desafios de integração de automação de rede
Integração sempre foi uma palavra de quatro letras, no sentido de que evoca ranger de dentes e lamentações daqueles que definham em projetos dedicados à sua implementação. Na verdade, 59% dos tomadores de decisão de TI caracterizaram “a integração como o 'calcanhar de Aquiles' de sua organização”. ( The Connected Business Integration 2018 Report )
Superficialmente, a integração começa com uma premissa simples: como compartilhamos dados entre aplicativos? Porque nenhuma aplicação — mesmo um monólito — é uma ilha. Ainda não conheci um aplicativo que não compartilhasse pelo menos um dado com outro aplicativo.
Nós (assim como na indústria) passamos por várias eras de integração. Dos modelos hub and spoke ao barramento empresarial (serviço) e filas de mensagens, a integração é sempre um componente integral de uma estratégia de aplicativo empresarial.
Não chamamos mais isso de Integração de Aplicativos Corporativos (EAI) — principalmente porque acho que isso assusta os mais jovens e faz com que nós, os mais velhos, tenhamos ataques de pânico — mas ainda usamos a palavra "integração". E o usamos cada vez mais fora do mundo do desenvolvimento de aplicativos. Afinal, CI significa integração contínua. Também vemos a integração como algo significativo para o lado da implantação (produção) do mundo. E vemos tanta frustração quanto nossos colegas desenvolvedores de aplicativos, conforme observado por aqueles que ficam frustrados com a falta de ferramentas integradas quando se deparam com a automação da rede.
As operações precisam de integração. Sem ela, não podemos automatizar processos (que é o que é a orquestração), porque os processos necessariamente abrangem vários sistemas, serviços e dispositivos — cada um dos quais provavelmente tem seu próprio domínio operacional e conjunto de ferramentas. Sem integração, você não pode construir um pipeline e, sem um pipeline, as operações ficarão sobrecarregadas pela crescente necessidade de implantação frequente sob demanda.
É aqui que a infraestrutura como código e repositórios pode fornecer alívio. Repositórios são mais do que um lugar onde você pode armazenar praticamente qualquer tipo de artefato, desde arquivos de configuração até programas Python, scripts e modelos. Eles podem ser participantes ativos no seu pipeline de implantação (integrado).
Os repositórios são mais do que baús de armazenamento
Repositórios não são apenas um lugar para armazenar artefatos. Quer dizer, sim, esse é o propósito principal deles, mas eles evoluíram para muito mais do que apenas um armário de armazenamento. Hoje, repositórios como GitLab e GitHub podem ser um componente essencial do pipeline automatizado. Usando gatilhos e eventos, os repositórios atuam não apenas como um local para armazenar artefatos, mas como ferramentas em uma cadeia de ferramentas maior. O commit inicia um trabalho que, quando concluído, invoca um webhook que aciona a próxima etapa do pipeline.
O que é um Webhook?
Às vezes chamado de 'API reversa', um webhook permite que um aplicativo - como um repositório - envie dados em tempo real para outro aplicativo por meio de uma URL/API. Por exemplo, após o commit de uma nova configuração para seu balanceador de carga, o repositório aciona um webhook que, por sua vez, envia a configuração ou URI para a configuração para um aplicativo (ou o balanceador de carga diretamente) que, por sua vez, carrega a nova configuração.
Basicamente, estamos usando repositórios da mesma forma que costumávamos usar um barramento de serviço empresarial para compartilhar dados e iniciar ações em diferentes aplicativos e serviços para concluir um "processo". No mundo dos negócios, esse processo pode ser a conclusão de um pedido do cliente e envolver o sistema de informações do cliente (CIS), um sistema de atendimento de pedidos, faturamento e elementos da cadeia de suprimentos.
No mundo das operações, esse processo abrange serviços de infraestrutura, rede e segurança envolvidos na implementação de um aplicativo ou política.
Ainda mais emocionante para aqueles que citaram "habilidades" como seu maior desafio, os repositórios podem ser controlados quase exclusivamente pela linha de comando. Sim, usando as mesmas habilidades já possuídas pela maioria dos NetOps. Um pouco de bash e um pouco de PERL*, uma API via curl e pronto!
Agora, isso não aborda a necessidade mais profunda de integração na camada do dispositivo, que é expressa na frustração da falta de soluções dos fornecedores. Porque, em última análise, a configuração ou as alterações na configuração que são armazenadas no repositório e acionadas por um Webhook ainda precisam ser traduzidas para a linguagem do dispositivo.
E é aí que a padronização e as soluções entram em cena.
A padronização reduz a carga de integração operacional
Automação é algo em que muitos de nós na F5 estamos focados agora. Uma das soluções que criamos é nossa cadeia de ferramentas de automação F5 . Ele compreende o F5 Application Services 3 Extension (AS3), o F5 Declarative Onboarding (DO), o F5 Telemetry Streaming e o F5 API Services Gateway. Junto com um repositório, eles podem permitir que as organizações criem o pipeline necessário para implantar os serviços de aplicativos que um aplicativo (e a empresa) precisa para manter os aplicativos rápidos, seguros e disponíveis.
Mas Lori, você deve estar pensando, isso não me ajuda com todos os outros dispositivos e serviços que preciso automatizar e integrar.
Verdadeiro. Esta é uma das maneiras pelas quais a padronização em uma plataforma comum de serviços de aplicativos pode ajudar. Como a plataforma (BIG-IP) é a mesma para um amplo conjunto de serviços de aplicativos, você pode usar a cadeia de ferramentas de automação para implantar um WAF, um balanceador de carga e controle de acesso, bem como proteção DDoS, entre outros. Padronizar o mínimo possível de plataformas agrega valor ao reduzir a carga de integração em todas as operações: rede, infraestrutura e segurança.
Isso é verdade dentro dos limites do data center e em um cenário de múltiplas nuvens. A padronização em uma única plataforma em serviços de aplicativos e ambientes de nuvem significa um tempo de retorno mais rápido ao implantar aplicativos em qualquer lugar.
Você pode encontrar o F5 Automation Toolchain (totalmente gratuito) em vários locais:
Então lembre-se, repositórios não são apenas um lugar para armazenar coisas. Eles são uma ferramenta valiosa no seu conjunto de ferramentas de automação que pode ser utilizada para ajudar a automatizar todas as partes distintas do seu pipeline. Padronizar um repositório junto com uma plataforma de serviços de aplicativos pode ajudar muito a reduzir a carga operacional imposta por essa palavra de quatro letras: integração.
*interprete "PERL" como Python ou alguma linguagem de script que seja realmente utilizável. PERL é o único que rima com curl e não encontrei nada bom que rime com wget .