Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Dica
Esse conteúdo é um trecho do eBook, Architecting Cloud Native .NET Applications for Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.
Em resumo, aqui estão conclusões importantes deste guia:
Cloud-native refere-se à criação de aplicativos modernos que adotam mudanças rápidas, grande escala e resiliência, em ambientes modernos e dinâmicos, como nuvens públicas, privadas e híbridas.
O Cloud Native Computing Foundation (CNCF) é um influente consórcio de software livre de mais de 300 grandes corporações. Ele é responsável por impulsionar a adoção da computação nativa de nuvem em pilhas de nuvem e tecnologia.
As diretrizes do CNCF recomendam que os aplicativos nativos de nuvem adotem seis pilares importantes, conforme mostrado na Figura 11-1:
Figura 11-1. Pilares fundamentais nativos da nuvem
Esses pilares nativos de nuvem incluem:
- A nuvem e seu modelo de serviço subjacente
- Princípios de design modernos
- Microsserviços
- Contenerização e orquestração de contêineres
- Serviços de backup baseados em nuvem, como bancos de dados e agentes de mensagens
- Automação, incluindo infraestrutura como código e implantação de código
O Kubernetes é o ambiente de hospedagem escolhido para a maioria dos aplicativos nativos de nuvem. Serviços menores e simples às vezes são hospedados em plataformas sem servidor, como o Azure Functions. Entre muitos dos principais recursos de automação, ambos os ambientes fornecem dimensionamento automático para lidar com volumes de carga de trabalho flutuantes.
A comunicação de serviço se torna uma decisão de design significativa ao construir um aplicativo nativo de nuvem. Os aplicativos normalmente expõem um gateway de API para gerenciar a comunicação do cliente front-end. Em seguida, os microsserviços de back-end se esforçam para se comunicar uns com os outros implementando padrões de comunicação assíncronos, quando possível.
gRPC é uma estrutura moderna e de alto desempenho que evolui o protocolo RPC (chamada de procedimento remoto) antigo. Aplicativos nativos de nuvem geralmente adotam gRPC para simplificar a troca de mensagens entre serviços de infraestrutura. O gRPC usa HTTP/2 como protocolo de transporte. Pode ser até 8x mais rápido do que a serialização JSON com tamanhos de mensagem de 60 a 80% menores. o gRPC é de software livre e gerenciado pela CNCF (Cloud Native Computing Foundation).
Os dados distribuídos são um modelo geralmente implementado por aplicativos nativos de nuvem. Os aplicativos separam a funcionalidade de negócios em microsserviços pequenos e independentes. Cada microsserviço encapsula suas próprias dependências, dados e estado. O modelo de banco de dados compartilhado clássico evolui para um dos muitos bancos de dados menores, cada um alinhado com um microsserviço. Quando a poeira abaixa, surge um design que expõe um modelo
database-per-microservice.No-SQL bancos de dados referem-se a armazenamentos de dados não relacionais de alto desempenho. Eles se destacam em suas características de facilidade de uso, escalabilidade, resiliência e disponibilidade. Serviços de alto volume que exigem tempo de resposta abaixo de um segundo favorecem bancos de dados NoSQL. A proliferação de tecnologias NoSQL para sistemas nativos de nuvem distribuída não pode ser superestimada.
NewSQL é uma tecnologia de banco de dados emergente que combina a escalabilidade distribuída do NoSQL e as garantias ACID de um banco de dados relacional. Os bancos de dados NewSQL têm como destino sistemas de negócios que devem processar grandes volumes de dados, em ambientes distribuídos, com conformidade transacional/ACID completa. O CNCF (Cloud Native Computing Foundation) apresenta vários projetos de banco de dados NewSQL.
A resiliência é a capacidade do seu sistema de reagir à falha e ainda permanecer funcional. Os sistemas nativos de nuvem adotam a arquitetura distribuída, onde a falha é inevitável. Os aplicativos devem ser construídos para responder elegantemente à falha e retornar rapidamente a um estado totalmente funcional.
As malhas de serviços são uma camada de infraestrutura configurável com recursos internos para lidar com a comunicação entre serviços e outros desafios transversais. Elas desacoplam responsabilidades abrangentes do código de negócios. Essas responsabilidades passam para um proxy de serviço. Conhecido como
Sidecar pattern, o proxy é implantado em um processo separado para fornecer isolamento do código de negócios.A observabilidade é uma consideração de design fundamental para aplicativos nativos de nuvem. À medida que os serviços são distribuídos em um cluster de nós, o registro centralizado, o monitoramento e os alertas tornam-se obrigatórios. O Azure Monitor é uma coleção de ferramentas baseadas em nuvem projetadas para fornecer visibilidade do estado do seu sistema.
A infraestrutura como código é uma prática amplamente aceita que automatiza o provisionamento de plataforma. Sua infraestrutura e implantações são automatizadas, consistentes e repetíveis. Ferramentas como o Azure Resource Manager, o Terraform e a CLI do Azure permitem que você crie um script declarativo da infraestrutura de nuvem necessária.
A automação de código é um requisito para aplicativos nativos de nuvem. Os sistemas modernos de CI/CD ajudam a atender a esse princípio. Eles fornecem etapas de build e implantação separadas que ajudam a garantir um código consistente e de qualidade. O estágio de build transforma o código em um artefato binário. O estágio de lançamento pega o artefato binário, aplica a configuração de ambiente externo e o implanta em um ambiente especificado. O Azure DevOps e o GitHub são ambientes de DevOps completos.