Translate

sábado, 11 de julho de 2026

Capítulo 11 — O Cemitério dos Buzzwords

Bellacosa Mainframe e o cemiterio dos Buzzwords

☕ Um Café no Bellacosa Mainframe

Capítulo 11 — O Cemitério dos Buzzwords

Enquanto Enterravam o Mainframe, os Modismos É que Foram Desaparecendo

Uma viagem bem-humorada pelos grandes modismos da indústria de TI que, em diferentes épocas, prometeram substituir completamente o mainframe, mas acabaram tornando-se apenas mais um capítulo da história da computação.

Por


Cemitério dos buzzwords e a continuidade da evolução do IBM Mainframe
Client/Server, Downsizing, Rightsizing, Cloud, Blockchain, Metaverso e outros modismos passaram. O IBM Mainframe continuou evoluindo e integrando cada uma dessas tecnologias.

"Na Tecnologia da Informação existem duas certezas: sempre surgirá um novo buzzword e alguém dirá que ele acabará com tudo o que veio antes."

— Bellacosa Mainframe

O ciclo dos buzzwords

Ao longo das últimas décadas, diversos conceitos ganharam enorme popularidade: Client/Server, Downsizing, Rightsizing, SOA, BPM, Virtualização, Cloud Computing, Containers, Blockchain, Metaverso e, mais recentemente, Inteligência Artificial.

Todos trouxeram contribuições importantes para a indústria. O erro não foi sua existência, mas a crença recorrente de que cada novidade eliminaria completamente tudo o que existia antes.

A estratégia vencedora

Enquanto o mercado frequentemente falava em substituição, o ecossistema IBM Z seguiu outro caminho: integração. Linux, Java, APIs REST, containers, OpenShift, Git, DevOps, Ansible, watsonx e IA passaram a conviver naturalmente com COBOL, CICS, Db2 e z/OS.

A grande lição

A História mostra que tecnologias realmente bem-sucedidas raramente eliminam completamente as anteriores. Elas evoluem, coexistem e se integram para resolver problemas de negócio de forma cada vez mais eficiente.

Bellacosa Mainframe e o museu da computação

Bem-vindo ao Museu da Computação

Imagine que exista um enorme museu.

Não um museu de computadores.

Um museu de previsões.

Cada sala possui um cartaz.

Um slogan.

Uma promessa.

Uma tecnologia revolucionária.

Ao lado...

Uma frase.

"Agora o Mainframe acabou de verdade."

Você entra na primeira sala.

Depois na segunda.

Na terceira.

Na décima.

Na vigésima.

E começa a perceber um padrão curioso.

Os nomes mudam.

A promessa continua exatamente a mesma.

Sala 1 — Client/Server

Ano: 1990.

A promessa:

"Agora tudo ficará distribuído."

O que realmente aconteceu?

Sim.

Aplicações distribuídas conquistaram o mercado.

Mas os grandes sistemas transacionais continuaram centralizados.

Hoje praticamente toda grande empresa utiliza ambos.

Resultado:

✔ Client/Server venceu.

✔ Mainframe também.

Empate por integração.

Sala 2 — RISC vai acabar com CISC

Ano: 1992.

Naquela época parecia que a arquitetura RISC resolveria todos os problemas da computação.

PowerPC.

SPARC.

MIPS.

Alpha.

PA-RISC.

Cada fabricante prometia o mesmo.

Mais desempenho.

Mais simplicidade.

Mais futuro.

Enquanto isso...

Os engenheiros da IBM continuavam evoluindo a arquitetura do mainframe.

Resultado?

RISC tornou-se extremamente importante.

Mas o IBM Z continuou evoluindo em paralelo.

Mais uma previsão que confundiu inovação com substituição.

Sala 3 — Windows NT dominará os datacenters

Quem viveu os anos 90 certamente se lembra.

Windows NT era apresentado como o sucessor natural dos grandes sistemas.

O marketing era gigantesco.

As demonstrações impressionavam.

As revistas adoravam.

O problema apareceu alguns anos depois.

Administrar milhares de servidores individuais revelou-se muito mais complexo do que muitos imaginavam.

Windows NT tornou-se uma plataforma importante.

Mas nunca substituiu o processamento crítico realizado pelos grandes sistemas corporativos.

Sala 4 — Java vai matar COBOL

Essa talvez seja uma das histórias mais divertidas.

Final da década de 1990.

Java dominava as conferências.

A frase mais comum era:

"Agora ninguém mais escreverá COBOL."

A IBM respondeu de maneira extremamente elegante.

Colocou Java dentro do mainframe.

Em vez de lutar contra Java...

Resolveu executá-lo.

Hoje Java e COBOL convivem naturalmente no IBM Z.

Mais uma vez...

Integração venceu.

Sala 5 — ERP elimina sistemas legados

Lembra dessa?

Bastaria instalar um grande ERP.

Pronto.

Todos os sistemas antigos desapareceriam.

Na prática...

Milhares de empresas descobriram que seus diferenciais competitivos estavam justamente naqueles sistemas chamados de "legado".

Resultado.

Os ERPs foram integrados aos sistemas existentes.

Não o contrário.

Sala 6 — SOA vai reescrever tudo

No início dos anos 2000 surgiu outro grande entusiasmo.

SOA.

Service-Oriented Architecture.

A promessa parecia familiar.

Tudo seria reescrito como serviços.

O que aconteceu?

Os serviços realmente apareceram.

Mas muitos deles passaram simplesmente a chamar programas COBOL já existentes.

CICS ganhou Web Services.

Depois REST.

Depois APIs modernas.

Mais uma vez...

O velho código apenas ganhou uma nova porta de entrada.

Sala 7 — Cloud vai acabar com os Datacenters

Essa previsão ainda aparece de tempos em tempos.

Segundo muitos especialistas...

Tudo iria para a nuvem.

Os datacenters desapareceriam.

Chegamos a 2026.

O que vemos?

Cloud.

Cloud híbrida.

Cloud privada.

Edge Computing.

IBM Z.

LinuxONE.

Todos convivendo.

A realidade novamente preferiu integração.

Sala 8 — Blockchain vai substituir bancos

Lembra de 2018?

Tudo seria Blockchain.

Contratos.

Documentos.

Identidade.

Cartórios.

Pagamentos.

Governos.

Algumas aplicações realmente prosperaram.

Outras desapareceram.

Os bancos?

Continuaram utilizando COBOL.

Db2.

CICS.

Mainframe.

E, curiosamente, várias soluções Blockchain passaram a integrar sistemas tradicionais.

Sala 9 — O Metaverso Corporativo

Talvez um dos buzzwords mais efêmeros.

Por algum tempo parecia que todas as reuniões aconteceriam em ambientes virtuais tridimensionais.

Empresas correram.

Investidores também.

Hoje...

As videoconferências continuam dominando.

O metaverso encontrou nichos específicos, mas não substituiu a forma como o mercado corporativo trabalha.

Mais uma previsão grandiosa que encontrou uma realidade bem mais pragmática.

Sala 10 — A Inteligência Artificial substituirá todos os programadores

Chegamos ao presente.

Agora o discurso mudou novamente.

A manchete da vez é:

"A IA escreverá todo o código."

Será?

A IA certamente mudou a forma como desenvolvemos software.

Produz documentação.

Sugere algoritmos.

Explica código.

Auxilia em testes.

Aumenta produtividade.

Mas alguém ainda precisa:

Entender o negócio.

Projetar arquitetura.

Validar regras.

Garantir segurança.

Tomar decisões.

Assim como aconteceu em 1990...

Existe uma enorme diferença entre automatizar tarefas e substituir conhecimento.

O padrão finalmente aparece

Observe todas essas previsões.

Client/Server.

RISC.

Windows NT.

Java.

ERP.

SOA.

Cloud.

Blockchain.

Metaverso.

IA.

Todas seguem praticamente o mesmo roteiro.

Primeiro aparece uma inovação verdadeira.

Depois surgem expectativas enormes.

Em seguida alguém anuncia:

"Agora acabou para o Mainframe."

Alguns anos passam.

A inovação permanece.

O Mainframe também.

A maior ironia de todas

Enquanto dezenas de tecnologias tentavam substituir o IBM Mainframe...

O IBM Mainframe fazia exatamente o contrário.

Incorporava cada uma delas.

Linux?

Venha.

Java?

Pode entrar.

REST?

Sem problema.

Containers?

Ótimo.

OpenShift?

Também.

Git?

Claro.

Python?

Bem-vindo.

Ansible?

Excelente.

Inteligência Artificial?

Vamos integrar.

Essa talvez seja a característica mais impressionante da plataforma IBM Z.

Ela raramente rejeita uma inovação.

Ela procura descobrir como utilizá-la.

O Padawan visita o cemitério

Nosso Padawan encontra um enorme portão.

Na entrada está escrito:

Cemitério dos Buzzwords

Ele começa a caminhar.

Primeira lápide.

"Client/Server substituirá tudo."

Segunda.

"COBOL acabou."

Terceira.

"O último mainframe será desligado."

Quarta.

"Cloud elimina os datacenters."

Quinta.

"IA elimina os programadores."

Ele continua andando.

Chega ao final do cemitério.

Olha para trás.

Percebe algo curioso.

Nenhuma lápide pertence ao IBM Mainframe.

Então escuta uma voz.

É o velho mestre.

— Está vendo?

— O quê?

— Buzzwords normalmente têm prazo de validade.

Arquiteturas bem projetadas costumam durar muito mais.

O segredo nunca foi resistir

Existe uma ideia equivocada.

Algumas pessoas imaginam que o IBM Mainframe sobreviveu porque resistiu às mudanças.

Não.

Ele sobreviveu justamente porque mudou.

Muito.

O System/360 de 1964 é completamente diferente do IBM z17 de 2026.

Mudaram:

Processadores.

Memória.

Compiladores.

Linguagens.

Virtualização.

Ferramentas.

Integração.

Observabilidade.

Automação.

DevOps.

Cloud.

IA.

O que permaneceu foi a filosofia.

Compatibilidade.

Disponibilidade.

Confiabilidade.

Escalabilidade.

O verdadeiro "dinossauro"

No primeiro capítulo vimos o mainframe ser chamado de dinossauro.

Chegamos agora ao final desta jornada.

E talvez possamos fazer uma pergunta provocativa.

Quem realmente envelheceu mal?

O IBM Mainframe?

Ou a ideia de que toda tecnologia nova precisa destruir completamente a anterior?

Porque o z17 continua evoluindo.

O COBOL continua recebendo novos recursos.

O Db2 continua inovando.

O CICS continua processando bilhões de transações.

O z/OS continua sendo atualizado.

Muitos dos buzzwords que prometeram acabar com eles...

Hoje aparecem apenas em livros de História da Computação.

A última aula para o Padawan

Sempre que surgir um novo modismo...

Não pergunte:

"Isso vai matar o Mainframe?"

Pergunte:

"Como o Mainframe vai incorporar isso?"

Essa pergunta possui muito mais chances de acertar o futuro.

Foi assim com:

Internet.

Java.

Linux.

Web Services.

Open Source.

Containers.

Cloud.

OpenShift.

DevOps.

E agora...

Inteligência Artificial.

Talvez a maior habilidade do IBM Mainframe nunca tenha sido processar bilhões de transações.

Sua maior habilidade foi outra.

Aprender continuamente sem abandonar aquilo que já funcionava.

Essa é uma lição que vale não apenas para computadores.

Vale também para arquitetos.

Para desenvolvedores.

Para empresas.

E, principalmente, para cada novo Padawan COBOL que inicia sua jornada.

Porque buzzwords vêm e vão.

Mas engenharia bem construída continua escrevendo a História.

Bellacosa Mainframe e o Funeral que nunca aconteceu



C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
▼ DIRETÓRIO DE CAPÍTULOS ▼

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , , ,

sexta-feira, 10 de julho de 2026

Kubernetes sem Mistérios : Os 50 Erros que Derrubam Clusters em Produção (e que um Profissional IBM Z já Aprendeu a Evitar Há Décadas)

Bellacosa Mainframe apresenta kubernetes sem misterios


☕ Um Café no Bellacosa Mainframe

Kubernetes sem Mistérios 

Os 50 Erros que Derrubam Clusters em Produção (e que um Profissional IBM Z já Aprendeu a Evitar Há Décadas)

Existe uma curiosidade interessante.

Muitos profissionais enxergam Kubernetes como uma tecnologia revolucionária.

Ela realmente é.

Mas existe outra forma de enxergá-la.

Para quem trabalhou anos em Mainframe, Kubernetes parece muito mais uma redescoberta de conceitos que IBM já aplicava há décadas.

Disponibilidade.

Balanceamento.

Isolamento.

Escalonamento.

Segurança.

Observabilidade.

Recuperação.

Controle de acesso.

Versionamento.

Rollback.

Tudo isso sempre existiu.

A diferença é que hoje esses conceitos aparecem usando containers, pods e YAML.

No IBM Z eles aparecem como:

  • JES2

  • WLM

  • RACF

  • Sysplex

  • CICS

  • Db2

  • GDG

  • VSAM

  • SMF

  • RMF

O objetivo continua exatamente o mesmo:

Fazer sistemas críticos permanecerem funcionando.

O grande problema

Criar um cluster Kubernetes é extremamente fácil.

Rodar um cluster durante cinco anos, sem interrupções relevantes, é extremamente difícil.

Quase todos os grandes incidentes em produção acontecem por pequenas decisões aparentemente inocentes.

É exatamente isso que o infográfico demonstra.

BLOCO 1

Cluster & Infrastructure

Erro 1

Um único Worker Node

Imagine um banco inteiro rodando em apenas um IBM Z.

Parece absurdo.

No Kubernetes isso acontece o tempo inteiro.

Node A

APP1
APP2
APP3
APP4

Se esse servidor falhar...

Tudo cai.

No Mainframe isso seria equivalente a:

  • um único CPC

  • sem Parallel Sysplex

  • sem GDPS

  • sem redundância

Alta disponibilidade simplesmente deixa de existir.

Erro 2

Não proteger o Control Plane

O Control Plane é o cérebro.

Ele contém:

  • API Server

  • Scheduler

  • Controller Manager

  • ETCD

Sem ele...

O cluster fica "cego".

Os containers podem continuar rodando por algum tempo.

Mas nada novo consegue ser criado.

É parecido com perder o JES2 Master.

Erro 3

Não fazer backup do ETCD

O ETCD guarda praticamente todo o estado do cluster.

É equivalente ao:

  • catálogo do sistema

  • SYS1

  • repositórios de configuração

Sem ETCD...

Você perdeu:

  • Deployments

  • Services

  • Secrets

  • ConfigMaps

  • RBAC

  • Namespaces

Ou seja...

Perdeu o cluster.

Erro 4

Misturar Desenvolvimento e Produção

Esse é um erro clássico.

Imagine colocar:

PIX
Internet Banking
Folha de Pagamento

junto com

Sistema de Testes

No mesmo cluster.

Um teste mal executado pode consumir:

CPU

Memória

IO

Rede

e afetar produção.

Mainframe resolveu isso há décadas.

LPARs.

WLM.

Classes de serviço.

Ambientes isolados.

BLOCO 2

Resource Management

Aqui aparece um dos assuntos mais importantes.

Recursos.

No Kubernetes nada funciona "no automático".

Requests

Requests significam:

"O mínimo que preciso."

Exemplo

CPU: 500m

Memory: 1GB

O Scheduler utiliza isso para decidir onde colocar o Pod.

Sem requests...

Ele simplesmente chuta.

É semelhante ao WLM tentando distribuir workload sem conhecer prioridades.

Limits

Agora vem outra história.

Limits representam o máximo permitido.

CPU

2 cores

RAM

4GB

Se ultrapassar...

O processo sofre throttling.

Ou pode ser encerrado.

OOMKilled

Talvez o erro mais famoso.

Quando um container usa mais memória que o permitido.

O Kernel Linux faz:

OOM Killer

e encerra o processo.

No Mainframe seria parecido com:

Storage exhaustion

ou

S878

HPA

Horizontal Pod Autoscaler.

Ele aumenta o número de Pods.

Mas cuidado.

Escalar uma aplicação ruim apenas cria mais instâncias lentas.

É parecido com colocar mais CICS Regions para um programa que possui SQL ruim.

O gargalo continua existindo.

BLOCO 3

Deployment

Aqui surgem alguns erros extremamente comuns.

Nunca usar latest

Jamais.

image: latest

Parece prático.

Mas amanhã...

"latest"

é outra versão.

Você perdeu reprodutibilidade.

Sempre utilize

1.2.7

2.1.0

5.8.12

ou melhor ainda

Digest SHA256.

Isso lembra muito o mundo Mainframe.

Nunca executamos:

PROD.COBOL

Sabemos exatamente qual Load Module foi promovido.

Readiness Probe

O Pod iniciou.

Mas será que ele está pronto?

Não necessariamente.

Uma aplicação Java pode precisar:

30 segundos.

Sem Readiness.

O Kubernetes envia tráfego imediatamente.

Resultado:

Erro.

Liveness Probe

Verifica se o processo continua vivo.

Se travar...

O Kubernetes reinicia.

É semelhante ao Automation do SA z/OS detectando um address space congelado.

Startup Probe

Ideal para aplicações pesadas.

Sem ela...

O Kubernetes mata a aplicação antes dela terminar de iniciar.

Rolling Update

Jamais atualizar todos os Pods simultaneamente.

Sempre:

1
2
3
4

Nunca:

100%

de uma vez

É exatamente o conceito de deploy gradual utilizado por bancos.

BLOCO 4

Networking

Aqui muitos iniciantes sofrem.

Network Policies

Sem elas...

Todo Pod conversa com qualquer Pod.

Isso é perigosíssimo.

Imagine um malware chegando.

Ele consegue acessar praticamente tudo.

É equivalente a um RACF onde todos possuem ALTER em todos os datasets.

Impensável.

DNS

Muitos problemas parecem ser de aplicação.

Na verdade são DNS.

service

↓

CoreDNS

↓

IP

Uma falha aqui afeta milhares de Pods.

NodePort

Expor NodePort diretamente para Internet.

Nunca.

Use:

Ingress

Load Balancer

API Gateway

WAF

TLS

Sem TLS.

Todo tráfego pode ser interceptado.

No Mainframe isso seria equivalente a utilizar TN3270 sem criptografia.

BLOCO 5

Storage & Security

Aqui aparecem erros gravíssimos.

Rodar como Root

Nunca.

Um container comprometido ganha acesso privilegiado.

Use:

runAsNonRoot

readOnlyRootFilesystem

drop capabilities

Secrets em ConfigMaps

Erro extremamente comum.

ConfigMap não criptografa.

Secrets devem permanecer em:

Secret

Vault

KMS

External Secrets

RBAC

Sem RBAC.

Todos administram tudo.

Imagine um operador podendo:

Excluir produção.

Criar usuários.

Modificar políticas.

É por isso que RACF existe.

RBAC é o RACF do Kubernetes.

BLOCO 6

Observabilidade

Talvez o capítulo mais importante.

Sem logs...

Não existe troubleshooting.

Sem métricas...

Não existe capacity planning.

Sem tracing...

Não existe análise distribuída.

Sem dashboards...

Não existe visão operacional.

Ferramentas normalmente utilizadas

Logs

  • ELK

  • OpenSearch

  • Loki

Métricas

  • Prometheus

Dashboards

  • Grafana

Tracing

  • Jaeger

  • Tempo

  • Zipkin

Alertas

  • Alertmanager

Isso lembra muito:

RMF

SMF

OMEGAMON

NetView

Tivoli

Z APM Connect

BLOCO 7

Operação

Aqui aparecem erros humanos.

E a maioria dos grandes incidentes nasce justamente deles.

Deploy manual

Nunca.

Sempre:

Git

Pipeline

Automação

GitOps

O Git torna-se a verdade absoluta.

Toda alteração passa por:

Commit

↓

Review

↓

Pipeline

↓

Deploy

↓

Rollback

É semelhante ao ChangeMan, ISPW ou Endevor.

Nada muda diretamente na produção.

Não testar recuperação

Backup sem restore não vale nada.

Todo DR precisa ser testado.

No IBM Z isso sempre foi obrigatório.

GDPS.

Recovery.

Image Copy.

Log Apply.

Não auditar segurança

Novas vulnerabilidades surgem diariamente.

Imagens precisam ser continuamente escaneadas.

Os "novos" erros 

Os últimos slides ampliam ainda mais a lista.

Entre eles destacam-se:

  • Não definir ResourceQuota.

  • Não usar LimitRange.

  • Ignorar Namespaces.

  • Expor aplicações diretamente.

  • Não realizar backup periódico do ETCD.

  • Não otimizar custos.

  • Não separar ambientes.

  • Não validar probes continuamente.

  • Não monitorar consumo financeiro do cluster.

Esses erros normalmente não derrubam o ambiente no primeiro dia, mas aumentam gradualmente a complexidade operacional e o risco de incidentes.

O grande paralelo com IBM Z

O aspecto mais interessante desse material é perceber que praticamente todos os "50 erros do Kubernetes" já possuem um equivalente consolidado no ecossistema IBM Z:

KubernetesIBM Z / Mainframe
RBACRACF
SchedulerWLM
Rolling UpdatePromoção controlada (Endevor/ISPW/ChangeMan)
ReplicaSetParallel Sysplex
ETCDCatálogos e repositórios críticos do sistema
ObservabilidadeRMF, SMF, OMEGAMON
Health ChecksSA z/OS, NetView
GitOpsGestão de configuração e promoção de software
SecretsRACF + ICSF + cofres corporativos
AutoscalingBalanceamento e classes de serviço do WLM

A tecnologia mudou, mas os princípios permanecem.

A maior lição para um Padawan COBOL

Quem está começando em Kubernetes costuma imaginar que dominar YAML, Pods e Deployments basta para operar um ambiente de produção. Na realidade, isso representa apenas uma pequena parte do trabalho.

Os profissionais mais experientes pensam primeiro em engenharia operacional. Antes de criar um único Deployment, eles definem como recuperar o cluster após uma falha, como limitar recursos para evitar que uma aplicação afete outra, como monitorar métricas, como proteger segredos, como automatizar implantações, como auditar mudanças e como garantir que qualquer alteração possa ser revertida rapidamente.

Essa é exatamente a mentalidade que sempre existiu no IBM Z. Durante décadas, bancos, seguradoras e governos construíram sistemas que precisavam permanecer disponíveis 24 horas por dia. Kubernetes não substitui esses princípios; ele os reapresenta em uma nova arquitetura baseada em containers.

No Bellacosa Mainframe, essa é talvez a maior mensagem deste material: um bom engenheiro de Kubernetes não é aquele que conhece mais comandos kubectl, mas aquele que projeta plataformas resilientes, observáveis, seguras e previsíveis. A verdadeira maturidade está menos na tecnologia utilizada e muito mais na disciplina de engenharia aplicada a ela.

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , ,

Projeto IBM : APPDEV Final do Projeto 2025/2026

Bellacosa Mainframe e a conclusão do projeto APPDEV

Chegamos ao final de mais uma grande jornada!


Essta semana encerramos oficialmente o Programa APPDEV 2025, um ciclo marcado por muito aprendizado, troca de experiências e crescimento profissional.

Foi uma enorme honra atuar como MSE (Master Subject Expert), conduzindo mais de 30 encontros e 60 horas de treinamentos, compartilhando conhecimento sobre desenvolvimento de aplicações, IBM Z, COBOL e tecnologias corporativas com uma turma extremamente dedicada.

Meu sincero agradecimento à IBM, aos organizadores, coordenadores e a todos que tornaram este programa possível.

Agradeço, principalmente, a cada participante pelo comprometimento, pelas perguntas, pelos desafios e pela vontade constante de aprender. Ensinar é uma das melhores formas de continuar aprendendo.

Parabéns a todos que concluíram esta jornada! Cada certificado representa muito mais do que horas de estudo: representa disciplina, perseverança e o desejo de evoluir profissionalmente.

Que este seja apenas o início de uma longa trajetória de sucesso no ecossistema IBM Z e no desenvolvimento de aplicações corporativas.
Nos vemos nos próximos desafios.

O aprendizado nunca termina.
Parabéns, turma APPDEV 2025!

Foi um privilégio fazer parte dessa história.
#APPDEV2025 #IBM #IBMZ #Mainframe #COBOL #EnterpriseComputing #ApplicationDevelopment #TechEducation #Learning #DigitalTransformation #IBMSkills #OpenMainframe #SystemZ #Gratidão #Parabéns

We are excited to announce the launch of our new project! #newproject
Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , ,
Subscrever: Mensagens (Atom)