December 8th, 2021
6 min
Daniel MüllerInnovation mit MACH (Part 1): Geschäftsmodelle mit Microservices
Soll sich die digitale Transformation an Bedürfnissen des Geschäfts, oder denen der Technik orientieren? Sind der Aufbau und der Betrieb einer großartigen Plattform ohne ein großes Team möglich? Bestimmen die Fähigkeiten der Plattform das Geschäftsmodell? Über diese Fragen haben wir alle schon nachgedacht. 81 % der IT-Entscheidungsträger weltweit planen, in Kürze MACH-Elemente in ihre Architektur aufzunehmen. Aber geschieht das aus den richtigen Gründen?
Microservices-Architekturen ermöglichen ganzheitliche Geschäftsmodelle und Plattformfunktionen. Lassen Sie uns sehen wie.
Fokus auf individuelle Business Capabilities
Unternehmen brauchen Software-Experten, die Geschäftsprobleme lösen und Plattformen, die ständig weiterentwickelt werden, um ihr Geschäft zu betreiben. Dieses Top-Down-Denken, bei dem sich die Geschäftsziele an der Entwicklung orientieren, ist mit Microservices möglich. Teilen Sie Ihre Geschäftsziele systematisch in mehrere kleinere, unabhängige Dienste auf.
Dieser Ansatz ist nicht an eine bestimmte Sammlung von Praktiken, Technologien, Prozessen oder Tools gebunden. Stattdessen führt jede gebündelte Business Capability ihre eigenen Aufgaben. Sie verfügen über separate Logik, Bereiche, Datenbanken, eine gemeinsame Datenquelle und spezifische Funktionen.
Unternehmen können ihre Domänen und Prozesse gestalten, sich auf das Testen von Geschäftsfunktionen konzentrieren und diese schnell zur Verfügung stellen. Mit anderen Worten: Einzelne Funktionen einer Plattform, wie Suche, Katalog, Produktpreise, Bestand, Versand, Lieferung, Kundenkonto, Werbeaktionen, Warenkorb etc. werden unabhängig voneinander aktualisiert, bereitgestellt und skaliert. Domain-driven-Design definiert Use Cases nach den Bedürfnissen des Geschäfts. Damit orientieren sich Business Use Cases nicht an technologischen Gegebenheiten.
Die ersten Fragen sollten lauten: Was ist das Besondere an einer bestimmten Domäne? Was sind die Anwendungsfälle und wie werden sie entworfen?
MACH-Technologien – Microservices, API-first, Cloud-native und Headless – markieren eine Abkehr von starrer, monolithischer Technologie hin zu modernen, kombinierbaren Plattformen. Einzelne oder mehrere Microservices werden eingesetzt, um die Grundlage für gebündelte Business Capabilities in einer MACH-Plattform zu bilden. Die Teams können kreativer arbeiten und sich auf die Entwicklung von Business Capabilities konzentrieren, anstatt Logik zu erstellen und langwierigen Code zu schreiben. Werfen Sie einen Blick auf diesen Anwendungsfall aus einem unserer Projekte:
Top-Down-Ansatz für Submetering Packaged Business Capability
- Das Unternehmen definiert die Anforderungen im Bereich Submetering als Packaged Business Capabilities (PBCs) auf der Grundlage von realen Verbräuchen, Kosten, Berechnungen und anderen Benchmarks.
- Dies fließt in die technische Architektur der PBCs ein, wo einzelne Microservices und Funktionen auf gemeinsame Daten zugreifen. Wir verwenden das CQRS-Muster, um diesen Anwendungsfall des Submeterings zu implementieren.
- Zukünftige Capabilities für das Unternehmen werden einbezogen und für technische und nicht-funktionale Anforderungen verfeinert, z. B. die Erhöhung der Verfügbarkeit und Leistung über CQRS.
Einzelne oder überschneidende Teams, unabhängige Releases
Mit Microservices definieren Sie verschiedene Domänen für Ihre Plattform und übertragen den richtigen Gruppen die Verantwortung dafür, ohne dass für jede Domäne ein eigenes Team erforderlich ist. Ein Team kann an mehreren Domänen arbeiten und seinen Fokus sprintweise auf verschiedene Domänen der Plattform verlagern.
Nicht jedes Unternehmen erwartet, ein „Netflix“ zu sein, das die beste Plattform in der Geschichte der Plattformen aufbauen will. Sie haben vielleicht dafür weder das Budget, noch den Bedarf. Sie sind nicht führend im technischen Bereich, brauchen aber Technik, um ihr Geschäftsmodell zu betreiben. Sie arbeiten meist mit begrenzten Ressourcen und konzentrieren sich auf die schrittweise Entwicklung von Funktionen, anstatt mehrere Schritte gleichzeitig zu unternehmen. Wir haben das bei vielen unserer Projekte so gemacht und damit gute Ergebnisse erzielt. Selbst wenn es sich nur um ein Team handelt, kann jeder Dienst mit der am besten geeigneten Technologie oder Sprache oder Framework entwickelt werden, ohne seine Fähigkeit zur Kommunikation mit anderen Diensten zu beeinträchtigen. Auf diese Weise können viele Geschäftsinitiativen parallel laufen.
Änderungen an einem Microservice sind nicht von anderen Teams abhängig, und der Code geht viel schneller in Produktion.
Selektive Änderung und Skalierung lose gekoppelter Systeme
Mithilfe von Microservices skalieren Sie Geschäftsbereiche separat und unabhängig voneinander, was Ihnen eine große Flexibilität bietet. Da die Systeme lose gekoppelt sind, binden Sie neue Geschäftsmodelle leicht ein, da die Funktionen schnell aufgebaut und selektiv geändert oder skaliert werden. Es muss nicht das gesamte System aktualisiert werden. Sie fügen neue Funktionen, Upgrades, Datenquellen und Frameworks schneller und ohne großen Ressourcenaufwand hinzu.
Das Ausprobieren von POCs mit verschiedenen Anbietern ist einfach, um die beste Option für ein gutes MVP zu ermitteln. Dies reduziert zukünftige Gesamtkosten, da Sie bereits im Vorfeld die beste UX auswählen.
Häufige Änderungen sind möglich, da die Systeme in Microservices containerisiert werden. Das Team passt sich schnell an neue Geschäftsanforderungen an, ändert schnell bestehende Funktionalitäten und bindet neue Ressourcen ein. Testfälle für diese individuellen, geschäftsorientierten Anwendungsfälle werden definiert und automatisiert. Dieser Agilitätsschub schafft Vertrauen in das Entwicklungsteam und gibt ihm die Freiheit, aus Fehlern zu lernen.
Häufige Releases ohne Beeinträchtigung des bestehenden Systems
Wie geben Sie Ihre Plattformfunktionen und Upgrades frei? Die Antwort auf diese Frage zeigt, ob Ihre Microservices ausgereift sind.
Sie könnten Branching-Strategien wie Git Flow oder Gitlab Flow verwenden, aber eine leichtgewichtige Entwicklung nach Baumschema hat sich in unseren Projekten am besten bewährt. Die Microservices-Architektur bietet mehr Flexibilität bei der Bereitstellung von Funktionen und Upgrades. Die Deployment-Zyklen benötigen kürzere Erstellungszeit und Testphase. Diese Releases werden an die Verwirklichung von Geschäftszielen geknüpft, da einzelne Geschäftsfunktionen als unabhängige Microservices entwickelt werden.
Jeder Commit sollte idealerweise zu einem Deployment führen. Für Entwickler, die an klassische Abläufe wie den Git Flow gewöhnt sind, erfordert das eine Änderung der gewohnten Denkweise, da jeder Commit produktionsreif sein muss, was die Test Driven Development umso wichtiger macht. Außerdem muss jeder Entwickler jeden Tag mindestens einen Commit durchführen.
Neue Funktionen können ein- und ausgeschaltet werden, aber es ist wichtig, dass es sich dabei um Geschäftsfunktionen und nicht um technische Komponenten handelt. Beispielsweise zeigen Sie einen neuen Teil einer Seite, ohne sich um die Backend-Systeme zu kümmern. Aktivieren Sie selektiv Funktionen für einige Beta-Nutzer, ohne die gesamte Plattform offline zu nehmen. Frühzeitiges Feedback von begrenzten Kundengruppen hilft Ihnen bei der Verbesserung Ihres Produkts, bevor es den Rest Ihrer Kunden erreicht. Wir haben beide Ansätze gesehen, bei denen jedes Team sein Release unabhängig definieren konnte und bei denen sich die Teams an einer zentral definierten Release-Struktur orientiert haben. Anleitungen zum Onboarding von Microservices, zur System-Governance und zur integrierten Sicherheit helfen den Teams.
Wenn Sie herausfinden möchten, wie sich die Microservices-Architektur auf Ihr Unternehmen auswirkt, setzen Sie sich mit uns in Verbindung. Sie müssen nicht bei Null anfangen, wenn Sie den B2B Accelerator+ mit vorgefertigten Anwendungsfällen und Standardfunktionen als Microservices und einem Kubernetes-Beschleuniger nutzen, um schneller auf den Markt zu kommen.
