Em qualquer tendência tecnológica, sempre há termos que rapidamente ficam tão cercados de expectativas exageradas que podem se tornar praticamente inúteis. No início, a nuvem foi um deles. De certa forma, ainda é. O DevOps levou vários anos para se definir (se é que isso já aconteceu). Atualmente, o aprendizado de máquina e a IA surfam descalços na onda do hype e não dão sinais de que vão cair dela tão cedo.
Logo atrás de todos eles vem o "como código".
De repente, tudo virou "como código". O mercado não se cansa de "como código", mesmo que a maior parte dele não saiba diferenciar C, C++ e C#. "Como código" se tornou a resposta para a vida, o universo e tudo mais. Não há problema que "como código" não possa resolver, e todo mundo está adotando essa abordagem.
Quando termos são usados indiscriminadamente, sem limites ou definições claras, é importante fazermos uma pausa e garantirmos que *nossas* definições estejam claras. Seria bom se houvesse um comitê de padronização com uma definição no estilo de uma RFC à qual pudéssemos recorrer, mas não há. O mais próximo que temos é o NIST, e vimos como eles conseguiram resolver bem o dilema da nuvem.
Há mais no conceito de "como código" do que apenas infraestrutura como código (IAC). Aiman Najjar, da Pythian, escreveu uma excelente visão geral do cenário atual de infraestrutura como código. Embora eu discorde de que os contêineres devam constituir uma camada própria (do ponto de vista da rede e dos serviços de aplicação, eles são apenas infraestrutura) e de que o Jenkins não se encaixe nesse cenário, de modo geral, o blog dele foi uma excelente forma de entender a relação entre as camadas "como código" e identificar as ferramentas certas para cada tarefa. Além disso, a maioria das discussões sobre infraestrutura como código se concentra na entrega contínua — ou seja, no pipeline que compila, testa, integra e libera um aplicativo para produção. Esse processo não é o mesmo que a implantação contínua, cujo foco é pegar o aplicativo liberado e implantá-lo em um ambiente de produção, juntamente com os serviços de rede e de aplicação necessários.
OBSERVAÇÃO Na utopia dos aplicativos, os pipelines de entrega e implantação são integrados. Mas a maioria de nós (ainda) vive na realidade dos aplicativos, em que os ambientes de produção e desenvolvimento são separados e têm diferentes conjuntos de requisitos e restrições. Daí a necessidade de reconhecer essa separação ao aplicarmos a automação ao pipeline.
Há três camadas distintas surgindo para lidar com as peculiaridades inerentes à TI e ao pipeline de implantação. A principal delas é a complexidade inerente ao ambiente. Aquela linha reta entre o cliente e o aplicativo que desenhamos nos diagramas de rede não engana ninguém. Há muito mais acontecendo nos bastidores do que temos tempo (e paciência) para representar em um diagrama.
A diversidade do próprio pipeline — que inclui hardware desenvolvido para fins específicos, bem como software virtual e baseado em contêineres implantado em COTS — também justifica a divisão do conceito de “como código” em camadas distintas. Embora seja verdade que hardwares mais modernos possam ser gerenciados por meio de uma abordagem como código, pode ser praticamente impossível incorporar hardwares legados (compartilhados) ao processo. Portanto, separar as camadas para refletir mais fielmente o próprio processo de implantação pode viabilizar a inclusão, no pipeline, tanto de soluções baseadas em hardware legado e moderno quanto de serviços baseados em software.
O objetivo é criar uma pilha contínua de TI capaz de oferecer suporte a cronogramas e arquiteturas de implantação específicos para cada aplicativo em um ambiente multinuvem. E, como a implantação é apenas o início do ciclo de vida ativo de um aplicativo, é necessária uma quarta camada voltada para as operações pós-implantação. Essa camada se soma às três camadas principais, que abrangem o provisionamento e a integração da infraestrutura, a configuração e o gerenciamento de serviços e o pipeline de implantação.
A lista de ferramentas não deve ser considerada completa. Existem muitas outras ferramentas e conjuntos de ferramentas. Por exemplo, sabemos, com base em diversas pesquisas e estudos, que a maioria dos profissionais de NetOps prefere scripts Python personalizados para automatizar serviços de rede e de aplicações. Também sabemos que sistemas e stacks de automação de rede, como Cisco ACI, VMware NSX, OpenStack e Red Hat OpenShift, são meios populares de implementar muitas funções na stack de operações contínuas. Simplesmente não há espaço suficiente no diagrama para incluir todas as ferramentas; por isso, foi incluída uma amostra com base na popularidade delas entre as equipes de DevOps. Isso ocorre porque a padronização em todo o pipeline de entrega e implantação será um componente essencial para o sucesso, e é difícil contestar o aproveitamento das habilidades e da experiência já existentes na organização com as ferramentas mais usadas para implementar pipelines de entrega “como código”. Vale observar que não listei nenhuma ferramenta para “operações como código”, pois muitas delas são personalizadas (scripts customizados) ou específicas da tecnologia de um fornecedor — pelo menos por enquanto.
OBSERVAÇÃO Operações como código são o equivalente, na área de TI, ao gerenciamento de processos de negócios (BPM). Com o BPM, os processos de negócios são automatizados. Algumas abordagens de BPM se concentram exclusivamente em fluxos de trabalho muito específicos, enquanto outras podem abranger toda a jornada de interação com o cliente, desde a compra até o pagamento e a entrega. Atualmente, operações como código ainda são uma prática incipiente na área de TI, mas precisarão evoluir para o gerenciamento de processos operacionais para que as empresas possam aproveitar a otimização desses processos da mesma forma que aprenderam a tirar proveito do BPM.
Pilha de operações contínuas
Infraestrutura como Código (IaC)
Seja na nuvem ou no data center, ainda há uma rede que precisa ser configurada. Até mesmo os serviços de nível superior (aqueles que operam nas camadas 4 a 7, também conhecidos como serviços de aplicação) exigem algum conhecimento da topologia da rede para funcionar. Alguns deles talvez precisem ser ativados (ou seja, licenciados) caso você esteja implantando um pipeline totalmente novo. A Infraestrutura como Código é necessária para viabilizar uma abordagem de autoatendimento para a implantação, pois, sem a infraestrutura (software e serviços) disponível, não há nada para configurar nem onde implantar uma aplicação.
Responsabilidades: infraestrutura integração, licenciamento e provisionamento
Configuração como Código (CaC)
Essa é uma questão distinta da configuração, que diz respeito especificamente à necessidade de, bem, configurar políticas e comportamentos próprios do serviço em questão. A configuração pode ser necessária a cada atualização principal do aplicativo. Ela também pode ser necessária a cada atualização secundária. No caso de serviços relacionados à segurança, pode ser necessário realizá-la em caráter emergencial para aplicar correções, atualizar ou fazer upgrade de um determinado serviço. A configuração como código é fundamental para dar suporte a cronogramas e pipelines de implantação específicos de cada aplicativo, bem como para garantir o isolamento dos caminhos de dados dos aplicativos, algo importante para assegurar a estabilidade do pipeline de produção como um todo.
Responsabilidades: configuração do serviço, atualização e aplicação de patches
Pipeline como Código (PaC)
Há também o processo abrangente que define toda a aplicação e seus serviços do início ao fim. Trata-se do pipeline completo, codificado em um processo executável que conduz automaticamente a implantação. O pipeline como código é o elo entre IaC e CaC, integrando-os para formar o que chamamos de pipeline de implantação. É no pipeline que se obtêm os maiores ganhos de velocidade e eficiência, pois ele permite eliminar os tempos de espera entre as etapas necessárias do processo.
Responsabilidades: automação do processo de implantação
Operações como Código (OaC)
Esta é a camada de operações contínuas. É nela que ocorrem o monitoramento e os alertas, o dimensionamento automático e a descoberta. Nessa camada, o objetivo é codificar os processos operacionais em um sistema capaz de executá-los de forma autônoma. O dimensionamento automático é um dos processos operacionais codificados com mais frequência e envolve vários sistemas. No entanto, a coleta de telemetria para análise é outro processo operacional que exige atenção, assim como as possíveis ações realizadas com base nessa telemetria, que permitem fazer ajustes (automáticos) para otimizar o caminho dos dados ou o desempenho da aplicação. Esses processos operacionais têm configurações próprias e entram em ação após a conclusão do processo de implantação.
Responsabilidades: automação de fluxos de trabalho operacionais
Analisar a implantação contínua sob a perspectiva da pilha de operações contínuas pode proporcionar uma abordagem estratégica para automatizar o pipeline de produção. Ao separar as camadas e as responsabilidades, torna-se mais fácil enfrentar a desafiadora tarefa de automatizar as atividades de TI de modo a viabilizar a abordagem de autoatendimento desejada por muitas organizações e cada vez mais exigida pelas áreas de negócios. Isso também abre caminho para as operações contínuas por meio de operações como código, uma evolução necessária no uso da automação em TI.
Agora, talvez essa não seja a "única maneira correta" de enxergar os esforços de automação associados ao pipeline de implantação. Mas é uma maneira, e ela permite que o mercado comunique claramente o que faz ou deixa de fazer.
Isso significa que você pode ter certeza do que quero dizer quando falo em infraestrutura como código ou configuração como código, especialmente no que diz respeito aos produtos da F5.
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...