Blog do Eduardo

Tecnologia, Inovação, Negócios e muito mais...

Arquitetura de Aplicativos no Azure

Introdução

  • 24 de Setembro de 2018 às 00:00
Capa Post

Introdução

O que você irá aprender neste post:

  • Visão geral das arquiteturas
    • Tipos de arquiteturas
      • N-tier
      • Web-Queue-Worker
      • Microservices
      • CQRS
      • Orientada a Eventos
      • Big Data e Computação massiva
    • Comparativo

Visão Geral

Com o surgimento da computação em nuvem, toda a maneira como os aplicativos são desenvolvidos está mudando, devido a grande flexibilidade que o ambiente permite. Mas você deve estar se perguntando agora, porque devo me preocupar com a arquitetura antes mesmo de começar a codar? A resposta para essa pergunta, pode soar um pouco “rude”, mas a verdade é que simplesmente “sair fazendo”, normalmente é pior maneira de resolver os problemas e provavelmente a sua aplicação não irá atender os requisitos. Sem falar no fator custo e tempo investidos, pois eles realmente valem muito. Tipicamente a escolha de uma arquitetura errada, ou pior não seguir nenhuma, pode gerar um retrabalho gigantesco no meio de um projeto e em último caso arruinar a totalmente aplicação. O objetivo desta série de artigos, onde irei abordar detalhadamente as arquiteturas sugeridas aqui, é auxiliar nos seguintes tópicos:

  • Escolher o estilo de arquitetura de aplicativo de nuvem certo para o seu aplicativo ou a sua solução.
  • Selecionar as tecnologias de armazenamento de dados e computação apropriadas.
  • Incorporar dez princípios de design para criar um aplicativo escalável, resiliente e gerenciável.
  • Seguir os cinco pilares de qualidade de software para garantir o sucesso do aplicativo de nuvem.
  • Usar padrões de design que se aplicam especificamente ao problema que você está tentando resolver.

Arquiteturas

N-tier

Das arquiteturas que irei trazer aqui, creio que essa seja a mais comum de se encontrar no merca, justamente pelo por ser já bem difundida e empregada no mercado. A solução é separada em diferentes contextos, afim de segregar ao máximo a lógica do sistema. Esse é um conceito que já trabalhei bastante aqui no blog no post sobre Separation of Concerns SoC. Basicamente a dividimos em camadas horizontais, isso significa que existe uma dependência e uma sincronia certa das camadas. Existe uma pequena desvantagem na composição desta abordagem, conforme é necessário uma evolução constante da aplicação fica cada vez mais desafiador manter todas a dependência e principalmente limitar a rapidez e a adesão ne novos recursos.

Web-Queue-Worker

Essa arquitetura é bastante utilizada quando é necessária uma demanda maior de processamento e a operação e totalmente assíncrona. Tipicamente a aplicação possuí uma parte responsável por responder a requisição HTTP e uma parte que roda no back-end que executa várias tarefas. As tarefas são colocadas em filas de mensageria, que são processadas exatamente na ordem em que chegam. O uso adequado para problemas relativamente simples com algumas tarefas com uso intensivo de recursos. Essa técnica simplifica a implantação e as operações, porém para problemas complexos, pode ser difícil gerenciar as dependências. O front-end e o nó de back-end podem facilmente se tornar componentes grandes e monolíticos, que são difíceis de manter e atualizar.

Microservices

A grande vantagem dessa arquitetura, pode ser também a sua maior deficiência, pois existe uma linha bem sútil entre a boa prática e o uso desta técnica para acelerar o processo de inovação e deployment. Um aplicativo de Microservices é composto de vários serviços pequenos e independentes. Cada serviço implementa um único conjunto da aplicação de negócios. Os serviços são flexíveis e se comunicam através de uma API, descentralizado assim os dados para cada uma das partes. Se você tem um requisito de consistência eventual e armazenamento distribuído essa é arquitetura é para você. Ela requer mais experiência em desenvolvimento e cultura de DevOps. Mas feito corretamente, esse estilo pode levar a uma velocidade maior de distribuição, inovação mais rápida e arquitetura mais resiliente.

CQRS

Para essa arquitetura as operações são separadas em leitura e gravação. Isso isola as partes do sistema que atualizam dados das partes que leem os dados. Além disso, as leituras podem ser executadas em uma exibição materializada que é fisicamente separada do banco de dados de gravação. Isso permite dimensionar as cargas de trabalho de leitura e gravação de forma independente e otimizar a exibição materializada para consultas. Essa técnica pode diminuir gargalos e ganhar performance, realizando escalonamento vertical.

A CQRS faz mais sentido quando é aplicada a um subsistema de uma arquitetura maior. Em geral, você não deve implementar esse estilo em todo o aplicativo, pois isso somente criará uma complexidade desnecessária. Um exemplo comum em que essa técnica pode ser bem aplicada em um ambiente colaborativo, onde muitos usuários acessam os mesmos dados.

Orientada a Eventos

Utiliza um modelo Publisher-Subscriber (pub-sub), onde os agentes produtores publicam eventos e os consumidores os observam. Os produtores são independentes dos consumidores, e os consumidores são independentes uns dos outros.

Considere uma arquitetura orientada a eventos para aplicativos que ingerem e processam um grande volume de dados com latência muito baixa, tais como soluções de IoT. O estilo também é útil quando os diferentes subsistemas devem executar diferentes tipos de processamento nos mesmos dados de evento.

Big data e Computação Massiva

São estilos de arquitetura especializados para cargas de trabalho que atendem a perfis específicos. Big data divide um conjunto de dados muito grande em partes, executando processamento paralelo em todo um conjunto, para análise e relatórios. Computação intensa, também chamada de computação de alto desempenho (HPC), faz cálculos paralelos em um número grande (milhares) de núcleos. Os domínios incluem renderização 3D, modelagem e simulações.

Comparativo

Arquitetura

Flexibilidade

Implantação

Complexidade

Evolução

N-tier

Baixa

Pode ser rápida

Baixa

Permite pouca

Web-Queue-Worker

 

Alta

Regular

Alta

Rápida

Microservices

Alta

Rápida

Alta

Altíssima

CQRS

Alta

Demorada

Alta

Regular

Orientada a Eventos

Alta

Regular

Regular, podendo ser alta

Regular

Big data e Computação Massiva

 

Baixa

Regular

Alta

Alta

Referências

 

Application Architecture Cloud Guide 

  • Acquisitions Editor: Christopher Bennage
  • Developmental Editors: Mike Wasson, Masashi Narumoto
    and the Microsoft Patterns and Practices team
  • Editorial Production: Phil Evans
  • Copyeditor: Jamie Letain

 

Azure Design de Software Microsoft
  • COMENTÁRIOS: 0 Seja o primeiro a comentar!

Você tem o permissão de:

Compartilhar: copiar e redistribuir o material em qualquer suporte ou formato.

Adaptar: remixar, transformar, e criar a partir do material para qualquer fim, mesmo que comercial.

Esta licença é aceitável para Trabalhos Culturais Livres. O licenciante não pode revogar estes direitos desde que você respeite os termos da licença.


Blog do Eduardo - Todos os direitos reservados © 2020 Licença Creative Commons