Bellacosa Mainframe e o problema do vendor lock-in

☕🚀 PADAWAN, O QUE É VENDOR LOCK-IN?

Imagine que você comprou uma cafeteira que só aceita cápsulas de uma única marca.

Enquanto tudo funciona, parece ótimo. Mas quando você descobre que as cápsulas são caras, difíceis de encontrar ou a empresa muda as regras, trocar de sistema vira um pesadelo.

Isso é Vendor Lock-In.

Definição Simples

Vendor Lock-In (aprisionamento ao fornecedor) é a situação em que uma empresa se torna tão dependente de uma tecnologia, produto ou fornecedor específico que mudar para outro se torna caro, complexo ou praticamente impossível.

Em outras palavras:

"Entrar foi fácil. Sair virou uma missão impossível."

---

Exemplo do Mundo Mainframe

Imagine um sistema COBOL rodando há 30 anos:

• Milhões de linhas de código

• JCLs personalizados

• CICS

• DB2

• RACF

• Ferramentas de monitoramento específicas

Tudo foi construído para funcionar perfeitamente naquele ambiente.

Migrar para outra plataforma exigiria:

• Reescrever aplicações

• Treinar equipes

• Alterar integrações

• Testar tudo novamente

O custo pode chegar a dezenas ou centenas de milhões de dólares.

Resultado?

A empresa fica "presa" ao fornecedor.

---

Exemplos Modernos

Cloud Computing

Uma empresa usa:

• AWS Lambda

• DynamoDB

• SQS

• Step Functions

Quanto mais utiliza serviços exclusivos da AWS, mais difícil fica migrar para:

• Azure

• Google Cloud

• Oracle Cloud

---

Banco de Dados

Aplicação criada usando recursos específicos do Oracle:

• PL/SQL

• Packages

• Procedures proprietárias

Migrar para PostgreSQL pode exigir anos de trabalho.

---

ERP

Uma empresa adota um ERP gigantesco.

Após anos:

• Processos foram customizados

• Integrações foram criadas

• Equipe foi treinada

Trocar de ERP pode ser mais caro que continuar usando o atual.

---

Como o Lock-In Acontece?

1. Tecnologia Proprietária

Somente aquele fornecedor possui a solução.

Exemplo:

• Linguagem exclusiva

• Banco de dados proprietário

• APIs fechadas

---

2. Dados Difíceis de Exportar

Os dados ficam presos.

Você até consegue sair...

Mas não consegue levar tudo junto.

---

3. Alto Custo de Migração

O sistema funciona tão bem que reescrevê-lo custa uma fortuna.

---

4. Falta de Conhecimento

A equipe só conhece aquela tecnologia.

Treinar todos em outra plataforma custa tempo e dinheiro.

---

Vendor Lock-In é Sempre Ruim?

Não.

Muitas vezes ele é uma consequência natural do sucesso.

Se um banco investiu bilhões em uma plataforma que funciona perfeitamente:

• Alta disponibilidade

• Segurança

• Performance

Talvez não faça sentido trocar.

Nesse caso, o lock-in é um risco controlado.

---

Como Reduzir o Vendor Lock-In?

Use Padrões Abertos

• REST

• JSON

• XML

• SQL padrão

---

Evite Recursos Exclusivos

Quanto mais código específico do fornecedor:

Mais difícil será sair depois.

---

Utilize Containers

• Docker

• Kubernetes

Facilitam mover aplicações entre ambientes.

---

Mantenha Documentação

Muitas empresas descobrem que não conseguem migrar porque ninguém sabe mais como o sistema funciona.

---

Curiosidade Histórica

O termo ganhou força nos anos 1980 e 1990, quando empresas começaram a depender fortemente de:

• IBM

• Oracle

• Microsoft

• SAP

Muitas organizações perceberam que o custo para trocar de fornecedor era maior do que o custo inicial da implementação.

---

☕ A Moral para o Padawan COBOL

Vendor Lock-In não significa que uma tecnologia é ruim.

Significa apenas que:

Quanto mais valor você constrói sobre uma plataforma, mais caro fica abandoná-la.

Isso vale para:

• Mainframe

• Cloud

• ERP

• Banco de Dados

• IA

• Ferramentas DevOps

Até mesmo linguagens modernas podem gerar lock-in.

A verdadeira arquitetura corporativa não busca eliminar completamente o Vendor Lock-In — isso é quase impossível. Ela busca entender, medir e controlar o nível de dependência do fornecedor, para que a empresa tenha opções quando precisar mudar de rumo. 🚀☕

Eastereggs

Sim. Embora o vendor lock-in nem sempre seja ruim, existem casos famosos em que a dependência excessiva de um fornecedor gerou enormes prejuízos, atrasos ou até fracassos de projetos.

☕🚀 1. O Caso Oracle e os Sistemas Legados Governamentais

Diversos governos ao redor do mundo construíram aplicações usando:

• Oracle Database

• Oracle Forms

• Oracle Reports

• PL/SQL

Após 15 ou 20 anos, descobriram que:

• Licenças ficaram muito caras

• Profissionais especializados eram raros

• Migração era extremamente complexa

Em alguns casos, o custo da migração ultrapassava o custo de continuar pagando as licenças.

Resultado:

Milhões gastos apenas para manter sistemas antigos funcionando.

---

☕🚀 2. O Drama do VMware após a Broadcom

Em 2023 a Broadcom adquiriu a VMware.

Muitas empresas possuíam:

• milhares de VMs

• automações

• processos

• treinamento

inteiramente dependentes do ecossistema VMware.

Após mudanças de licenciamento, diversas organizações relataram aumentos expressivos nos custos de renovação. Muitas iniciaram projetos emergenciais para migrar para:

• Hyper-V

• Proxmox

• Nutanix

• OpenShift Virtualization

O problema?

Anos de dependência tornaram a saída lenta e cara.

---

☕🚀 3. O Windows Phone

A Microsoft criou um ecossistema próprio.

Desenvolvedores precisavam:

• ferramentas específicas

• APIs específicas

• marketplace próprio

Quando a plataforma fracassou comercialmente:

• milhares de aplicativos perderam valor

• empresas tiveram que reescrever aplicações para Android e iOS

Foi um lock-in que terminou em um beco sem saída.

---

☕🚀 4. Salesforce Excessivamente Customizado

Muitas empresas adotaram Salesforce.

Depois de anos:

• workflows complexos

• Apex

• integrações proprietárias

ficaram profundamente acoplados.

Em alguns casos a organização descobriu que:

Trocar de CRM custaria mais do que continuar pagando o Salesforce.

O fornecedor virou praticamente parte da arquitetura da empresa.

---

☕🚀 5. SAP e os Projetos Bilionários

Existem empresas que investiram centenas de milhões de dólares em customizações SAP.

Anos depois:

• a versão ficou obsoleta

• o fabricante mudou a estratégia

• surgiu a necessidade de migrar para S/4HANA

Muitas organizações enfrentaram projetos enormes de conversão.

Algumas gastaram mais na migração do que no projeto original.

---

☕🚀 6. AWS e o "Cloud Shock"

Na década de 2010 muitas empresas migraram rapidamente para a AWS.

Utilizaram serviços exclusivos como:

• Lambda

• DynamoDB

• Aurora

• Step Functions

Anos depois perceberam que:

• custos cresceram

• negociar preços ficou difícil

• migrar para Azure ou GCP exigiria reescrever aplicações inteiras

Nasceu o movimento chamado:

Cloud Repatriation

Ou seja:

trazer sistemas de volta para datacenters próprios.

---

☕🚀 7. O Fracasso do Google App Engine Original

Nos primeiros anos, o Google App Engine exigia uma arquitetura bastante específica.

Muitas aplicações foram escritas para aquele modelo.

Quando as necessidades cresceram:

• migrar para outras clouds era complicado

• várias empresas reescreveram aplicações inteiras

Foi uma das razões para a popularização dos containers e Kubernetes.

---

☕🚀 8. Lotus Notes

Quem viveu os anos 90 e 2000 conhece.

Muitas empresas criaram:

• workflows

• aplicações

• bases documentais

inteiramente dentro do Lotus Notes.

Quando surgiu a necessidade de migrar:

• milhares de aplicações precisaram ser convertidas

• regras de negócio estavam escondidas nos bancos Notes

Alguns projetos levaram anos.

---

☕🚀 9. Mainframe: O Lock-In Mais Famoso (e Talvez o Mais Justificado)

Muitos executivos enxergam o Mainframe como exemplo clássico de lock-in.

Mas existe um detalhe interessante:

Os bancos normalmente permanecem porque:

• funciona

• é seguro

• é rápido

• processa bilhões de transações

Muitas tentativas de migração fracassaram porque o custo era gigantesco.

Um exemplo famoso foi o esforço de alguns bancos europeus e seguradoras que investiram centenas de milhões de euros em projetos de "saída do mainframe" e acabaram cancelando ou reduzindo o escopo após anos de trabalho.

O lock-in existia.

Mas o valor entregue pelo sistema também.

---

☕🚀 O Caso Mais Trágico: Quando o Fornecedor Morre

Existe algo ainda pior.

Imagine:

• software proprietário

• banco de dados proprietário

• fabricante pequeno

A empresa fecha as portas.

Agora você possui:

• sistema crítico

• sem suporte

• sem código-fonte

• sem atualização

Isso aconteceu inúmeras vezes com ERPs regionais, softwares hospitalares e sistemas industriais.

Nesse momento o vendor lock-in vira um risco existencial.

---

☕ A Grande Lição

O maior prejuízo não ocorre quando você compra uma tecnologia proprietária.

O maior prejuízo ocorre quando você constrói toda a sua estratégia acreditando que nunca precisará sair dela.

Os maiores desastres de TI costumam acontecer quando a organização descobre, tarde demais, que:

"Entrar levou seis meses. Sair levará seis anos e custará dez vezes mais." 🚀☕

 

Bellacosa Mainframe e os primordios da nuvem

Do Mainframe a Cloud Computer, la e ca outra vez...

Conceitos sobre Nuvem / Cloud Computer

Salve jovem padawan, feliz 2022 e hoje voltamos a ativa, passado as festividades da Epifania dos Reis Magos, iniciamos o ano com um artigo de conceitos gerais, uma ferramenta para elucidar alguns termos usados nos cursos, principalmente nos AWS da Amazon e Azure da Microsoft.

Mas antes de iniciarmos, saiba que a origem desta moda das nuvens, iniciou-se em tempos idos, afinal tudo era nuvem, calma, não entre em pânico, o tiozão não surtou nem bebeu demais nas festas, mas nos primórdios da computação na Era de ouro dos Mainframes, tudo estava armazenado num servidor, longe da sede da empresa, muitas vezes a dezenas, quiçá centenas de quilômetros de distância.

O Centro de Processamento de Dados, era um servidor conectado via linha discada através de modens, que distribuía a informação localmente em terminais 3270 e posteriormente em emuladores de terminal 3270, através de conexões via ponte em CICS, época que os caracteres EBCDIC imperavam, era em que o espaço em disco era caríssimo, memoria idem, as empresas alugavam tempos de processamento com X ciclos de CPU, X espaço de memória e disco.

O armazenamento era feito em tapes e cartridges com a utilização de inúmeros aplicativos em COBOL, PLI e Assembly para gerar copias via JCL, que encareciam o processo e limitava o armazenamento de dados, obrigando que as empresas usassem estratégias locais para solucionar questões estratégicas analisando os dados.

Anos 60 a padronização dos serviços

Com pouco mais de duas décadas, muitos fabricantes e pouca padronização, situação que obrigou ao governo americano a lançar inúmeras Normas ISO/ASA para definir os tipos de serviços prestados em processamento de dados, as linguagens de programação aceitas e outras especificações técnicas que serviram para impulsionar o serviço e democratizar o acesso dos Computadores as Universidades e Empresas civis.

Anos 70 a Mainframe Cloud

Um pouco abstrato, um pouco imaginação do tiozão, porem nos primórdios os Mainframes, capitaneado a pela gigante azul, a IBM dominou o mercado e vendia/alugava serviços : serviços de codificação, processamento de dados, armazenamento e impressão de relatório, basicamente os clientes utilizavam-se de terminais para acessar os serviços e consumirem as informações, poucas empresas tinham capital suficiente para serem donas de 100% do parque informático e os Centro de Processamento situação muito semelhante com os services atuais (IaaS, PaaS, SaaS e DaaS, com uma vantagem adicional a concorrência era baixa e a maior parte das patentes e pessoal qualificado era da empresa.

Anos 80 e a multiplicação dos dados

Com o advento da microinformática e o uso intensivo do Clipper e base de dados XBase, surgiu novos ares no processamento de dados num mundo off-line, as empresas sentiram o poder da análise de dados e acumulação de informações e uso de planilhas de dados Lotus 123 e Supercalc..

Uma era fortemente ligada aos mainframes que geravam dados brutos e transmitiam via arquivos sequenciais em TXT, convertidos de EBCDIC para ASCII via protocolo FTP de alta para baixa plataforma e os pioneiros em ciências de dados, criavam programa estatísticos ou planilhas para explorarem tendências e acúmulos de dados.

Antes de prosseguirmos, recordem que era uma era off-line, onde muita das informações eram transmitidas via disquetes de 5 ¼, 3 ½ de face simples e dupla de acordo com a evolução, era uma era de rede em cabo coaxial, bem difícil de operar e com limitação de largura banda.

Anos 90 e a era da internet

Com a evolução tecnológica dos anos 90, o antigos PC XT rapidamente tornou-se obsoletos, o milagre da miniaturização e a produção em massa, facilitou a evolução, primeiros 286, 386, 486 e Pentiuns.

A linguagem Clipper e o padrão DBase com suas inúmeras versões, facilitaram o processo de processamento de dados, com utilização de fórmulas matemáticas e estatísticas sofisticadas e troca de dados na velocidade da luz, através de linhas discadas com modens rápidos e internet rápida com poderosos servidores.

Nisso foram surgindo novas linguagens e formatos de base de dados com SQL poderoso, pela primeira vez o domínio dos mainframes foi abalado, acuado com os ERPs e descentralização dos CPDs.

Y2K um fantasma na virada do século

Lembra do custo de armazenamento e uso de memória nos Mainframes nos primórdios da computação? Uma solução simples e econômica que atendia a 100% dos problemas na época. Para que século, cortaram 2 bytes do armazenamento e processamento da Data, afinal ninguém usava o 19 para nada, em milhões de registros era moedinhas no cofre, ninguém contava que os programas iriam durar tanto, e o doce cortar de bytes, gerou um bug, o bug do milênio transformou-se num monstro.

A resposta das empresas e consultorias informáticas virou uma enorme bola de neve, sorvedora de recursos e os custos para conversão de antigos programas em linguagens de alta plataforma, quebrou empresas e assustou gestores e investidores que forçou medidas drásticas aos sistemas centrais, deixando atemorizados acionistas e sociedade civil.

O JAVA e o MySQL, o Oracle, o Python, C e seus dialetos, o MS SQL e o pacote MS Office criaram um mundo novo na programação e o conceito de armazenamento de dados, fora do Mainframe e dentro de Servidores Web.

Anos turbulentos devido ao colapso econômico da Bolha da Internet e o atentado suicida as Torres gêmeas do Word Trade Center em Nova Iorque com perda de muita informação armazenada nos servidores locais.

Primeira década do novo milênio

O mundo se recuperava do colapso econômico e tudo parecia que estava bem, porem o mercado especulativo imperava, a formula de Back-Scholes-Merlon transformou o Mercado Financeiro um grande cassino, que gerou a grande bolha especulativa detonada em 2008.

As empresas buscavam soluções entre os servidores locais, servidores backups, mainframes e repentinamente as empresas viram-se numa arapuca, sem dinheiro para investir e com falências em todo o mercado.

A resposta foi cortar custos e com isso voltamos aos primórdios da informática e os servidores transformaram-se em sistemas centrais e empresas ocupam o nicho da IBM, vendendo espaço de armazenamento, serviço de processamento de dados e codificação.

Nuvem / Cloud

Uma metáfora para descrever a rede global de servidores temos inúmeros Centros de Processamento de Dados controlados por poucas empresas Amazon, Google, Microsoft, VMWare, SalesForce, RackSpace, Verizon, Cisco, entre outras. São computadores espalhados por todo o mundo que armazenam dados, executam aplicativos e fornecem serviços aos usuários por meio da internet, ocorrendo um movimento de migração e modernização de softwares.

Computação sem servidor

Foi o modelo de negócios principal da IBM no passado, hoje é um método desenvolvido para fornecer serviços de back-end às empresas, oferecendo tecnologias para escrever e executar códigos, gerir dados e integrar aplicações, tudo isso sem a necessidade de gerenciar servidores.

Uma verdadeira volta as origens, desta vez com a vantagem de existirem mais players no mercado, a concorrência ajuda a melhorar a qualidade e os custos dos serviços.

Redundância de dados

Duplicação de componentes para garantir serviço ininterrupto e evitar perda de dados. Para isso, são feitos backups dos dados em diferentes datacenters para acionar imediatamente quando houver falhas em algum deles.

Eu trabalhei no Banco Real na década de 90 e além, havia 3 grandes maquinas, o SP11, SP51 e o CA81, respectivamente na sede do Banco, na IBM SP e IBM Hortolândia, garantindo a execução dos processamentos batch e rotinas onlines durante 24 horas dias, 7 dias por semana e 365 dias ao ano.

A parte mais importante era a garantia de replicação dos dados e zero downtime. Participei de algumas simulações e os serviços levavam menos de um minutos para restabelecerem, trocava-se o servidor sem percebermos.

Middleware

O software que fica entre um sistema operacional e os aplicativos executados nele que permite a comunicação e o gerenciamento de dados para aplicativos distribuídos, como os aplicativos baseados em nuvem.

No passado era o COBOL, Natural, PL/I, Rexx, Assembly, que operavam em processo batchs via JCL, atualmente o JAVA e o C Sharp levam uma ligeira vantagem, mas existem linguagens e tecnologias para dar e vender, tornando o mercado caótico.

Services

Existem 4 tipos de serviços fortemente ligados a nuvem, mas antes a verdadeira imagem que devemos pensar é a terceirização dos diversos elementos ligado aos serviços informáticos. Pense uma grande empresa, necessita de uma equipe para manutenção de hardware, uma equipe de gestão de servidores, uma equipe de análise de incidentes e ocorrências, uma equipe de sustentação, uma equipe de desenvolvimento, uma equipe de base de dados, uma equipe de análise e organização e métodos, uma equipe de gestão de auditoria e acesso e finalizando uma equipe de comunicação e redes.

Devido a complexidade constantes, a necessidade de treinamentos e os altos custos envolvidos na aquisição de equipamento, locação de espaço, instalação de redes e comunicação e a gestão de pessoal implicou na evolução forçada dos CPDs e os inúmeros serviços que as SLAs, não conseguiam contemplar.

Por isso surgiram os serviços: IaaS, PaaS, SaaS, DaaS entre outros, que veremos nos parágrafos abaixo.

IaaS (Infrastructure as a Service)

é um tipo de serviço de computação em nuvem que oferece recursos fundamentais de computação, armazenamento e rede sob demanda e pagos conforme o uso, ou seja, um modelo de computação em nuvem que fornece recursos de computação na nuvem (como servidores, armazenamento, rede e software operacional) em um ambiente virtualizado. Ex: IBM Cloud.

Qualquer semelhança com os velhos serviços de mainframe é mera coincidência. Será?

PaaS (Plataform as a Service)

é um ambiente de desenvolvimento e implantação completo na nuvem, com recursos que permitem a você fornecer tudo, de aplicativos simples baseados em nuvem a sofisticados aplicativos empresariais habilitados para a nuvem, sem a necessidade de aquisição de licenças e pessoal técnico. .

Uma plataforma de nuvem completa para o desenvolvimento, execução e gestão de aplicações. Ex: AWS (Amazon Web Services), porém esse processo não é linear e simples, em alguns momentos ocorrem situações catastróficas como exemplo o TSB Bank.

SaaS (Software as a Service)

Uma inovação devida aos altos custos de aquisição de software, no passado fomentou muita pirataria e quebras de patentes. Também chamado de aplicativo hospedado, é um tipo de software que não precisa ser adquirido, instalado ou executado em computadores dos usuários. Ex: Adobe Creative Cloud.

DaaS (Desktop as a Service)

Os serviços evoluíram tanto, que atualmente até o Desktop é emulado, a semelhança dos antigos terminais 3270 da IBM, podemos acessar um determinado tipo de equipamento, bem como inúmeros Sistemas Operacionais de acordo com nossa necessidade.

Nuvem pública

Um dos primeiros serviço oferecidos, no passado pessoas e empresas armazenavam imagens, vídeos e arquivos de negócio. São serviços oferecidos por terceiros através da Internet e disponíveis a qualquer pessoa que queira adquirir. Ex: Google Cloud Platform.

Nuvem privada

Semelhante a nuvem publica, mas com melhores ferramentas de segmentação e segurança, pertinente para empresas com dados mais sensíveis. São serviços oferecidos pela Internet ou uma rede interna privada apenas para uso exclusivo de usuários selecionados. Ex: Cisco Cloud Center.

Nuvem híbrida

Como o mercado é dinâmico, e os custos envolvidos acabam criando barreiras, solucionadas através de packages que unem nuvem publica com a privada. Uma nuvem que combina nuvens públicas e privadas com tecnologia que permite que dados e aplicativos sejam compartilhados entre elas. Ex: Azure Stack.

Virtualização

O ato de criar uma versão virtual do ambiente de computação em vez de uma versão física, incluindo hardware, sistema operacional e dispositivos de armazenamento.

Conclusão

Caro padawan, espero não ter me estendido muito, mas tentei apresentar de maneira resumida o universo do Cloud Computer, utilizando como metodologia fazer uma comparação aos antigos sistemas centrais de Mainframe e a evolução com um pouco da historia recente.

Foi um mix de informações, onde aproveitei para tirar algumas duvidas no sites da Azure, AWS, Google e Wikipedia, qualquer duvida ou correção chama aqui ou no Discord.

Espero ter ajudado, lembre-se que é um trabalho continuo, sempre que possível irei atualizar e agregar novas informações.

Mais momento jabá, para distrair, vamos conhecer um pouco da Revolução Paulista de 1932, que completa 90 anos e em Itatiba a prefeitura fez uma justa homenagem ao transladar os restos mortais de um soldado constitucionalista para o Obelisco Mausoléu do Ibirapuera em SP, visite meu vídeo e veja para onde fui desta vez: https://www.youtube.com/watch?v=yqYWSLtsrps

https://www.linkedin.com/in/vagnerbellacosa/

https://github.com/VagnerBellacosa/

Pode me dar uma ajudinha no YouTube?

https://www.youtube.com/user/vagnerbellacosa

hashtag#Desafio21DiasNaDIO

publicado originalmente em : https://web.dio.me/articles/do-mainframe-a-cloud-computer-la-e-ca-outra-vez/