So implementieren Sie Ihr Microservices-Projekt (Teil 3)
In dieser 6-teiligen Serie zur Entwicklung von Microservice-Anwendungen bieten wir einen Kontext für die Definition eines Cloud-basierten Pilotprojekts, das den aktuellen Bedürfnissen am besten entspricht und auf eine längerfristige Entscheidung zur Cloud-Einführung vorbereitet.
Hier in Teil 3: Wir bieten eine Methode zur Implementierung Ihrer eigenen Microservice-Projekte.
Weiterentwicklung einer bestehenden Anwendung
Jetzt gehen wir näher darauf ein, wie man einen Kurs für eine bestimmte Microservice-Anwendungs-Entwicklung in unterschiedlichem Umfang und mit Blick auf einen möglichen Übergang von kleineren zu größeren Transformationen von Anwendungen festlegen kann.
Obwohl der Aufbau von Microservice-Projekten ohne vorherige Anwendung relevant oder wichtig ist, einigen wir uns bei der Erstellung von Microservices auf einen „Monolith First“-Ansatz. Kurz gesagt bedeutet dies, dass Sie Ihre Anwendung auf jede erdenkliche Weise erstellen, um Ihre Idee zunächst zu validieren. Anschließend wenden Sie die Prinzipien in dieser Blogreihe an, um Ihren anfänglichen Monolithen zu skalieren und zu einem Microservice-Projekt weiterzuentwickeln. Es hat keinen Sinn, architektonisch reine Microservices zu erstellen, die dem Unternehmen keinen Mehrwert bieten.
Es gibt drei Bereiche, die Sie verstehen müssen, um ein erfolgreiches Microservice-Projekt zu implementieren: Ihr Unternehmen, Ihre Kultur und Ihre Fähigkeiten sowie Ihre Technologie.
Geschäftsanforderungen verstehen und definieren
Warum denken Sie über einen Umstieg auf Microservice nach? Viele Unternehmen benötigen effizientere Softwareentwicklungs- und Betriebspraktiken, um schneller einen Mehrwert für das Unternehmen zu schaffen und eine bessere Benutzererfahrung zu schaffen.
Bevor Sie die Auswirkungen eines Microservices-Projekts auf Ihre vorhandenen Anwendungen und Infrastrukturen verstehen können, müssen Sie verstehen, welche Teile Ihres Unternehmens zu langsam vorankommen, um zufriedenstellende Ergebnisse zu erzielen. In vielen Fällen sind die Engagement-Systeme (SOE) des Unternehmens die Ursache für die Verlangsamung. Diese Systeme sind über viele Kanäle verfügbar – Web, mobil, APIs und dergleichen. Mangelnde Geschwindigkeit ist der Hauptgrund für die Umstellung auf eine Microservice-Architektur.
Bevor Sie einen Microservice-orientierten Ansatz verfolgen können, müssen Sie und Ihre Geschäftsbeteiligten wissen, was nicht schnell genug auf den Markt kommt. Welche Teile der Anwendung müssen verbessert und geändert werden, um sie schneller zu machen? Die Beantwortung dieser Frage beinhaltet, welche Teile des bestehenden Monolithen für die Weiterentwicklung von Microservice ins Visier genommen werden sollten.
Verwenden Sie Erfahrungsabläufe oder Architekturdiagramme, um dem Team zu helfen, Teile des bestehenden Monolithen anhand von Anmerkungen im Heatmap-Stil schnell herauszuarbeiten. Hier ist ein Webanwendungsarchiv für eine Storefront, das beispielsweise die Rot-Gelb-Grün-Skala für die Priorität von Schmerzpunkten verwendet:
Zum jetzigen Zeitpunkt, ohne Anspruch auf Vollständigkeit und in der Bereitschaft zu iterativen Anpassungen, sind die Hauptziele der Bewertung:
Identifizierung der einzelnen Geschäftsfunktionen, die Ihr Monolith bietet
Verständnis der relativen Geschwindigkeit und Komplexität, die erforderlich ist, um diese Geschäftsfunktionen zu ändern
Verständnis des Wunsches des Geschäftsinhabers nach schnelleren Feedbackzyklen für diese spezifischen Geschäftsfunktionen
Verständnis Ihrer Unternehmenskultur und Ihrer Fähigkeiten
Obwohl dies nicht spezifisch für Microservice-basierte Architekturen gilt, ist ein gründliches Verständnis der Teams, der Kultur und der Kompetenzen einer Organisation kritisch für eine erfolgreiche digitale Transformation.
Typischerweise sind die meisten Unternehmen in technischen Monolithen in Silos aufgebaut, in denen Teams je nach Bedarf am Lebenszyklus der Softwareentwicklung teilnehmen. Dadurch entstehen oft klar definierte Grenzen mit restriktiven Rollen und Verantwortlichkeiten entlang dieser Grenzen.
Microservices-Architekturen können nur dann erfolgreich sein, wenn Teams den gesamten Lebenszyklus der Softwareentwicklung und des Softwarebetriebs zu verantworten können. Der Aufbau funktionsübergreifender Teams, die alle Rollen und Verantwortlichkeiten repräsentieren, ist bei der Implementierung von Microservice-basierten Architekturen von grundlegender Bedeutung. Alle – vom Design über die Entwicklung und den Betrieb bis hin zum Firmeninhaber – arbeiten eng zusammen und sind oft am selben Standort.
Da alle Stakeholder in den Bereichen Design, Entwicklung und Betrieb im Team vertreten sind, kann die Arbeit schneller, effizienter und mit klarem Fokus auf die Verbesserung der Erfahrung zur Erreichung der Geschäftsziele voranschreiten.
Ein funktionsübergreifendes Team unterstützt auch die schnelle Entwicklung individueller Fähigkeiten im gesamten Team. Wenn ein Team alles besitzt, wofür der Microservice verantwortlich ist, alles vom Design über den Betrieb bis hin zu den Laufzeitdaten, führt kein einzelnes Teammitglied auch nur eine einzige Aufgabe aus. Oft entwickeln Front-End-Ingenieure Fähigkeiten zur Datenbankverwaltung, während operative Teammitglieder mehr über die Unterschiede bei den Frameworks der Benutzeroberflächen erfahren. Diese Erweiterung der Fähigkeiten hilft der gesamten IT-Unternehmen, mit Microservice erfolgreich zu sein, da es viel einfacher ist, neue Teams von vielseitigen Teammitgliedern aufzubauen, anstatt ständig nach Spezialisten zu suchen, die ganz bestimmte Rollen besetzen.
Verstehen der Technologie
Wenn Sie sich nicht mit dem Geschäftsproblem und der Kultur und den Fähigkeiten Ihres Teams auseinandersetzen, werden Sie nicht in der Lage sein, die Microservice-Technologie effektiv umzusetzen, und Sie werden die gleichen Prozesse und Strukturen beibehalten.
Die richtige Analyse der vorhandenen Technologie-Stacks variiert stark von Unternehmen zu Unternehmen, aber der vereinfachte Ansatz, den wir beschreiben, hilft dabei, sowohl den anfänglichen als auch den nachhaltigen Erfolg Ihrer Microservice-Projekte sicherzustellen. Klein anzufangen und iterative, schrittweise Erfolge zu definieren, ist ein weitaus erreichbarerer und fruchtbarerer Ansatz als einer, bei dem alles auf einmal umgestaltet werden soll.
Die erste Phase zum Verständnis Ihrer Technologie besteht darin, die grobkörnigen Dienste zu identifizieren, die im bestehenden Monolithen enthalten sind. Die Identifizierung dieser grobkörnigen Dienste hilft Ihnen, die Komplexität der Datenstrukturen, den Grad der Kopplung zwischen den aktuellen Komponenten, die Teams, die für diese neuen grobkörnigen Dienste verantwortlich sind, usw. zu verstehen. Eine erfolgreiche Überprüfung von grobgranularen Diensten gibt Ihnen ein klares Verständnis der Datengrenzen, sowohl innerhalb eines bestimmten Dienstes als auch dienstübergreifend.
Nachdem Sie die grobgranularen Dienste identifiziert haben, müssen Sie einen Plan erstellen, wie diese grobkörnigen Dienste zu feingranularen Microservices weiterentwickelt werden sollen. Diese Microservices, basierend auf Ihrer früheren Arbeit, sollten alle mit ähnlichen Daten arbeiten, ihre „eigenen“ Daten besitzen und wissen, welche Daten sie von wo lesen und an andere Dienste schreiben müssen. Von hier aus können Sie die Resilienz, die Skalierbarkeit und die Agilität der einzelnen fein abgestuften Microservices identifizieren und implementieren.
APIs und Microservices sind zwei Teile des großen Ganzen. Sobald Sie Ihre feingranularen Microservices besser verstehen, werden Sie auch Ihre Schnittstellen besser verstehen, welche Schnittstellen sich auf dem kritischen Pfad befinden, welche Schnittstellen optional sind und welche Schnittstellen Sie nicht mehr benötigen. Wenn Sie eine vorhandene Schnittstelle oder API nicht auf einen Ihrer grob- oder feingranularen Microservice abbilden können, können Sie sie höchstwahrscheinlich abschaffen.
Dimensionierung des Microservice-Aufwands
Die schwierige Aufgabe, das Geschäft, die Teamstruktur und die Technologie zu verstehen, stellt sicher, dass Ihre Teams und Ihr größeres Unternehmen darauf vorbereitet sind, die gesamte Microservice-Entwicklung eines bestimmten Monolithen zu verstehen – sei es im Rahmen eines Proof-of-Concept, Pilotprojekt oder eine groß angelegte Entwicklungsmaßnahme sein.
Nachdem alle Analyse- und Planungsarbeiten abgeschlossen sind, besteht der nächste Schritt darin, Zeitpläne, Liefergeschwindigkeiten und Ergebnisse zu definieren.
Im nächsten Beitrag werden wir Entwicklungs- und Betriebsmuster betrachten, die Sie bei der Durchführung einer Microservice-Transformation anwenden können.
Die nächsten Schritte:
Für die Modernisierung und das Refactoring einer monolithischen Anwendung besuchen Sie die eine detaillierte Architektur-Progression.
Roland Barcia (IBM Distinguished Engineer/CTO) und Rick Osowski (Senior Technical Staff Member) haben mit Kyle an diesem Beitrag zusammengearbeitet.