Se você tem filhos (e, mesmo que não tenha, sem julgamentos), provavelmente já teve que assistir a Uma Aventura Lego. Mais de uma vez.
Na minha opinião, esse filme provavelmente deveria ser obrigatório para qualquer empresa que esteja pensando em adotar DevOps.
É sério.
Isso porque uma das (muitas) lições aprendidas é que até mesmo os Mestres Construtores, especialistas em suas respectivas áreas, precisam colaborar com outras pessoas para salvar o mundo levar uma aplicação ao estado desejado de implantação. Ou seja, um estado em que ela não fique presa em produção pelo assustador Kragle tecnológico que são os processos manuais.
Individualmente, os mestres construtores conseguem visualizar não apenas o que querem construir, mas também todas as peças necessárias para isso. E, no filme, eles fazem isso com frequência e de forma admirável, criando num piscar de olhos obras completas capazes de esmagar, voar, correr e sair atirando para salvar o dia. Mas, quando chegou a hora de pensar no panorama “maior” — não apenas construir criações individuais, mas também orquestrar (viram o que eu fiz aqui?) uma série de eventos para frustrar o plano do Vilão Malvado —, eles não conseguiram. Precisaram do cara que gostava de consultar instruções e carregar uma lista de verificação com os procedimentos necessários para fazer com que todos seguissem na mesma direção.
No nosso caso, essa direção é a produção.
À medida que a implantação contínua se torna uma possibilidade real e o objetivo final do DevOps, superando a barreira entre o desenvolvimento e o “restante da TI”, surge uma necessidade concreta de coordenação entre os quatro domínios operacionais — segurança, armazenamento, computação e rede — para garantir que os principais responsáveis por cada conjunto de serviços e sistemas não trabalhem de forma isolada.
Até mesmo os desenvolvedores que adotam microsserviços, com seu princípio de “código local e independente de outros serviços”, sabem que essa mentalidade e abordagem só funcionam se houver interfaces (APIs) claramente definidas e documentadas por meio das quais outros serviços possam se comunicar. Essas interfaces não são (ou não deveriam ser) desenvolvidas de forma isolada, sem compreender como outros serviços irão invocá-las.
O mesmo se aplica ao lado de produção dessa divisão, onde os quatro domínios operacionais precisam se comunicar em algum momento para que a implantação contínua realmente aconteça. Existe um plano geral, um conjunto de instruções que deve ser seguido, independentemente dos detalhes de como cada serviço ou conjunto de serviços possa ser criado. Em algum momento, eles precisam ser orquestrados em um processo abrangente que conduza a implantação de uma ponta à outra do pipeline de produção.
Os principais responsáveis pela construção em cada domínio não podem trabalhar de forma totalmente independente uns dos outros. Eles precisam se coordenar, cooperar e considerar como sua peça do quebra-cabeça se encaixa no grande plano para salvar o mundo dos aplicativos no qual os negócios se baseiam atualmente.
Uma das maneiras de começar é mapear graficamente os conjuntos de impacto. Lembrei-me disso depois de ler um artigo recente sobre acoplamento de código, A regra dos 80% do acoplamento de programas, sob a perspectiva da segurança. O artigo é bastante focado em código e na criação do que, na prática, são grafos de dependências voltados especificamente para profissionais de desenvolvimento. No entanto, se você elevar o nível de abstração e considerar funções/procedimentos/métodos como sistemas em produção, começará a perceber como isso pode ser útil. Entender o grau de dependência que a implantação de uma aplicação tem de serviços específicos (ou até mesmo, inicialmente, no nível do domínio) pode fornecer informações valiosas para compreender quanta coordenação entre as equipes será necessária para realizar o trabalho e elaborar um plano para alcançar esse objetivo.
Um dos melhores exemplos é que praticamente tudo depende de os principais serviços de rede serem implantados primeiro. Isso vale não apenas para a aplicação e seus componentes dependentes, mas também para os serviços de segurança e de nível superior (da aplicação) responsáveis por disponibilizá-la. O balanceamento de carga, a segurança de aplicações web e até mesmo o firewall dependem de atributos da rede para funcionar. Compreender essas dependências (o fator de acoplamento) entre sistemas e serviços gerenciados por diferentes grupos (silos) dentro da TI pode contribuir muito para reforçar a necessidade de comunicação e colaboração a fim de alcançar ao menos algo semelhante à implantação contínua.
Até mesmo os mestres construtores precisam entender como sua criação se encaixa no panorama geral. Aplicar técnicas e ferramentas de desenvolvimento ao mundo das operações de TI, cada vez mais automatizado e baseado em código, ajudará esses profissionais a criar melhor as interfaces necessárias para integrar sua peça do quebra-cabeça ao grande esforço de construção que é a implantação contínua.
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...