O jornalista Matthew Syed, autor do livro "Rebel Ideas, the Power of Diverse Thinking", defende a tese de que a falta de diversidade em seu quadro de funcionários levou a CIA a ignorar os sinais de alerta dos ataques terroristas de 11 de setembro de 2001. Syed afirma que a diversidade em grupos humanos deve ser tratada como fonte de vantagem competitiva para todas as organizações, por criar um ambiente com perspectivas "que desafiam, ampliam, divergem e polinizam" [1].

E o que isso tem a ver com software? Tudo, pois o software, como parte de produtos e serviços de tecnologia de informação em uma sociedade cuja economia está baseada na informação, precisa ser competitivo. E a competição está acirrada. O professor Klaus Schwab afirma que uma das mudanças provocadas pela difusão da Internet das Coisas é que toda empresa se torna potencialmente uma empresa de software.

Segundo o Conselho da Agenda Global sobre o Futuro do Software e da Sociedade do Fórum Econômico Mundial [3], "o software tem o potencial de mudar drasticamente nossas vidas". Schwab [2] vai um pouco além e afirma que "na quarta revolução industrial, a conectividade digital habilitada por tecnologias de software [já] está mudando fundamentalmente a sociedade".

É por esse papel central na sociedade contemporânea e pela alta competitividade decorrente da digitalização dos negócios que se faz necessário compreender mais profundamente a natureza do software, de sua construção e de sua manutenção. Ao compreender esses aspectos podemos perceber o motivo da diversidade ser um elemento precioso para o software hoje.

Uma breve história do software

Apesar de recente na história da humanidade, o software é uma tecnologia cuja complexidade cresceu exponencialmente nas últimas décadas. Dos primeiros programas de cálculo executados em uma única máquina, hoje triviais para pequenas calculadoras, o software passou a complexos sistemas de controle distribuídos em múltiplas unidades de processamento interligadas em rede pelo mundo.

Conforme o escopo dos problemas aumentava, crescia também o tamanho do software e o tempo para seu desenvolvimento. No final dos anos 70, Brooks [4] já mostrava que o software havia deixado de ser apenas um programa que podia ser escrito e mantido por uma única pessoa, sem necessidade de ambientes específicos, para se tornar um produto da programação de sistemas que exigia grandes equipes cujos integrantes não tinham individualmente o domínio completo do sistema. O software passou de meros scripts de automação de cálculos balísticos para grandes sistemas de informação. E grandes sistemas de informação exigiam grandes softwares com grandes equipes e grandes prazos de execução.

Mas esse crescimento atingiu um limite. O professor Stephen Andriole afirma que hoje o "grande software está morto" [5]. Para ele, não há mais motivos para manter projetos que exijam vários anos de trabalho. Existem, atualmente, alternativas para desenvolver sistemas altamente complexos pela composição de pequenos softwares baseados em nuvem, que escalam, integram e compartilham o controle de processos. Esse é o movimento da diversidade.

E para compreender as razões da morte desse grande software e porque os sistemas contemporâneos precisam ter diversidade em sua composição, faremos agora uma breve viagem pela história da tecnologia.

E nasce o software

Pressman e Maxim [6] definem software de computador como “programas executáveis em um computador de qualquer porte ou arquitetura”. Apenas com esse conceito, podemos considerar software a programação direta de unidades de processamento na década de 1940. Mas Brooks [4] acrescenta que um programa “está completo, pronto para ser executado” o que não é o caso da primeira fase da programação de computadores. Nesse sentido, é necessário considerar o conceito de programa armazenado, que surgiu no documento First Draft of a Report on the EDVAC, de John Von Neumann, em 1945 [7]. Pode-se assumir que essa seja, de forma mais precisa, a data de nascimento do software.

O surgimento da linguagem de programação

A programação era muito limitada, no início da computação eletrônica, pelas limitações do próprio computador. A instrução da máquina pelo homem também era limitada pela dificuldade de traduzir o pensamento humano para a linguagem de máquina. Para que a atividade de programar computadores pudesse ser produtiva, era necessário uma camada de abstração entre o ser humano e o computador. Assim surgiram as linguagens de programação, quer permitiam expressar as primitivas interações da máquina com comandos que faziam sentido para um humano.

A primeira linguagem de programação foi projetada em 1945, mas as primeiras a serem implementadas foram o FORTRAN e o FLOW-MATIC em 1957. A partir dessa data até 2004, o professor Sebesta [8] registra o surgimento de cerca de 50 versões de linguagens. Em janeiro de 2020, o índice TIOBE [9] registrou 50 diferentes sintaxes de linguagem, sem considerar suas versões. Essa diversidade reflete a variedade de problemas para os quais se propõe o uso do computador eletrônico.

O crescimento desta complexidade foi resumido, em 1972, por Dijkstra [10]: “quando nós tínhamos poucos computadores fracos, programar era um problema suave, e agora quando temos computadores gigantes, programar tem se tornado um problema igualmente gigante”.

A independência dos sistemas

Ainda nos 70, segundo Pacitti [11], ocorreu uma mudança no tratamento do software dentro da cadeia de valor dos sistemas de informação computacionais. Mudanças na jurisprudência dos Estados Unidos contribuíram para o nascimento de uma indústria de software, baseada na produção e venda de software independente do hardware.

O software, antes simples e preso a um único modelo de um único fabricante, agora se tornava independente da máquina onde seria executado – e mais complexo. O software que no princípio era livremente distribuído e compartilhado, agora se tornava um produto de valor, cujo código-fonte era protegido e cuja execução era controlada por meio de licenças.
A seguir, abordaremos as principais categorias nas quais o software foi dividido ao longo do tempo.

Software monolítico

Na primeira fase de sua curta história, o software era escrito para ser hospedado e executado em um único computador. Poderia ser composto de vários programas, distribuídos em vários arquivos, mas todas essas partes eram interdependentes, de modo que a falha em uma das partes implicava a falha do todo.

Software distribuído

Na década de 1960, os computadores já eram conectados em rede, mas os programas rodavam, cada um, em apenas uma unidade de processamento. Embora o hardware fosse distribuído, o software ainda não era. Uma instância de um programa podia criar vários processos em um sistema operacional e atender vários usuários simultaneamente, mas ainda era um único software monolítico que, se falhasse, deixaria de atender a todos simultaneamente.

Com a disseminação dos microcomputadores na década de 1980 e posterior abertura comercial da internet na década de 1990, foi possível distribuir o software entre duas partes: o cliente, um microcomputador; e um servidor, que poderia ser um mainframe, um minicomputador ou outro microcomputador. Uma parte do software era executada no cliente e outra no servidor, em uma arquitetura denominada de cliente-servidor, que se expandiu nesse período.

Mas embora o software fosse distribuído nesse modelo, ele permaneceu centralizado: os clientes dependiam completamente do servidor. Se o servidor falhava, todos os clientes falhavam. A disponibilidade nesse caso era garantida com replicação ou espelhamento de servidores: se um servidor parasse de funcionar, outro, com a mesma configuração e os mesmos programas, assumia. Mas se a falha estivesse no software, o problema continuaria mesmo com a substituição da máquina.

Software descentralizado

A complexidade do desenvolvimento de software e a exigência de alta disponibilidade para serviços de tecnologia da informação obrigaram a adoção de arquiteturas que descentralizassem o software, em uma evolução da arquitetura cliente-servidor. Funcionalidades antes concentradas em um único software foram distribuídas em mais de um, de modo que se uma parte do sistema parasse de funcionar, as demais poderiam continuar operando normalmente.

Neste modelo, um sistema de bancos de dados pode, por exemplo, ser dividido em vários sistemas, cada um sendo executado em diferentes máquinas. O serviço que consome os dados de um banco não precisa parar se outro banco de dados, do qual ele não depende, ficar indisponível. Um banco de dados relacional, que segue um modelo criado no paradigma do software centralizado, exige que todas as tabelas estejam no mesmo banco apenas se elas estiverem relacionadas. Tabelas que não tem relacionamentos não precisam ficar em um banco relacional. Assim, um banco não relacional pode manter disponível um serviço mesmo com a queda do banco relacional, pois encontram-se em máquinas diferentes e talvez até em redes diferentes.

Software orientado a serviço

Com a combinação de distribuição e descentralização, o software não precisa se orientar para resolver todos os problemas de uma organização. Ele volta, de certa forma, para o passado, quando era apenas um programa em um computador limitado, e se orienta para resolver apenas um problema específico, mas que constitui um serviço a ser prestado e consumido. Um grande sistema de informação pode ser composto a partir de diversos serviços, executados em diferentes máquinas e implementados por diferentes linguagens de programação.

Software Wolverine

É assim que chegamos ao modelo de software que deve ser pensado para um microsserviço, um serviço altamente focado em resolver um problema bem delimitado. Como o personagem Wolverine, dos X-Men, o microsserviço deve ser construído para ser o melhor no que ele faz. E para ser o melhor no que faz, ele deve usar os melhores recursos disponíveis.

Quando o software era monolítico, fazia todo sentido desenvolvê-lo com apenas uma linguagem de programação. Todas as partes do sistema estavam na mesma máquina e a comunicação entre elas era direta. Mas agora, com a arquitetura de sistemas distribuídos em microsserviços, a comunicação não é direta. Cada serviço pode estar hospedado em uma máquina diferente, ou em um container diferente dentro um ambiente virtualizado, e terá de usar um barramento de rede para se comunicar com os outros serviços.

Nesse cenário, cada serviço pode ser implementado na linguagem de programação que ofereça o melhor compromisso entre o consumo de recursos da máquina e a manutenção do software. Para cada problema, pode ser usada a linguagem de programação que ofereça a melhor implementação. Assim como um mecânico tem diversas ferramentas e cada uma é adequada para um tipo de situação (pregar, parafusar, serrar, etc), cada linguagem de programação é mais adequada para determinado tipo de problema.

É aqui que a diversidade se torna uma vantagem no desenvolvimento de software. Quando o software era monolítico, não valia a pena ter diversidade, mas agora, com cada software distribuído, cada serviço pode usufruir dos melhores recursos disponíveis, pois os problemas têm um escopo menor. A homogeneidade não faz sentido para tarefas complexas como inteligência.

E essa vantagem pode ser explorada não apenas por novos microsserviços. Os que estão em produção podem se beneficiar de uma refatoração, que aumente desempenho ou reduza a complexidade com consequente economia do custo de manutenção. Como os microsserviços só conhecem a interface um do outro e não dependem da implementação, esta pode ser alterada desde que a primeira se mantenha. O fato da arquitetura de microsserviços obrigar os desenvolvedores a programar para interfaces torna mais fácil alterar as implementações.

Melhorar o que existe ou criar algo que seja o melhor possível são capacidades exigidas para um ambiente de negócios competitivo. A inovação não requer necessariamente que algo novo (produto ou serviço) seja criado, mas sim que a forma como ele é apresentado, oferecido ou prestado seja melhorada. E a diversidade no desenvolvimento de software oferece essa possibilidade hoje.

Referências

[1] SYED, Matthew. 11 de setembro: a surpreendente tese que tenta explicar por que a CIA ignorou sinais dos ataques. https://www.bbc.com/portuguese/internacional-49660015

[2] SCHWAB, Klaus. The Fourth Industrial Revolution. Cologny, Geneva: World Economic Forum, 2016.

[3] WORLD ECONOMIC FORUM. Deep Shift: Technology Tipping Points and Societal Impact. http://www3.weforum.org/docs/WEF_GAC15_Technological_Tipping_Points_report_2015.pdf

[4] BROOKS, Frederick P. O mítico homem-mês: ensaios sobre engenharia de software. Tradução: Cesar Brod. Rio de Janeiro: Elsevier, 2009.

[5] ANDRIOLE, Stephen. J. The Death of Big Software. Communications of the ACM. v. 60, n. 12, dez. 2017. http://mags.acm.org/communications/december_2017/?folio=29&&pg=31#pg31

[6] PRESSMAN, Roger S. MAXIM, Bruce R. Engenharia de Software: uma abordagem profissional. Traduação: João Eduardo Nóbrega. 8 ed. Porto Alegre: AMGH, 2016.

[7] VON NEUMANN, John. First Draft of a Report on the EDVAC. https://fa82ee93-a-62cb3a1a-s-sites.googlegroups.com/site/michaeldgodfrey/vonneumann/vnedvac.pdf

[8] SEBESTA, Robert W. Conceitos de Linguagens de Programação. 9. ed. Tradução: Eduardo Kessler Piveta. Porto Alegre: Bookman, 2011.

[9] TIOBE. TIOBE Index for January 2020. https://www.tiobe.com/tiobe-index/

[10] DIJKSTRA, Edsger W. The Humble Programmer. ACM Turing Lecture 1972. https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html

[11] PACITTI, Tércio. Paradigmas do Software Aberto. 2006.

Autor

Flávio Gomes da Silva Lisboa é Mestre em Tecnologia e Sociedade, especialista em Programação Orientada a Objetos e Tecnologia Java, Zend Certified Architect e Engineer, autor de 7 livros sobre programação de computadores, do romance distópico O UM e professor em graduação e pós-graduação. É analista do Serpro há 15 anos.