O Software no século XXI

Tenho falado muito sobre o "Século XXI", sobre as empresas, os negócios e os profissionais. Mas faltou falar sobre uma coisa: O Software!

Eu meto o "malho" na maneira como as pessoas e empresas pensam e constroem software hoje em dia, e tenho recebido algumas críticas, de pessoas que dizem que eu critico sem mostrar um caminho. Pois bem, de "presente" de Reveillon, aqui vai.

Um castelo de frameworks e componentes

 As pessoas e as empresas ainda projetam e constroem software como faziam no século passado. Neste aspecto, as empresas ainda vivem nos gloriosos anos 70! O Software é projetado como um castelo (ou bolo de noiva), com diversas "camadas" altamente acopladas, cuja menor alteração, implicará em uma entrega do "bolo" todo de uma só vez.

Por que fazer um software????

Essa é a primeira pergunta que um Gestor do Século XXI deveria fazer. Só isso, já "aguaria"os ímpetos "gastadores" dos informatas de plantão, literalmente colocando "areia" na "farofa" deles.

Escrever programas é caro! Dá trabalho e demora, isso sem falar nos riscos! E, ao final, você terá um produto, que dura apenas alguns poucos meses, ficando completamente desatualizado em pouco tempo. E, como os softwares são criados em arquiteturas "bolo de noiva", mudar um aspecto significa mudar tudo!

Estamos na época do XaaS! Tudo "As a Service"! Será que não tem um XaaS que atenda às suas necessidades, com pouca ou nenhuma configuração? E, caso seja um sistema analítico, será que uma combinação de ElasticSearch com Kibana não seria mais barato e eficiente? Em último caso, será que não tem um conjunto de ferramentas que você possa "encaixar" e atender às suas necessidades? É claro que tem! E o pior de tudo: Open Source.

Soluções como: Apache Flume, Apache Hadoop, Hive, Pentaho, ElasticSearch, Kibana e outros, podem ser conectados, como "tubos", e lhe permitem criar um fluxo de dados com pouca ou nenhuma programação, em curto espaço de tempo (o seu "backend"), e você pode disponibilizar essa informação para o mundo, igualmente sem escrever código, usando soluções "zero code", como o Zoho Creator, Ionic Creator, e outros, permitem criar apps REST / HTML 5 para interagir com o seu "pipeline" de "backend", com pouquíssimo investimento em codificação.

É preciso trocar "programação" por "configuração", e, se você tem que investir em alguma coisa, tem que ser em UX (Experiência do Usuário), e não em um time de Desenvolvedores!

Sério... Não dá para atender nossos usuários só com isso

É claro que não! As empresas de TI vivem de "mamar" nas "tetas" dos Otá... Ops, "Clientes", então precisam se repetir constantemente, criando e recriando as mesmas porcarias de sempre, que já saem da prancheta desatualizadas. Isso sem falar, nos "bugs" transformados em "features", que podem ser melhoradas em versões futuras...

Ok, então tá... Já que você insiste em criar software, por que não usar uma arquitetura melhor, mais moderna, que valorize o investimento feito, sendo mais adaptável, flexível e aderente aos desafios do Século XXI?

O software moderno tem que ser projetado como uma "vila"

Se você realmente precisa construir um software, então ele tem que ser adaptável e flexível. Tem que ser como uma "vila" de casinhas, onde cada uma delas tenha seu próprio "quintal", e se responsabilize por todo que esteja em sua "cerquinha". E deve ser possível substituir uma casa, sem ter que derrubar tudo e construir novamente.

Em vez de pensar "verticalmente", como os "viciados" Engenheiros e Arquitetos de software de hoje em dia, que, por síndrome do comprometimento, continuam a projetar sistemas como foram ensinados a fazer, na faculdade, é preciso pensar "fora da caixa", ou seja "horizontalmente",  em soluções que efetivamente valorizem o investimento do Cliente, e agreguem valor ao produto.

Porém, enquanto o Cliente descreve suas necessidades, os Informatas, estão pensando algo assim: "Bem, para isso, eu crio alguns EJBs, e posso usar um Cluster de Container JEE assim, assado, com um banco relacional XPTO e posso usar Transações JTA com um Orquestrator ABCD..., usando uma fila JMX...", em outras palavras: Camadas do "Bolo de Noiva"!

Não me leve a mal, essas ferramentas e padrões são boas, mas tiveram o seu tempo. E, ao investir nessas tecnologias, você já está adotando a arquitetura "bolo de noiva", condenando o resto da aplicação a serem parte dele!

Divida seu software em pedacinhos

Sim, para começar, divida seu software em unidades autônomas e independentes, com seu próprio "quintal", ou seja, seu armazenamento de dados e regras tudo encapsulado. Pode chamar do que quiser: Módulos, Unidades, Moléculas (já ouvi chamarem assim), Células, ou então, como o Mercado gosta de chamar: "Microsserviços".

É extremamente importante notar que Microsserviços devem usar mecanismos padrões de mercado, como os da Plataforma da Web Aberta. Nada de protocolos e padrões semi-livres, ou que impliquem no uso de determinada linguagem, sistema operacional ou framework. Cada Microsserviço tem que poder ser codificado na linguagem mais apropriada para sua função, usando o mecanismo de persistência igualmente mais apropriado. E ninguém pode "olhar debaixo da saia" de um microsserviço, ou seja, o acesso aos seus dados só pode ser feito através da sua interface. Mais nada. Um MS não pode usar dados do banco que outro MS usa.

Cada "macaco" no seu "galho"

É isso que estou falando! Cada Microsserviço é um módulo COMPLETAMENTE independente. E podem haver diversas instâncias de cada microsserviço, dependendo da CARGA que cada um está suportando. Isso se chama: "Curadoria de Microsserviços".

Os consumidores dos microsserviços podem criar serviços especiais, que agregam ou criam fluxo de conversação, baseados nos recursos, e estes "agregadores" podem ser executados diretamente pelos Clientes, não requisitando tempo de processamento do "backend".

Microsserviços podem ser "coreografados"

Em vez de usar "Orquestradores" caros e "Componentes Transacionais" consumidores de recursos, podemos criar um sistema baseado em Eventos! Cada instância de microsserviço pode ser configurada para consumir e postar eventos, executando suas atividades quando demandada. Isto se chama de "Coreografia" de serviços.

E os críticos dirão: "Mas e como controlar uma transação distribuída?" Cara, 2-phase commit é coisa do passado! Se você "cultua" essa porcaria, então vá visitar um museu! Os Eventos podem ser encadeados em fila e desfeitos em fila. Um Microsserviço pode manter log de suas transações e desfaze-las sob demanda. E ninguém garante que transações distribuídas, entre EJBs rodando em diferentes nós, são uma boa solução.

Microsserviços são baseados em REST e, portanto, "Stateless". Manter vários componentes "aguardando" um sinal verde para "comitar" os dados, é coisa dos anos 70! Você precisa repensar sua arquitetura. Este Artigo apresenta soluções mais leves e compatíveis com os novos tempos.

Utilizar EJB por que tem que ter "componentes transacionais" é desculpa de quem não estuda, quem não se atualiza, e de quem quer manter o "status quo", acima da real necessidade dos Clientes.

Não é só programar diferente!

Sua aplicação tem que ser entregue em um fluxo contínuo, dentro de "Containers" imutáveis, desta forma, toda a infraestrutura de TI que você necessita, é virtualizada, e entregue como parte do seu produto, evitando "configuration drift" e problemas causados por intervenções manuais.

Não basta construir o software de maneira moderna, é preciso entregá-lo de acordo com os padrões do Século XXI.

E você deve empregar algum tipo de serviço de Curaroria, para ter elasticidade nos seus serviços, reduzindo custo (quando necessário) e melhorando a experiência do usuário, através da escalabilidade elástica.

Soluções como o Eureka, da Netflix, ou o ServKeeper, permitem esse tipo de Entrega contínua.

É assim que fazemos e não vemos razão para mudar

Infelizmente, é assim que as pessoas agem, mesmo os profissionais mais novos de idade, que deveriam ser mais flexíveis, já saem "agarrados" nas "tetas" de certos frameworks e padrões, e, talvez por medo, empregarão as mesmas tecnologias em seus projetos, resistindo fortemente a qualquer sugestão diferente.

Cabe aos Empresários e Gestores, ou seja, os que "metem a mão no bolso", rejeitarem tecnologias, frameworks e ferramentas com quase 20 anos de uso (ou mais). É preciso exigir oxigenação, e não confiar cegamente no "pessoal de TI".


Então, quando o software, finalmente, estiver pronto, depois de uns 30 Sprints, vários meses de espera e milhões de dólares gastos, você constatará que seus concorrentes já estão trabalhando de forma diferente, se adaptando melhor às constantes mudanças no Mercado, e você, que mal acabou de implantar seu caríssimo Software, ainda está discutindo com o pessoal de TI por conta de bugs e de tempo de resposta ruim.


Se realmente for necessário construir um novo Software, ele tem que ficar pronto em semanas, e não em meses. E nenhum "método ágil" garante isso! É preciso repensar a arquitetura e engenharia do software!