Aprenda sobre os 05 pilares da qualidade de software: qualidade, disponibilidade…

Aprenda sobre os 05 pilares da qualidade de software

Um aplicativo em nuvem que funciona de forma satisfatória se concentrará nesses cinco pilares da qualidade do software: qualidade, disponibilidade, resiliência, gerenciamento e segurança. São eles: 

Escalabilidade: A capacidade de um sistema para lidar com aumento de carga.
Disponibilidade: A proporção de tempo que um sistema está funcional e funcionando.
Resiliência: A capacidade de um sistema para recuperar-se de falhas e continuar a funcionar.
Gestão: Processos de operações que mantém um sistema em execução na produção.
Segurança: Protegendo aplicativos e dados contra ameaças.

Escalabilidade

Escalabilidade é a capacidade de um sistema para lidar com aumento de carga. Existem duas maneiras principais que um aplicativo pode escalar. Escala vertical (aumento de escala) significa aumentar a capacidade de um recurso, por exemplo, usando um tamanho de VM maior. Escala horizontal (escalando fora) é a adição de novas instâncias de um recurso, como VMs ou réplicas de banco de dados.

  • A escala de nuvem real. Os aplicativos podem ser projetados para serem executados em centenas ou até milhares de nodes, alcançando escalas que não são possíveis em um único node.

  • Escala horizontal é elástica. Você pode adicionar mais instâncias se a carga aumentar ou removê-las durante períodos mais silenciosos.

  • O dimensionamento pode ser disparado automaticamente, seja em uma programação ou em resposta a alterações na carga.

  • A expansão pode ser mais barata do que a ampliação. Executar várias VMs pequenas pode custar menos que uma única grande VM.

  • O dimensionamento horizontal também pode melhorar a resiliência, adicionando redundância.

Se uma instância ficar inativa, o aplicativo continuará em execução.

Uma vantagem do dimensionamento vertical é que você pode fazer isso sem fazer alterações no aplicativo. Mas em algum momento você atingirá um limite, onde você não poderá mais escalar. Nesse ponto, qualquer escala adicional deve ser horizontal.

A escala horizontal deve ser projetada no sistema. Por exemplo, você pode dimensionar VMs colocando-as atrás de um load balancer. Mas cada VM no pool deve ser capaz de manipular qualquer solicitação do cliente, portanto, o aplicativo deve estar sem estado ou armazenar o estado externamente (digamos, em um cache distribuído). Os serviços de PaaS gerenciados geralmente têm dimensionamento horizontal e escalonamento automático integrados. A facilidade de escalonar esses serviços é uma grande vantagem do uso de serviços de PaaS.

Apenas adicionar mais instâncias não significa que um aplicativo será dimensionado, no entanto. Pode simplesmente empurrar o gargalo em algum outro lugar. Por exemplo, se você dimensionar um front-end da Web para lidar com mais solicitações de clientes, isso poderá acionar as contenções de bloqueio no banco de dados.

Sempre realize testes de desempenho e carga para encontrar esses possíveis gargalos. As partes com estado de um sistema, como banco de dados, são a causa mais comum de gargalos e exigem um projeto cuidadoso para dimensionar horizontalmente. Resolver um gargalo pode revelar outros gargalos em outros lugares.

Use a lista de verificação Escalabilidade para revisar seu design do ponto de vista da escalabilidade.

Disponibilidade

A disponibilidade é a proporção de tempo em que um sistema está funcional e funcionando. Geralmente é medido como uma porcentagem do tempo de atividade. Erros de aplicação, problemas de infraestrutura e carga do sistema podem reduzir a disponibilidade.

Um aplicativo de nuvem deve ter um Objetivo de Nível de Serviço (SLO) que defina claramente a disponibilidade esperada e como a disponibilidade é medida. Ao definir a disponibilidade, observe o caminho crítico. O front-end da Web pode ser capaz de atender a solicitações de clientes, mas se toda transação falhar porque não pode se conectar ao banco de dados, o aplicativo não estará disponível para os usuários.

A disponibilidade é geralmente descrita em termos de “9s” – por exemplo, “quatro 9s” significa 99,99% de tempo de atividade. A tabela a seguir mostra o possível tempo de inatividade cumulativo em diferentes níveis de disponibilidade.

% Tempo de atividade

Tempo de inatividade por semana

Tempo de inatividade por mês

Tempo de inatividade por ano

99%

1,68 horas

7,2 horas

3,65 dias

99,9%

10 minutos

43,2 minutos

8,76 horas

99,95%

5 minutos

21,6 minutos

4,38 horas

99,99%

1 minuto

4,32 minutos

52,56 minutos

99,999%

6 segundos

26 segundos

5,26 minutos

Observe que 99% de tempo de atividade pode resultar em uma interrupção de serviço de quase duas horas por semana. Para muitas aplicações, especialmente aplicações voltadas ao consumidor, isso não é um SLO aceitável.

Para muitas aplicações, especialmente aplicações voltadas ao consumidor, isso não é um SLO aceitável. Por outro lado, cinco 9s (99,999%) significam não mais do que 5 minutos de inatividade em um ano. É desafiador o suficiente apenas detectar uma interrupção tão rápida, quando mais resolver o problema. Para obter uma disponibilidade muito alta (99,99% ou mais), você não pode confiar na intervenção manual para se recuperar de falhas. A aplicação deve ser self-diagnosing e self-healing, que é onde a resiliência se torna crucial.

No Azure, o Acordo de Nível de Serviço (SLA) descreve os compromissos da Microsoft quanto a tempo de atividade e conectividade. Se o SLA de um determinado serviço for 99,5% isso significa que você deve esperar que o serviço esteja disponível 99,95% do tempo.

Os aplicativos geralmente dependem de vários serviços. Em geral, a probabilidade de um dos serviços ter tempo de inatividade é independente. Por exemplo, suponha que seu aplicativo dependa de dois serviços, cada um com um SLA de 99,9%. O SLA composto para ambos os serviços é de 99,9% x 99,9% ≈ 99,8% ou um pouco menos do que cada serviço por si só.

Use a lista de verificação de disponibilidade para revisar seu design de um ponto de vista de disponibilidade.

Resiliência

Resiliência é a capacidade do sistema de se recuperar de falhas e continuar a funcionar. O objetivo da resiliência é retornar o aplicativo a um estado totalmente funcional após uma falha ocorrer. A resiliência está intimamente relacionada à disponibilidade.

No desenvolvimento tradicional de aplicativos, houve um foco na redução do tempo médio entre falhas (MTBF). Esforço foi gasto tentando evitar que o sistema falhasse. Na computação em nuvem, é necessária uma mentalidade diferente, devido a vários fatores:

  • Os sistemas distribuídos são complexos, e uma falha em um ponto pode potencialmente se espalhar pelo sistema.

  • Custos para ambientes de nuvem são mantidos baixos através do uso de hardware commodity, portanto, falhas ocasionais de hardware devem ser esperadas.

  • Os aplicativos geralmente dependem de serviços externos, que podem ficar temporariamente indisponíveis ou limitar os usuários de alto volume.

  • Os usuários de hoje esperam que um aplicativo esteja disponível 24 horas por dia, 7 dias por semana, sem nunca ficar off-line.

Todos esses fatores significam em nuvem devem ser projetados para esperarem falhas ocasionais e se recuperarem deles. O Azure tem muitos recursos de resiliência já incorporados à plataforma. Por exemplo:

  • O armazenamento do Azure, o banco de dados SQL e o banco de dados do Cosmos fornecem replicação de dados incorporada, tanto em uma região quanto entre regiões.

  • Os discos gerenciados do Azure são colocados automaticamente em diferentes unidades de escala de armazenamento para limitar os efeitos de falhas e hardware.

  • VMs em um conjunto de disponibilidade estão espalhadas por vários domínios de falha. Um domínio de falha é um grupo de VMs que compartilham uma fonte de energia e um comutador de rede comuns. A disseminação de VMs em domínios de falha limita o impacto de falhas físicas de hardware, interrupções de rede ou interrupções de energia.

Dito isso, você ainda precisa criar resiliência em seu aplicativo. As estratégias de resiliência podem ser aplicadas a todos os níveis da arquitetura. Algumas atenuações são mais táticas por natureza – por exemplo, tentar novamente uma chamada remota após uma falha de rede transitória. Outras atenuações são mais estratégias, como o failover de todo o aplicativo para uma região secundária.

Mitigações táticas podem fazer uma grande diferença. Embora seja raro que uma região inteira sofra uma interrupção, problemas transitórios, como congestionamento da rede, são mais comuns – portanto, direcione-os primeiro. Ter o monitoramento e o diagnóstico corretos também é importante, tanto para detectar falhas quando elas ocorrem quanto para encontrar as causas-raiz.

Ao projetar um aplicativo para ser resiliente, você deve entender seus requisitos de disponibilidade. Quanto tempo de inatividade é aceitável? Isso é parcialmente uma função do custo. Quanto o tempo de inatividade potencial custará à sua empresa? Quanto você deve investir para tornar o aplicativo altamente disponível?

Use a lista de verificação Resiliency para revisar seu design do ponto de vista de resiliência.

Gestão do DevOps

Este pilar cobre os processos de operações que mantêm um aplicativo em execução na produção.

As implantações devem ser confiáveis e previsíveis. Eles devem ser automatizados para reduzir a chance de erro humano. Eles devem ser um processo rápido e rotineiro, para que não atrasem o lançamento de novos recursos ou correções de bugs. Igualmente importante, você deve poder retroceder ou avançar rapidamente se uma atualização tiver problemas.

Monitoramento e diagnóstico são cruciais. Os aplicativos em nuvem são executados em um datacenter remoto, no qual você não tem controle total da infraestrutura ou, em algum casos, do sistema operacional. Em um aplicativo grande, não é prático fazer login em VMs para solucionar um problema ou filtrar arquivos de log. Com os serviços de PaaS, talvez nem haja uma VM dedicada para fazer o login. O monitoramento do diagnóstico fornecem informações sobre o sistema, para que você saiba quando e onde as falhas ocorrem. Todos os sistemas devem ser observáveis. Use um esquema de log comum e consistente que permita correlacionar eventos entre sistemas.

O processo de monitoramento e diagnóstico tem várias fases distintas:

  • Instrumentação. Gerando os dados brutos, de logs do aplicativo, logs do servidor da web, diagnósticos incorporados na plataforma do Azure e outras fontes.

  • Coleta e armazenamento. Consolidando os dados em um só lugar.

  • Análise e diagnóstico. Para solucionar problemas e ver a integridade geral.

  • Visualização de alertas. Usando dados de telemetria para detectar tendências ou alertar a equipe de operações.

Use a lista de verificação do DevOps para revisar seu design de um ponto de vista de gerenciamento e DevOps.

Segurança

Você deve pensar em segurança durante todo o ciclo de vida de um aplicativo, desde o design e a implementação até a implantação e as operações. A plataforma do Azure fornece proteções contra uma variedade de ameaças, como invasão de rede e ataques DDoS. Mas você ainda precisa criar segurança em seu aplicativo e em seus processos de DevOps.

Segurança de aplicativos

Em geral, as práticas recomendadas de segurança para desenvolvimento de aplicativos ainda se aplicam à nuvem. Isso inclui coisas como o uso de SSL em todos os lugares, proteção contra ataques de CSRF e XSS, prevenção de ataques de injeção de SQL e assim por diante.

Fonte: Microsoft