O Retorno ao “Bare Metal”

Não estou falando de uma vertente de rock oriundo do Heavy Metal, apesar de gostar muito do estilo… estou falando de uma mudança na arquitetura computacional e, mais uma vez, visando aumentar ainda mais a eficiência das equipes de TI e melhor utilização dos recursos disponíveis: sejam on premise, sejam na cloud, preferencialmente em várias clouds, e sem ficar “preso” à elas. Basicamente estamos falando de parar de utilizar a virtualização de servidores e basear-se exclusivamente em uma plataforma de containers: com Kubernetes, Service Mesh, Circuit Breaker, Kafka, EFK, Serverless, SDS, SDN e todas as novas tecnologias que estão revolucionando a forma de tratar dados e desenvolver aplicações.

Embora soe moderno, o conceito de virtualização tem suas origens nas tecnologias dos mainframes, no final dos anos 1960 e no início dos anos 1970, quando a IBM investiu muita pesquisa e esforço no desenvolvimento de soluções robustas de compartilhamento de recursos computacionais. Trata-se do uso compartilhado de recursos do computador entre um grande grupo de usuários, com o objetivo de aumentar a eficiência e os dispendiosos recursos do computador que eles compartilham.

A virtualização de servidores foi um avanço que permitiu aproveitar melhor a capacidade de processamento, já que se conseguiu condicionar um único computador a suportar várias instâncias de sistemas operacionais. Isso se tornou possível por meio do hypervisor, camada de software que proporciona ao sistema operacional (OS) visitante a abstração da máquina real, criando o conceito de máquina virtual. É ele que controla o acesso dos sistemas operacionais visitantes aos dispositivos de hardware.

A virtualização habilita um ambiente de computação para executar vários sistemas independentes ao mesmo tempo, modelo que reduziu o custo de fornecimento de capacidade computacional. A partir daí, organizações e indivíduos passaram a compartilhar os servidores, com o isolamento de cada sistema operacional dentro de uma máquina virtual, consolidando vários servidores subutilizados em um menor número de máquinas, aumentando a eficiência do uso desses computadores, economizando espaço, energia e refrigeração. Diminuiu-se o tempo de provisionamento dos servidores, permitiu-se automatizar diversas tarefas diminuindo riscos e aumentando a velocidade de processos operacionais.

Servidores físicos e o sonho da abstração

Embora a tecnologia de virtualização tenha sido criada nos anos 60, ela não foi amplamente adotada até o final dos anos 1990. No início dos anos 1990, a maioria das empresas possuía servidores físicos e pilhas de software de um único fornecedor, o que dificultava que aplicativos legados fossem executados em outra pilha de software ou mesmo no hardware de um fornecedor diferente. À medida que as empresas atualizavam seus ambientes de TI com servidores, sistemas operacionais e aplicativos de diversos fornecedores, ficavam sujeitas a hardware físico subutilizado – cada servidor executava apenas uma aplicação para evitar interferência de uma aplicação com outra na mesma máquina: briga por recursos ou instabilidades de uma aplicação afetando a outra. Era o bare metal sem orquestração, cada servidor uma aplicação.

Essa forma de organização de TI trouxe um problema sério: desperdício. Utilizava-se mais servidores, espaço e energia do que o necessário: muitos servidores com baixa utilização poderiam ser consolidados e foi essa necessidade que impulsionou a adoção da tecnologia de virtualização de servidores.

As aplicações eram desenvolvidas de uma forma monolítica: um grande binário com todos os componentes altamente acoplados e dependentes que somente escalava verticalmente: para melhorar a performance colocava-se uma CPU mais rápida e, caso a aplicação tenha sido desenvolvida utilizando-se multithreading, podia-se colocar mais CPUs. Trabalhava-se na época com computadores que permitiam a instalação de muitas CPUs e muita memória (para os padrões da época) para que esses aplicativos monolíticos conseguissem atender mais demandas. Foi o auge dos grandes servidores RISC, arquiteturas e componentes proprietários acabavam prendendo ao fornecedor de Hardware e Software.

A onda seguinte foi a migração para arquiteturas abertas saindo principalmente do UNIX para Linux e Windows e é onde estamos agora: uma quantidade enorme de máquinas virtuais, rodando em cima de virtualizadores caros e com dificuldades em escalar horizontalmente pois temos um legado enorme de aplicações que foram desenvolvidas monoliticamente.

Breve história dos Containers

Nos últimos dez anos, a ideia de consumir recursos computacionais conforme demanda e cobrada conforme o uso trouxe o conceito de cloud computing.

A nuvem pública passou a proporcionar um pool de recursos virtuais, provisionado e alocado automaticamente entre vários clientes, por meio de uma interface de autosserviço. Já a nuvem privada agregou todos os processos básicos da computação em nuvem (padronização, automação e self-service) para acesso exclusivo apenas aos servidores e data centers da corporação. O que estamos procurando agora é abstrair as peculiaridades de cada infraestrutura para conseguir utilizá-las da forma mais eficiente possível: analisando-se necessidades específicas de cada aplicação e parâmetros como latência, custo de CPU, memória e transferência de dados e níveis de serviço toma-se a decisão onde o provisionamento de recursos deverá ser feito.

Colocar uma máquina virtual em uma nuvem pública pode custar muito caro: afinal de contas na nuvem pública cobra-se por utilização de CPU e memória e, aplicações monolíticas, junto com suas bibliotecas e todo o sistema operacional, em uma máquina virtual não são a solução ideal para cloud computing aliás, nem foi pensada para isso. Para isso, temos os containers. Os Containers isolam aplicações (ou microsserviços) enquanto a virtualização isola sistemas operacionais.

Em 2004, os Solaris Containers (depois chamados de Solaris Zones) foram introduzidos para as arquiteturas X86 e SPARC, combinando controles de recursos do sistema e os limites de separação fornecidos por zonas. Essas zonas atuavam como servidores virtuais completamente isolados em uma única instância do sistema operacional, diferentemente da virtualização de servidores tradicional que adicionava uma camada de software a mais. Contudo, ainda não era justificativa suficiente para sua ampla adoção, uma vez que a virtualização se encontrava bem desenvolvida, a necessidade de escalabilidade horizontal ainda não estava tão clara e as tecnologias de desenvolvimento em microsserviços estavam apenas começando.

Os Linux Containers começaram como um projeto em 2006 e, em 2008, tiveram seu release inicial com foco nas novas abordagens de desenvolvimento baseado em microsserviços.

Em 2011 a Red Hat lançou a primeira plataforma comercial de containers, ainda baseada em LXC e gears e, com o surgimento do formato Docker de containers e Kubernetes como motor de orquestração, o OpenShift v3 foi a primeira tecnologia empresarial baseada em Docker e Kubernetes ainda em 2015 adotando o que estava virando o padrão de fato. Uma aposta certeira pois hoje em dia vemos que Kubernetes é, de longe, a padrão de orquestração de containers.

Hoje em dia a dependência do Docker foi eliminada com o surgimento de tecnologias abertas de containers em especial o CRI-O, que é um runtime de containers compatível com Kubernetes para o formato de containers aberto estipulado pelo OCI (Open Container Initiative).

O futuro é híbrido

Atualmente, os datacenters usam técnicas de virtualização para abstrair o hardware físico, criar grandes conjuntos agregados de recursos lógicos e oferecer esses recursos a usuários ou clientes de forma ágil.

Estamos vivendo agora a transição para um próximo patamar de eficiência: redes definidas por software e armazenamento definido por software em vez de appliances proprietários. Containers rodando em bare metal em vez de máquinas virtuais rodando em hypervisors: menos overhead, arquiteturas descentralizadas e mais ágeis, escalabilidade horizontal e abstrações de tecnologias proprietárias de nuvens pública. Menor dependência de fabricantes de hardware e software (especialmente a dobradinha HW+SW proprietários que ainda consomem grande parte do orçamento de TI) e, principalmente uma arquitetura capaz de se adaptar para as novas tecnologias que estão surgindo ou que ainda surgirão sem ficar preso a nenhum fabricante de hardware, software ou nuvem.

Não há dúvidas que a infraestrutura de nuvem, baseada em padrões, híbrida e aberta é o que será utilizado no futuro: não teremos tudo on premise, nem tudo na nuvem pública. Infraestrutura automatizada, descentralizada, altamente escalável e com maior liberdade de escolha de fornecedores é o que o futuro pode nos reservar se as armadilhas de lock-in forem evitadas.

*Boris Kuszka é diretor dos arquitetos de solução da Red Hat.