Ir para cloud não significa abandonar o mainframe

Quando ouvimos que uma empresa está “migrando para a nuvem”, é quase automático imaginar o que aconteceu.

Servidores foram substituídos por instâncias na AWS, Azure ou Google Cloud. Aplicações antigas foram reescritas. O monolito foi dividido em microsserviços. E, se havia COBOL no meio da história, provavelmente virou Java.

Mas nem sempre é assim. Uma empresa pode migrar para um modelo de cloud e continuar executando suas aplicações em um IBM Z com z/OS.

Para entender como isso é possível, precisamos separar duas coisas que frequentemente aparecem misturadas nas discussões sobre modernização: a plataforma onde uma aplicação é executada e a maneira como essa plataforma é consumida.

Quando o mainframe era seu

Durante décadas, o modelo tradicional era relativamente fácil de entender. Uma grande empresa comprava ou alugava um mainframe, instalava o equipamento em seu data center e mantinha toda a estrutura necessária para operá-lo.

Isso significava muito mais do que simplesmente ter um computador. Era preciso manter capacidade de processamento, armazenamento, conectividade, segurança, backup, recuperação de desastre e, principalmente, profissionais especializados capazes de administrar todo esse ambiente.

Também era necessário dimensionar capacidade, e aí começava o pesadelo. Uma empresa não pode dimensionar sua infraestrutura apenas para um dia normal. Um banco precisa estar preparado para períodos de processamento mais intenso. Uma seguradora pode ter picos relacionados aos seus ciclos de negócio. Um varejista não pode perder vendas na Black Friday por falta de capacidade operacional.

Consequentemente, parte da infraestrutura pode permanecer subutilizada durante determinados períodos simplesmente porque precisa estar disponível quando a demanda chegar. Esse dilema entre capacidade para suportar os picos e subutilização nos períodos normais que ajudou a tornar o modelo de cloud computing tão atraente.

A virtualização nasceu no mainframe

Normalmente associamos cloud à virtualização: uma máquina física executando diferentes ambientes independentes, permitindo melhor utilização dos recursos disponíveis.

Para quem conhece mainframe, isso não é exatamente uma novidade.

O IBM Z utiliza uma tecnologia chamada PR/SM — Processor Resource/Systems Manager, que permite dividir os recursos de uma máquina física em Logical Partitions, ou LPARs. Cada LPAR funciona como uma máquina lógica independente e pode executar seu próprio sistema operacional. Assim, um mesmo mainframe IBM Z pode ter diferentes partições executando z/OS, z/VM ou Linux, por exemplo.

Não estamos falando simplesmente de uma VM no sentido em que normalmente usamos o termo no mundo x86. A arquitetura é diferente. Mas o princípio fundamental é familiar: recursos como processador, armazenamento, memória e dispositivos de I/O podem ser particionados ou compartilhados entre ambientes independentes.

E isso não apareceu com a computação em nuvem. A virtualização faz parte da história do mainframe há décadas.

Do compartilhamento ao multi-tenancy

Se uma grande máquina pode ser particionada em diferentes ambientes isolados, o que impede que um provedor especializado utilize sua infraestrutura para atender diferentes clientes? É aqui que aparece o conceito de multi-tenancy.

Em vez de cada empresa possuir toda a infraestrutura IBM Z, um provedor pode operar uma plataforma na qual diferentes clientes utilizam recursos compartilhados, mantendo seus ambientes segregados.

Esse princípio é familiar para quem utiliza cloud pública. Quando criamos uma máquina virtual em um hyperscaler, normalmente não sabemos — nem precisamos saber — qual é o servidor físico que está executando aquela instância.

Mainframe as a Service

MaaS não significa transformar um mainframe em um conjunto de servidores x86 que emulam um mainframe. Significa transformar a capacidade do mainframe em um serviço. A empresa continua podendo executar seus workloads, testados e estabilizados há décadas,  no IBM Z, mas não precisa necessariamente possuir e operar toda a infraestrutura física que existe por trás deles.

O provedor assume parte dessa responsabilidade. E isso muda bastante a discussão sobre modernização.

Imagine uma empresa com milhares de programas, milhões de linhas de código e décadas de regras de negócio executando de maneira confiável em z/OS. O problema dessa empresa não é o COBOL, o JCL, o CICS e o DB2.

Talvez ela simplesmente não queira continuar investindo e mantendo por conta própria toda a infraestrutura necessária para executá-los. Nesse caso, reescrever milhares de aplicações apenas para mudar o local onde elas executam pode representar anos de trabalho, custos enormes e um risco injustificável.

Mudar o modelo de consumo da infraestrutura, nesse caso, pode ser uma alternativa muito mais segura. Em vez de manter permanentemente recursos dimensionados para o pico, o provedor de MaaS pode oferecer modelos nos quais a capacidade contratada acompanha melhor as necessidades do negócio.

Voltando ao exemplo do varejo, a capacidade necessária numa terça-feira comum de março talvez seja muito diferente daquela exigida durante a Black Friday.

CAPEX e OPEX

Existe ainda uma consequência financeira importante. Manter infraestrutura própria exige investimentos em capacidade que precisa ser dimensionada não apenas para a utilização média, mas também para os períodos de pico. Parte desse capital pode, portanto, permanecer imobilizada em recursos subutilizados durante boa parte do tempo.

Ao consumir infraestrutura como serviço, parte desse CAPEX pode ser transformada em OPEX. A empresa preserva capital, transfere ao provedor parte do risco de renovação e dimensionamento da infraestrutura e, dependendo do contrato, consegue aproximar melhor o custo da capacidade efetivamente necessária.

Uma empresa pode concluir que IBM Z continua sendo a melhor plataforma para determinado workload e, ao mesmo tempo, decidir que possuir toda a infraestrutura necessária para executá-lo deixou de ser a melhor opção financeira. As duas decisões não são contraditórias.

Quando uma empresa contrata infraestrutura de mainframe como serviço, ela não está terceirizando apenas ferro, disco e capacidade de processamento. Ela está terceirizando também toda a estrutura de especialistas em z/OS, storage, segurança, middleware, banco de dados, performance, recuperação de desastre e muitas outras disciplinas.

E para algumas organizações, essa talvez seja uma vantagem tão importante quanto a própria economia de infraestrutura.

Conclusão: Nuvem não é sinônimo de x86

Recentemente tivemos um exemplo bastante interessante desse modelo no Brasil. A Kyndryl anunciou a conclusão da migração do ambiente mainframe do Grupo Casas Bahia para seu modelo zCloud, buscando benefícios como flexibilidade, escalabilidade e otimização de custos.

O interessante nesse caso é que uma grande empresa brasileira realizou uma iniciativa de transformação tecnológica na qual migrar para um modelo de cloud não significou abandonar o mainframe.

E isso desmonta uma associação que fazemos com muita frequência.

Durante muito tempo construímos uma oposição artificial: mainframe de um lado, cloud do outro, como se fossem gerações sucessivas de tecnologia. Primeiro tivemos mainframes. Depois servidores distribuídos. Depois cloud. Portanto, cada etapa deveria necessariamente substituir a anterior.

Só que sistemas corporativos não evoluem dessa maneira. Uma empresa pode utilizar SaaS para algumas funções, microsserviços em Kubernetes para outras, aplicações em um hyperscaler, Linux em IBM Z e workloads transacionais em z/OS.

Por isso, quando alguém disser que determinada empresa está “indo para a nuvem”, talvez valha a pena fazer uma pergunta antes de concluir que seus sistemas COBOL estão sendo aposentados: O que exatamente está sendo migrado? As aplicações? A arquitetura? A infraestrutura? Ou apenas a maneira como essa infraestrutura é adquirida, operada e consumida?

Ir para a nuvem não significa necessariamente sair do mainframe.

Às vezes, o mainframe vai junto.