De Soluções para Pilhas: A Era da Assembleia

Essa componentização da TI é como a componentização dos aplicativos que ela tem a tarefa de proteger e entregar. Estima-se que 80 a 90% dos aplicativos modernos são compostos de componentes de terceiros, a maioria dos quais são de código aberto. Os benefícios de fazer isso incluem velocidade, capacidade de resposta a mudanças (agilidade) e redução no custo de criação do software. Afinal, se outra pessoa já escreveu o código para uma roda, por que reinventá-la?

Não há estimativas sobre o quão componentizada a TI pode ser hoje, mas a resposta sobre o quão componentizada ela será no futuro é clara: Muito.

Não construímos mais nossos próprios sistemas de monitoramento. Nós adotamos um, como Prometeu. Não desenvolvemos nossos próprios mecanismos de busca; integramos com o Elastic Search ou o Lucerne. Não precisamos projetar e desenvolver controladores de formação e infraestrutura; temos o Helm e o Terraform. Não somos mais questionados sobre integração com sistemas; somos questionados sobre nosso suporte aos ecossistemas.

Nós construímos sistemas a partir de uma pilha de software em vez de desenvolver cada componente nós mesmos.

O efeito cascata da componentização

Esse pensamento em nível de sistema é difundido no desenvolvimento e está começando a ter um impacto profundo na maneira como todo software — comercial e personalizado — é desenvolvido. Também está tendo um impacto significativo na maneira como arquitetamos a rede.

Alguns anos atrás, notei que os microsserviços estavam destruindo a rede . Isso continua sendo uma ruptura em andamento, por razões intimamente ligadas à mentalidade do DevOps. Ou seja, é mais provável que o DevOps pense em termos de sistemas componentizados, principalmente quando influenciado pela nuvem. À medida que o DevOps continua a invadir o território tradicional de NetOps e operações, eles trazem consigo sua maneira de pensar. Isso significa pilhas em vez de soluções.

Essa perspectiva leva naturalmente à adoção de serviços de aplicativos individuais que se adaptam melhor ao modo de operação e pensamento em que o DevOps opera hoje. Serviços de aplicativos com foco funcional e de propósito único são usados para compor um caminho de dados em vez de construir um.

Isso significa que balanceamento de carga é balanceamento de carga. Controle de entrada é controle de entrada. E um gateway de API é um gateway de API. Com uma variedade de serviços de aplicação, os artesãos operacionais compõem (montam) um caminho de dados que se estende do código (o aplicativo) até o cliente (o cliente). 

Podemos ver isso nas extraordinárias taxas de adoção de serviços direcionados, como gateway de API, controle de entrada e defesa de bots, que vimos no relatório State of Application Services deste ano.

Essa mudança não passou despercebida. Assim como a transformação digital continua forçando os negócios a se redefinirem e se decomporem em serviços representados por APIs e aplicativos (recursos digitais), ela muda drasticamente a maneira como projetamos, desenvolvemos e entregamos serviços de aplicativos.

Subindo na pilha

O roteamento baseado em IP sempre foi a maneira como os caminhos de dados são arquitetados. Roteie esse tráfego aqui, e esse tipo de tráfego ali, e se houver algo na carga útil que corresponda a X, roteie o tráfego para lá. Ele é muito específico da rede e, portanto, acopla firmemente o caminho de dados à rede na qual é implantado.

Isso dificulta a replicação em outros ambientes, como uma nuvem pública. Embora você provavelmente possa reutilizar políticas, não poderá aproveitar a configuração que vincula o caminho de dados à rede.

Tanto os contêineres quanto a nuvem estão basicamente forçando os caminhos de dados a subir na pilha e serem montados na camada de aplicativo a partir dos serviços de aplicativo. Isso é muito mais portátil entre ambientes porque você está operando em metadados, como nomes de host ou tags e rótulos, que não estão vinculados à rede.

Em última análise, isso significa que precisamos mudar de configurações para políticas que possam montar caminhos de dados sem estar vinculados a endereços IP e ambientes.

Não há dúvidas de que estamos migrando de soluções para pilhas, de processos manuais para pipelines. À medida que expandimos nossos recursos digitais em negócios e operações, a necessidade de composição e controle sobre o caminho dos dados continuará a subir na pilha e dependerá mais fortemente dos serviços de aplicativos que os direcionam.