Partilhar via

Recomendações para uma conceção que privilegie a simplicidade e a eficiência

  • Artigo

Aplica-se a esta Power Platform recomendação de lista de verificação de fiabilidade bem arquitetada:

RE:01 Estruture a sua carga de trabalho para se alinhar com os objetivos de negócio e evitar uma complexidade ou uma sobrecarga desnecessárias. Utilizar uma abordagem prática e equilibrada para tomar decisões de conceção que produzam os resultados desejados. Limite o seu design às necessidades para reduzir as ineficiências e os potenciais problemas.

Este guia descreve as recomendações para minimizar a complexidade desnecessária e a sobrecarga para manter as suas cargas de trabalho simples e eficientes. Escolha os melhores componentes para executar as tarefas de carga de trabalho necessárias para otimizar a fiabilidade da sua carga de trabalho. Para reduzir os seus encargos de desenvolvimento e gestão, tire partido das eficiências que os serviços fornecidos pela plataforma oferecem. Este design ajuda-o a criar uma arquitetura de carga de trabalho que é resiliente, repetível, escalável e gerível.

Definições

Termo Definição
Carga de trabalho Uma capacidade discreta ou tarefa de computação que pode ser logicamente separada de outras tarefas.

Principais estratégias de design

Um princípio chave da conceção para a fiabilidade é manter as coisas simples e eficientes. Concentre a conceção da sua carga de trabalho no cumprimento dos requisitos comerciais para reduzir o risco de complexidade desnecessária ou de excesso de despesas gerais. Considere as recomendações deste artigo para o ajudar a tomar decisões sobre a sua conceção, de modo a criar uma carga de trabalho simples, eficiente e fiável. Diferentes cargas de trabalho podem ter diferentes requisitos de disponibilidade, escalabilidade, consistência de dados e recuperação de desastres.

É necessário justificar cada decisão de conceção com um requisito comercial. Este princípio de design pode parecer óbvio, mas é crucial para a conceção de cargas de trabalho. Sua carga de trabalho suporta milhões de usuários ou alguns milhares? Há grandes picos de tráfego ou uma carga de trabalho constante? Que nível de interrupção é aceitável? Os requisitos comerciais orientam estas considerações de design.

Compensação: Uma solução complexa pode oferecer mais recursos e flexibilidade, mas pode afetar a fiabilidade da carga de trabalho porque requer mais coordenação, comunicação e gerenciamento de componentes. Em alternativa, uma solução mais simples pode não satisfazer totalmente as expectativas do utilizador ou pode ter um efeito negativo na extensibilidade à medida que a carga de trabalho evolui.

Exercícios de design colaborativo

Trabalhe com os intervenientes para:

  • Defina e atribua um nível de criticidade à sua carga de trabalho e seus componentes. Este exercício ajudá-lo-á a determinar os componentes necessários e a melhor abordagem para atingir o nível de resiliência exigido. Para mais informações, consulte Definir escalões de aplicações.

  • Definir requisitos funcionais e não funcionais. Os requisitos funcionais definem as funcionalidades e o comportamento do sistema. São especificados pelo utilizador e capturados em casos de utilização. Os requisitos não funcionais definem os atributos de desempenho e a qualidade do sistema. Certifique-se de que compreende os requisitos não funcionais, como a disponibilidade, a conformidade, a retenção/residência de dados, o desempenho, a privacidade, o tempo de recuperação, a segurança e a escalabilidade. Estes requisitos influenciam as decisões de design e as escolhas tecnológicas.

    Eis alguns exemplos de requisitos funcionais e não funcionais, no contexto de um volume de trabalho que trata de relatórios de despesas:

    Requisitos funcionais Requisitos não funcionais
    A carga de trabalho deve permitir que os utilizadores iniciem sessão com as suas credenciais e acedam apenas aos seus dados pessoais. A carga de trabalho deve estar disponível pelo menos 99,9% do tempo.
    A carga de trabalho deve incluir um dashboard que fornece uma visão geral dos relatórios de despesas abertos, aprovados e recusados. A carga de trabalho deve cumprir os regulamentos e normas relevantes em matéria de proteção de dados e privacidade.
    A carga de trabalho deve suportar operações de cópia de segurança e restauro dos dados da carga de trabalho. A carga de trabalho deve ter um tempo de resposta inferior a 5 segundos para a maioria dos pedidos dos utilizadores.
    A carga de trabalho deve enviar notificações aos utilizadores e administradores quando determinados eventos ou limiares são acionados. A carga de trabalho deve ter um elevado nível de segurança e encriptação para os dados em trânsito e em repouso.

    Para mais informações, consultar o módulo de formação intitulado Trabalhar com os requisitos para o Microsoft Power Platform e o Dynamics 365.

  • Divida a carga de trabalho em componentes. Durante o processo de deteção e recolha de requisitos, algumas ideias de soluções devem começar a tornar-se claras. Identifique os componentes da solução que podem constituir a solução proposta para satisfazer as suas necessidades comerciais. Dê prioridade à simplicidade, eficiência e fiabilidade no seu design. Determine os componentes necessários para suportar a sua carga de trabalho. Realce onde podem ser utilizadas capacidades prontas a utilizar e onde pode ser necessário um desenvolvimento personalizado.

  • Use a análise do modo de falha para identificar pontos únicos de falha e riscos potenciais. Compreenda claramente a tolerância da sua empresa ao risco. Para mais informações, consulte Recomendações para efetuar a análise do modo de falha.

  • Defina metas de disponibilidade e recuperação para sua carga de trabalho para informar as decisões de arquitetura. As métricas de negócio incluem objetivos de nível de serviço (SLOs), acordos de nível de serviço (SLAs), tempo médio de recuperação (MTTR), tempo médio entre falhas (MTBF), objetivos de tempo de recuperação (RTOs) e objetivos de ponto de recuperação (RPOs). Defina valores alvo para estas métricas. Este exercício pode exigir um compromisso e uma compreensão mútua entre as equipas tecnológicas e comerciais para garantir que os objetivos de cada equipa correspondem aos objetivos comerciais e são realistas. Para obter mais informações, consulte Recomendações para definir alvos de fiabilidade. Power Platform Os SLAs fornecem os Microsoft compromissos de tempo de atividade e conectividade. Serviços diferentes têm SLAs diferentes e, por vezes, as SKUs de um serviço têm SLAs diferentes. Para mais informações, consulte Acordos de nível de serviço para serviços online.

Recomendações de design adicionais

É possível fazer as seguintes recomendações sem o envolvimento dos intervenientes:

  • Procure simplicidade e clareza no seu design. Utilize o nível adequado de abstração e granularidade para os seus componentes e serviços. Evite a sobre-engenharia ou a sub-engenharia da sua solução. Por exemplo:

    • Se resolver um requisito de automatização de processos com o Power Automate, dividir um grande processo em vários fluxos de cloud mais pequenos pode dificultar a sua compreensão, teste e manutenção. Por outro lado, manter tudo num fluxo grande pode ter um impacto negativo no desempenho e no volume de chamadas à API.

    • Se resolver um requisito de contacto com o utilizador com o Power Apps, uma grande aplicação de tela monolítica com muitos controlos pode ter um impacto negativo no desempenho. A sua divisão em aplicações individuais ou páginas personalizadas pode tornar os testes mais difíceis, mas pode ter um impacto positivo significativo no desempenho.

  • Antecipe mudanças ao longo do tempo, seja para corrigir bugs, implementar novos recursos ou tecnologias, ou tornar os sistemas existentes mais escaláveis e resilientes.

  • Descarregar preocupações transversais para um serviço separado. Minimizar a necessidade de duplicar código em diferentes funções. Prefira a reutilização de serviços com interfaces bem definidas que possam ser facilmente consumidas por diferentes componentes. Por exemplo, se um conjunto de operações de dados tiver de ser executado a partir de locais diferentes, pode transferir esta funcionalidade para um plug-in com pouco código.

  • Avalie a adequação de padrões e práticas comuns às suas necessidades. Evite seguir tendências ou recomendações que possam não ser as melhores para o seu contexto ou necessidades. Por exemplo, a implementação de componentes de código personalizados pode não ser a melhor opção para todas as aplicações, porque podem introduzir complexidade, sobrecarga e problemas de dependência.

Desenvolver apenas código suficiente

Os princípios de simplicidade, eficiência e fiabilidade também se aplicam às suas práticas de desenvolvimento. Considere estas recomendações:

  • Utilize as capacidades da plataforma quando estas satisfazem os seus requisitos comerciais. Por exemplo:

    • Use controles modernos em vez de desenvolver seus próprios componentes de código para alcançar um padrão de design Fluent 2.
    • Use conectores nativos em vez de desenvolver conectores personalizados para reduzir o código personalizado.
    • Use respostas generativas para Microsoft Copilot Studio permitir que seu copiloto encontre e apresente informações de várias fontes, internas ou externas, sem tópicos criados manualmente.

  • Introduza sessões dedicadas de revisão de código como uma prática de desenvolvimento.

  • Implemente uma abordagem para identificar código morto. Seja cético em relação ao código que os seus testes automatizados não cobrem.

  • Considere o conjunto de competências da sua equipa de desenvolvimento. É preciso tempo para aprender uma nova competência ou adotar uma nova tecnologia.

Considere onde estão os seus dados

Como parte do seu projeto de arquitetura, é necessário considerar a forma de armazenar os seus dados ou de os recuperar para atividades de leitura. Os dados podem ser recuperados e armazenados de diferentes formas:

  • Novos dados: se seu aplicativo criar dados que ainda não existem, como quando o processo de negócios existente foi feito no papel, recomendamos armazenar os dados Microsoft Dataverse.

  • Leitura/gravação de um sistema existente: se seu aplicativo precisar recuperar dados de um banco de dados ou sistema existente, você precisará avaliar a melhor maneira de se conectar ao banco de dados ou sistema: usando um conector pronto para uso, um conector personalizado ou tabelas virtuais.

  • Faça uma cópia dos dados: em situações em que os dados originais nunca devem ser modificados ou substituídos, você pode copiar os dados para outro arquivo de dados como Dataverse. Essa estratégia mantém os dados do sistema original inalterados, permitindo que seu aplicativo trabalhe com ele. Este cenário é comum quando se trabalha com dados em sistemas contabilísticos e relacionados com receitas. É necessário considerar a forma como os dados são copiados, a frequência com que são atualizados e se é necessário efetuar uma sincronização bidirecional.

Facilitação do Power Platform

Para conselhos práticos de conceção, consulte os seguintes artigos:

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de fiabilidade