Cadeias de ferramentas de entrega e implantação: Ainda sujeito ao axioma do elo mais fraco
Hoje em dia, é difícil passar por aqui sem que alguém mencione seu conjunto de ferramentas de suporte ao DevOps. Todo mundo tem uma (sim, até nós) e todas elas são habilitadas pela (outra) economia de API. De acordo com a Wikipedia , uma cadeia de ferramentas DevOps é: “um conjunto ou combinação de ferramentas que auxiliam na entrega, desenvolvimento e gerenciamento de aplicativos durante todo o ciclo de vida de desenvolvimento de software, conforme coordenado por uma organização que usa práticas DevOps ”.
Agora, isso se concentra principalmente no aplicativo, mas também há o lado da produção da casa – onde o software geralmente passa boa parte de sua vida (pelo menos é o que se espera). A mesma definição também funciona para isso, com a ressalva de que seu foco (com base na minha perspectiva) está no “provisionamento, configuração e gerenciamento de serviços de rede e aplicativo durante todo o ciclo de vida do aplicativo, conforme coordenado por uma organização que usa práticas de DevOps”. No contexto do DevOps tradicional, esse foco expande a fase de “lançamento” no ciclo e abrange “atividades relacionadas ao lançamento” que incluem provisionamento e implantação de software na produção. Isso inclui necessariamente (ou deveria incluir) os serviços de rede e aplicativos necessários para permitir a entrega segura de aplicativos aos usuários-alvo.
O problema é que nenhum fornecedor ou projeto de código aberto contém todas as ferramentas necessárias para atingir o sonho utópico de implantação contínua (a propósito, esse é o lado da produção). Na verdade, algumas das mesmas ferramentas usadas no desenvolvimento de aplicativos também são usadas na produção. Cada vez mais, vemos um cruzamento entre os dois mundos, o que é um bom sinal para os "devops" em geral, pois mostra alguma normalização entre o que são duas organizações tradicionalmente muito arraigadas, com pouco em comum além do aplicativo.
Então você pode usar o Puppet ou o Chef em combinação com o VMware e o Cisco para automatizar uma pilha completa de serviços de rede e aplicativos para dar suporte à necessidade de um aplicativo para segurança, identidade e escala. Você criou os modelos e scripts aplicáveis necessários para fazer isso e verificou se eles estão corretos, talvez usando o Postman e seus recursos de script para testar a infraestrutura virtual no laboratório. Você decidiu que o git é uma boa escolha como repositório para artefatos de configuração porque o desenvolvimento de aplicativos já o utiliza e pode fornecer orientação e talvez até mesmo realizar uma ou duas sessões de treinamento. E você pode ir além e começar a criar um aplicativo (ou criar uma implementação do OpenStack ) para orquestrar o processo e fornecer autoatendimento de serviços individuais. Você está essencialmente definindo a cadeia de ferramentas de implantação.
E é aí que o Axioma do Elo Mais Fraco começa a mostrar sua cara feia. Você conhece a premissa: uma corrente é tão fraca quanto seu elo mais fraco. “Forte” é enfatizado aqui porque podemos substituí-lo por outras características como “confiável” ou “seguro” ou “escalável” e o axioma permanece verdadeiro. Isso é importante porque, à medida que você começa a definir a cadeia de ferramentas que dará suporte à implantação contínua , cada “elo” dessa cadeia pode se tornar um ponto de falha, onde a segurança, a escala ou a disponibilidade são comprometidas.
Assim como o planejamento, a verificação e o monitoramento são elos essenciais na cadeia de ferramentas DevOps, eles também devem ser na cadeia de ferramentas NetOps. Isso é especialmente importante para monitoramento, onde aplicativos e infraestrutura (serviços de rede e aplicativos) se cruzam mais em ambientes de produção. É por meio do monitoramento (visibilidade) que uma visão abrangente de tudo, desde transações comerciais até solicitações e respostas individuais, pode ser entendida em caso de falha.
A configuração também necessariamente une as cadeias de ferramentas, pois a configuração dos serviços de rede e de aplicativo pode ser (e geralmente é) peculiar a um determinado aplicativo.
Embora os mecanismos de empacotamento e liberação possam utilizar ferramentas semelhantes, eles são preocupações distintas que frequentemente apresentam grande disparidade em termos de necessidades. Como os serviços de rede e aplicativos podem ser implantados em infraestrutura compartilhada, ferramentas que pressupõem uma abordagem de sistema único podem não ser apropriadas para NetOps. Por outro lado, o uso de modelos é cada vez mais comum para implantar rapidamente serviços padronizados em produção, mas raramente são aplicáveis em DevOps, onde os aplicativos apresentam um alto grau de exclusividade.
Independentemente disso, ambas as cadeias de ferramentas compartilham um ponto em comum: a fraqueza de um elo que infecta toda a cadeia. Mesmo que você esteja contando principalmente com implantações manuais que aproveitam scripts, ainda há uma cadeia de ferramentas que representa o processo geral de entrega e implantação. As pessoas podem, e são, elos nas cadeias de ferramentas que entregam e implantam software hoje. E acontece que quando um elo crítico está faltando – porque Bob está fora com a última gripe – o processo falha. A cadeia de ferramentas falha na entrega (ou implantação).
É importante que, à medida que você continua avançando com sua transformação digital interna, reconheça a importância das cadeias de ferramentas DevOps e NetOps e não negligencie nenhum dos elos que as compõem. Não prestar atenção a apenas um dos elos à medida que avançamos em direção à meta de implantação contínua enfraquecerá toda a cadeia. À medida que os negócios dependem cada vez mais dessas cadeias interligadas, um elo fraco quebra mais do que apenas um processo, ele quebra o negócio também.