Aqui está um experimento de pensamento. Pegue um computador, instale nele um sistema operacional dominante, junto com vários softwares (bancos de dados, servidores de aplicação, servidores web etc.). Uma vez que tudo estiver funcionando devidamente, desconecte o computador e o coloque em um armário por um ano. Após o ano decorrido, retire-o de seu refúgio, conecte-o na energia e Internet, e inicialize-o. Qual será a primeira coisa (ou melhor, o primeiro conjunto de coisas) que irão acontecer? 47 atualizações de software disponíveis! Novas definições de Vírus!! O Office precisa desligar todos os navegadores para se atualizar!!!

Mesmo que nada tenha mudado dentro do armário, o universo como um todo continuou seu ritmo implacável. Nada no universo de software é estático.

Arquitetos de software têm a responsabilidade de elucidar as decisões sobre como os sistemas se encaixam, muitas vezes através da criação de diagramas, com graus variados de aparatos. Os diagramas têm um ar vago de certeza ao redor deles, um aroma flutuante da matemática.

Assim, os arquitetos frequentemente caem na armadilha de visualizar a arquitetura de software como uma equação que eles devem resolver. A maioria do instrumental comercial vendido para arquitetos de software reforça a ilusão matemática de certeza, com caixas, linhas e gráficos que não mentem! Embora úteis, esses diagramas oferecem uma visualização bidimensional, um instante de um mundo ideal, mas nós vivemos em um mundo quadridimensional.

Para concretizar aquele diagrama 2D, você deve colocar especificidades nele. O rótulo ORM no diagrama 2D se torna Hibernate v4.2.17, evoluindo para uma visão tridimensional do mundo. Quando você tem um plano sobre colocar isso em produção e atualizá-lo para o inevitável Hibernate v4.3.0.1 em seis meses, você se graduou para um mundo quadridimensional. Muitos arquitetos falham em perceber que uma figura estática tem uma vida útil curta.

O universo de software existe em um estado de fluxo constante, é dinâmico e não estático. Arquitetura não é uma equação, mas sim um instante de um processo contínuo.

Os movimentos de entrega contínua e DevOps ilustram as armadilhas de ignorar o esforço necessário para implementar uma arquitetura e mantê-la atual. Não há nada de errado em modelar a arquitetura e capturar esse esforço, mas a implementação é só o primeiro passo.

A arquitetura é abstrata até ser operacionalizada

Em outras palavras, você realmente não pode julgar a viabilidade a longo prazo de qualquer arquitetura até que ao menos você a tenha implementado e também a atualizado. E talvez ainda permitir que ela resista a ocorrências inusitadas.

Aqui está um exemplo concreto, baseado em experiências reais de usuários. Os arquitetos de uma companhia aérea criaram uma arquitetura baseada em serviços com um serviço canônico ao Cliente, encapsulando tudo que era sabido sobre os Clientes. Isso é um instinto natural de projetos de software, o princípio DRY (Don’t Repeat Yourself) – traduzindo, não se repita, fonte única de confiança e outras boas (mas abstratas) ideias. Em seguida, um vulcão entrou em erupção na Islândia, interrompendo as viagens aéreas drasticamente. Os clientes da companhia aérea inundaram o centro de suporte com chamadas, perguntando se o desastre iria afetar seus voos. E as pessoas segurando bilhetes de embarque em partes do mundo não afetadas não podiam embarcar em seus voos (porque, é claro, pesquisas de passagens incluíam Clientes).

Enquanto a arquitetura fez uma lógica sensata, ela caiu durante circunstâncias extraordinárias. Embora possa parecer um desperdício ou talvez até levar à duplicação (surpresa!), ter vários serviços aos clientes (um para lidar com os problemas, um para lidar com os embarques) teria servido melhor ao negócio. Somente ao pensar sobre o aspecto operacional da arquitetura você pode construir um sistema mais robusto, que é um dos objetivos da arquitetura de micro-serviços.

A arquitetura de micro-serviços é a primeira revolução de arquitetura pós-DevOps, destacando a percepção de que arquitetura e DevOps devem se entrosar, tornando preocupações operacionais de um cidadão de primeira classe no projeto arquitetônico.

Tradicionalmente, a mudança é a coisa mais temida para arquitetura de software. Martin Fowler escreveu um artigo intitulado Who Needs an Architect? (em português, Quem precisa de um arquiteto?) destacando várias definições históricas de arquitetura, algumas que dizem que “a arquitetura é o conjunto de decisões de design que devem ser feitas no início de um projeto”. Devido à presença desses elementos arquitetônicos sustentando que tudo mais deve ser confiável, as mudanças na arquitetura são tipicamente demoradas e difíceis.

Uma parte dessa dificuldade é causada por ignorar os aspectos operacionais da arquitetura. Arquiteturas de micro-serviços assumem mudanças evolucionárias constantes, tornando-as menos custosas e propensas a erro, mesmo em situações extraordinárias.

Um bom exemplo de projetos robustos vem de umas das referências de arquiteturas de micro-serviços, Netflix. Muitos grupos de operações tratam suas operações como frágeis, coisas delicadas. A Netflix tenta quebrar seu ecossistema com ferramentas como Simian Army, em português, exército Simiano, projetado para estressar sua arquitetura de formas criativas.

Você não precisa percorrer todo o caminho de uma arquitetura de micro-serviços exótica para ver os benefícios dessa mudança de perspectiva. Um bom exemplo do efeito da energização de um bom controle operacional é a prática de entrega contínua de desassociar a implantação do lançamento.

Um dos eventos mais assustadores para monólitos tradicionais é “ir ao ar”, porque você deve fazer todas as mudanças funcionarem de uma só vez: banco de dados, código, configuração, integração etc. Se você está acostumando com este mundo de Big Bang, uma prática como implantação contínua soa insana: como você pode gerenciar todas essas mudanças o tempo todo?

O segredo é separar a implantação do lançamento das funcionalidades. Feature Toggles (alternar funcionalidade, em português) é uma prática comum de entrega contínua que permite definições de funcionalidades “em voo” em desenvolvimento baseado em tronco (em inglês trunk-based). Bibliotecas de alternar como Togglz lhe permitem controlar a exposição de funcionalidades em tempo de execução através de um filtro de servelet. Assim, você pode implantar um componente em seu ecossistema que inclui código desativado, o que lhes permite ter certeza (através de monitoração) que o componente implantado não teve qualquer efeito nocivo sobre o ecossistema. Na hora marcada, você pode habilitar a funcionalidade e continuar acompanhando para garantir que nada está errado. Se algo der errado, desative a funcionalidade enquanto você determina uma correção. Ao desvincular a implantação do lançamento, separamos as preocupações operacionais dos desenvolvedores e dos usuários.

Os micro-serviços passam a ser a primeira arquitetura que abraça totalmente o DevOps, mas não será a última. As preocupações operacionais da arquitetura continuarão impactando nossos projetos e decisões, o que considero parte da maturação do processo para arquitetura de software.