ir para o conteúdo principal

NEWSLETTER

dias00 horas00 minutos00 segundos00 REGISTE-SE JÁ
Building the future
PT EN

A caminho da alta disponibilidade, e mais além!

Voltar Development & Coding

A caminho da alta disponibilidade, e mais além!

IMG 0966
Nuno Cancelo 6 minutos Partilha

Transformar os sonhos dos nossos parceiros numa realidade é sempre um desafio interessante. Não é só criar uma nova aplicação, nem seguir as melhores práticas no desenvolvimento de software. Quer saber mais? Descubra aqui.

Conhecem a expressão: "Se podes sonhar, podes fazê-lo"? Nós, na Polarising, estabelecemos parcerias para colaborar com os nossos parceiros e ajudá-los a concretizar os seus sonhos.

Recentemente, fomos desafiados por um dos nossos parceiros a implementar a nova versão do seu produto. Este parceiro destacou alguns desafios que desejava que fossem ultrapassados ou evitados, minimizando o impacto nas atividades do dia-a-dia.

Este novo produto deveria ter uma aplicação web e móvel (Android e IOS) baseada na cloud, escalável e com alta disponibilidade. Deveria ser possível, também, fazer deploy das novas versões da aplicação durante o horário de expediente e sem perder o serviço.

Não vou descrever temas monótonos, como a arquitetura de soluções ou o design de aplicações, mas vou mostrar-vos alguns dos desafios que encontrámos e as decisões que tomámos para entregar valor e, em alguns casos, reduzir os custos do dia-a-dia.

Escolha de uma Plataforma

A nossa primeira decisão foi em relação à plataforma a utilizar. Por um lado, tinha de ser uma plataforma que apoiasse a equipa nas suas tarefas e, por outro lado, que permitisse a transição do projeto para a manutenção. Da experiência de outros projetos, e por manter toda a informação do projeto no mesmo espaço de trabalho, optar por trabalhar com a Azure DevOps foi uma escolha clara.

O Azure DevOps tem uma versão gratuita para pequenas equipas de desenvolvimento e com stakeholders ilimitados e abrange todas as áreas do ciclo de vida de um projeto de desenvolvimento. Por exemplo, com o Azure Boards podemos definir os Épicos, User Stories e alimentar o Backlog, com o Azure Repo (gestão do código fonte, pull-requests, etc.), com os Azure Pipelines podemos automatizar os ciclos de CI/CD. E não deixar de mencionar o Azure Test Plans para criar os planos de testes para aplicação. Tudo out-of-the-box.

Existe outro grande benefício: todas as atividades e artefactos relacionados com a solução estão disponíveis no mesmo espaço de trabalho, agregando toda a informação, alterações e decisões num espaço centralizado.

Criação do código fonte das aplicações web

Dada a complexidade da solução, criámos vários projetos para manter os diversos componentes desacoplados e coesos. Desta forma, cada um dos projetos tem apenas uma única responsabilidade, e essa responsabilidade é contida. Esta abordagem levou-nos ao nosso próximo desafio: executar os pipelines Continuous Integration de todos estes projetos e fazer deploy das aplicações nos ambientes. Estas atividades de build levam o seu tempo, e na plataforma Azure Devops existe limite para os números de minutos de build.

O plano gratuito da Azure DevOps inclui 1800 minutos de build para um único agente, sendo que qualquer agente adicional tem um custo extra. Para ultrapassar esta limitação, instalámos alguns agentes on-permises e configurámo-los em Azure DevOps. Com esta abordagem, conseguimos criar agentes específicos de build (por exemplo: permitir a execução do SonarQube, build de aplicações React, entre outros) e possibilitámos a sua execução pelos vários projetos.

Esta abordagem tem uma vantagem adicional. Os pipelines podem aceder a servidores ou serviços internos, on-premises, sem que estes estejam expostos na internet.

Criação do código fonte das aplicações mobile

Embora esta infraestrutura permita a gestão da maioria das soluções do projeto, um dos seus requisitos é o desenvolvimento de uma aplicação móvel em Android e IOS. Em Azure DevOps é possível criar pipelines para fazer build de aplicações Android e IOS, mas o investimento pessoal necessário não faz sentido para uma configuração standard.

Existe uma alternativa com fácil integração e com um conjunto de funcionalidades excelentes. O Visual Studio App Center permite a integração contínua de aplicações mobile, tem delivery e deploy para as lojas da Apple e Google e interliga-se com os maiores fornecedores de repositórios git. Infelizmente, não suporta integração com os serviços git on-permisses.

Esta plataforma gere de forma simples todo o ciclo de vida da aplicação móvel, e oferece funcionalidades de análise/diagnóstico que consolidam informações úteis sobre o uso da aplicação.

Variáveis de Ambiente

O nosso design de solução definiu o desacoplamento da solução entre a aplicação de front-end e os sistemas de back-end, e com esta decisão surgiram outros desafios.

Na aplicação de front-end optámos por uma Single Page Application, ou SPA, e escolhemos o React como tecnologia. Com o React, à semelhança de outras tecnologias em JavaScript, as variáveis de configuração da aplicação são definidas em tempo de build. Isto significa que para cada ambiente (Desenvolvimento, Aceitação e Produção), é preciso um pipeline de build. São fatores a ter em conta, quando definirmos os pipelines de build desta aplicação.

O Azure DevOps simplificou a gestão destas tarefas e a manutenção das variáveis. A plataforma tem uma interface gráfica para gerir as configurações da aplicação por ambiente e permite que o pipeline aceda a estas configurações quando está a fazer build.

Num só local gerimos as configurações de cada ambiente, sem ser necessário ir a todos os pipelines fazer alterações. Assim, para cada pipeline de build, e para cada ambiente, são aplicadas as configurações corretas.

No que diz respeito às aplicações back-end, optamos por .NET Core. Todas as aplicações a correm em Azure Web Apps. Em aplicações server-side, o paradigma é diferente. Com este paradigma, temos apenas um pipeline de build para fazer as tarefas de build, teste, análise de código e gera um único artefacto para fazer deploy nos diferentes ambientes.

Para gerir as configurações por ambiente, existem, geralmente, três possibilidades:

1. No pipeline de release definimos, à semelhança do pipeline de build, todas as configurações por ambiente, e no pipeline aplicamos sobre os ficheiros de configuração.
2. Na configuração da Azure Web App, criar todas as configurações para cada um dos ambientes.
3. Utilizar a Azure App Configuration para armazenar informações não sensíveis, e usar o Azure Key Vault para armazenar informações sensíveis e configurar a configuração Azure Web App para utilizar os dados destas fontes.

Esta última opção é uma extensão da segunda opção e proporciona um armazenamento de dados mais seguro e centralizado. Esta abordagem permite que várias aplicações utilizem os mesmos dados sem replicar a informação entre todas as aplicações. Se tivermos de atualizar alguma chave, alguma propriedade, ou variável, só as editamos num lugar.

Controlar o deploy das aplicações

Num cenário normal existem três ambientes:
1. Ambiente de Testes para os developers testarem as funcionalidades que desenvolvem.
2. Ambiente de Aceitação para os utilizadores de negócio testarem a aplicação.
3. Ambiente de produção para os consumidores da aplicação em geral.

Fazer deploy num ambiente de desenvolvimento não causa muito impacto. Já em ambientes superiores os desafios tendem a aumentar.

Para ultrapassar este ponto sensível, na pipeline de release, aplicamos controlo chamado "condições de pre-deployment" para podermos ativar as aprovações de pre-deployment e configurar a(s) pessoa(s) que deve(m) aprovar a execução do pipeline. Por exemplo, para fazer deploy no Ambiente de Aceitação, o "Product Owner" poderá aprovar o deploy, enquanto para Produção poderá ser o "Product Owner" e o "Supervisor de TI".

Na realidade pode ser qualquer pessoa, mas recomendamos que seja alguém relacionado com o projeto.

A plataforma mantém o registo das versões implementada e as aprovações para cada ambiente, tornando a gestão de versões ou rollback muito mais fácil de gerir.

Fazer deploy sem perder serviço

Neste momento, estamos em condições de demorar apenas alguns minutos entre submeter uma alteração de código fonte até fazer deploy na cloud Azure, disponibilizando a aplicação aos nossos utilizadores.

Todos se lembram daqueles dias em que as equipas de TI planeavam implementar novas versões da aplicação à noite, perto do fim-de-semana, e durante o tempo da "manutenção", e o sistema se encontrava indisponível.

Nos dias de hoje, é possível fazer deploy de uma aplicação sem perder o serviço. Existem muitas estratégias de deploy, e a maioria visa casos específicos de uso complexo, sendo a estratégia mais simples a "Blue-Green Deployment". Com esta, fazemos deploy da nossa aplicação num nó (Blue), os utilizadores fazem testes de regressão nas funcionalidades significativas e, se tudo estiver bem, trocamos com o nó de "produção" (Green) (que tem a versão anterior). Depois, se for detetado algum erro ou bug, podemos voltar a mudar o nó.

Na cloud Azure, para alcançar este objetivo, usamos “Deployment Slots”, onde temos a slot de "Production" e criamos e configuramos outro slot para um deploy "Blue". A ação de permuta diz à infraestrutura que a versão atual de produção não receberá mais pedidos e lidará com os pedidos que já estão a ser processados. Quaisquer novos pedidos serão aceites pela nova aplicação. Esta ação pode demorar algum tempo, mas, no final, a slot de produção terá a versão mais recente, enquanto o slot "Blue" terá a versão anterior.

Aplicação de Alta Disponibilidade

A maioria dos utilizadores queixam-se da lentidão da aplicação quando estão a tentar fazer algumas operações, especialmente em períodos de elevada procura, quando temos elevado número de utilizadores a interagirem com a aplicação. Para colmatar esta limitação, as aplicações precisam de estar habitadas em escalar, seja em ter mais recursos (memória, CPU, etc.), ou mais instâncias a responder aos pedidos.

Uma das muitas funcionalidades do “Azure App Service” é a autoscaling, onde podemos fazer, de forma automática, o escalar, ou reduzir infraestrutura de acordo com as regras definidas. Estas regras são definidas em dois fatores:
1. Base de horário: especificado por um período de tempo.
2. Bases métricas: determinadas por métricas de utilização como CPU.

Para a nossa solução, optámos por aplicar ambas as estratégias. Durante o dia, configurámos o escalar de forma automática com base em métricas (como CPU, Memória ou tráfego de rede) e depois do pico passar, aplicámos regras para reduzir a infraestrutura.

É importante não esquecer que, para cada controlo de adicionar recursos, deve ser criado um controlo para reduzir recursos, para evitarmos que a fatura a pagar não escale também.

Pela análise de utilização da aplicação anterior, verificou-se que à noite o uso da aplicação é inferior. Assim, criaram-se outras regras que fazem a redução de infraestrutura no início da noite e aumentam no início da manhã.

Esta estratégia aumenta a elevada disponibilidade e resiliência da aplicação e atrai poupanças, reduzindo a capacidade noturna e otimizando o uso da infraestrutura.

Conclusão

Transformar os sonhos dos nossos parceiros numa realidade é sempre um desafio interessante. Porque é mais do que apenas criar uma nova aplicação, ou seguir as melhores práticas no desenvolvimento de software. Trata-se, também, de olhar para o futuro e construir uma infraestrutura que permita à equipa de desenvolvimento ter uma experiência agradável na evolução e estabilidade das aplicações, dando controlo e visibilidade aos stakeholders sobre o produto e, em simultâneo, reduzindo o tempo e o custo no desenvolvimento e implantação de novas funcionalidades e estar disponível na Cloud sem grandes demoras.

É, também, essencial proporcionar aos utilizadores da aplicação uma experiência agradável, tendo disponibilidade de serviço; otimizando os custos com a infraestrutura; e reduzindo-a durante os períodos de utilização menores.

Nuno Cancelo
Microsoft Practice Lead na Polarising

Partilha

Pesquisa

Resultados Erro. Tente novamente mais tarde
  • Result item