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 tem 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 tem 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 bi-dimensional, um instante de um mundo ideal, mas nós vivemos em um mundo quadri-dimensional.
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 tri-dimensional 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 quadri-dimensional. 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 de software é 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ê tenha a implementado e também a atualizado. E talvez ainda a permitir que 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 vôos. E as pessoas segurando bilhetes de embarque em partes do mundo não afetadas não podiam embarcar em seus vôos (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é mesmo 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 a 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 evolucionarias 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 perspetiva. 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 vôo” 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 dá 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 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.
Esta é uma livre tradução do artigo Architecture is abstract untill operationalized, de Neal Ford.