Serviços de Aplicação e o Pipeline de CD

Como acontece com todas as tecnologias que dominam as conversas sobre data centers, o DevOps está atualmente sofrendo de fadiga de definição. Na verdade, neste ponto, acho que é exaustão, mas a linha entre os dois é difícil de determinar. Basta dizer que DevOps está tão longe de ter uma definição universalmente aceita quanto nuvem e SDN.

Mas o DevOps é único porque seus conceitos compostos também são frequentemente confundidos e combinados. Por exemplo, CD pode ser entendido como “entrega contínua” ou “implantação contínua”. Esses dois não são a mesma coisa e não devem ser confundidos ou relacionados. A Puppet Labs fez um ótimo trabalho ilustrando a diferença em uma postagem de blog :

Você notará que a diferença definidora é se a implantação na produção é “manual” (entrega contínua) ou “automatizada” (implantação contínua).  

O problema é que há uma quantidade significativa de trabalho naquela caixinha laranja chamada “implantar para produção” que precisa ser automatizada. Não se trata apenas de implantar o aplicativo e suas dependências (bancos de dados, outros serviços, infraestrutura, etc.). Também se trata de implantar todos os serviços de rede e aplicativos necessários para entregar esse aplicativo ao consumidor final.  É aqui que os serviços de aplicativos entram em cena e onde a entrega de aplicativos (no sentido de produção, não de desenvolvimento) entra no pipeline de Implantação Contínua.

Para automatizar a etapa de “implantação para produção” no pipeline de Implantação Contínua, muitas partes móveis precisam ser provisionadas, configuradas e testadas. Isso significa tudo, desde redes básicas até segurança (como firewalls), disponibilidade (balanceamento de carga) e serviços de desempenho (aceleração, cache, etc.). Em média, as organizações usam 11 serviços diferentes de entrega de aplicativos para atender à necessidade de aplicativos rápidos, seguros e disponíveis. Cada um deles precisa ser implantado (provisionado e configurado) e alguns dependem da implantação de outros.

Cada um desses serviços (isso é como aquele enigma de St. Ives, para aqueles que estão brincando) tem um número variável de características que devem ser configuradas, opções definidas como verdadeiras ou falsas, algoritmos selecionados, rotas estabelecidas, etc.

Em outras palavras, fazer a mudança de “manual” para “automático” não é tão fácil quanto parece.

O que está segurando a rede?

Um obstáculo significativo na automatização desses processos pode ser encontrado nas diferenças entre componentes compartilhados e por aplicativo. A infraestrutura como código é possível no âmbito da infraestrutura de aplicativos precisamente porque podemos dedicar infraestrutura (como um servidor web ou balanceador de carga) a um aplicativo. Isso significa que seu arquivo de configuração é como um microsserviço: ele é localizado e focado em fornecer serviços para um aplicativo.

Quando passamos para o mundo das redes e serviços de aplicativos, isso nem sempre acontece. Um roteador ou switch, por exemplo, é projetado especificamente para fornecer serviços de conectividade e encaminhamento para vários aplicativos. Isso significa que os arquivos de configuração necessariamente abrangem múltiplos aplicativos. Embora o versionamento possa ajudar aqui, continua sendo uma realidade que as configurações estão muito mais vinculadas a um dispositivo, não a um aplicativo. O mesmo vale para serviços de aplicativo e segurança.

Então, embora seja muito bom que estejamos todos caminhando em direção a um mundo onde a API é a CLI, também temos que abordar a necessidade de oferecer suporte a um paradigma por aplicativo (ou centrado no aplicativo, se preferir) em que as configurações possam ser gerenciadas por aplicativo .

Isso significa migrar para uma arquitetura de rede no estilo microsserviços, na qual os serviços são implantados e configurados por aplicativo. Isso pode assumir a forma de “dispositivos” dedicados (virtuais ou de hardware, o fator de forma é irrelevante para os propósitos desta discussão) ou configurações específicas de aplicativos, como modelos .

Já chegamos?

Estamos chegando perto, com modelos declarativos para provisionamento e gerenciamento que fazem uso de APIs para implantar modelos (ou seja, infraestrutura como código) por aplicativo, mas ainda não chegamos lá. Ainda há muito trabalho a ser feito para descobrir como orquestrar a automação necessária para permitir totalmente uma implantação contínua bem-sucedida.

A rede, a infraestrutura, os serviços de aplicativos e os silos de segurança devem ser incluídos se quisermos fazer a mudança de "manual" para "automático" para a etapa de "implantação para produção", que é essencial para concluir a mudança da entrega contínua para a implantação contínua. E isso significa mais trabalho na camada de automação, bem como na orquestração abrangente necessária para automatizar completamente os processos que, em última análise, impulsionam a implantação contínua na produção.