Infraestrutura na Nuvem – não dê nome aos bois

boisEra uma vez um programador de DAOs. Dionatan tinha conseguido essa honrada posição no Projeto Quéops depois de um ano como “programador júnior”, cuja principal atividade era programar “getters, setters e toStrings”. O antigo programador de DAOs saiu da empresa e, amigo de Dionatan, recomendou-o por ser confiável o suficiente para mexer com os acessos ao banco. Dionatan recebia uma “Java Interface”, provavelmente do cara do cubículo ao lado, que também fez o DAO Factory (e inúmeras outras “factories”) seguindo as recomendações do Todo-Poderoso arquiteto. Dionatan não sabia o nome do homem-factory e do Todo-Poderoso, porque trocavam as pessoas com frequência. Com a “Java Interface”, bastava criar uma implementação e preencher os métodos. Várias vezes, era só copiar boa parte do que o amigo já tinha deixado pronto e mudar alguns nomes.

Dionatan era de uma equipe formada por quase 45 pessoas, contando dois gerentes, um gestor, o novo Todo-Poderoso, três pessoas dos requisitos, e mais outras pessoas espalhadas em diversos cargos, QA, testes, UI, front-end, engenheiros XML, DBAs, Analistas de Negócios, etc. O suficiente para cada um botar a culpa em outra pessoa. E quando todo mundo terminasse seu trabalho, a equipe de integração juntava tudo e entregava para a equipe de Operações. Ainda não existia essa equipe, porque o projeto ainda deve demorar uns meses… ou anos, se o Todo-Poderoso conseguir convencer os gestores de atualizar algumas bibliotecas…

Dionatan conheceu na padaria do outro lado da rua um colega que fazia parte da equipe de Operações de outro projeto. Antigamente, o colega contou, chamavam de equipe de manutenção, mas as coisas complicaram, e o gestor sugeriu um nome mais chique. As coisas são entregues de qualquer forma, com uma documentação desatualizada, e a equipe precisa descobrir como colocar aquilo para rodar, e já sabendo que vão reclamar com eles. Se perguntarem para qualquer desenvolvedor que trabalhou nas etapas anteriores, a resposta vai ser “na minha máquina funciona”, ou “também não entendi porque pediram para ser assim, só fui lá e fiz”. Mas a equipe era boa. Tinha que ser.

A equipe de Operações usava duas super máquinas, uma para fazer testes em geral e outra para a implantação de verdade. Nem poodle de madame era tão bem cuidado quanto essa última VM. Todo dia alguém tinha que pentear, verificar memória, ou logs do sistema, atualizar alguma coisa. Se algo desse errado e o servidor caísse, a empresa teria que pagar multa para o cliente, e, dependendo da multa, alguém seria cortado. Um júnior para multa pequena, o gestor para multas altas.

Mas Dionatan deu sorte. Muita sorte. O projeto já estava nas últimas, atrasado, com custos além do orçamento, e Todo-Poderoso IV tentou dar uma sobrevida, adiantando a criação de uma equipe de Operações para dar a impressão de que faltava pouco para a entrega. Com dificuldade para conseguir “recursos” (para usar o termo do gestor), o arquiteto escalou Dionatan para uma das vagas. “Você está aqui desde o começo, jovem, merece uma promoção”, disse.

Mas o projeto descambou, sem nem Dionatan saber por quê. Na verdade, nem sabia para que serviria o projeto, tinha uma vaga ideia por causa dos nomes das interfaces que recebia. E agora sabia que não serviu para nada. E ainda perdeu o emprego, junto com os outros 40 e tantos.

Acabou entrando numa empresa de aplicativos mobile (RedApp, nome fictício), para trabalhar no “server-side” de um novo aplicativo, o quinto da empresa. Entrou bem no início do projeto. Aliás, da concepção do produto, lá não tem “projeto”. Um protótipo já tinha sido feito, mas ainda tinha muita coisa para decidir. Dionatan já tinha até dado contribuições de ideias para o aplicativo, mesmo sendo novato, mesmo que a interface gráfica não fosse sua responsabilidade. E Dionatan sabia que não sabia tudo o que precisava, tinha muita coisa para aprender se quisessem entregar um produto de qualidade.

Uma coisa que ele aprendeu sobre a implantação do produto, por exemplo, foi com Marcos Tiago (Dionatan sabia o nome de todo mundo agora). MarTi é desenvolvedor, mas manda muito na implantação (todo mundo sabe um pouco de tudo na RedApp.) MarTi mostrou que as aplicações devem rodar em contêineres. Assim, tudo que precisa para a aplicação rodar está num documento de texto que é tratado como um código, com direito ao seu espaço no Git, com controle de versão, e tudo mais. Aí, o contêiner fica igual, não importa se está na máquina do desenvolvedor ou rodando em produção para o cliente final. Não tem mais dessa de “na minha máquina funcionou.” E se algo estiver errado, provavelmente vai ser percebido bem antes de ir para produção.

Por falar em ir para a produção, até as definições das máquinas, da rede, de tudo, também estão em um código bem descritivo. MarTi disse que a antiga empresa de Dionatan tratava servidor como um pet, um bichinho que todo mundo tinha que saber o nome e todo mundo devia zelar com o maior cuidado. Na RedApp, a infraestrutura era tratada como gado, e estão sempre matando uns servidores e subindo outros a qualquer necessidade, ao alcance de um script. Nem valia a pena dar nome aos bois.


Dionatan, Quéops, RedApp e Marcos Tiago são nomes fictícios para uma história fictícia com problemas reais. Não se sinta ofendido ou homenageado.

 

Anúncios
Marcado com: , ,
Publicado em Microsserviços

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: