Onde começa e onde termina a arquitetura de um Software?
Sempre defendi que arquitetura é arquitetura, independente da cenários que estamos abordando (não significa que vou sair por ai construindo prédios rsrs). Mas segue uma comparação que podemos fazer:De acordo com o site significado. Significado de arquitetura é:
"Arquitetura é a arte e técnica de projetar uma edificação ou um ambiente de uma construção. É o processo artístico e técnico que envolve a elaboração de espaços organizados e criativos para abrigar diferentes tipos de atividades humanas.
A arquitetura é a disposição das partes ou dos elementos que compõem os edifícios ou os espaços urbanos em geral."
Em software podemos traduzir para:
"Arquitetura é a arte e técnica de projetar um software ou infraestrutura de um software. É o processo artístico e técnico que envolve a elaboração de componentes organizados e coesos para abrigar diferentes tipos de requisito funcionais e não funcionais de um projeto de software.
A arquitetura é a disposição das partes ou dos componentes que compõem o software ou os recursos de infraestrutura em geral."
Dito isso... gostaria de compartilhar algumas alterações que fiquei sabendo que ocorreram na Obra do meu apartamento (certamente você já passou por isso ou sabe de alguém que passou).
Assim que entrei em meu apartamento (onde estou morando a pouco mais de 4 anos), percebi algumas coisas diferentes do que foram apresentados na planta e outras que mudaram no meio do caminho. Duas dessas mudanças, lembro ter questionado:
1. Na planta, existia uma entrada no corredor para prateleiras (na mesma parede de um dos quartos). Mas ao longo da obra, perceberam que se tornaria um espaço de poucas opções e reduziria o quarto por um espaço que poucos utilizariam.
2. No banheiro, o teto do box não deveria ter saída de energia para lampada, mas tem. Pois a medida que a obra foi evoluindo, o arquiteto percebeu que o box poderia ficar escuro por conta de uma leve separação entre o box e o teto do banheiro. O que faria, dependendo da lampada que fosse usada, que o box não recebesse luz o bastante e então ele incluiu uma saída a mais para receber outra lampada, dentro do box.
Percebam que o que foi definido lá no inicio da obra, sofreu alterações (não apenas essa, mas deveríamos ter um espaço para visitantes estacionarem, mas se tivessem levado isso pra frente, hoje não teríamos vagas exclusivas, sem rodizio e totalmente separadas)
E o kiko?
Agora vou citar dois casos reais, onde alterei a abordagem que estava em uso, também por alguns motivos e também com o carro andando.1. Uma aplicação web (front), utilizada apenas no horário comercial. Estávamos rodando no kubernetes, junto com outras aplicações (bacana, utilizando recursos já reservados, faz sentido). Mas começamos a utilizar mais e mais recursos do kubernetes, então, eu poderia tomar duas ações: Fazer upgrade do cluster kubernetes para atender a necessidade, ou mover a aplicação (que só era usada poucas vezes no horário comercial), para serverless (pagando pelo uso apenas - ainda não saímos da faixa gratuita), garantindo liberação de recursos no kubernetes, para outras aplicações que necessitam executar 24/7.
2. Um service executa algumas tarefas de replicação de dados dentro do kubernetes, usando uma biblioteca para agendamento de baseado em cron. Porém, como o responsável por agendar as tasks está dentro da aplicação, somos obrigados a manter apenas uma instancia de POD (unidade de container), nessa apliação. Perdendo um dos grandes benefícios do kubernetes (escalabilidade vertical dos pods). E também somos obrigados a realizar novos deploys ou executar os endpoints dentro da rede manualmente para forçar ma atualização quando necessário. Para contornar isso, optamos por usar o cloud scheduler para chamar esse service. Permitindo auto scale, alteração direto pelo painel do cloud scheduler no intervalo das execuções ou até mesmo, solicitar uma imediata execução manual, sem ter que fazer nada na aplicação.
Humm, parecem abordagens semelhantes.
Se esse titulo não foi sua conclusão, desculpe!Em ambas as situações, projetamos algo no inicio e isso foi alterado a medida que a aplicação ou a infraestrutura cresce. Nos forçando a tomar outras decisões e rever o que antes era visto como "adequado".
Em resumo, o que pretendo com isso, é mostrar que arquitetura é algo tão mutável, como o próprio projeto. Arrisco dizer que mais mutável que o próprio projeto, visto que geralmente os projetos recebem novas features e pouco se altera nas já implementadas, enquanto a arquitetura pode mudar drasticamente se um crescimento exponencial for identificado, por exemplo.
Enfim. Arquitetura nunca tem fim!
Se eu tivesse de escolher uma palavra para definir arquitetura, eu certamente escolheria Resiliência.
Projetar um software, por mais simples ou inadequado que sejam as tecnologias elencadas, deixa de ser um problema se o software está desacoplado e distribuído o suficiente para tornar a refatoração não impactante para o projeto.
Então, respondendo a pergunta no titulo desse artigo: Arquitetura inicia junto com o projeto e nunca tem fim.
