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.
Uma solução nativa de nuvem cria um novo valor de negócios criando novas cargas de trabalho (aplicativos) ou adicionando novos recursos a cargas de trabalho existentes. Se você estiver desenvolvendo um aplicativo novo ou adicionando novos recursos a um sistema existente, o desenvolvimento nativo de nuvem é um percurso por meio do planejamento, criação, implantação e otimização de suas cargas de trabalho. Essa estrutura fornece diretrizes de ponta a ponta para garantir que seu aplicativo nativo de nuvem esteja alinhado com as metas de negócios, bem arquitetadas e fornecidas com o mínimo de risco.
Pré-requisitos:zona de destino do Azure
Definir objetivos de negócios para soluções nativas de nuvem
Comece com metas de negócios claras. Defina os resultados específicos que sua solução nativa de nuvem deve alcançar, como habilitar um novo produto digital, entrar em um novo mercado, melhorar a experiência do cliente ou reduzir os custos operacionais. Use indicadores mensuráveis, como crescimento da receita, redução de tempo de entrada no mercado ou volume de tíquetes de suporte para quantificar o sucesso. Para novos recursos, defina metas como melhorar a experiência do cliente, reduzir custos operacionais ou aumentar a escalabilidade do sistema.
Identificar restrições e critérios de êxito. Documente quaisquer restrições comerciais, como orçamento, conformidade ou cronogramas de entrega. Defina o que é sucesso para cada meta. Por exemplo, "inicie um novo portal do cliente até o 4º trimestre" ou "reduza a latência da finalização de compra em 40%". Esses critérios orientam a priorização e ajudam a avaliar as decisões de equilíbrio durante o planejamento.
Validar o alinhamento dos stakeholders. Confirme que todos os stakeholders (comerciais e técnicos) concordam com as metas, restrições e a aparência do sucesso. Esse alinhamento pode envolver workshops ou aprovações formais. O alinhamento antecipado previne a falha de comunicação futura e evita o retrabalho custoso, garantindo que todos compartilhem as mesmas expectativas desde o início.
Definir requisitos para soluções nativas de nuvem
Requisitos funcionais do documento. Documente as capacidades e recursos que o sistema deve fornecer para atender às necessidades do usuário. Cada requisito deve ser associado a um objetivo de negócios, garantindo que o esforço de desenvolvimento dê suporte diretamente aos resultados desejados. Use entrevistas de stakeholders e documentos de estratégia de negócios para identificar resultados de alto valor. Priorize os recursos com base no valor comercial e na viabilidade técnica. Rastreie cada requisito para um objetivo de negócios mensurável para justificar sua inclusão.
Estabelecer requisitos não funcionais. Requisitos não funcionais definem requisitos técnicos para atender aos requisitos funcionais e à governança. Estabeleça os atributos de qualidade e as metas técnicas necessárias para dar suporte a esses recursos. Defina métricas de confiabilidade de destino, como SLOs (objetivos de nível de serviço) para tempo de atividade, RPOs (objetivos de ponto de recuperação) e RTOs (objetivos de tempo de recuperação). Estabeleça uma linha de base de segurança. Criar modelo de custo. Definir metas de desempenho.
Controlar o escopo das soluções nativas da nuvem. Defina claramente o que está no escopo versus fora do escopo da versão inicial. É tentador incluir funcionalidades desejáveis, mas o aumento do escopo pode colocar em risco os cronogramas e orçamentos. Documente os limites da solução e implemente um processo de controle de alteração para quaisquer novas solicitações. Aprove apenas as alterações que dão suporte diretamente às metas definidas e que podem ser entregues sem prejudicar o agendamento ou o orçamento. Adie ideias de baixa prioridade para uma lista de pendências futura. O gerenciamento rigoroso do escopo mantém a equipe focada em fornecer a funcionalidade mais valiosa primeiro dentro das restrições.
Planejar as arquiteturas nativas de nuvem
Uma arquitetura bem planejada é fundamental para atender às suas metas e requisitos. Cada grande decisão arquitetônica envolve compensações em escalabilidade, complexidade, custo e agilidade. As seguintes etapas e pontos de decisão ajudam você a criar um design nativo de nuvem alinhado com as práticas recomendadas:
Explorar arquiteturas nativas de nuvem validadas
Examine os conceitos básicos e as práticas recomendadas da arquitetura. Antes de inventar uma arquitetura do zero, examine as arquiteturas de referência validadas e os conceitos básicos do Centro de Arquitetura do Azure. Estilos de arquitetura familiares incluem explorar arquiteturas de referência validadas para cargas de trabalho comuns. Essas arquiteturas ajudam a acelerar as decisões de design e reduzir o risco.
Selecione um estilo de arquitetura apropriado. Escolha um estilo de arquitetura com base nas características da carga de trabalho e nas funcionalidades da equipe. Os estilos de arquitetura incluem N camada (monolítica), microsserviços, baseado em evento (baseado em mensagem), web-queue-worker. Por exemplo, se você precisar de desenvolvimento rápido para um aplicativo relativamente simples, um monolito de N camadas bem estruturado poderá ser suficiente. Para um aplicativo em grande escala ou em rápida evolução com domínios distintos, microsserviços ou abordagens orientadas a eventos oferecem flexibilidade (ao custo da complexidade). Na prática, muitos sistemas acabam com um estilo híbrido. Por exemplo, há um núcleo de microsserviços com alguns serviços compartilhados ou um subsistema controlado por eventos. A chave é entender as compensações de cada estilo e selecionar a abordagem que melhor atenda aos seus requisitos de escalabilidade, resiliência e agilidade.
Aplicar as práticas recomendadas de design. Não importa qual estilo você escolher, siga os conceitos básicos e as práticas recomendadas da arquitetura de nuvem. O Centro de Arquitetura do Azure fornece um catálogo de padrões de design de nuvem (Repetição, Disjuntor, CQRS) que abordam desafios comuns em cargas de trabalho distribuídas. A integração desses padrões ao seu design pode melhorar a confiabilidade e o desempenho.
Integre os cinco pilares às decisões de design. Use o Well-Architected Framework para orientar decisões sobre confiabilidade, segurança, eficiência de desempenho, otimização de custos e excelência operacional. Esses cinco pilares devem informar todas as decisões de design. Por exemplo, ao escolher um banco de dados, considere a confiabilidade (redundância, backup), o desempenho e o custo juntos para atingir o equilíbrio certo. Documento em que você faz compensações entre pilares, como mais custo para um desempenho mais alto. Essas notas são valiosas para governança e revisões futuras.
Planejar integrações com sistemas existentes
Inventar todos os sistemas e serviços dependentes. As novas soluções nativas de nuvem raramente operam de forma isolada, a menos que você seja uma startup em estágio inicial. Considere como sua nova carga de trabalho ou recurso se encaixa no ambiente. Mapeie os fluxos de dados e garanta a compatibilidade com os padrões. Crie uma lista abrangente de todos os sistemas com os quais sua carga de trabalho interage. Essa lista inclui APIs internas, bancos de dados, provedores de identidade (ID do Microsoft Entra), ferramentas de monitoramento, pipelines de CI/CD e sistemas locais acessados via VPN ou ExpressRoute. Use diagramas de arquitetura e mapas de dependência para visualizar essas relações.
Classifique os tipos de integração e os protocolos. Categorize cada ponto de integração por tipo (autenticação, troca de dados, mensagens) e protocolo (REST, gRPC, ODBC, SAML, OAuth2). Essa classificação ajuda a identificar os requisitos de compatibilidade e possíveis gargalos.
Validar a identidade e a integração de acesso. Verifique se sua solução se integra ao provedor de identidade da organização. Por exemplo, use a ID do Microsoft Entra para autenticação e autorização em vez de introduzir um novo sistema de identidade. Confirme o suporte para SSO (logon único), RBAC (controle de acesso baseado em função) e políticas de acesso condicional.
Avaliar a conectividade e a segurança de rede. Examine como sua carga de trabalho se conecta a outros sistemas. Validar regras de firewall, resolução DNS e caminhos de roteamento. Para cenários híbridos, confirme se as configurações do ExpressRoute ou VPN estão em vigor e testadas. Use o Observador de Rede do Azure para monitorar e solucionar problemas de conectividade.
Verifique a compatibilidade e a conformidade do fluxo de dados. Mapear fluxos de dados entre sistemas. Confirme os formatos de dados, os esquemas e os requisitos de transformação. Verifique a conformidade com as políticas de residência, criptografia e retenção de dados.
Testar pontos de integração antecipada e continuamente. Execute testes de integração durante os estágios iniciais de desenvolvimento. Use simulações ou stubs para sistemas indisponíveis. Automatize esses testes em seu pipeline de CI/CD usando ferramentas como o Azure DevOps ou o GitHub Actions. Monitore a latência, a taxa de transferência e as taxas de erro. Por exemplo, você deseja evitar que uma API da qual seu aplicativo depende não suporte a carga necessária ou o bloqueio de um firewall de rede ao seu serviço.
Contratos de integração de documentos e SLAs. Defina e documente o comportamento, a disponibilidade e o desempenho esperados de cada ponto de integração. Inclua lógica de repetição, configurações de tempo limite e mecanismos de fallback. Alinhe-se aos SLAs (contratos de nível de serviço) de sistemas dependentes.
Selecione os serviços e as camadas de serviço apropriadas do Azure
Use guias de decisão para selecionar serviços que correspondam aos requisitos de carga de trabalho. O Azure fornece várias opções para executar o código do aplicativo, cada uma com prós e contras. Examine a visão geral das opções de tecnologia para identificar os serviços que se alinham aos seus requisitos funcionais e não funcionais. Priorize as opções de PaaS (plataforma como serviço), pois esses serviços reduzem a sobrecarga operacional tratando o gerenciamento de infraestrutura, a aplicação de patch e o dimensionamento automaticamente.
Defina padrões de uso e requisitos de desempenho para selecionar camadas de serviço. A seleção da camada de serviço afeta o custo e a funcionalidade. Documente volumes de transação esperados, cargas de usuário simultâneas, requisitos de armazenamento e destinos de desempenho, como tempos de resposta e taxa de transferência. Use essas métricas para selecionar uma SKU (camada de serviço) inicial que atenda aos requisitos de linha de base sem significativo provisionamento excessivo. Planeje ajustar as camadas com base nos padrões de uso reais após a implantação.
Valide a compatibilidade de recursos entre as camadas de serviço selecionadas. Recursos críticos, como recursos avançados de segurança, opções de alta disponibilidade ou APIs de integração, variam de acordo com a camada de serviço. Crie uma matriz de recursos que mapeie os recursos necessários para SKUs disponíveis. Verifique se a camada selecionada dá suporte a todos os recursos necessários para evitar migrações dispendiosas ou alterações arquitetônicas posteriormente. Consulte a documentação específica do serviço para confirmar a disponibilidade e as limitações do recurso.
Selecione quantas regiões usar
Avalie os trade-offs de implantações de várias regiões. As arquiteturas de região única são mais simples e baratas, mas uma interrupção regional derrubaria seu aplicativo. As implantações de várias regiões podem obter maior disponibilidade (uma região pode falhar e os usuários são atendidos de outra) e também podem melhorar o desempenho atendendo os usuários da região mais próxima. O compromisso é o aumento da complexidade na implantação e na sincronização de dados. Você deve lidar com a replicação de dados entre regiões com possíveis problemas de consistência, roteamento de tráfego global e custos mais altos. Permita que seus requisitos de confiabilidade impulsionem essa decisão.
Use metas de confiabilidade para orientar a estratégia regional. Defina objetivos de nível de serviço (SLO), RPO (objetivos de ponto de recuperação) e RTO (objetivos de tempo de recuperação) para determinar os requisitos regionais.
Confirme a conformidade com os regulamentos de residência de dados. Trabalhe com equipes legais e de conformidade para garantir que as escolhas regionais atendam às obrigações regulatórias.
Arquiteturas de documentos
Crie um diagrama de arquitetura detalhado e um documento de design. A documentação dá suporte à implementação, revisão e manutenção futura. Inclua serviços do Azure selecionados, SKUs, fluxos de dados e interações do usuário. Verifique se o diagrama fornece uma representação visual clara da arquitetura para dar suporte à implementação e às revisões.
Registre as principais decisões de design e as compensações. Documente a lógica por trás das escolhas arquitetônicas, incluindo requisitos não funcionais, como confiabilidade, segurança e desempenho. Realce todas as compensações feitas para equilibrar as prioridades concorrentes.
Planejar a estratégia de implantação nativa de nuvem
Ao implantar a solução nativa de nuvem na produção, siga uma estratégia planejada em vez de um push ad hoc. Um plano de implantação sólido minimiza os efeitos sobre os usuários e fornece maneiras de se recuperar se algo der errado.
Planejar práticas de desenvolvimento e implantação
As práticas de desenvolvimento e implantação garantem a entrega consistente e a preparação operacional entre ambientes. Essas práticas reduzem o risco de implantação e melhoram a coordenação da equipe.
Estabeleça práticas de DevOps para automação de implantação. As práticas de DevOps alinham as equipes de desenvolvimento e operações por meio de pipelines de automação, controle de versão e CI/CD. Use ferramentas como o Azure DevOps ou o GitHub Actions para automatizar fluxos de trabalho de build, teste e implantação. Essa abordagem reduz erros manuais, acelera os ciclos de lançamento e fornece processos de implantação consistentes entre ambientes.
Planeje a preparação operacional para dar suporte a atividades de implantação. A preparação operacional inclui procedimentos de monitoramento, alertas e resposta a incidentes para cenários de implantação. Runbooks de implantação de documentos e scripts de automação que abrangem procedimentos de reversão, verificações de integridade e etapas de solução de problemas. Armazene esses recursos em um local central, como o Wiki do Azure DevOps ou o GitHub, para garantir a acessibilidade durante as atividades de implantação.
Defina práticas de desenvolvimento que dão suporte a implantações confiáveis. Use padrões de codificação, revisões de pares e testes automatizados para garantir a qualidade do código e a preparação da implantação. Integre essas práticas ao modelo de pipeline CI/CD para aplicar barreiras de qualidade antes da implantação. Inclua testes específicos de implantação, como testes de integração, testes de fumaça e validação de desempenho para verificar a preparação do sistema para produção.
Planejar a implantação para novas cargas de trabalho
Use a exposição progressiva para limitar o impacto. Para um novo aplicativo (greenfield) sem usuários existentes, você deve fazer um lançamento suave. Implante na produção, mas exponha-a apenas a usuários internos ou a um grupo piloto inicialmente. Essa abordagem é uma implantação canária para uma nova carga de trabalho. Se for realmente novo e isolado, uma implantação única para a produção completa é possível, mas a exposição progressiva ainda é recomendada para identificar quaisquer problemas de maneira controlada. Não libere o sistema para 100% dos usuários no primeiro dia sem uma validação do mundo real antes. Para obter mais informações, consulte WAF – Adotar um modelo de exposição progressiva.
Documente procedimentos operacionais e caminhos de escalonamento. Crie uma documentação clara para reiniciar serviços, acessar logs, lidar com problemas comuns e escalar incidentes. Armazene essa documentação em um repositório compartilhado, como o SharePoint ou o GitHub, para garantir a disponibilidade das equipes de suporte.
Planejar o processo de implantação para novos recursos
Planeje a nova integração de recursos usando o gerenciamento de alterações. Siga o processo de gerenciamento de alterações da sua organização para controlar e documentar as alterações de produção. Defina procedimentos de reversão, como reverter versões do aplicativo ou restaurar backups de banco de dados. Garanta a aprovação dos stakeholders antes da implantação para garantir o alinhamento com as metas de negócios. Para obter mais informações, consulte Gerenciar alteração no CAF.
Use atualizações in-loco para alterações secundárias ou compatíveis com versões anteriores. Implante atualizações diretamente no ambiente de produção usando atualizações sem interrupção ou sinalizadores de recursos. Comece com uma pequena porcentagem de usuários ou instâncias. Monitore as métricas e os logs do sistema para validar a estabilidade antes da distribuição completa.
Use implantações paralelas (azul-verde) para alterações importantes ou de alto risco. Implante a nova versão em um ambiente separado. Encaminhe uma pequena parte do tráfego dinâmico para a nova versão para validar o comportamento. Se tiver êxito, desloce todo o tráfego para a nova versão. Se surgirem problemas, reverta o tráfego para a versão original para garantir a continuidade.
Planeje a transferência operacional para novas cargas de trabalho. Identifique a equipe responsável por operar e dar suporte à solução após a implantação. Defina o modelo de suporte (24 horas por dia, 7 dias por semana ou suporte comercial) e garanta que todos os stakeholders entendam suas funções.
Defina as responsabilidades de propriedade e suporte. Confirme se a equipe de operações está preparada para dar suporte ao novo recurso. Atualize a documentação e os caminhos de escalonamento para refletir novas responsabilidades e garantir uma resposta rápida a incidentes.
Definir plano de reversão para soluções nativas de nuvem
Um plano de reversão permite que as equipes revertam rapidamente as alterações quando uma implantação falha ou introduz riscos. Um plano bem definido minimiza o tempo de inatividade, limita o impacto nos negócios e mantém a confiabilidade do sistema. Sempre estabeleça critérios e procedimentos de reversão antes de iniciar qualquer migração ou implantação.
Como definir uma implantação com falha? Colabore com partes interessadas de negócios, responsáveis por cargas de trabalho e times operacionais para decidir o que conta como uma implantação com falha. Os exemplos incluem verificações de integridade com falha, desempenho ruim, problemas de segurança ou métricas de êxito não atendidas. Essa definição garante que as decisões de reversão estejam alinhadas com a tolerância a riscos da sua organização. Inclua condições específicas que disparam uma reversão em seu plano de implantação, como limites de uso da CPU, limites de tempo de resposta ou taxas de erro. Essa avaliação torna as decisões de reversão claras e consistentes durante incidentes.
Automatize as etapas de reversão em pipelines de CI/CD. Use ferramentas como o Azure Pipelines ou o GitHub Actions para automatizar processos de reversão. Por exemplo, configure pipelines para reimplantar uma versão anterior se as verificações de integridade falharem.
Crie instruções de reversão específicas da carga de trabalho. Desenvolva etapas de reversão que correspondam ao tipo de carga de trabalho, ao ambiente e ao método de implantação. Por exemplo, implantações de infraestrutura como código exigem reaplicação de modelos anteriores. As reversões de aplicativo envolvem a reimplantação de uma imagem de contêiner anterior. Anexe scripts de reversão, instantâneos de configuração e modelos de infraestrutura como código ao seu plano de reversão. Esses ativos permitem a execução rápida e reduzem a dependência da intervenção manual.
Testar procedimentos de reversão. Simule falhas de implantação em um ambiente de pré-produção para validar a eficácia da reversão. Identificar e resolver lacunas na automação, permissões ou dependências. Confirme se a reversão restaura o sistema para um estado conhecido e estável.
Aprimorar estratégias de reversão Após cada evento de implantação ou reversão, realize uma retrospectiva para avaliar o que funcionou e o que não funcionou. Atualize critérios de reversão, procedimentos e automação com base em lições aprendidas, alterações arquitetônicas ou novas ferramentas. Mantenha a documentação para garantir que as estratégias de reversão permaneçam atuais e eficazes.