BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Uma Abordagem de Arquitetura Incremental para Construção de Sistemas

Uma Abordagem de Arquitetura Incremental para Construção de Sistemas

Favoritos

Para a maioria das aplicações que temos no mundo, talvez 90% delas, sejam perfeitamente atendidas por uma abordagem monolítica; para evitar a superengenharia, devemos começar com uma arquitetura simples e evoluí-la conforme as necessidades, declarou Randy Shoup na conferência Reactive Summit 2018. Em sua apresentação recentemente publicada, ele descreve sua experiência com empresas que começaram pequenas e depois cresceram em grandes empresas globais de internet, como sua arquitetura evoluiu durante esse tempo e suas recomendações de uma perspectiva de TI ao iniciar uma nova empresa ou um novo produto.

Shoup, com experiência trabalhando para eBay, Google e Stitch Fix, atualmente é vice-presidente de engenharia da WeWork. Seu primeiro exemplo foi o eBay, que começou em 1995 como um projeto de fim de semana de três dias, não como uma prova de conceito (PoC) para um negócio, mas para ver se era possível fazer algo interessante na web. Hoje, ele está em sua quinta reescrita completa da infraestrutura e Shoup caracteriza a empresa como um conjunto poliglota de microservices e acrescenta que o Twitter e a Amazon passaram por uma evolução semelhante.

Começar com alguma forma de monolítico e terminar com um conjunto de microservices é para Shoup um padrão comum para grandes empresas, e observa que há duas partes neste padrão - ninguém começa com microservices e, acima de uma certa escala, todos acabam com microservices.

As empresas mencionadas são todas muito grandes e Shoup aponta que a arquitetura que funciona em sua escala é completamente inadequada para a maioria das empresas. A maioria das aplicações é perfeitamente atendida por uma abordagem monolítica, e a recomendação de Shoup ao criar uma nova aplicação ou sistema é começar de maneira simples e desenvolver a arquitetura conforme as necessidades. Ele gosta de reformular isso como:

Se você não acabar lamentando suas decisões iniciais de tecnologia, você provavelmente está na superengenharia.

Para Shoup, uma curva de progressão comum para a maioria das empresas e produtos inclui uma fase de idéias e de início, uma fase de escalonamento em que os sistemas distribuídos podem ser relevantes e comumente uma fase de otimização:

Architecture progression

Na fase de ideias, Shoup afirma que não devemos ter nenhuma arquitetura sofisticada - somos apenas protótipos. Para evitar a superengenharia, devemos nos perguntar constantemente: "Que problema estamos tentando resolver?" O objetivo nesta fase é explorar o espaço da solução o mais rápido possível e com custo mínimo para:

  • Encontre um modelo de negócio
  • Encontre um ajuste do mercado de produtos
  • Adquira nossos primeiros clientes

Se possível, ele recomenda que tentemos ficar longe de toda a tecnologia, por exemplo, usando anúncios do Google para ver se há cliques, ou usando protótipos de papel ou planilhas do Excel.

Ao entrar na fase inicial, o objetivo é atender às necessidades de curto prazo dos clientes e fazê-lo o mais barato possível. Normalmente, nesta fase, há apenas uma equipe composta por 4 ou 6 pessoas. Eles trabalham com um horizonte de tempo relativamente curto, talvez de 3 a 4 meses. Um argumento para isso é que muitas vezes é difícil enxergar muito à frente em termos de quais recursos criar. Nós só precisamos de uma quantidade mínima de arquitetura, o suficiente para nos fazer avançar. Shoup enfatiza que ainda não é sobre escalonamento; devemos usar tecnologia simples e familiar e, definitivamente, uma arquitetura monolítica - um aplicativo único e um único banco de dados. A infraestrutura deve ser mínima e não construída por você. Em vez disso, ele sugere o uso de plataforma como serviço (PaaS) ou tecnologia similar.

As vantagens de usar uma arquitetura monolítica neste ponto incluem:

  • É simples
  • É rápido porque tem apenas latências no processo
  • Você obtém uma unidade de implantação única
  • É muito eficiente em termos de recursos em pequena escala

Além da falta de dimensionamento e um único ponto de falha, uma grande desvantagem de um monolítico é a fraca aplicação da modularidade. É factível, mas requer programação e disciplina de equipe. Mas Shoup ressalta que nada disso é de alguma preocupação nesta fase. Ainda assim, conforme vemos a necessidade de nos preparar para o dimensionamento, ele acha que vale a pena adotar uma disciplina de modularidade usando componentes ou módulos dentro do monolito. Isso simplificará futuras modificações ou substituições por serviços externos.

Observando quando podemos precisar reestruturar este monolítico, Shoup testou alguns indicadores de aviso:

  • Velocidade: sua capacidade de entrega diminui devido ao acoplamento e falta de isolamento
  • Escala: o escalonamento vertical não funciona mais ou partes diferentes do sistema precisam ser escalonadas independentemente
  • Implantação: diferentes partes evoluem em diferentes velocidades e, portanto, precisam de implantação independente

Quando entramos na fase de escalonamento, o objetivo é ficar à frente de um negócio em rápido crescimento e manter nosso aplicativo em funcionamento. No contexto organizacional, normalmente aumentamos o número de equipes e trabalhamos com um horizonte temporal mais longo. Geralmente, há também a necessidade de introduzir processos repetitivos.

No contexto técnico, a fase de escalonamento geralmente significa uma mudança para uma tecnologia que é dimensionada. Normalmente, começamos a dividir os serviços do monolito, e é muito comum tentar diminuir a carga no banco de dados único, por exemplo, criando réplicas de dados somente leitura. Também é comum começar separando serviços especiais, como pagamento e faturamento, e introduzindo uma fila de eventos ou um barramento de mensagens.

Para Shoup, esse também é normalmente o momento de considerar se devemos migrar nosso monólito para pequenos componentes independentes, o que hoje chamamos de microservices. Também devemos considerar se o armazenamento principal único usado ainda é o caminho certo para armazenar dados. No QCon New York 2017, Shoup mostrou como fazer uma migração incremental de um aplicativo monolítico para microservices e vários mecanismos independentes de armazenamento para diferentes domínios.

No livro The Art of Scalability, um modelo de escalabilidade tridimensional (o AKF Scale Cube) é descrito onde os três eixos representam diferentes tipos de escala:

  • X: duplicação horizontal e clonagem
  • Y: decomposição funcional e segmentação (microservices)
  • Z: particionamento horizontal de dados (shards)

O último passo é a fase de otimização, e Shoup enfatiza que, se alcançado, é um sinal de sucesso. O objetivo é manter o conjunto de funcionalidades, mas usar menos recursos, talvez com menos equipes. Nós também temos um horizonte temporal mais longo, talvez 2 a 5 anos.

Shoup conclui afirmando que a razão para reestruturar neste contexto é uma coisa positiva:

Chegar à revitalização de um sistema é um sinal de sucesso, não de falha.

O negócio está indo bem e você tem os recursos para isso. Não é que você precise ser reestruturado, mas sim fazê-lo.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT