Microsoft Power Platform

(Verfasst in Zusammenarbeit mit Gerasimos Fousekis & Stefan Starke)

Obwohl unsere Wurzeln fest in traditionellen Softwareentwicklungsmethoden verankert sind, treibt uns unser Engagement für Innovation und Kundenzufriedenheit dazu an, kontinuierlich neue Horizonte zu erkunden. Das veranlasst uns, verschiedene aufkommende Plattformen wie Microsoft Power Platform als potenzielle Ergänzungen zu unserem bereits umfangreichen Toolkit zu betrachten. Obwohl das für ein Softwareentwicklungsunternehmen etwas unkonventionell erscheinen mag, ist unsere Motivation in einem tieferen Verständnis der sich ständig weiterentwickelnden Geschäftslandschaft und der vielfältigen Bedürfnisse unserer Kunden verwurzelt.

„Was war euer Ziel?”, fragt ihr.

Kurz gesagt:

Schnelle Ergebnisse: Um wie viel schneller können wir Lösungen implementieren, wenn wir in einer Umgebung arbeiten, in der Themen wie Authentifizierung, Infrastruktur und Deployment mehr oder weniger out-of-the-box verfügbar sind?

Kundenbefähigung: Kann der Einsatz von etwas wie Power Platform Kunden dabei helfen, ihre Anwendungen zu pflegen, Updates durchzuführen und neue Features mit wenig bis gar keinen Vorkenntnissen in der Programmierung einzuführen?

Projektvielfalt: Bei welchen Projekten sehen wir diesen Ansatz als vorteilhaft, ja sogar optimal? Gibt es Hindernisse, die uns daran hindern könnten, diesen Ansatz zu verfolgen?

Überblick

Power Platform Architekturüberblick

Microsoft Power Platform ist eine Suite integrierter Tools und Dienste, die Einzelpersonen und Organisationen dabei unterstützt, benutzerdefinierte Geschäftsanwendungen zu erstellen, Workflows zu automatisieren, Daten zu analysieren und Berichte zu erstellen. Sie besteht aus vier Kernkomponenten:

Power Apps & Power Pages: Sie ermöglichen Benutzern zunächst das Erstellen benutzerdefinierter Anwendungen ohne umfangreiche Programmierkenntnisse. Sie bieten Canvas-Apps und modellgesteuerte Apps: Canvas-Apps ermöglichen das Erstellen von Anwendungen mit einer visuellen Oberfläche, während modellgesteuerte Apps datenzentrierter sind und auf dem Common Data Service basieren. Beide interagieren mit (Geschäfts-)Daten, die im Dataverse gespeichert sind, wobei der Hauptunterschied darin besteht, dass Power Pages auf externe Benutzer ausgerichtet ist, unterstützt durch die vielen Authentifizierungsoptionen (z. B. Azure AD, LinkedIn, Facebook), die out-of-the-box verfügbar sind.

Power Automate: Früher bekannt als Microsoft Flow, ermöglicht die Automatisierung von sich wiederholenden Aufgaben und Workflows über verschiedene Anwendungen und Dienste hinweg. Es verbindet Hunderte von Apps und Diensten und ermöglicht es Benutzern, automatisierte Prozesse ohne große Komplexität zu erstellen (z. B. automatisches E-Mail-Versenden).

Power BI: Ein leistungsstarkes Business-Analytics-Tool, das Benutzern ermöglicht, Daten zu visualisieren, Berichte zu erstellen und dynamische Dashboards aufzubauen. Es ist besonders nützlich für die Datenanalyse und Entscheidungsfindung, indem Rohdaten in handlungsorientierte Erkenntnisse umgewandelt werden.

Power Virtual Agents: Ermöglicht Benutzern die Erstellung von Chatbots, die für die Interaktion mit Kunden, die Bereitstellung von Support, die Beantwortung von Anfragen und die Automatisierung verschiedener Interaktionen verwendet werden können.

Mit dem Ziel, die zuvor genannten Anforderungen zu erfüllen, konzentrierten wir uns letztlich auf den Einsatz von Power Pages und Power Automate.

Vor- und Nachteile

VORTEILE

NACHTEILE

Kleinere, datengesteuerte Anwendungen können wirklich schnell zusammengeklickt werden

Generell nützliche Features (d. h. manuelle Codeänderungen, Vorlagenvoreinstellungen) sollten aufgrund begrenzter Benutzerfreundlichkeit am besten ganz vermieden werden

Out-of-the-box-Ökosystem (z. B. Infrastruktur, Skalierung, IP-Whitelisting usw.)

Häufig unzuverlässige und lange Ladezeiten während der Entwicklung, insbesondere beim Neuladen des Designers

Integriertes Application Lifecycle Management (z. B. Umgebungen mit Pipelines)

Die Kosten können bei Projekten mit einem größeren Publikum sehr hoch werden

Integrierte i18n-Funktionen

Änderungen, die direkt an den Tabellen im Dataverse vorgenommen werden (z. B. geplanter Job, der einige Zeilen manipuliert), können bis zu 15 Minuten in Anspruch nehmen, bis sie angewendet werden

Begrenzte Monitoring-Fähigkeiten und keine Möglichkeit zu sehen, woher anonyme Benutzer kommen (d. h. IP-Adressen)

Im Folgenden werden einige nützliche Erkenntnisse geteilt, die unterwegs gewonnen wurden.

Preisgestaltung & Kosten

Zunächst ein Rat: Stellt sicher, dass ihr die Lizenzierung und Abrechnung des gesamten Power-Platform-Ökosystems versteht, um unangenehme und kostspielige Überraschungen zu vermeiden. In unserem Setup war der Hauptkostentreiber (neben dem Dataverse-Speicher) die Anzahl der monatlich aktiven Benutzer, sowohl anonyme als auch authentifizierte. Die Preise variieren je nach gewähltem Abonnementplan, also entweder einem Paket mit einer festgelegten Anzahl von Benutzern oder der Option „Pay as you go” (PAYG). Technisch gesehen verwendeten wir eine Abrechnungsrichtlinie, die direkt mit einem aktiven Azure-Abonnement verknüpft war. Zu beachten ist jedoch: Die aktuellen Kosten sind nicht sofort sichtbar, und es kann bis zu 24 Stunden dauern, bis sie im Azure Cost Management verfügbar werden.

„Warum wird so viel Wert auf die Preisgestaltung gelegt?”, fragt ihr vielleicht. Stellen wir uns ein Szenario vor, in dem jemand einen einfachen Cron-Job einrichtet, der jede Minute oder so auf dem Dataverse operiert. Ein Premium-Flow, der entweder in der Cloud oder attended laufen kann, kostet wohlgemerkt 0,60 $ pro Ausführung. Wir überlassen euch die Berechnung, wie hoch die Kosten werden, wenn die Cost-Management-Alarme zu triggern beginnen, was – wie oben erklärt – bis zu 24 Stunden dauern kann, bis sie aktualisiert werden. Spoiler-Alarm: Es sind 864 $. Verwendet in ähnlichen Szenarien eine Power-Automate-Lizenz.

Apropos monatlich aktive Benutzer…

Sie werden in einer täglichen Zusammenfassung gemeldet, die im Power Admin Portal heruntergeladen werden kann. Angesichts der Einzigartigkeit eines anonymen Benutzers, der mithilfe eines Browser-Cookies verfolgt wird, sehen wir ein potenzielles Risiko unvorhersehbarer Kosten als Konsequenz. Die Behauptung ist, dass böswillige Angriffe, Bots und Crawler von der Zählung ausgeschlossen werden, aber wir konnten diese Aussage nicht zu 100 % bestätigen.

Kurzfassung:

• Das Verständnis des Hauptanwendungsfalls der Anwendung in Bezug auf Zielbenutzer wird dringend empfohlen, um prekäre finanzielle Situationen zu vermeiden
• Stellt sicher, von Anfang an das optimale Lizenzierungsmodell zu wählen
• Wie bei allen Cloud-Projekten: Kostenwarnungen von Tag eins an aktivieren!

Entwicklung

Wie bei jeder neuen Technologie wird es eine Lernkurve geben. Bei der Power Platform selbst ist sie nicht besonders steil, aber man muss sich bewusst sein, dass der Workflow nicht mit einem „traditionellen” Softwareentwicklungsprozess vergleichbar ist. In Verbindung mit der von Microsoft bereitgestellten Dokumentation, die leider manchmal etwas veraltet ist, kann das zu plötzlichen Sprüngen in der Gesamtlernkurve führen.

Als wir mit dieser Methodik begannen, dauerte es einige Zeit, bis wir uns daran gewöhnt hatten, wie kollaborative Arbeit in einer gemeinsamen Power-Pages-Umgebung eingerichtet werden kann. Da es keine Implementierung von Versionskontrolle, Merge Requests oder individuellen Commits gibt, war eine weitere Koordination erforderlich, um gegenseitige Interferenzen zu vermeiden. Das ist für kleinere Projekte leicht handhabbar, wird jedoch für größere Projekte nicht empfohlen. Daher empfehlen wir eine Teamgröße von maximal 3 Personen für einen optimalen Workflow.

Ein unbestreitbarer Vorteil ist, dass – bei einem Hintergrund in datengesteuerten Anwendungen mit CRUDL (Create-Read-Update-Delete-List) – die Gesamtentwicklungszeit rasend schnell ist. Es läuft im Wesentlichen darauf hinaus, „Tabellen, Views und Formulare zu erstellen (und zu wiederholen)”. Die Entwicklung wird durch die Verwendung bereitgestellter Komponenten für Features wie die folgenden weiter beschleunigt:

• Login
• Benutzerregistrierung
• Authentifizierungsanbieter

Kurzfassung:

• Ideal für kleine, wenig komplexe Projekte
• Funktioniert am besten für kleine Teams (maximal 2-3 Personen)
• Kaum kollaborative Features, an die ein Entwickler normalerweise gewöhnt wäre
• Komponenten immer (wieder) verwenden, wann immer möglich

Testing

Wir wissen, wie sehr Entwickler das Testen von Code lieben (Sarkasmus). Gute Neuigkeit: Manuelles Testing ist bei Power Platform mehr oder weniger der Hauptansatz. Für diejenigen, die an automatisiertem Testing interessiert sind, kann das Standard-Framework (Cypress) verwendet werden, das durch einen externen Build ausgelöst wird.

Deployment

Was Deployments betrifft, haben wir eine Pipeline eingerichtet, die innerhalb der Power Platform ausgeführt werden kann, zusammen mit dem typischen Muster der umgebungsübergreifenden Bereitstellung: Dev → Test → Prod. Wir haben festgestellt, dass das für die oben genannten kleineren Projekte ausreichend ist. Natürlich ist es nicht so leistungsstark wie GitLab oder TeamCity, aber das wäre auch nicht notwendig.

Skalierung, Erweiterung & Wartbarkeit

Was die Skalierbarkeit betrifft, abgesehen von möglicherweise mehr Geld für eine breitere Benutzerbasis oder Dateispeicherfähigkeiten, gibt es in dieser Hinsicht nicht viel hinzuzufügen. Wenn das Endziel darin besteht, kleinere, weniger komplexe Anwendungen zu erstellen, sollten die bereitgestellten Erweiterungsoptionen ausreichen (eine API für CRUDL kann verwendet werden, ebenso wie Azure Functions mit einem HTTP-Trigger für komplexere Logik).

Ebenso sollten bei der Prämisse einer kleineren Anwendung die angebotenen Wartbarkeitsoptionen für die meisten Projekte wiederum ausreichen.

i18n („Internationalisierung”)

i18n-Unterstützung wird auf der Plattform bereitgestellt. Es gibt eine angemessene Liste verfügbarer Sprachen, die für jede Seite aktiviert werden können. Das verwendete Muster ist ein „Schlüssel-Wert”-Ansatz: Sprache → Übersetzung. Mit Ausnahme einiger Komponenten, die automatisch übersetzt werden (d. h. Login), müssen Übersetzungen kontextuell auf jeder Seite für jede gewünschte Sprache bereitgestellt werden. Auf der anderen Seite gibt es die Option, eine Ressourcendatei für diese Übersetzungen bereitzustellen (wobei wir diesen Ansatz nicht tief genug untersucht haben, um seinen Nutzen zu bestätigen).

Lessons Learned

Für manche mag Microsoft Power Platform nur in bestimmten Szenarien aufzublühen scheinen (man denke an ein Ein-Trick-Pony). Wir glauben, dass es seinen Platz im Ökosystem moderner Technologie-Stacks verdient hat, und wenn es um Folgendes geht:

• Schnelle MVPs
• Rein datengesteuerte Projekte
• „Set it and forget it”-Projekte
• Vordefinierte Benutzerbasen
• Minimale UI
• Vorhandene Microsoft-Ökosystem-Integration
• „Entwickeln ohne Entwickler” (Willkommen im Jahr 2023)

gibt es kaum Konkurrenz. Wir sagen: „Probiert es aus.” Es könnte am Ende die Lösung sein, nach der ihr gesucht habt.