Skip to content

deal-machine/architectures

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

53 Commits
 
 
 
 
 
 

Repository files navigation

Software Architecture

"É 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."

"É a relação entre os objetivos de negócio e suas restrições com os componentes a serem criados e suas responsabilidades visando a evolução do software."

Architecture Types

  • Software
    • Uma "disciplina" da engenharia de software
    • Está diretamente ligado ao processo de desenvolvimento de software
    • Afeta e recebe influência da estrutura organizacional da empresa
      • Formação de times
      • Estrutura dos componentes de software
  • Solution - Solução
    • Fica entre a área de negócios e a área de software
    • Transforma requisitos de negócio em soluções de software
    • Realiza os desenhos da solução e como o sistema irá funcionar
      • C4, UML, BPMN
    • Analisa os impactos comerciais em relação as tecnologias
    • Pode participar do processo comercial
    • Analisa os custos
  • Technology - Tecnológica
    • Especialidade em tecnologias específicas de mercado
    • Geração de valor baseado em ferramenta tecnológica
    • Diversidade de profissionais especialistas
  • Corporate - Corporativa
    • Tem impacto direto na organização como um todo
    • Avaliação de custos em áreas e projetos relacionados a empresa
    • Responsável por avaliação de novas tecnologias
    • Padroniza tecnologias e planjea implementações
    • Migrações

what does the software architect do?

  • Transforma requisitos de negócio em padrões arquiteturais
  • Orquestra pessoas desenvolvedoras e experts de domínio
  • Entender profundamente conceitos e modelos arquiteturais
  • Auxilia na tomada de decisões em situações inesperadas
  • Reforçar boas práticas de desenvolvimento, também faz code review

Vantagens em Arquitetar Software

  • Pode navegar da visão macro a visão micro dos softwares
  • Ter opções para solucionar um problema, avaliando os contextos
  • Pensar em longo prazo e sustentabilidade
  • Tomar melhores decisões
  • Não cair em hypes de mercado
  • Imersão em padrões de projetos, desenvolvimento e boas práticas
  • Maior clareza no impacto do software possui na organização
  • Tomar decisões com confiança e mais segurança

Sustentabilidade

  • Desenvolver software é caro
  • Software resolve uma "dor"
  • Software Precisa se pagar ao longo do tempo
  • Software precisa acompanhar a evolução do negócio
  • Quanto mais tempo o software fica no ar, mais receita ele gera
  • A solução precisa ser arquitetada

Pilares da Arquitetura de Software

  • Estruturação
    • Fácil evolução
    • Componentes para atender objetivos do negócio
  • Modularização
    • Independentes que desempenham funções específicas
  • Relacionamento entre sistemas
  • Governança
    • Definições, padronização, regras, documentação, linguagem, protocolos
    • Maneira de produzir software

Requisitos Arquiteturais

  • Performance
  • Armazenamento de dados
  • Escalabilidade
  • Segurança
  • Legalidade
  • Auditoria
  • Marketing

Características Arquiteturais

Operacionais

  • Disponibilidade
    • é quanto o sistema fica no ar e disponível
    • SLA - Service Level Agreement
      • o acordo que vc faz com clientes
    • SLOs Service Level Objectives
      • o objetivo de nível de serviço
    • SLIs - Service Level Indicators
      • o número real da performance
  • Recuperação de desastres
  • Performance
  • Recuperação - Backup
  • Confiabilidade e Segurança
  • Robustes
  • Escalabilidade
    • The Twelve-Factor App
      1. Base do código
      2. Dependências
      3. Configurações
      4. Serviços de apoio
      5. Construa, lance, execute
      6. Processos
      7. Vínculo de porta
      8. Concorrência
      9. Descartabilidade
      10. Dev/prod semelhantes
      11. Logs
      12. Processos Admin

Estruturais

  • Configurável
  • Extensibilidade
  • Fácil instalação
  • Reutilização de componentes
  • Internacionalização
  • Fácil manutenção
  • Portabilidade
  • Fácil suporte (logs, debugging)

Cross-Cutting

  • Acessibilidade
  • Retenção de dados
  • Autenticação e Autorização
  • Legalidade
  • Privacidade
  • Segurança
  • Usabilidade


Documentação

Cada tipo de documentação tem sua própria importância e função, e todas elas juntas ajudam a garantir que o software seja compreendido e mantido ao longo do tempo.

  • Utilização do projeto
    • Como usar o software
    • Quais as funcionalidades
    • Como realizar tarefas específicas
    • Passo-a-passo, imagens, vídeos, fluxogramas e outras formas de ajudar a familiarização do sistema.
  • Desenvolvimento do projeto
    • Registrar processos do inico ao fim no desenvolvimento
    • Tecnologias usadas
    • Decisões de arquiteturas
    • Testes
    • Bugs
    • Soluções adotadas
  • Infraestrutura do projeto
    • Inventário de hardware
    • Inventário de software
    • Diagramas de rede
    • Políticas e procedimentos
    • Documentação de configuração e setup
    • Relatórios de monitoramento
  • Arquitetura do projeto
    • Visão geral da arquitetura
      • objetivos de design
      • requisitos
      • restrições
      • decisões de design importantes
    • Diagramas da arquitetura
      • componentes
      • interfaces
      • dependências
      • fluxos de dados
    • Padrões de design
      • padrões de arquitetura
      • padrões de componentes
      • padrões de comportamento
    • Descrição dos componentes
      • objetivos
      • funcionalidades
      • interfaces
      • detalhes das decisões
    • Interfaces do sistema
      • APIs
      • protocolos
      • formatos dos dados
      • interfaces relevantes
    • Decisões de design
      • motivos das escolhas no projeto
      • decisões

Testabilidade

Quanto mais testável o software for, menos tempo e recursos serão necessários para testá-lo, o que pode ajudar a reduzir o custo e o tempo de desenvolvimento.

  • Design de software
    • código modular, legível e reutilizável
  • Arquitetura do software
    • reduz a complexidade do sistema
  • Instrumentação de código
    • coleta de dados para análise
    • monitoramento
  • Dados de teste
    • disponibilidade de dados
  • Ferramentas de testes
    • automatizados
  • Acessibilidade de interfaces
    • interfaces bem definidas e documentadas

Modificabilidade

É importante porque os sistemas de software precisam ser modificados com frequência para corrigir defeitos, melhorar a funcionalidade, lidar com novos requisitos ou adaptar-se a novos ambientes.

  • Design de software
    • modular e bem estruturado
    • componentes bem definidos
    • interações documentadas
  • Arquitetura de software
    • facilita na hora de adicionar ou remover componentes
    • visa a evolução do sistema
  • Qualidade do código
    • legibilidade
    • utilização de padrões
    • minimização de code smells
    • clean code
  • Documentação
    • completa e atualizada
  • Testabilidade
    • testes garantem a modificação bem sucedida

Escalabilidade

Escalabilidade de software se refere à capacidade de um sistema de software de crescer e se adaptar para lidar com um aumento na demanda.

  • Arquitetura escalável
    • deve suportar altas demandas sem interferir no desempenho
    • pode utilizar sistemas distribuidos e balanceamento de carga
  • Tecnologias
    • Computação em nuvem
    • Conteinerização
    • ferramentas que permitam dimensionamento e gerenciamento
  • Banco de dados escalável
    • deve ser capaz de lidar com grande quantidade de dados e usuários simultaneamente
    • pode utilziar de bancos NoSQL e tecnologias de Cache
  • Monitoramento e otimização
    • ajuda a garantir escalabilidade a longo prazo
    • exemplos de aplicativos
      • New Relic
      • Nagios
      • Splunk
      • AppDynamics
      • VisualVM

Escalabilidade vs Performance

Enquanto performance tem o foco em reduzir a latência e aumentar o throughput (taxa de transferência), a escalabilidade visa a possibilidade de aumentar ou diminuir o throughput, adicionando ou removendo capacidade computacional.

Escala vertical -> aumenta quantidade de recursos Escala horizontal -> aumenta quantidade de instâncias

Descentralização - "Tudo pode ser criado e destruído facilmente."

  • disco efêmero (transitório/temporário)
  • servidor de aplicação vs servidor de assets
  • cache centralizado (compartilhável)
  • sessões centralizada
  • upload e gravação de arquivos

Banco de dados

  • aumento de recurso computacional (discos, memórias, CPU)
  • distribuir responsabilidades (escrita vs leitura) (CQRS)
  • shards (fragmentos) de forma horizontal
  • serverless (s3/dynamoDB)
  • otimização de queries e índices
    • APM - Application Performance Monitoring (Datadog)
    • CQRS - Command Query Responsability Segregation

Proxy Reverso

Um proxy (procurador) reverso é um servidor que fica à frente dos servidores web, e encaminha as solicitações para os servidores web

  • redistribui requisições entre os servidores
  • opções
    • Nginx - Engine X
    • HAProxy - High Availability
    • Traefik

Disponibilidade e Observabilidade

Disponibilidade refere-se à capacidade de um sistema ou serviço estar disponível para uso em um determinado momento.

  • tempo de atividade
  • tempo de disponibilidade do sistema

Observabilidade, refere-se à capacidade de observar e medir o comportamento de um sistema ou serviço em tempo real.

  • métricas de desempenho
  • tempo de resposta
  • taxa de erros
  • utilização de recursos

Performance

É a medida de quão bem um sistema ou componente executa uma tarefa em relação às expectativas ou requisitos estabelecidos.

  • Latência - Response time - Tempo de resposta

    • respostas de solicitações ou chamadas
    • medido em miliseconds
    • tempo de processamento da aplicação + rede + chamadas externas
  • Throughput Taxa de transferência

    • quantidade de requisições
    • quantidade de dados transferidos em função do tempo
  • Utilização de recursos computacionais

    • processamento(CPU)
    • memória
    • armazenamento(Disco)
    • Rede
  • Lógica

    • queries
    • algoritmos
    • overhead de frameworks
  • concorrência e paralelismo

  • banco de dados e modelagem

  • caching

  • Confiabilidade

    • funcionar sem falhas
    • funcionar sem interrupções por longos períodos
  • Escalabilidade

    • capacidade em lidar com aumento de requisições, dados sem perda de desempenho
    • escala vertical
      • aumentar recurso computacional de uma maquina para melhorar performance
    • escala horizontal
      • aumentar a quantidade de máquinas para aumentar o desempenho

Estratégias de CACHE

Armazenar temporariamente dados que são frequentemente acessados em memória cache para evitar buscar esses dados novamente do local original, como um banco de dados ou sistema de arquivos.

  • Cache da página inteira
    • melhora significativa no desempenho de carregamento
  • Cache de banco de dados
    • reduz a quantidade de solicitações de banco de dados
  • Cache de objeto
    • recursos frenquentes são armazenados
  • Cache de sessão
    • informações da sessão do usuário, ou dados transitórios e temporários
  • Cache de CDN - Content Delivery Network
    • uma rede de entrega de conteúdo
    • armazena arquivos de mídia em servidores distribuídos

Caching

  • Edge computing -> cache na borda
  • Dados estáticos
  • Páginas Web
  • Funções internas
    • evita processamentos pesados
    • acesso ao banco de dados
  • Objetos

exclusivo vs compartilhado

  • exclusivo -> diversas intâncias de cache

    • baixa latência
    • duplica entre os nós
    • problemas relacionados a sessões
  • compartilhado -> cache centralizado

    • alta latência
    • não há duplicação
    • sessões compartilhadas
    • banco de dados externo

Resiliência

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

  1. Um sistema em uma arquitetura distribuída precisa adotar mecanismos de autopreservação para garantir ao máximo sua operação com qualidade.
  2. Um sistema não pode ser "egoísta" ao ponto de realizar mais requisições em um sistema que está falhando.
  3. Um sistema lento no ar, muitas vezes é pior do que um sistema fora do ar.
  • Health Check
    • Verifica a "saúde" de um sistema
    • health check de qualidade, ou seja, dados relevantes para verificação de saúde
  • Rate Limiting
    • Protege o sistema baseado no que foi projetado para suportar
    • Deve-se conhecer o limite do sistema de requisições
    • Pode ser seletivo por cliente ou tipo de cliente que faz as requisições
  • Circuit Breaker
    • Protege o sistema interrompendo as comunicações para restauração do sistema com falha
      • circuito fechado -> requisições chegam normalmente
      • circuito aberto -> requisições não chegam ao sistema
      • circuito meio aberto -> permite quantidade limitada de requisições para verificar as condições de operação
  • API Gateway
    • centraliza as requisições
    • aplica regras, políticas, transformações, verificações, pluggins, etc...
    • entende a necessidade individual de cada serviço
    • implementa rate limiting, health check...
  • Service Mesh
    • Malha de serviços
    • controla o tráfego de rede
    • gerência de proxicies entre serviços
    • entende o comportamento da rede e controla o tráfego
    • mTLS
      • comunicação criptografada entre serviços
    • trabalha com circuit breaker, rerty, timeout, fault injection, etc...
  • Comunicação assíncrona
    • evita perda de dados
    • utiliza message broker que processa dados no tempo de disponibilidade
    • entender com profundidade message broker e sistema de stream
  • Retry
    • garantia de entrega com retentativas de chamadas
      • linear - sem backoff retentativa com tempo crescente linearmente
      • exponential backoff retentativa com tempo crescente exponencialmente
      • exponential backoff - Jitter retentativa em momentos diferentes

About

Some concepts about software architecture

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors