Raccomandazioni per la progettazione di carichi di lavoro semplici ed efficienti

Si applica a questa raccomandazione dell'elenco di controllo di affidabilità Well-Architected Power Platform:

Questa guida descrive le raccomandazioni per ridurre al minimo la complessità e i costi generali non necessari per mantenere i carichi di lavoro semplici ed efficienti. Scegli i componenti migliori per eseguire le attività del carico di lavoro necessarie per ottimizzare l'affidabilità del carico di lavoro. Per ridurre gli oneri di sviluppo e gestione, sfrutta l'efficienza offerta dai servizi forniti dalla piattaforma. Questa progettazione ti aiuta a creare un'architettura del carico di lavoro resiliente, ripetibile, scalabile e gestibile.

Definizioni

Strategie di progettazione chiave

Un principio fondamentale della progettazione mirata all’affidabilità è mantenere le cose semplici ed efficienti. Concentra la progettazione del tuo carico di lavoro sul rispetto dei requisiti aziendali per ridurre il rischio di complessità non necessaria o di spese generali eccessive. Prendi in considerazione le raccomandazioni in questo articolo per aiutarti a prendere decisioni sulla progettazione per creare un carico di lavoro snello, efficiente e affidabile. Carichi di lavoro diversi potrebbero avere requisiti diversi in termini di disponibilità, scalabilità, coerenza dei dati e ripristino di emergenza.

Devi giustificare ogni decisione di progettazione con un requisito aziendale. Questo principio di progettazione potrebbe sembrare ovvio, ma è fondamentale per la progettazione del carico di lavoro. La tua applicazione supporta milioni di utenti o poche migliaia? Ci sono grandi picchi di traffico o un carico di lavoro costante? Quale livello di interruzione dell'applicazione è accettabile? I requisiti aziendali guidano queste considerazioni di progettazione.

Compromesso: una soluzione complessa può offrire più funzionalità e flessibilità, ma potrebbe alterare l'affidabilità del carico di lavoro poiché richiede un maggiore coordinamento, comunicazione e gestione dei componenti. In alternativa, una soluzione più semplice potrebbe non soddisfare pienamente le aspettative degli utenti o avere un effetto negativo sull'estendibilità con l'evoluzione del carico di lavoro.

Esercizi di progettazione collaborativa

Collabora con gli stakeholder per:

• Definire e assegnare un livello di criticità al tuo carico di lavoro e ai relativi componenti. Questo esercizio ti aiuterà a determinare i componenti necessari e l'approccio migliore per raggiungere il livello di resilienza richiesto. Per ulteriori informazioni, vedi Definire i livelli delle applicazioni.

• Definire i requisiti funzionali e non funzionali. I requisiti funzionali definiscono le funzionalità e il comportamento del sistema. Sono specificati dall'utente e acquisiti in casi d'uso. I requisiti non funzionali definiscono le prestazioni e gli attributi di qualità del sistema. Assicurati di comprendere i requisiti non funzionali come disponibilità, conformità, conservazione/residenza dei dati, prestazioni, privacy, tempi di ripristino, sicurezza e scalabilità. Questi requisiti influenzano le decisioni di progettazione e le scelte tecnologiche.

  Ecco alcuni esempi di requisiti funzionali e non funzionali, nel contesto di un carico di lavoro che gestisce le note spese:

  Requisiti funzionali	Requisiti non funzionali
  Il carico di lavoro deve consentire agli utenti di accedere con le proprie credenziali e accedere solo ai propri dati personali.	Il carico di lavoro deve essere disponibile almeno il 99,9% del tempo.
  Il carico di lavoro deve includere un dashboard che fornisca una panoramica delle note spese aperte, approvate e rifiutate.	Il carico di lavoro deve essere conforme alle normative e agli standard pertinenti per la protezione dei dati e la privacy.
  Il carico di lavoro deve supportare le operazioni di backup e ripristino per i dati del carico di lavoro.	Il carico di lavoro deve avere un tempo di risposta inferiore a 5 secondi per la maggior parte delle richieste degli utenti.
  Il carico di lavoro deve inviare notifiche a utenti e amministratori quando vengono attivati determinati eventi o soglie.	Il carico di lavoro deve avere un livello elevato di sicurezza e crittografia per i dati in transito e inattivi.

  Per ulteriori informazioni consulta il modulo formativo Utilizzare i requisiti per Microsoft Power Platform e Dynamics 365.

• Suddividere il carico di lavoro in componenti. Durante il processo di scoperta e raccolta dei requisiti, alcune idee di soluzione devono iniziare a diventare chiare. Identifica i componenti della soluzione che potrebbero costituire la soluzione proposta per soddisfare i requisiti aziendali. Dai priorità a semplicità, efficienza e affidabilità nella tua progettazione. Determina i componenti necessari per supportare il carico di lavoro. Evidenzia dove è possibile utilizzare le funzionalità predefinite e dove potrebbe essere necessario uno sviluppo personalizzato.

• Utilizzare l'analisi della modalità di errore per identificare i singoli punti di errore e i potenziali rischi. Comprendi chiaramente la tolleranza al rischio della tua azienda. Per ulteriori informazioni, vedi Raccomandazioni per l'esecuzione dell'analisi della modalità di errore.

• Definire gli obiettivi di disponibilità e ripristino affinché il carico di lavoro consente di prendere decisioni informate relative all'architettura. Le metriche aziendali includono obiettivi del livello di servizio (SLO), contratti di servizio (SLA), tempo medio di ripristino (MTTR), tempo medio tra guasti (MTBF), obiettivi del tempo di ripristino (RTO) e obiettivi del punto di ripristino (RPO). Definisci i valori target per queste metriche. Questo esercizio potrebbe richiedere un compromesso e una comprensione reciproca tra i team tecnologici e aziendali per garantire che gli obiettivi di ciascun team soddisfino gli obiettivi aziendali e siano realistici. Per ulteriori informazioni, vedi Raccomandazioni per definire obiettivi di affidabilità. I contratti di servizio di Power Platform forniscono gli impegni di Microsoft in termini di tempo di attività e connettività. Servizi diversi hanno contratti di servizio diversi e talvolta gli SKU in un servizio hanno contratti di servizio diversi. Per ulteriori informazioni, vedi Contratti di servizio per servizi online.

Ulteriori raccomandazioni di progettazione

Puoi eseguire le seguenti raccomandazioni senza coinvolgere gli stakeholder:

• Cerca semplicità e chiarezza nella tua progettazione. Utilizza il livello appropriato di astrazione e granularità per componenti e servizi. Evita un'ingegnerizzazione eccessiva o insufficiente della tua soluzione. Ad esempio:

  • Se risolvi un requisito di automazione dei processi con Power Automate, suddividere un processo di grandi dimensioni in molteplici flussi cloud più piccoli potrebbe renderlo più difficile da comprendere, testare e gestire. D'altro canto, mantenere tutto in un flusso di grandi dimensioni potrebbe avere un impatto negativo sulle prestazioni e sul volume delle chiamate API.

  • Se risolvi un requisito rivolto all'utente con Power Apps, un'app canvas monolitica di grandi dimensioni con molti controlli potrebbe avere un impatto negativo sulle prestazioni. Suddividerlo in singole app o pagine personalizzate potrebbe rendere i test più difficili, ma potrebbe avere un impatto positivo significativo sulle prestazioni.

• Anticipa i cambiamenti nel tempo, sia per correggere bug, implementare nuove funzionalità o tecnologie, sia per rendere i sistemi esistenti più scalabili e resilienti.

• Scarica le preoccupazioni trasversali su un servizio separato. Riduci al minimo la necessità di duplicare il codice in funzioni diverse. Privilegia il riutilizzo di servizi con interfacce ben definite che possano essere facilmente utilizzate da diversi componenti. Ad esempio, se è necessario eseguire una serie di operazioni sui dati da luoghi diversi, puoi spostare questa funzionalità su un plug-in con poco codice.

• Valuta l'idoneità di modelli e pratiche comuni per le tue esigenze. Evita di seguire tendenze o raccomandazioni che potrebbero non essere adatti al tuo contesto o alle tue esigenze. Ad esempio, l'implementazione di componenti di codice personalizzato potrebbe non essere l'opzione migliore per ogni applicazione perché possono introdurre problemi di complessità, sovraccarico e dipendenza.

Sviluppare solo il codice necessario

I principi di semplicità, efficienza e affidabilità si applicano anche alle pratiche di sviluppo. Prendi in considerazione queste raccomandazioni:

• Utilizza le funzionalità della piattaforma quando soddisfano i tuoi requisiti aziendali. Ad esempio, utilizza controlli moderni invece di sviluppare componenti di codice personalizzati per ottenere uno standard di progettazione Fluent 2.

• Introduci sessioni di revisione del codice dedicate come pratica di sviluppo.

• Implementa un approccio per identificare codice non utilizzato. Sii scettico nei confronti del codice che i tuoi test automatizzati non coprono.

• Prendi in considerazione le competenze del tuo team di sviluppo. Ci vuole tempo per apprendere una nuova competenza o adottare una nuova tecnologia.

Prendere in considerazione la residenza dei dati

Nell'ambito della progettazione dell'architettura devi considerare come archiviare i dati o come recuperarli per le attività di lettura. I dati possono essere recuperati e archiviati in diversi modi:

• Nuovi dati: se la tua app crea dati che non esistono ancora, come quando il processo aziendale esistente è stato eseguito su supporto cartaceo, ti consigliamo di archiviare i dati in Microsoft Dataverse.

• Lettura/scrittura da un sistema esistente: se la tua app deve recuperare dati da un database o sistema esistente, devi valutare il modo migliore per connetterti al database o al sistema: utilizzare un connettore predefinito, un connettore personalizzato o tabelle virtuali.

• Crea una copia dei dati: in situazioni in cui i dati originali non devono mai essere modificati o sovrascritti, puoi copiarli in un altro archivio dati come Dataverse. Ciò garantisce che i dati nel sistema originale non vengano modificati, consentendo nel contempo il funzionamento dell'app con gli stessi. Questo scenario è comune quando si lavora con dati in sistemi contabili e relativi ai ricavi. Devi considerare il modo in cui vengono copiati i dati, la frequenza con cui vengono aggiornati e se è necessaria una sincronizzazione bidirezionale.

Facilitazione di Power Platform

Questi articoli di Power Apps forniscono consigli pratici di progettazione:

• Determinare dove posizionare la logica nel sistema: app canvas, app basate su modello, Microsoft Dataverse o flussi di Power Automate
• Determinare quale tipo di app creare: app basate su modello o app canvas
• Modellazione dei dati: progettazione della struttura dei dati
• Progettazione dei dati:utilizzo di sistemi aziendali

Vedi anche

• Contratti di servizio per servizi online
• Utilizzare i requisiti per Microsoft Power Platform e Dynamics 365
• Pianificazione di un progetto Power Apps

Lista di controllo dell'affidabilità

Fare riferimento alla serie completa di raccomandazioni.