Características e dicas de arquitetura/requisitos não funcionais

Fala galera,

tudo beleza?

Vou começar alguns artigos aqui no Dev.to mais voltados a arquitetura, segurança e boas praticas.

Para começar vamos falar um pouco sobre algumas caracteristicas e dicas para uma boa arquitetura de software :)

Arquitetura de software não é uma receita de bolo pronta. Embora tenhamos diversos "Patterns" para nos auxiliar , a utilização e elaboração depende muito da necessidade.

Por exemplo, um sistema distribuido de larga escala tem necessidades diferentes de um sistems de ticket ou intranet (muitas vezes conhecidos como um simples CRUD) que rodam apenas interno em uma empresa.

Esses pensamentos deve sempre existir no inicio da elaboração de uma arquitetura: Quais recursos essenciais você precisa neste sistema? Ele pode ficar fora do ar por quanto tempo ? Quantas pessoas irão utilizar ? Ele precisa escalar ? etc etc etc

Existem diversos requisitos que um sistema precisa cumprir, mas claro tudo depende da famosa NECESSIDADE! Você não precisa utilizar tudo isso que explicarei em seu sistema, na verdade a ideia é lhe dar um leque de caracteristicas e como disse acima você aprender o que é e quando utilizar.

Adotando que os requisitos funcionais irão definir o que um sistema deve fazer vamos citar algumas caracteristicas que podem ser uteis :

Scalability:

A capacidade do seu sistema continuar funcionando normalmente à medida que o número de usuários ou solicitações aumenta. A escalabilidade é alcançável com dimensionamento horizontal ou vertical ( Sim aplicações monoliticas escalam tambem, não só os "Amados" microservices Dica de Leitura : MONOLITOS NÃO ESCALAM? ) .

Traffic Pattern: Qual o padrão de de tráfego do sistema ? Isso é importante principalmente visando custos ,para não alocar recursos desnecessarios.

- Diurnal Pattern: O famoso tráfego intenso pela manhã ,mas que diminui a noite. Podendo ser em uma determinada região apenas por exemplo, e invertendo em outra.
- Global / Regional: O uso intenso da sua aplicação a nivel global, preciso me preocupar com isso em uma aplicação disponibilizada globalmente.
- Thundering Herd: o Famoso horario de pico, preciso de muitos recursos mas posso não ter marquinas suficientes para atender o novo tráfego.

Elasticity: Capacidade de automaticamente gerar novos recursos para lidar com o aumento do tráfego e remove-los quando o mesmo estiver diminuindo.

Latency: Como atender uma solicitação o mais rápido possível. Deve-se otimizar os algoritmos para reduzir por exemplo o tempo de uma solicitação. Isso deve ser considerado de acordo com a principal funcionalidade do seu sistema.Por exemplo a velocidade de uma busca de um produto na Amazon.

Availability:

Quanto tempo o seu sistema necessita ficar "no ar" ? Muitos sistemas (principalmente internos em empresas) não necessitem ficar no ar 24 horas por dia, 7 dias por semana. Entretanto aqueles que necessitam devem estar procupados com erros do proprio sistema, problemas de infraestrutura, ataques externos, quantidade de acessos e sobrecarga do mesmo.

Deployment Stamps: A possibilidade de gerar varias "copias" independentes de componentes de suas aplicações, incluindo armazenamentos de dados, banco e etc.

Geodes: Em aplicações globais, implante serviços/Aplicações em locais especificos capaz de atender uma requisição em qualquer região do Globo.

Extensibility

A extensibilidade é a capacidade de criar funcionalidades novas, melhorias e etc.Porem sem afetar as funções existentes da aplicação atual. Um bom sistema é pensado para ser capaz de evoluir mas sem afetar o funcionamento ou indisponibilizar a aplicação atual.

Modular / Reusability: Modularização e reutilização, juntamente com a extensibilidade, facilita alterações de projeto com menos tempo de desenvolvimento e manutenção, além de maior confiabilidade.

Pluggability: Seu sistema ,caso precise, deve ser capaz de se conectar facilmente a outros componentes / serviços externos.

Consistency e Resiliency

Consistencia é um ponto muito importante de um software bem feito. Cada leitura deve garantir que seja retornado o registro mais recente. Imagine um sistema Bancario, é preciso garantir que o saldo retornado sempre seja o atual considerando todas as operações realizadas naquele periodo.

Ja a Resiliencia deve garantir a capacidade de se recuperar de qualquer falha, seja acidental ou não (uma invasão, código malicioso). No mesmo exemplo do sistema bancario é garantir que a indisponibilidade não gere valores incorretos em contas.

Recoverability e Disaster Recovery: Capacidade que sua aplicação tem de se recuperar ao estado inicial. Ao pensar em uma arquiterura grande e principalmente distribuida o "e se" é uma preocupação. Se um serviço ficar offline sua aplicação tem a capacidade de se recuperar e seguir sem ele?

Existem boas praticas que devem ser pensadas para prevenir e minimizar problemas externos e alem do controle na aplicação. A garantia de integridade de dados deve ser priorizada para não causar problemas futuros.

Design Patterns:

- Bulkhead: A ideia é isolar os elementos das aplicações para que caso um falhe os outros continuem funcionando.
- Circuit Breaker: a possibilidade de resolver problemas que podem levar um tempo consideravel para ser corrigido. Como um serviço de terceiro por exemplo.
- Leader Election: Consiste em eleger uma instancia como Lider que ficara responsavel por gerenciar outras instancias.

Usability

De que adianta uma linda arquitetura se seu sistema não é facil de utilizar? Usabilidade é a capacidade de um sistema fornecer uma excelente experiencia e condições para que os usuarios executem suas tarefas de forma simples, eficaz e com segurança.

Accessibility: Disponibilizar o sistema de forma inclusiva para pessoas com a mais ampla gama de características e capacidades. Por exemplo, deficiente auditivos, visuais, daltonismo, etc.

Learnability: O Quão facil é aprender a utilizar seu sistema? Sem uma explicação ou um manual prévio como seu usuario consegue utilizar e fazer o que é preciso?

API Contract: No caso de outras equipes, é facil entender como foram criadas as apis caso seja necessario integrar/serem consumidas com sistemas de terceiros ?

Observability

Dados! sim , quanto mais dados coletados pela sua aplicação melhor. Erros internos, logs de uso, dados sobre a comunicação com serviços de terceiros e etc. É possivel utilizar várias técnicas e ferramentas de log e rastreamento de informação.

Inclusive recomendo um Episodio do Devshow( Podcast que faço parte) sobre o Assunto : DEVSHOW #39 – MONITORAMENTO E OBSERVABILIDADE

Logging: Logs gerados pelo sistema. logs de eventos, logs de transações, logs de mensagens e logs do servidor.

Alerts & Monitoring: Painéis de monitoramento, dashboard e outros recursos podem ser uteis para entender como o serviço esta se comportando. Tanto em uso, como em comportamento.

L1 / L2 / L3: Processo de suporte padrão. Sim, por incrivel que pareça isso deve ser considerado em elaboração de uma arquitetura bem feita. O suporte L1 inclui a interação com os clientes. O suporte L2 gerencia os tickets encaminhados a eles por L1 e ajuda a solucionar problemas. L3 é a última linha de suporte e geralmente inclui uma equipe de desenvolvimento que trata das questões técnicas.

Security

Considero uma das partes mais importantes da sua aplicação. Como seu sistema protege as informações. Quais os acessos que cada utilizador pode ter.A aplicação não deve permitir acessos não autorizados ou revelar dados de terceiros a utilizadores.
Alem de claro uma verificacão de autenticidade dos usuarios.

Sua aplicação deve ser auditavel de forma facil, caso uma brecha de segurança ocorra essa auditoria deve ajudar a determinar onde o problema ocorreu.

Compliance e privacidade devem ser essenciais para os dados, principalmente os sensiveis. Evitando vazamentos e problemas para terceiros.

Recentemente gravamos uma live falando sobre o assunto, vale a pena dar uma conferida :

Mesa Redonda #129: Código seguro - dicas para aplicações, ferramentas...

Este assunto pretendo fazer um artigo separado falando mais de segurança.

Durability

Quanto a sua aplicação vai ficar no ar? A durabildiade é a capacidade da aplicação, de manutenção e atender às necessidades dos usuários por um tempo relativamente longo.

Replication: Compartilhamento de informações para garantir a consistência entre recursos.

Fault Tolerance: A garantia que permite que sua aplicação continue operando corretamente em caso de falha de um ou mais componentes.

Archivability: Os dados precisão ser arquivados ou excluidos? Caso necessario é bom ter o famoso plano B em caso de recuperação. Ao inves de excluir apenas uma mudança de satatus ou um banco secundario. Lembrando que dados sensiveis devem sempre respeitar a LGPD

Development

Maintainability: O Quão facil é modificar sua aplicação? Ela foi construida com eficiencia prevendo uma modificação futura? A capacidade de manutenção representa a eficacia com que sua equipe pode modificar seu sistema para corrigi-lo ou melhora-lo de forma agil.

Testability: A facilidade com quem os desenvolvedores e outras equipes cosneguem testar a sua aplicação .

Deployability: O tempo para colocar sua aplicação em produção, configuração e etc.

Portability: Caso seu sistema precise rodar em plataformas diferentes, por exemplo com um banco SQL e depois com um banco Oracle. Em Windows e depois em Linux.

Compatibility: O Quão compatil sua aplicaçào é para trocar dados e informações com outros serviços, produtos ou ambientes de hardware por exemplo.

Ufa! eu sei que é muita coisa e acredite eu poderia falar de mais hehehehe. Porem são algumas dicas que podem ser utilizadas na elaboração de aplicações, para minimizar erros, melhorar qualidade e tempo de manutenções desnecessarias.

Como material complementar que pode auxiliar em pontos citados eu gostaria de recomendar :

DEVSHOW #33 – GERENCIAMENTO DE CONFIGURAÇÕES

DEVSHOW #40 – APLICAÇÕES MULTI-TENANT

IoC e Dependency Injection – Os erros comuns

Mesa Redonda #120: Arquitetura de Microsserviços - tecnologias, dicas, problemas comuns... | 2a ed

Mesa Redonda #117: Cloud Computing - boas práticas, dicas, problemas comuns...

Live #31 - Autenticação e Autorização em Web APIs

Live #27 - O Fim dos Sistemas Monolíticos?

Live #25 - Clean Architecture - Independência

Espero ter ajudado!

Aquele abraço!