Pluraridade: A palavra chave da nova arquitetura de software

#engenhariaDeSoftware #arquiteturaDeSoftware #microsserviços #sistemasReativos

Pluralidade! Sim! O novo software corporativo não pode mais ser chamado assim... Você desenvolve um software para sua empresa, compartilhando recursos com seus parceiros, fornecedores e até com o Governo. O software, hoje em dia, é mais "federativo" do que "corporativo", ou seja, você não cria software pensando só na sua plataforma.

Vou tentar explicar alguns dos "drivers" por trás dessa mudança...




É como uma "vila", formada por: casas, edifícios, barracos e galpões. Não podemos presumir nada sobre quem está em qual ponta do seu software.

Isso não ocorre apenas em TI (tecnologia da informação), mas em praticamente todas as áreas de negócio. E, não podemos esquecer, não há negócio sem TI!

Evolução socioeconômica

Você entra no seu carro, um sensor detecta sua presença e envia (utilizando mecanismos IoT) para uma central de monitoração. Você pega seu smartphone e faz "check-in" no seu vôo, e, logo depois, aciona um aplicativo de navegação.

Notou quantas transações interligadas você acionou, somente nesse pequeno e corriqueiro ato? Pois é... Hoje, sequer consideramos um software que não se integre a diversos meios, como: Web, Mobile e IoT. É a evolução socioeconômica, puxada pela evolução tecnológica.

Algo mudou nas nossas cabeças e, hoje em dia, Internet é algo tão básico que sequer nos damos conta disso. Passou a ser despesa corrente em nossas casas e empresas. Raras são as pessoas que conseguem viver sem ela.

WhatsApp, Facebook eTwitter são tão essenciais que sequer conseguimos viver na Sociedade sem eles.

Evolução tecnológica

O hardware evoluiu, sem dúvida, mas o software, ou as ferramentas e técnicas para desenvolve-lo, evoluíram mais ainda, nos últimos 5 anos.

Arquiteturas distribuídas e heterogêneas são um "must" hoje em dia. Ninguém, nenhum fornecedor, nenhuma linguagem, nenhuma plataforma, nenhum framework e nenhuma ferramenta, conseguem, sozinhas, atender à todas as necessidades que a que a evolução socioeconômica nos desperta.

Precisávamos de uma nova visão sobre arquitetura de software, menos monolítica, menos centralizada. Padrões como Java EE, por exemplo, vêm sentindo e sofrendo modificações em função dessa evolução tecnológica.

Para começar a conversa, temos a "federação" de informações, que já descrevi. Hoje, você não cria software para sua empresa, mas para um aglomerado amorfo de agentes, que utilizam mecanismos distintos e plataformas distintas. Certamente, residem e trabalham em países distintos, com culturas distintas. Isso é pluralidade!

Em segundo lugar, a rápida evolução socioeconômica e tecnológica, nos obriga a sempre repensarmos nosso software, portanto, isso demanda componentes de software menores, descartáveis e distribuídos. Não existe mais o conceito de "vida útil" do software: Quando fica pronto, já é hora de altera-lo.

Novos padrões

Sinceramente, quando está pensando na arquitetura do seu novo software, você ainda considera seriamente "coisas" como: "Façade"? Claro que não! Não faz mais sentido hoje em dia. E outras coisas? Por exemplo: EJBs? Trasações 2 phase commit síncronas? Isso, sem falar nas outras "porcarias", como: OOP e ORM...

A própria plataforma preferida pode mudar... Seu software pode ter que se integrar a um MQTT Broker e receber inputs de Arduinos e Raspberries!

Novos padrões arquiteturais, que favorecem a distribuição e pluralidade do processamento, como Arquitetura de Microsserviços e Sistemas Reativos, estão proliferando rapidamente, e, com elas, novas técnicas de persistência e consistência de dados também.

A unidade do nosso software tem que ser baseada em componentes simples, com menos "pelancas" e de baixo acoplamento (incluindo a redução de Acoplamento de Plataforma). Estes componentes rodarão em múltiplas instâncias, auto controladas por "coreografia", e com segregação de persistência.

Novas práticas de desenvolvimento

Eu sempre fui um defensor do Manifesto Ágil, embora rejeite alguns métodos "fashionistas", e gosto de deixar isso bem claro. Para mim, agilidade é XP, seguido de TDD e BDD, com uma camada de Integração contínua por cima.

Mas, sem dúvida alguma, práticas mais lúdicas, e menos objetivas, como Scrum, por exemplo, dominam o mercado. Elas requerem uma arquitetura mais simples, com menor Complexidade acidental, para atender aos prazos dos Sprints (e também diminuir a quantidade deles).

Infelizmente, no nosso caso em especial (Brasil) focamos no lado errado da revolução! Em vez de acompanharmos as novidades em engenharia de software, focamos em Scrum... Todos querem ser "Scrum Masters", mas esquecem do outro lado, muito mais importante dessa história: O engenheiro de software. Onde vamos parar com isso?

Precisamos urgentemente focar nas novas práticas de desenvolvimento, sob o ponto de vista da pluralidade!

Cleuton Sampaio, M.Sc.