A Elegância das Soluções

É muito fácil, ao trabalhar em TI, ficar concentrado em soluções grandes e complexas. Parece que é aí que devem residir as boas soluções – grandes soluções, muito software, todas as mais recentes engenhocas. O que fazemos é entusiasmante e é muito fácil deixar-se levar pela inércia. É divertido realizar projetos desafiantes e de grande dimensão. Ouvir o que outros profissionais de TI estão a fazer, como outras empresas resolvem desafios e conversar com fornecedores que têm grandes sistemas para nos vender, tudo isto contribui para o entusiasmo, e é muito fácil perder a noção do âmbito e do objetivo, sendo tão comum ver soluções grandes e exageradas para problemas simples que parece que é assim mesmo que a TI tem de ser.

Mas não tem de ser assim. A complexidade é inimiga tanto da fiabilidade como da segurança. Soluções desnecessariamente complexas aumentam o custo tanto na aquisição como na implementação, bem como na manutenção, sendo geralmente mais lentas, mais frágeis e possuindo uma grande superfície de ataque que é mais difícil de compreender e de proteger. Soluções simples ou, mais adequadamente, elegantes são a melhor abordagem. Isto não significa que todos os projetos sejam simples, de modo algum. Projetos complexos são muitas vezes necessários. A TI não é propriamente uma área que padeça de falta de complexidade. Na verdade, acredita-se frequentemente que o desenvolvimento de software poderá ser o mais complexo de todos os empreendimentos humanos, pelo menos entre os realizados a alguma escala. Uma instalação típica de TI inclui milhões de linhas de código, centenas ou milhares de protocolos, grandes quantidades de sistemas interligados, camadas de configurações de software únicas, mais definições do que qualquer equipa poderia conhecer, e só então acrescentamos a complexidade de centenas ou milhares ou centenas de milhares de seres humanos imprevisíveis e irracionais a tentar usar estes sistemas, cada um à sua maneira. A TI é, sem dúvida, complexa.

O que importa é reconhecer que a TI é complexa, que isto não pode ser totalmente evitado, mas concentrar-se em conceber e projetar soluções para que sejam tão simples, tão graciosas… tão elegantes quanto possível. Esta ideia de projeto provém, pelo menos na minha mente, da engenharia de software, onde o código complexo é visto como um erro e o código simples e belo, fácil de ler e fácil de compreender, é considerado bem-sucedido. Um dos maiores elogios que se pode atribuir a um engenheiro de software é que o seu código seja considerado elegante. Quão apropriado é que se atribua a Blaise Pascal, em homenagem a quem foi batizada uma das linguagens de programação mais populares das décadas de 1970 e 1980, esta famosa citação (mal traduzida do francês): “Lamento ter tido de lhe escrever uma carta tão longa, mas não tive tempo de lhe escrever uma curta.”

É muitas vezes bem mais fácil conceber soluções complexas e intrincadas do que determinar que abordagem simples seria suficiente. Quer estejamos com pressa ou não saibamos por onde começar uma investigação, a elegância é sempre um desafio. A inércia da indústria é a de promover o caminho mais difícil. É do interesse dos fornecedores vender mais equipamento, não só para concretizar a venda inicial, mas porque sabem que com mais equipamento vêm mais receitas de suporte e que, se for vendido equipamento novo e complexo em quantidade suficiente, as necessidades de suporte deixam de aumentar linearmente e começam a aumentar geometricamente, pois é necessário suporte adicional não apenas para o próprio equipamento ou software, mas também para a configuração e o suporte das interações entre sistemas ou para personalizações adicionais. As influências financeiras por detrás da complexidade são grandes, e não se ficam pelos fornecedores. Os profissionais de TI ganham muita segurança no emprego, ou a ilusão dela, ao gerir grandes conjuntos de hardware e software que são difíceis de transferir sem sobressaltos para outro profissional de TI.

Muitas vezes a complexidade é de tal forma pressuposta, de tal forma esperada, que o processo de seleção de uma solução começa com uma grande complexidade como conclusão antecipada, sem qualquer consideração pela possibilidade de uma solução menos complexa poder ser suficiente, ou até ser superior, à parte da questão da própria complexidade e do custo. A complexidade está por vezes tão completamente associada a determinados conceitos que cheguei mesmo a deparar-me com incredulidade perante a ideia de que uma solução simples pudesse superar uma complexa em preço, desempenho e fiabilidade.

A retórica é fácil, mas qual é um exemplo do mundo real? Os melhores exemplos que vejo hoje estão sobretudo relacionados com a virtualização, seja no que toca ao armazenamento, a uma camada de gestão na nuvem ou software, ou simplesmente à própria virtualização. Vejo com bastante frequência que uma conversa que envolva apenas virtualização traz, para uma pessoa, uma conotação imediata de exigir armazenamento de blocos partilhado e em rede, software de gestão de virtualização dispendioso, muitos nós de virtualização redundantes e software complexo de alta disponibilidade – nada disto sendo intrínseco à virtualização e a maior parte raramente tendo por finalidade apoiar, ou estando sequer ao serviço do interesse da empresa para a qual serão implementados. Em vez de partir dos requisitos do negócio, estes conceitos surgem predominantemente de preconceitos tecnológicos. É simples apontar para a complexidade e parecer estar a resolver um problema – a complexidade cria uma sensação de conforto. Filtre muitos argumentos até ao fim e ouvirá “Como é que pode não funcionar, é complexo?” A complexidade proporciona uma ilusão de completude, de ter resolvido um problema, mas isto pode frequentemente ocultar o facto de uma solução poder não estar realmente completa ou sequer funcional, sendo que o grau de complexidade torna isto difícil de ver. As nossas mentes não aceitarão então facilmente que uma abordagem mais simples seja mais completa e resolva um problema quando uma complexa não o faz, porque tal parece tão contraintuitivo.

Um ótimo exemplo disto é o facto de recorrermos a discutir redundância em vez de fiabilidade. A fiabilidade é difícil de medir; a redundância é simples de quantificar. Um tijolo é altamente fiável, mesmo isolado. Não é preciso redundância para que um tijolo seja estável e robusto. O seu desenho é simples. Poderia fazer uma estrutura de suporte a partir de muitos paus redundantes que não seria nem de perto tão fiável como um único tijolo. Se falar em fiabilidade – a probabilidade de a estrutura não falhar – é claro que o tijolo é uma escolha superior a vários paus. Mas se disser “mas não há redundância, o tijolo poderia falhar e não há nada para tomar o seu lugar”, parece tolo. Porém, quando falamos de computadores e sistemas informáticos, encontramos sistemas tão complexos que raramente as pessoas conseguem perceber quando têm um tijolo ou um pau, pelo que, uma vez que não conseguem determinar a fiabilidade, que é o que importa, concentram-se na redundância, fácil de quantificar, que não importa. O sistema inteiro é demasiado complexo, mas procurar a solução simples, aquela que aborda diretamente o cerne do problema a resolver, pode reduzir a complexidade e dar-nos, no fim, uma resposta muito melhor.

Isto pode até ver-se no RAID. O RAID espelhado é simples, apenas um disco ou conjunto de discos a ser uma cópia exata de outro conjunto. É tão simples. O RAID de paridade é complexo, com cálculos sobre um stripe variável distribuído por muitos dispositivos que têm de ser codificados na escrita e descodificados caso um dispositivo falhe. O RAID espelhado não tem esta complexidade e resolve o problema da fiabilidade dos discos através de operações de cópia simples e elegantes, altamente fiáveis e muito bem compreendidas. O RAID de paridade é desnecessariamente complexo, o que o torna frágil. No entanto, ao fazê-lo e ao comprometer a sua própria capacidade de resolver o problema para o qual foi concebido, torna-se também, em simultâneo, aparentemente mais fiável com base em nenhum fator que não a sua própria complexidade. A mente humana salta de imediato para “é complexo, portanto é mais avançado, portanto é mais fiável”, mas nenhuma destas progressões é lógica. A complexidade não sugere que algo seja mais avançado, e ser avançado não sugere que seja fiável, mas a própria mente humana é complexa e facilmente induzida em erro.

Não há resposta simples para encontrar a simplicidade. Saber que a complexidade é má pela sua natureza, mas por vezes inevitável, ensina-nos a estar atentos, porém não nos ensina quando suspeitar de excesso de complexidade. Temos de estar vigilantes, procurando sempre determinar se existe uma resposta mais elegante e não aceitar a complexidade como a resposta certa simplesmente por ser complexa. Precisamos de questionar as soluções propostas e de nos questionarmos a nós próprios. “Será esta solução tão simples quanto deveria ser?” “Será esta complexidade necessária?” “Será que isto requer a complexidade que eu tinha presumido?”

Na maioria das recomendações de projeto de sistemas que dou, o primeiro passo de determinação técnica que normalmente dou, depois do passo de averiguar qual a necessidade do negócio que precisa de ser resolvida, é questionar a complexidade. Se a complexidade não puder ser defendida, é provável que seja desnecessária e esteja ativamente a frustrar o propósito para o qual foi escolhida.

“Será realmente necessário dividir esses discos em muitos arrays separados? Se sim, qual é a justificação técnica para o fazer?”

“Será o armazenamento partilhado realmente necessário para a tarefa para a qual o está a propor?”

“Justifica realmente o negócio o uso de tecnologias distribuídas de alta disponibilidade?”

“Por que estamos a substituir um sistema simples que ontem era adequado por um sistema dramaticamente mais complexo amanhã? O que mudou que torna uma melhoria importante, mantendo-se simples, não mais do que suficiente, mas que exige ordens de grandeza mais de complexidade e mais despesa que anteriormente não se justificava?”

Estes são apenas exemplos comuns; a complexidade existe em todos os aspetos da nossa indústria. Procure a simplicidade. Lute pela elegância. Não aceite a complexidade sem a examinar rigorosamente. Submeta-a ao proverbial crivo. Não permita que a complexidade se infiltre onde não se justifica. Não peque por excesso de complexidade – na dúvida, falhe de forma simples. Simplificar demasiado uma solução resulta normalmente numa falha menor, ao passo que torná-la excessivamente complexa abre caminho a um grau de falha muito maior. A aposta mais segura está na solução mais simples. E se uma solução simples for escolhida e se revelar inadequada, é muito mais fácil acrescentar complexidade do que removê-la.