Arquitetura de Software 101

disclaimer: dependendo de quando você estiver lendo, pode estar desatualizado. 🤙

Tipos de arquitetura

Existem vários tipos, mas talvez os principais sejam:

• software
• solução
• tecnológica
• corporativas

Arquitetura tecnológica

• conhecimento em tecnologias específicas do mercado
• geração de valor baseado na especialidade
• diversidade de profissionais
  • arquiteto elastic (search, kibana etc)
  • arquiteto java (detalhes da jvm etc)
  • bancos de dados (especialistas oracle, sql server etc)
  • ERP (SAP, Salesforce etc)

Basicamente são os especialistas certificados em alguma coisa específica.

Arquitetura corporativa

• impacta estrategicamente a organização como um todo
• avaliação de custos
• avaliação de possíveis novas tecnologias
• padronização de tecnologias
• planejamento de grandes implantações
  • sistema core
  • migrações

Arquitetura de soluções

• fica entre a área de negócios e software
• transforma requisitos em soluções de software
• desenho da solução
  • c4
  • uml
  • bpmn
• analisa os impactos comerciais em relação a uma escolha de tecnologia
• pode auxiliar no processo comercial de venda e pré-venda
• analisa os impactos de custos para o negócio

Arquitetura de software

• é uma disciplina da engenharia de software
• diretamente ligada ao processo de desenvolvimento
• afeta diretamente na estrutura organizacional da empresa
  • formação dos times
  • estrutura dos componentes do software

É a organização fundamental de um sistema e seus componentes, suas relações, seu ambiente, bem como os princípios que guiam seu design e evolução.

organizações que desenvolvem sistemas tendem a produzir sistemas que são cópia das estruturas de comunicação dessas empresas
Melvin Conway

O processo de arquitetar um software estabelece que o que está sendo desenvolvido faça parte de um conjunto maior.

Papel do arquiteto de software

• transformar requisitos de negócio em padrões arquiteturais
• orquestrar desenvolvedores e experts de domínio
• entender conceitos e modelos arquiteturais
• auxiliar nas tomadas de decisão em momentos de crise
• reforçar boas práticas de desenvolvimento
  • testes
  • solid
  • code reviews

Muitas empresas não tem esse cargo explicitamente mas as tarefas são realizadas por profissionais mais experientes como desenvolvedores seniores e tech leads.

Arquitetura vs Design

• arquitetura: escopo global ou alto nível
• design: escopo local

Atividades relacionadas a arquitetura de software são sempre de design. Entretanto, nem todas atividades de design são sobre arquitetura. O objetivo primário da arquitetura de software é garantir que os atributos de qualidade, restrições de alto nível e os objetivos do negócio, sejam atendidos pelo sistema. Assim, compete a aqueles que elaboram a arquitetura tomar as decisões de design necessárias para que esse objetivo seja atingido.
Elemar Jr.

Sustentabilidade

• desenvolver software é caro
• software resolve uma dor
• software precisa se pagar ao longo do tempo
• o software precisa acompanhar a evolução do negócio
• toda solução precisa ser arquitetada

Pilares da arquitetura de software

• estrutura
  • fácil evolução, componentização para atender objetivos do negócio
• componentização
• relacionamento entre sistemas
• governança

Requisitos arquiteturais

• performance
• armazenamento de dados
• escalabilidade
• segurança
• legislação
• auditoria
• marketing

Características arquiteturais

Operacionais

• disponibilidade
• recuperação de desastres
• performance
• backup e recuperação
• confiabilidade e segurança
• robustez

Estruturais

• configurável
• extensibilidade
  • interfaces
  • adaptadores
• fácil instalação
• reuso de componentes
• internacionalização
• fácil manutenção
• portabilidade
• fácil suporte
  • logs
  • debug

Cross-cutting

ou: características que permeiam o software de forma geral

• acessibilidade
• processo de retenção e recuperação de dados (por quanto tempo eles serão mantidos)
• autenticação e autorização
• privacidade
• segurança
• usabilidade

Perspectivas para arquitetar um software de qualidade

Performance

• É o desempenho de um software para completar uma tarefa
• comparar as métricas do software com o mesmo software ao longo do tempo, não comparar com outros softwares
• unidades de medida
  • latência / response time (diminuir)
    • medida em milisegundos
    • é afetado pelo tempo de processamento, rede e chamadas externas
  • throughput (aumentar)
    • quantidade de requisições
• ser performático é diferente de ser escalável
• razões para baixa performance
  • processamento ineficiente
  • recurso computacional limitado
  • trabalhar de forma bloqueante
  • acesso serial a recursos
• formas para aumentar a eficiência
  • escala da capacidade computacional (cpu, disco, memória, rede)
  • lógica do software (algoritmos, queries, overhead de frameworks)
  • concorrência e paralelismo
  • banco de dados (tipos de banco, schema, modelagem)
  • caching
• caching
  • aumenta o throughput
  • cache na borda / edge computing
  • dados estáticos
  • páginas web
  • funções internas
    • evita reprocessamento de algoritmos pesados
    • acesso ao banco de dados
  • objetos
  • caching exclusivo
    • baixa latência
    • duplicado entre os nós
    • problemas com sessões
  • caching compartilhado
    • maior latência
    • não há duplicação
    • sessões compartilhadas
    • banco de dados externo
      • mysql
      • redis
      • memcache

Escalabilidade

capacidade de sistemas suportarem o aumento (ou redução) dos workloads incrementando (ou reduzindo) o custo em menor ou igual proporção.

• escala vertical
  • aumento de recurso computacional na mesma máquina
  • parece mais simples mas caso a máquina tenha problema para tudo
• escala horizontal
  • aumento da quantidade de máquinas
  • mais complexo mas o problema em uma máquina não afeta as outras
  • mais comum no mercado

Escalabilidade x performance

• performance tem o foco em reduzir a latência e aumentar o throughput
• escalabilidade visa aumentar ou diminuir o throughput adicionando ou removendo a capacidade computacional

Escalando software - descentralização

• máquinas são criadas e destruídas o tempo todo, não pode ter medo
  • disco efêmero
    • usar apenas para arquivos temporários
    • utilizar storage / buckets para destinação final
  • servidor de aplicação x servidor de assets
  • cache centralizado
  • sessões centralizadas

Escala de banco de dados

• aumentar recursos computacionais
• distribuir responsabilidade (escrita vs leitura)
• shards de forma horizontal
• serverless
• otimização de queries e índices
  • utilizar APM
  • trabalhar com índices conscientemente
  • explain nas queries
  • CQRS

Proxy reverso

servidor que fica na frente dos servidores web e encaminha as solicitações do cliente para esses servidores

• Nginx
• HAProxy (HA = High Availability)
• Traefik

Resiliência

Conjunto de estratégias adotadas intencionalmente para a adaptação de um sistema quando ocorre uma falha.

O software irá falhar, quer você queira ou não. Seja por nossa culpa que programamos algo errado, seja por culpa de outros softwares em volta dele que vão causar algum erro no nosso.

• ter estratégias de resiliência possibilita minimizar os riscos de perda de dados e transações importantes para o negócio
  • proteger e ser protegido
    • um sistema em arquitetura distribuída precisa adotar mecanismos de autopreservação para garantir ao máximo sua operação com qualidade
    • um sistema não deve realizar mais requisições em um sistema que já está falhando
    • um sistema lendo no ar muitas vezes é pior que um sistema fora do ar (efeito dominó)
  • health check
    • sem sinais vitais não é possível saber a saúde de um sistema
    • um sistema doente possui chance de se recuperar se parar de receber requisições temporariamente (self healing)
    • health check de qualidade
      • não basta apenas retornar um html simples, isso não demonstra a saúde real do sistema
      • é preciso simular algum processamento e consulta ao banco de dados
  • rate limiting
    • você tem que saber os limites do seu sistema
      • teste de estresse
    • proteger o sistema baseado no que ele foi projetado para suportar
  • circuit breaker
    • protege o sistema através da negação de requisições
    • circuito fechado: requisições chegam normalmente
    • circuito aberto: requisições não chegam ao sistema
    • circuito meio aberto: permite algumas requisições para verificar se o sistema tem condições de voltar ao ar integralmente
    • pode ser feito tanto via código quanto direto na rede (service mesh)
  • api gateway
    • centraliza todas as requisições para redistribuição
    • garante que requisições inapropriadas chegam ao sistema (usuário não autenticado por exemplo)
    • implementa políticas de rate limiting, health check etc
  • service mesh (malha de serviço)
    • controla o tráfego de rede
    • todo o tráfego da rede é feito através de proxies
    • evita implementação de proteção no próprio sistema
    • mTLS, circuit breakr, retry, timeout, fault injection etc
  • trabalho assíncrono
    • evita perda de dados
    • não há perda de dados no envio de uma transação se o servidor estiver fora
    • servidor pode processar a transação no seu tempo quando estiver online
    • entender com profundidade o message broker / sistema de stream
  • garantia de entrega (retry)
    • tentativas de entrega a um servidor indisponível
      • linear, sem backoff
      • exponential backoff
      • exponential backoff com jitter
    • kafka / rabbitmq / sqs
      • ack 0 (fire & forget): envia a informação para o broker sem se preocupar com confirmação de recebimento
      • ack 1: broker líder confirma o recebimento
      • ack -1: confirmação de recebimento após líder e seguidores receberem a informação
  • situações complexas (resiliência da resiliência)
    • o que acontece se o message broker cair?
      • perde mensagens?
      • sistema também fica fora do ar?
    • o que acontece se a amazon cai?
      • az? região? multi cloud?