O que podemos aprender sobre escala com a virtualização

À medida que a virtualização começou a se consolidar, uma variedade de métricas foram propostas para medir o sucesso. Taxas de consolidação, taxas de administradores para máquinas virtuais, tempo de provisionamento e porcentagem de servidores virtualizados estavam entre os mais comumente usados para medir e classificar o sucesso de projetos de virtualização.

Hoje estamos observando o DevOps começar sua escalada ascendente e métricas semelhantes estão sendo propostas para medir seu sucesso. Tempo de colocação no mercado, tempo médio de recuperação, tempo de espera para mudança e frequência de implantação estão entre as medidas mais comuns mencionadas quando focamos no "M" na definição CAMS (Cultura, Automação, Medição, Compartilhamento) de DevOps.

Elas são boas e necessárias, mas há um benefício – um caso de uso, se preferir – do DevOps que raramente é discutido e que é igualmente crítico: escala operacional.

É o mesmo problema que a SDN tenta resolver “na rede” por meio da operacionalização; permitindo que a escala de equipes por meio da tecnologia corresponda à taxa de crescimento desejada e experimentada pelo negócio graças ao rápido crescimento de aplicativos móveis e da web. É um problema clássico “30/30/3” resultante do crescimento de dados que aumenta os custos de TI (para transportar, processar e armazenar) com apenas um aumento mínimo na receita. Resolver esse problema exige foco na única parte da equação sobre a qual temos controle: maiores custos de TI. Então, se você quiser chamá-lo de SDN, vá em frente. Se você quiser chamar isso de DevOps para a Rede, vá em frente. Se você quiser chamá-lo de SDDC, por que não? Chame-o de nuvem também, se você preferir. Todos eles têm uma premissa comum: a rápida escala operacional é essencial para o crescimento.

Não se trata apenas de recursos de hardware e software; trata-se também de como provisionamos e gerenciamos esses recursos. É necessário reduzir a quantidade de esforço necessária para gerenciar o conjunto de recursos – hardware e software – necessários para implantar e entregar um aplicativo.

É aí que o “A” de “Automação” desempenha bem na redução dos custos de TI necessários para mudar a equação de crescimento e permitir a escala para suportar um maior crescimento empresarial. 

Mas não é apenas uma visão superficial da automação que precisamos. Embora a automação (usando scripts e orquestração para conduzir o provisionamento e o gerenciamento e os processos operacionais necessários para implantar serviços e aplicativos) seja importante, não podemos esquecer o papel crítico que a “infraestrutura como código” desempenha.

Podemos fazer isso em parte dando uma olhada na máquina do tempo para ver o sucesso da virtualização no gerenciamento de escala de recursos de computação (em grande parte) graças ao tratamento dessa infraestrutura "como código".

Eu sei, eu sei, não era realmente um código no sentido de que não era um script ou um arquivo de configuração ou qualquer coisa que parecesse "código". Mas foi tratado “como código” no sentido de que usamos repositórios centralizados de “imagens douradas” para provisionar e configurar servidores rapidamente. Servidores web, servidores de aplicativos, servidores de dados. Diferentes tipos de servidores foram idealizados por uma “imagem” predefinida que permitiu aos operadores escalar.

E quando digo escala, quero dizer ESCALA. Embora existam muitos números divulgados, não era incomum em 2011 encontrar organizações com uma proporção de 1:350 de administrador:servidor virtual. Alguns reivindicaram entre 1:500 e 1:1000, enquanto outros, simplesmente frustrados pelo tamanho de sua organização, só puderam reivindicar 1:100 ou 1:150. Um relatório de 2012 que analisou dados de vários relatórios de benchmark de TI observou que a proporção de administrador: servidor era de 1: 50-75 para servidores físicos e 1:185-450 para servidores virtuais.

Em termos de escala, isso é incrível. Isso permite o crescimento sem os custos de TI mais altos, geralmente complementares.

Agora, considere que a proporção média de engenheiros:dispositivos em empresas de todos os tamanhos é de cerca de 1:36. Isso é interessante por si só, você não acha? A proporção não parece mudar à medida que o negócio cresce. O que é meio ruim e só contribui para o problema 30/30/3.

Mas se pudéssemos mudar isso de alguma forma, mesmo que fosse apenas dobrar os dispositivos por engenheiro, cortaríamos os custos de crescimento e permitiríamos uma melhor escala de toda a rede.  Para fazer isso, temos que imitar o sucesso da virtualização. Não necessariamente usando virtualização, mas usando os conceitos que permitiram suportar proporções inacreditáveis de administradores para servidores: infraestrutura como código e automação.

O motivo pelo qual não podemos simplesmente criar imagens de ouro de switches e balanceadores de carga e mais de 20 outros serviços de aplicativos L4-7 que sabemos que as organizações estão empregando para entregar e proteger seus aplicativos é porque cada configuração é única; ela é centrada no aplicativo, e isso significa que, embora você certamente possa usar o software (virtual) e implantar uma imagem de base de ouro para qualquer um desses serviços, ainda precisará de alguém para fazer a configuração. E não é uma configuração simples.

Configurando alguns serviços de aplicativo para o Exchange? São necessários mais de 80 objetos diferentes para serem criados, configurados e associados corretamente para obter a disponibilidade, o desempenho e a segurança necessários.

É certamente aqui que o tempo (e os custos relacionados) são incorridos “na rede”.

É aí que precisamos escalar. Onde precisamos tratar a infraestrutura “como código”.

Esta é a razão pela qual a modelagem está incluída no componente “A” de Automação do DevOps. Porque a criação de modelos permite que as operações de rede (e de segurança também) tratem configurações comuns “como código” que pode ser gerenciado em um repositório central. O modelo se torna a “imagem dourada” a partir da qual os serviços de aplicativo são provisionados e configurados. Essa abordagem permite automação e orquestração que imitam o provisionamento de máquinas virtuais e fornece a base para a escalabilidade operacional que as organizações precisam para permitir o crescimento dos negócios.

DevOps, SDN, SDDC e até mesmo a nuvem não visam apenas melhorar o tempo de colocação no mercado ou reduzir custos operacionais. Eles também são essenciais para uma escala eficiente que permite, em vez de impedir, o crescimento dos negócios. O custo de adicionar mais e mais operadores ou engenheiros para gerenciar os recursos crescentes em todo o data center (computação, rede, segurança, armazenamento) vai devorar o crescimento resultante dessa escala. Escalar de forma mais eficiente usando automação e tratando a infraestrutura como código pode ser uma maneira de gerenciar a escala necessária para dar suporte ao crescimento desejado pelo negócio.