Melhoria da Qualidade com a Nuvem - Parte II
Na primeira parte de qualidade de processos na Nuvem examinamos como a nuvem ajuda com Performance, Funcionalidades, Confiabilidade e Conformidade. Na parte II descreveremos os efeitos positivos da nuvem sobre a Durabilidade, Serviciabilidade, Estética e Qualidade Percebida.
Durabilidade
Durabilidade mede a extensão de vida do produto. Quando um produto pode ser reparado, se torna mais difícil estimar sua durabilidade, já que ele será usado até não ter mais retorno economico para ser operado.
O segredo da durabilidade é usar peças intercambiáveis. Um vela de ignição típica dura de 16.000 a 32.000 kilometros. Um carro durará muito mais - contanto que você substitua suas velas de ignição, óleo, os pneus, os freios e outras peças. Quando a vela de ignição alcança o fim da sua expectativa de vida, ela é substituída e não reparada.
O mesmo deveria acontecer com os servidores. Servidores, especialmente em nuvem, seriam supostamente commodities idênticas. Mesmo existindo alguns tipos de servidores - servidores web, servidores de banco de dados, servidores app X - servidores do mesmo tipo deveriam ser idênticos. Por isso se um servidor pára de funcionar corretamente, deveria ser mais simples e fácil substituí-lo do que consertá-lo.
Servidores que são facilmente destruídos e substituídos são chamados de Servidores Phoenix. Nós recomendamos que servidores renasçam das cinzas mais frequentemente, ao invés de esperar eles quebrarem. Você não iria esperar seu carro parar de andar para substituir o óleo. Por que deveríamos esperar nosso website cair para substituir o antigo servidor web?
Esse processo não se aplica apenas ao hardware. Ele involve reverter a “deriva de configurações” (ou configuration drift) - mudanças ao longo do tempo que começam a diferenciar servidores que deveriam ser idênticos. Algumas vezes isso acontece mesmo que você esteja usando ferramentas de automação de infraestrutura como Puppet e Chef. Seus servidores antigos têm somente a tech stack atual como os servidores novos ou eles tem algum resquício de software antigo que você esqueceu de desinstalar?
Serviciabilidade
Serviciabilidade (ou Recuperabilidade) é a velocidade com a qual um produto pode ser colocado em serviço quando danificado, bem como a competência e o comportamento do técnico de manutenção.
A nuvem é incrivelmente fácil de ser mantida e nos possibilita construir sistemas e produtos, de TI como serviço, de uma maneira jamais anteriormente criada. Mais uma vez, a característica de self-service da nuvem é extremamente importante, como um recurso de pooling. Se precisamos executar uma mudança ou manutenção em um serviço, nós podemos simplesmente removê-lo do pool, repará-lo e recolocá-lo em serviço.
1. Reduzir downtime e evitar janelas de manutenção para deploy às 3am
Técnicas como Blue/Green deployments são fáceis na nuvem. Essa é uma estratégia de deploy onde você tem o balanceador de carga com dois pools: azul e verde. Somente um pool está ativo por vez, e você pode fazer deploys com zero downtime utilizando a alternância entre os dois pools. Então, se o pool azul está ativo, você faz o deploy das suas mudanças no pool inativo,neste caso o verde. Uma vez que você rodou seu smoke test nos servidores verde, você pode desativar o pool azul e ativar o pool verde. Se acontecer qualquer downtime, deverá ser de cerca de um segundo. Você então monitora seus sistemas e o feedback de usuários para verificar quaisquer sinais de problemas. No primeiro sinal de problema, você só precisa trocar novamente para o pool azul. Novamente, isso só durará um segundo. Você não reverteu e perdeu todas as suas mudanças do pool verde - você só esta comprando mais tempo para poder investigar os problemas que foram apontados. E se você determinar que é um problema mínimo ou um alarme falso, você pode dar uma segunda chance ao pool verde.
2. … Ou considere iniciar um substituto
O padrão azul/verde é o mais fácil para visualizar, implementar e zerar o downtime de deploy dos sistemas, mas há outras opções. Algumas organizações aplicam algo parecido com o padrão azul/verde, mas revertem para o seu sistema em um site de Reparação de Desastre. Um bom benefício dessa abordagem é exercitar alguns dos seus processos de Reparação de Desastre e equipamentos a cada deploy - uma coisa que muitas empresas deixam passar. O padrão de deploy canário é uma técnica que redefine o que "produção" and "versão de produção" significam. Se você tem um grupo de servidores, você poderia fazer o release de uma nova versão em somente um deles. Você verifica (exatamente como no caso do canários em uma mina de carvão) se esse servidor apresenta qualquer problema, e reverte o release caso necessário. Se não encontrar problemas, você pode continuar um novo release de maneira incremental - 10%, 25%, 50%, 80% e finalmente 100% em seus servidores. Essas estratégias não exigem fluxos de trabalhos manuais complexos e propensos a erros.
3. A nuvem é altamente controlável, com SDKs multi-nuvem com várias linguagens de programação e ferramentas disponíveis de fornecedores populares como PuppetLabs, OpsCode, Ansible e HashiCorp.
A maioria dos provedores de nuvem fornecem uma poderosa API de controle para seus recursos. Frequentemente, você pode escolher seu conjunto de linguagens e ferramentas favoritas - a Rackspace, por exemplo, suporta SDKs em Ruby, Java, .Net, Node.js, Python e PHP. Não subestime o poder de fazer deploys usando scripts que seu time de desenvolvimento e operações entendam, e fazendo o deploy as 3pm ao invés das 3am, dessa forma o time que criou as mudanças está por perto para suportar o seu lançamento.
Estética
Estética é a medida subjetiva que indica como um usuário responde a um produto. Ela representa uma preferência pessoal. Concordo que a nuvem pouco faz para embelezar o seu site. Apesar disso, ambientes e serviços na nuvem ainda assim são ferramentas poderosas para refinar a estética da sua aplicação.
Como é muito fácil colocar pra rodar um ambiente na nuvem, você pode facilmente criar um para demonstrar uma proposta de alteração visual ou para melhorar a experiência de usuário.
Se você está construindo um website, especialmente um website para dispositivos móveis, um grande desafio é certificar-se de que ele está esteticamente bom, não só no seu laptop, mas também em cada navegador e dispositivo móvel usado pelos seus usuários. Ferramentas de teste baseadas na nuvem tornam fácil o processo de comparar a aparência da aplicação quando executada nos diversos dispositivos. Se você criar um ambiente para homologação, você pode utilizar serviços cloud do tipo amplo acesso (Broad Network Access) como mogotest, Browsershots, Browserstack ou Cross Browser Testing. Você também pode criar seu próprio ambiente de testes na nuvem, utilizando ferramentas como Selenium, Huxley ou dpxdt.
Qualidade percebida
A percepção da qualidade é uma qualidade atribuída a um bem ou serviço baseada em medidas indiretas como “história do produto”. O seu site pode estar livre de problemas agora, mas se você teve um monte de problemas no passado seus usuários ainda podem estar com a sensação que seu site é de baixa qualidade. Não é apenas o número de bugs que você teve mas também o quão rápido você os corrigiu.
O uso da nuvem, combinado com entrega contínua, tornam mais fáceis e rápidas a reprodução, correção e lançamento da correção de bugs. Tornam também mais fácil lançar novas funcionalidades e melhorias baseadas em feedback do usuário.
Esse ciclo rápido de correção de bugs e entrega de melhorias é o que dá ao usuário uma percepção de qualidade. Aumentar a percepção de qualidade é a chave para fazer seus usuários sentirem-se como parceiros e promover o seu produto fazendo indicações.
A nuvem e as oito dimensões
Eu acredito piamente que desenvolvendo, testando e fazendo implantação na nuvem você pode construir produtos de melhor qualidade. A capacidade de construir um produto de melhor qualidade em todas as 8 dimensões pode não ser exclusividade da nuvem, mas a nuvem ajuda a remover quaisquer barreiras que estejam impedindo você de atingir estas metas.
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.