Como acontece com toda tecnologia que passa a dominar as discussões sobre data centers, o DevOps atualmente sofre com o desgaste causado pelo excesso de definições. Na verdade, a esta altura, acho que já é exaustão, mas é difícil distinguir uma coisa da outra. Basta dizer que o DevOps está tão longe de ter uma definição universalmente aceita quanto a nuvem e as SDNs.
Mas o DevOps é único no sentido de que os conceitos que o compõem também são frequentemente confundidos e tratados como se fossem a mesma coisa. Por exemplo, CD pode significar “entrega contínua” ou “implantação contínua”. Esses dois conceitos não são iguais e não devem ser confundidos nem tratados como equivalentes. A Puppet Labs fez um excelente trabalho ao ilustrar a diferença em uma publicação no blog:
Você perceberá que a principal diferença é se a implantação em produção é “manual” (entrega contínua) ou “automatizada” (implantação contínua).
A questão é que há uma quantidade significativa de trabalho naquela pequena caixa laranja chamada “implantar em 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.). Trata-se também de implantar todos os serviços de rede e de aplicativos necessários para entregar esse aplicativo ao consumidor final. É aí que entram os serviços de aplicativos e que a entrega de aplicativos (no sentido de produção, não no de desenvolvimento) passa a fazer parte do pipeline de implantação contínua.
Para automatizar a etapa de “implantação em produção” no pipeline de implantação contínua, muitos componentes precisam ser provisionados, configurados e testados. Isso inclui desde serviços básicos de rede e segurança (como firewalls) até serviços de disponibilidade (balanceamento de carga) e desempenho (aceleração, cache etc.). Em média, as organizações usam 11 serviços diferentes de entrega de aplicações para atender à necessidade de aplicações rápidas, seguras 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 (é como aquela charada de St. Ives, para quem está acompanhando) tem um número variável de características que precisam ser configuradas, opções definidas como verdadeiras ou falsas, algoritmos selecionados, rotas estabelecidas etc.
Em outras palavras, mudar de “manual” para “automático” não é nem de longe tão fácil quanto parece.
O que está atrasando a rede?
Um obstáculo significativo à automação desses processos está nas diferenças entre os componentes compartilhados e os específicos de cada aplicativo. A Infraestrutura como Código é possível no âmbito da infraestrutura de aplicativos justamente porque podemos dedicar uma infraestrutura (como um servidor web ou balanceador de carga) a um aplicativo. Isso significa que seu arquivo de configuração funciona como uma espécie de microsserviço: ele é localizado e voltado à prestação de serviços para um único aplicativo.
Quando passamos para o mundo das redes e dos serviços de aplicativos, nem sempre é assim. Um roteador ou switch, por exemplo, é projetado especificamente para fornecer conectividade e serviços de encaminhamento para vários aplicativos. Isso significa que os arquivos de configuração necessariamente abrangem vários aplicativos. Embora o versionamento possa ajudar nesse caso, a realidade é que as configurações estão muito mais vinculadas a um dispositivo do que a um aplicativo. O mesmo se aplica aos serviços de aplicativos e à segurança.
Portanto, embora seja muito bom que todos estejamos avançando rumo a um mundo em que a API é a CLI, também precisamos atender à necessidade de oferecer suporte a um paradigma por aplicativo (ou centrado no aplicativo, se preferir), no qual as configurações possam ser gerenciadas por aplicativo .
Isso significa adotar uma arquitetura de rede no estilo de microsserviços, na qual os serviços são implantados e configurados para cada aplicativo. Isso pode assumir a forma de “dispositivos” dedicados (virtuais ou físicos; o formato é irrelevante para esta discussão) ou de configurações específicas para cada aplicativo, como modelos.
Já chegamos lá?
Estamos chegando mais perto, com modelos declarativos de provisionamento e gerenciamento que usam APIs para implantar modelos (isso é infraestrutura como código) para cada aplicação, mas ainda não chegamos lá. Ainda há muito trabalho a ser feito para descobrir como orquestrar a automação necessária para viabilizar plenamente uma implantação contínua bem-sucedida.
Os silos de rede, infraestrutura, serviços de aplicativos e segurança precisam ser incluídos se quisermos passar do “manual” para o “automático” naquela etapa de “implantação em produção”, que é fundamental para concluir a transição 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 totalmente os processos que, em última análise, viabilizam a implantação contínua em produção.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...