Os construtores mestres (DevOps) também precisam de colaboração

Se você é pai ou mãe (e mesmo que não seja, não vou te julgar), você provavelmente já foi submetido a assistir ao filme Lego. Mais de uma vez.

Sou da opinião de que provavelmente deveria ser uma observação obrigatória para qualquer empresa que esteja pensando em adotar o DevOps.

Seriamente.

Isso porque uma das (muitas) lições aprendidas é que até mesmo os Master Builders, especialistas em seu domínio específico, precisam colaborar com outros para salvar o mundo e mover um aplicativo para seu estado desejado e implantado. Ou seja, alguém que não esteja preso na produção com o 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 compostas necessárias para isso. E eles fazem isso, com frequência e admiravelmente, no filme, ao criarem criações completas que podem destruir, voar, correr e atirar para salvar o dia. Mas quando chegou a hora de agir no cenário "maior"; não apenas construir criações individuais e então orquestrar (viu o que eu fiz aí?) uma série de eventos para frustrar a trama do vilão maligno, eles não conseguiram. Eles precisavam de um cara que gostasse de consultar instruções e carregasse uma lista de verificação com os procedimentos necessários para que todos caminhassem 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 à medida que ele escala o muro entre o desenvolvimento e o "resto da TI", há uma necessidade muito real de coordenação em todos os quatro domínios operacionais (ou seja, segurança, armazenamento, computação e rede) para garantir que os construtores mestres de cada conjunto individual de serviços e sistemas não estejam trabalhando no vácuo.

Mesmo os desenvolvedores que adotam microsserviços, com seu “código local e independente de outros serviços”, sabem que tal mentalidade e abordagem só funcionam se houver interfaces (APIs) claramente definidas e documentadas com as quais outros serviços possam se comunicar. Essas interfaces não são (ou não deveriam ser) desenvolvidas no vácuo, sem uma compreensão de como outros serviços irão invocá-las.

O mesmo acontece no lado da produção do muro, onde todos os quatro domínios operacionais precisam se comunicar em algum momento para permitir que a implantação contínua realmente aconteça. Existe um plano mestre; um conjunto de instruções que devem ser seguidas, mesmo que sejam detalhados como cada serviço individual ou conjunto de serviços pode ser criado. Eles devem, em algum momento, ser orquestrados em um processo abrangente que conduza a implantação de uma ponta a outra do pipeline de produção.

Os mestres construtores de cada domínio não podem trabalhar de forma totalmente independente uns dos outros. Eles precisam coordenar, cooperar e considerar como sua parte do quebra-cabeça se encaixa no grande plano para salvar o mundo (de aplicativos) no qual o negócio é construído hoje.

Uma das maneiras de começar é criar gráficos de conjuntos de impacto. Lembrei-me disso depois de ler um artigo recente sobre acoplamento de código, The 80% Rule of Program Coupling , com foco na segurança. O artigo é muito focado em código e na construção de gráficos de dependência específicos para pessoas com mentalidade de desenvolvimento, mas se você elevar o nível (abstrair) e considerar funções/procedimentos/métodos como sistemas em produção, poderá começar a ver como isso pode ser útil. Entender o nível de dependência que uma implantação de aplicativo tem em serviços específicos (ou mesmo no nível de domínio, para começar) pode fornecer insights valiosos para entender quanta coordenação será necessária entre os grupos para que tudo seja concluído e para poder traçar um plano de como atingir esse objetivo.

Um dos melhores exemplos é que quase tudo depende da implantação prévia dos principais serviços de rede. Isso é verdade não apenas para o aplicativo e seus componentes dependentes, mas para a segurança e serviços de ordem superior (app) que entregam o aplicativo. Balanceamento de carga, segurança de aplicativo web e até mesmo o firewall dependem de atributos de rede para funcionar. Entender essas dependências (o fator de acoplamento) entre sistemas e serviços gerenciados por diferentes grupos (silos) dentro da TI pode contribuir muito para encaminhar a necessidade de comunicação e colaboração para alcançar até mesmo a semelhança de implantação contínua.

Até mesmo os Mestres Construtores precisam entender como sua criação se encaixa no cenário geral. A aplicação de técnicas e ferramentas de desenvolvimento ao mundo cada vez mais automatizado e baseado em código das operações de TI os ajudará a construir melhor as interfaces necessárias para integrar sua parte do quebra-cabeça ao grande esforço de construção que é a implantação contínua.