Preparamos a tradução de um artigo de Neil Ford, arquiteto de sistemas e idealizador ideológico da ThoughtWorks, uma empresa de desenvolvimento de software que automatiza os processos de teste e implantação de software.
Neil é um reconhecido especialista em desenvolvimento de software que trabalha na encruzilhada do design ágil e da arquitetura de sistemas. Ele é autor de vários artigos, livros, dezenas de apresentações em vídeo, fala nas principais conferências de desenvolvedores. Você pode ver o trabalho dele em
nealford.com .
Microsserviços como arquitetura evolutiva
A arquitetura de microsserviços está conquistando rapidamente o mundo. Em março, a editora O'Reilly organizou sua primeira O'Reilly Software Architecture Conference. E quase 60% dos relatórios foram dedicados a certos aspectos do uso de microsserviços. Por que esse estilo arquitetônico específico de repente se tornou tão popular?
A arquitetura de microsserviço é um novo estilo de design de arquitetura que surgiu após o DevOps e incorpora práticas contínuas de entrega de software. É também um exemplo de uma arquitetura evolutiva que segue o princípio de mudanças graduais e contínuas em várias dimensões no nível estrutural de uma aplicação. Este artigo discute alguns dos principais recursos e princípios dessa família de estilos arquitetônicos.
Arquitetura evolutiva
Anteriormente, acreditava-se que os elementos da arquitetura "são muito difíceis de mudar após a sua criação". A mudança gradual é o principal princípio da arquitetura evolucionária. Atrai atenção geral precisamente porque as mudanças na arquitetura sempre foram difíceis de prever e muito caras de realizar. Se a possibilidade de mudanças evolutivas for incorporada à própria arquitetura, sua implementação se tornará muito mais simples e barata, contribuindo para mudanças nas práticas de desenvolvimento e liberação de software, além de aumentar o nível de flexibilidade geral do processo.
A arquitetura de microsserviço é totalmente consistente com essa ideia, pois possui
Contextos Limitados, que são alocados logicamente de acordo com o Design Orientado a Domínio de Eric Evans e são implementados como componentes fisicamente separados. Essa separação é alcançada através da implementação de práticas de DevOps, como provisionamento de máquinas virtuais, testes e implantação automatizada. Como cada serviço é separado de todos os outros serviços (no nível estrutural), substituir um microsserviço por outro é tão fácil quanto trocar cubos de lego.
Características da arquitetura evolutiva
As arquiteturas evolucionárias têm várias características comuns. Todos esses recursos serão descritos em um próximo livro sobre arquitetura evolucionária. Neste artigo, apresentamos apenas alguns deles.
Modularidade e conectividade
A capacidade de compartilhar componentes dentro de limites bem definidos oferece aos desenvolvedores o benefício de alterações contínuas, se necessário. Se a arquitetura não foi projetada e o sistema se parece com uma grande bola de barro (
arquitetura Big Ball of Mud ), as mudanças evolutivas são impossíveis, uma vez que não existem partes distintas nessa estrutura.
[O relacionamento entre as classes (aponta ao redor do perímetro) em uma grande quantidade de sujeira de um projeto de cliente sem nome.]A interconexão incorreta de componentes impede a evolução do sistema devido ao fato de que fazer alterações pode afetar imprevisivelmente outras partes do sistema. Todas as arquiteturas evolucionárias fornecem algum nível de modularidade, geralmente no nível da arquitetura técnica (por exemplo, arquitetura em camadas).
Organização em torno de oportunidades de negócios
Influenciada pelos princípios do design orientado ao assunto em arquiteturas modernas de sucesso, a modularidade no nível do domínio está sendo cada vez mais usada. Uma arquitetura baseada em serviço difere de uma arquitetura tradicional orientada a serviços (SOA) principalmente em sua estratégia de alocação de serviços. A arquitetura orientada a serviços é estritamente dividida por níveis técnicos, enquanto as arquiteturas baseadas em serviços são construídas principalmente em partes da área de assunto definida por microsserviços.
Os experimentos
A realização de experimentos é uma das vantagens significativas que a arquitetura evolutiva oferece aos negócios. A capacidade de fazer pequenas alterações com facilidade nos aplicativos fornece o uso de práticas comuns de implantação contínua, como testes A / B, testes para um grupo limitado de usuários (versão Canary) e outros. As arquiteturas de microsserviço geralmente são construídas com base em chamadas de serviço de roteamento, o que possibilita o uso de várias versões do serviço em um ecossistema inteiro. Por sua vez, isso abre grandes oportunidades para experimentação e alterações na funcionalidade existente. Por fim, ao desenvolver aplicativos de negócios, gasta-se menos tempo discutindo planos e pedidos em atraso, e o desenvolvimento é realizado principalmente no modo de teste rápido de hipóteses.
Princípios da arquitetura evolucionária
Uma imagem mais completa da arquitetura evolutiva pode ser obtida familiarizando-se com seus princípios básicos. Esses princípios estão relacionados a várias características da própria arquitetura e de seus métodos de design. Parte dos princípios refere-se à escolha do momento de tomar decisões arquitetônicas no processo de design do sistema.
Função de fitness
É necessário distinguir entre arquitetura emergente (formada como resultado do processo de design) e arquitetura evolutiva - isso é extremamente importante. Assim como os métodos de computação evolutiva (como algoritmos genéticos), a função de adequação arquitetônica define uma meta no projeto arquitetônico. Para alguns sistemas, o principal requisito é um longo tempo de atividade, para outros, alto desempenho ou segurança.
[Tabela de radar usada para destacar funções importantes de condicionamento relevantes para este sistema de software.]
Se você pré-determinar a função de adequação para um sistema específico, isso ajudará no futuro a tomar as decisões corretas em tempo hábil. Para diferentes soluções arquiteturais, é possível calcular funções de adequação e, se seu valor melhorar, isso significa que a arquitetura está se desenvolvendo na direção certa.
Atenção aos pontos de dor
Muitos dos métodos de trabalho usados no fornecimento contínuo de software e no desenvolvimento de uma arquitetura em evolução são baseados no princípio de “atenção aos pontos problemáticos” formulados pela comunidade de programação do eXtreme. Quando surgem momentos no trabalho de design que podem se tornar fontes de problemas (pontos problemáticos), é necessário prestar atenção neles o mais rápido possível. Isso ajudará a identificar problemas potenciais com antecedência e a eliminá-los em uma ordem de funcionamento. Práticas comuns de entrega contínua, como o pipeline de implantação, o provisionamento automático de máquinas virtuais e a migração de banco de dados, ao projetar uma arquitetura evolutiva, simplificam bastante a eliminação de pontos problemáticos durante a fase de mudança.
Ponto de decisão
A principal diferença entre a arquitetura tradicional e a evolutiva é quando são tomadas decisões significativas. Essas decisões podem estar relacionadas à estrutura do aplicativo, pilha de tecnologia, ferramentas individuais ou padrões de comunicação. No caso de projetar uma arquitetura tradicional, essas decisões são tomadas no estágio inicial, antes de escrever o código. No processo de desenvolvimento da arquitetura evolucionária, qualquer decisão é tomada o mais tarde possível, no último momento, quando ainda é aceitável. A vantagem da tomada de decisão posterior é que informações adicionais podem estar disponíveis neste momento. Os custos desse método incluem os custos de um possível refinamento da arquitetura após a tomada de uma decisão. Esses custos podem ser reduzidos usando abstrações adequadas, mas ainda podem ocorrer. No entanto, os custos de tomar decisões na fase inicial também são bastante reais. Tome, por exemplo, a decisão de escolher uma ferramenta de mensagens. Diferentes ferramentas suportam funções diferentes. Se escolhermos uma ferramenta mais poderosa do que o necessário, obteremos uma arquitetura mal concebida que inevitavelmente exigirá mais desenvolvimento. Essa "dívida técnica", decorrente da seleção da ferramenta errada, será um encargo adicional para os desenvolvedores.
Obviamente, o principal problema com o último momento possível de tomar uma decisão é determinar quando ela chega. Para fazer isso, concentre-se na função da aptidão. Antes de tudo, é necessário tomar decisões que possam ter um impacto significativo na escolha de elementos de arquitetura ou design, bem como decisões que afetem significativamente o sucesso geral do projeto. O impacto negativo de adiar essa decisão geralmente supera os possíveis benefícios de uma decisão posterior.
Conclusão
Os arquitetos de software devem explicar as decisões tomadas sobre o design dos sistemas que estão sendo desenvolvidos, como regra, usando vários tipos de diagramas. Os desenvolvedores de arquitetura geralmente caem na armadilha de apresentar a arquitetura de software como a equação que precisam resolver. Muitas ferramentas comerciais oferecidas pelos arquitetos de software permitem que você descreva formalmente a arquitetura na forma de quadrados, linhas e setas. Embora esses diagramas possam ser úteis, eles oferecem apenas exibição bidimensional, um instantâneo do mundo ideal, mas vivemos na realidade quadridimensional.
Para preencher esse diagrama bidimensional com vida, é necessário especificá-lo. O rótulo
ORM em um diagrama bidimensional se torna o
Hibernate v4.2.17 , tornando o mundo em
questão tridimensional. Quando você planeja sua implementação em produção e atualiza seis meses depois para a versão inevitável do
Hibernate v4.3.0.1 , você estará pronto para o mundo quadridimensional. Muitos arquitetos não percebem que uma visão estática da arquitetura tem uma vida útil curta. O universo do software existe em um estado de fluxo; é dinâmico, não estático. Arquitetura não é uma equação, mas um instantâneo de um processo em andamento.
As práticas de entrega contínua de software e o DevOps mostraram problemas crescentes devido à falta de entendimento dos esforços necessários para implementar e dar suporte à arquitetura. A implementação da arquitetura é apenas o primeiro passo.
A arquitetura permanece uma abstração até ser posta em ação. Em outras palavras, a viabilidade de qualquer arquitetura a longo prazo pode ser julgada apenas quando você não apenas implementou, mas também a modificou pelo menos uma vez. E talvez eles tenham conseguido lidar com as surpresas ao longo do caminho.
O entendimento de um arquiteto de software sobre os recursos operacionais é fundamental para o desenvolvimento de uma arquitetura evolutiva. O desenvolvimento evolutivo da arquitetura afeta os recursos de sua implementação e, portanto, eles devem ser levados em consideração no processo de conclusão. Os requisitos do processo de entrega contínua para a arquitetura visam melhorar sua visualização e simplificar as alterações. Dessa forma, a entrega contínua aprimora os recursos da arquitetura evolutiva.
Em 19 de novembro, Neil Ford chega a Moscou com uma master class
sobre a criação de arquitetura evolutiva de software .