Muito Antes do DevOps: Quando o "Deploy" significava soldar um cabo DB25 e configurar o IRQ 4

Hoje, falamos muito sobre "DevOps" e "Full-Stack". Na teoria moderna, isso significa que as “equipes de desenvolvimento” assumem a responsabilidade pela infraestrutura, gerindo servidores virtuais, containers e deployments através de código. É uma abstração poderosa.

Mas nos anos 80 e 90, para quem trabalhava com sistemas robustos como o QNX, "Full-Stack" não era uma abstração; era uma realidade física e brutal. Naquela época, simplesmente não existia uma divisão entre a equipe de software e a equipe de infraestrutura. A empresa que vendia o software tinha de fazer tudo.

Quando fechávamos um contrato, o nosso trabalho começava muito antes do código. Significava ir ao cliente, montar as máquinas, instalar o sistema operacional (muitas vezes perdendo o boot e tendo de recuperar "na mão" ) e, o mais importante, fazer a rede funcionar.

A nossa "rede" não era Ethernet; era uma rede de terminais burros ligados ao servidor via comunicação serial RS-232. Isso significava que nós tínhamos de fazer os cabos. Literalmente, sentarmo-nos com um ferro de solda e rolos de fio.

Eu tinha de saber os mapas de pinagem de cor. Lembro-me perfeitamente do mapa para ligar um cabo DB25 a outro DB25 para comunicação serial: tínhamos de pegar no conector e soldar uma ponte entre os pinos 4 e 5. Depois, outra ponte ligando o 6, o 8 e o 20. O pino 7 (terra) ligava ao 7 do outro lado. E, finalmente, a comunicação: o pino 2 deste lado tinha de ser soldado ao pino 3 do outro lado, e o pino 3 deste lado soldado ao 2 do outro. Haviam mapas diferentes se a ligação fosse DB9 com DB25, ou DB9 com DB9. Quem é que ia fazer isto? Não havia "equipe de rede". Éramos nós, os programadores (leia também o artigo "A Conexão Física – A Arte do Cabo Manga e o Padrão Simplificado" que contém os diagramas de pinagem).

O desafio continuava dentro do servidor. Para ligar dezenas de terminais a um único PC (um 386 ou 486 na época), precisávamos de placas multi-seriais especiais (usávamos umas de uma empresa chamada TAL). A instalação não era plug and play. Tínhamos de tirar a placa da caixa e configurar fisicamente os jumpers nela para definir os endereços de memória corretos (leia também o artigo "O Hardware de Multiplicação" que detalha a configuração das placas MUSA). Depois, tínhamos de colocar no slot e configurar a interrupção de hardware correta no computador, geralmente a IRQ 4, para que o PC a reconhecesse . Só então é que dávamos os comandos no QNX para ele reconhecer aquelas portas.

E se o hardware falhasse? A responsabilidade também era nossa. Chegámos a ter terminais burros que queimavam, e as empresas de manutenção demoravam muito no conserto. Depois de um colega acompanhar um conserto, descobrimos que o problema era quase sempre um único chip específico na placa processadora do terminal. O que fizemos? Começamos a comprar esses chips e a consertar os terminais nós mesmos. Até isso nós fizemos.

Essa era a realidade do "suporte". O meu caso mais memorável foi um cliente em Chapecó que ligou dizendo que um terminal tinha parado. Tentamos tudo por telefone, e o cliente jurava que o cabo estava perfeito. Tivemos de viajar de Porto Alegre a Chapecó. Ao chegar lá, descobrimos o problema: alguém tinha cortado o cabo serial e feito uma "emenda" com durex.

Hoje, o conceito de "ownership" do DevOps é gerir o stack de software. Naquela épocaa, o "Full-Stack Raiz" significava ser dono de tudo, desde o sinal elétrico que passava num fio que soldamos, uma interrupção física do hardware (IRQ 4), até ao bug de lógica na aplicação. É um nível de compreensão da máquina que se perdeu nas abstrações, mas que é fundamental para entender porque é que os sistemas realmente funcionam ou falham.

Este artigo é baseado numa história de "Dos 5 Minutos de uma Fita Cassete a 40 Anos de Código", as memórias do autor.
Leia a história completa aqui.