Sempre há termos em qualquer tendência tecnológica que rapidamente se tornam tão badalados que podem se tornar praticamente inúteis. Cloud era uma só, no princípio. De certa forma, ainda é. O DevOps levou vários anos para ser resolvido (se é que foi resolvido). O aprendizado de máquina e a IA estão atualmente surfando descalços na onda do hype e não mostram sinais de que irão desaparecer tão cedo.
Logo atrás de todos eles está "como código".
De repente tudo está "como código". O mercado não se cansa de "como código", mesmo que a maior parte dele não consiga 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á fazendo isso.
É importante que, quando termos são usados sem limites ou definições claras, paremos e tenhamos certeza de que estamos deixando claras *nossas* definições. Seria bom se houvesse um comitê de padrões com uma definição no estilo RFC para consultar, mas não há. O mais próximo que temos é o NIST, e vimos o quão bem eles foram capazes de acabar com o enigma da nuvem.
Há mais no "como código" do que apenas infraestrutura como código (IAC). Aiman Najjar @ Pythian escreveu uma ótima visão geral do cenário atual de infraestrutura como código . Embora eu discorde que os contêineres devam ser sua própria camada (é apenas infraestrutura da perspectiva dos serviços de rede e aplicativo) e que o Jenkins não faça parte dela, em geral seu blog foi uma excelente maneira de entender o relacionamento das camadas "como código" e mapear as ferramentas certas para o trabalho certo. Além disso, a maioria das discussões sobre infraestrutura como código se concentra na entrega contínua, ou seja, o pipeline que cria, testa, integra e lança um aplicativo para produção. Este não é o mesmo processo da implantação contínua, que se concentra em pegar o aplicativo lançado e implantá-lo em um ambiente de produção, juntamente com os serviços de rede e aplicativo necessários.
OBSERVAÇÃO No App Utopia, os pipelines de entrega e implantação são convergentes. Mas a maioria de nós (ainda) vive na realidade dos aplicativos, onde produção e desenvolvimento são ambientes separados, com diferentes conjuntos de requisitos e restrições. Daí a necessidade de reconhecer essa separação quando aplicamos automação ao pipeline.
Há três camadas distintas surgindo para cobrir as excentricidades inatas à TI e ao pipeline de implantação. A mais importante delas é a complexidade inerente ao ambiente. Essa linha reta do cliente para o aplicativo que desenhamos em diagramas de rede não engana ninguém. Há muito mais acontecendo nos bastidores do que temos tempo (e paciência) para diagramar.
A diversidade do pipeline em si — que compreende hardware desenvolvido especificamente, bem como software virtual e baseado em contêiner implantado em COTS — também fornece o ímpeto para dividir e segmentar "como código" em camadas separadas. Embora seja verdade que hardware mais moderno pode ser gerenciado por meio de uma abordagem como código, hardware legado (compartilhado) pode ser quase impossível de incluir no processo. Separar as camadas, então, para espelhar mais de perto o próprio processo de implantação, pode fornecer uma maneira de incluir soluções baseadas em hardware legadas e modernas, juntamente com serviços baseados em software no pipeline.
O objetivo é construir uma pilha de TI contínua capaz de dar suporte a cronogramas e arquiteturas de implantação por aplicativo em um ambiente de várias nuvens. E como a implantação é apenas o começo do ciclo de vida ativo de um aplicativo, é necessário que haja uma quarta camada focada nas operações pós-implantação. Isso se soma às três camadas principais que abrangem o provisionamento e a integração da infraestrutura, a configuração e o gerenciamento do serviço e o pipeline de implantação.
A lista de ferramentas não deve ser considerada exaustiva. Existem muitas outras ferramentas e conjuntos de ferramentas. Por exemplo, sabemos por meio de diversas pesquisas e estudos que a maior parte dos NetOps prefere scripts Python personalizados para a tarefa de automatizar serviços de rede e aplicativos. E também sabemos que sistemas de automação de rede e pilhas como Cisco ACI, VMware NSX, OpenStack e Red Hat OpenShift são meios populares de implementar muitas funções na pilha de operações contínuas. Simplesmente não há espaço suficiente no visual para incluir todas as ferramentas e, portanto, uma amostra foi incluída com base na popularidade das ferramentas com 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 argumentar contra o aproveitamento das habilidades e conhecimentos existentes em sua organização com as ferramentas mais comumente usadas para implementar pipelines de entrega "como código". Vale ressaltar que não listei nenhuma ferramenta para "operações como código" porque muitas delas são personalizadas (scripts personalizados) ou específicas para uma tecnologia de fornecedor - pelo menos por enquanto.
NOTA Operações como código são o equivalente de TI ao gerenciamento de processos de negócios (BPM). Com o BPM, os processos de negócios são automatizados. Alguns BPMs se concentram apenas em fluxos de trabalho muito específicos, outros podem cobrir toda a extensão da interação com o cliente, desde a compra até o pagamento e a entrega. Operações como código são uma prática emergente em TI hoje, mas precisarão amadurecer e se tornar gerenciamento de processos operacionais se as empresas quiserem capitalizar a otimização de processos operacionais da mesma forma que aprenderam a aproveitar o BPM.
Seja na nuvem ou no data center, ainda há uma rede que precisa ser configurada. Mesmo serviços de ordem superior (aqueles que operam nas camadas 4-7, também conhecidos como serviços de aplicação) exigem algum conhecimento de topologia de rede para operar. Pode ser que parte dele precise ser ativado (também conhecido como licenciado) se você estiver implantando um pipeline totalmente novo. A infraestrutura como código é necessária para permitir uma abordagem de autoatendimento para implantação, pois sem a infraestrutura (software e serviços) em vigor, não há nada para configurar ou implantar um aplicativo.
Responsabilidades: integração de infraestrutura , licenciamento, provisionamento
Esta é uma questão separada da configuração, que aborda especificamente a necessidade de configurar políticas e comportamentos específicos para o serviço em questão. A configuração pode ocorrer novamente com cada atualização importante do aplicativo. Ele também pode ocorrer novamente com cada atualização menor. Para serviços relacionados à segurança, pode ocorrer em caráter emergencial a correção, atualização ou aprimoramento de um determinado serviço. A configuração como código é essencial para dar suporte a cronogramas e pipelines de implantação por aplicativo e para impor o isolamento de caminhos de dados do aplicativo, importante para garantir a estabilidade do pipeline de produção como um todo.
Responsabilidades: configuração de serviço , atualização e patch
Depois, há o processo abrangente que define todo o aplicativo e seus serviços do início ao fim. É todo o pipeline e é codificado em um processo executável que direciona automaticamente a implantação. O pipeline como código é o elo entre o IaC e o CaC que os une para descrever o que chamamos de pipeline de implantação. É no pipeline que serão encontrados os maiores ganhos em rapidez e eficiência, pois ele possibilita a eliminação de tempos de espera entre as etapas necessárias ao processo.
Responsabilidades: automação do processo de implantação
Esta camada é a camada operacional contínua. É onde ocorrem o monitoramento e o alerta, o dimensionamento automático e a descoberta. Nesta camada, estamos preocupados em codificar processos operacionais em um sistema capaz de executá-los por conta própria. O dimensionamento automático é um dos processos operacionais mais frequentemente codificados e envolve vários sistemas. Mas coletar telemetria para análise é outro processo operacional que precisa de atenção, assim como as possíveis ações tomadas com base nessa telemetria que permitem ajustes (automáticos) para otimizar o caminho dos dados ou o desempenho do aplicativo. Esses processos operacionais têm sua própria configuração e entram em ação após a conclusão do processo de implantação.
Responsabilidades: automação do fluxo de trabalho operacional
Visualizar a implantação contínua através das lentes da pilha de operações contínuas pode fornecer uma abordagem estratégica para automatizar o pipeline de produção. Ao separar as camadas e responsabilidades, fica mais fácil abordar a tarefa assustadora de automatizar as tarefas de TI de uma forma que permita a abordagem de autoatendimento desejada por muitas organizações e cada vez mais exigida pelos negócios. Ele também permite um caminho para operações contínuas por meio de operações como código, o que é uma evolução necessária no uso da automação em TI.
Agora, essa pode não ser a "única maneira verdadeira" de visualizar os esforços de automação associados ao pipeline de implantação. Mas é uma maneira, e fornece a capacidade para o mercado falar claramente sobre o que eles fazem ou não fazem.
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 com relação aos produtos F5.