Eventualmente, precisamos projetar workloads que recebem requisições dos clientes – usuários ou outros sistemas – demandando processamentos de longa duração ou com elevado custo computacional.
Workload (Carga de Trabalho)
Um workload é uma coleção de itens de infraestrutura, aplicações e dados que, coletivamente, suportam um objetivo de negócio ou a execução de um processo de negócios. Exemplos de workloads são aplicações LoB, como “folha de pagamento”, CRM, fluxos de trabalho para aprovação de documentos, etc.
Eventualmente, workloads compartilham recursos técnicos (como bancos de dados).
O usual é que tais workloads sejam projetados para garantir baixo response time para as requisições dos clientes, postergando os processamentos mais pesados para que ocorram, mais tarde, em segundo plano, com o melhor throughput possível.
Abstração arquitetônica
As arquiteturas para workloads como os descritos neste post costumam contemplar:
- uma ou mais interfaces (web frontend) para atender as demandas dos clientes, com o melhor response time possível;
- algum mecanismo de sequenciamento ou agendamento onde as demandas mais “pesadas” são enfileiradas para processamento posterior;
- um ou mais artefatos computacionais (workers) que executam o trabalho, com o melhor throughput possível;
Não raro, as arquiteturas também incluem:
- uma ou mais bases de dados (relacionais ou não relacionais);
- proxies para APIs internas ou para serviços remotos;
- algum mecanismo de caching para diminuir a pressão sobre as bases de dados, APIs internas ou serviços remotos, diminuindo tempos de leitura;
- CDN para conteúdos estáticos.
Com vistas a garantir elasticidade horizontal, tanto web frontends quanto workers, nessas arquiteturas, costumam ser stateless e usam caching distribuído para armazenamento de estados transientes.
Todo trabalho “pesado” é executado assincronamente pelos workers que são acionados por mecanismos de mensageria ou de agendamento. Operações “leves” podem ser executadas diretamente pelos web frontends.
Veja também
- APIs internas e externas: um modelo de classificação para aumentar a eficácia e reduzir custos.
- SÉRIE: Fundamentals of Caching (em inglês)
Essa proposta de design tem as vantagens de ser simples de entender e manter. Também é positivo o desacoplamento entre o frontend e o worker, reforçado pelo mecanismo de mensageria. Entretanto, principalmente para as operações síncronas, é importante evitar implementações demasiadamente complexas, sobretudo no frontend que possam aumentar o custo de manutenção futura.
Implementação no Azure
A opção pela implementação da arquitetura descrita acima, na nuvem, é natural implicando no uso das tecnologias apropriadas em cada componente.
- O frontend pode ser implementado tanto como Azure Function quanto como Azure App Service.
- Tanto Azure Service Bus como Azure Storage Queues podem ser utilizados como mecanismo de mensageria.
- O worker pode ser implementado como Azure Function
- O mecanismo de caching distribuído recomendado seria Azure Cache for Redis
- Para o conteúdo estático podemos usar Azure Storage Blobs para armazenamento e Azure CDN para distribuição.
Caso o frontend seja implementado usando Azure App Service, será possível utilizar mecanismos de escalonamento automatizado para suportar flutuações de demanda. Aliás, é importante colocar o frontend e o worker em planos diferentes para que o escalonamento de ambos componentes seja independente.
Principais ganhos para a organização
Workloads que tratam requisições de longa duração e com alto custo computacional costumam ser específicos e com baixa dependência de outras rotinas da empresa, entregando valor consistente. Por isso, são ideais para iniciar jornadas de modernização e migração de aplicações para a nuvem, mitigando receios eventuais.
Veja também
- Benefício tangíveis para o negócio na migração de aplicações para a nuvem
- Receio de migrar aplicações para a nuvem? Comece pequeno!
Outro aspecto importante é que esse tipo de solução, frequentemente, demanda estratégias de provisionamento complexas, quando executadas on-premises. Usar uma infraestrutura em nuvem reduz significativamente essa complexidade.
Finalmente, todos os componentes e soluções de nuvem usados nessa proposta arquitetura são aplicáveis e comuns, também, para outros cenários. Dessa forma, a “curva de aprendizado” do time acaba ficando menos desafiadora para o futuro.