Kurz und letzten Blogkamen wir zu dem Schluss, dass Conways Gesetz sich durchsetzen wird und dass Microservices in einer Welt von Enterprise DevOps unverzichtbar sind. Das bedeutet, dass jeder, der es mit DevOps ernst meint, lernen sollte, wie man Microservices definiert, wie man sie verwaltet, wie man den Nutzen maximiert und wie man die Probleme minimiert. Es ist wichtig zu wissen, wie man ideale Microservices für verschiedene Technologien und verschiedene Anwendungsfälle entwirft. Dieser Blog gibt einen Überblick darüber, wie Microservices das Geschäft optimal unterstützen.

Was ist eine Microservices-Architektur?

James Lewis und Martin Fowler geben uns die beste Definition von Microservices-Architekturen:

Der Microservices-Architekturstil bietet einen Ansatz zum Erstellen größerer Anwendungen als Suite kleinerer Dienste (= IT-Komponenten oder Apps), wobei jeder Dienst:

• Basiert auf einer Geschäftsfähigkeit
• Führt seinen eigenen Prozess aus
• Kommuniziert über einen leichten Mechanismus und
• Kann selbstständig durch automatisierte Bereitstellungsmaschinen bereitgestellt werden

Letztendlich sollten Microservices die geschäftliche Flexibilität fördern. Dies wird erreicht, wenn neue Funktionsanforderungen mit maximaler Wahrscheinlichkeit nur einen einzigen Microservice beeinträchtigen, sodass ein DevOps-Team das Problem schnell beheben, mithilfe der Automatisierung schnell erneut testen und den Microservice erneut bereitstellen kann.

Was sind funktionale Microservices?

Da die meisten Funktionsanfragen von Endbenutzern kommen, sind die meisten Microservices funktionsorientiert. Funktionsanfragen beinhalten in der Regel Änderungen an GUI, Logik, Workflow und Daten. Daher minimiert das Entwerfen von Microservices, die alle diese Teile in derselben Bereitstellungsumgebung enthalten, die Auswirkungen von Änderungen.

Das Design wird weit mehr als nur technische Überlegungen beinhalten. Wir haben gesehen, dass der Geschäftsprozess in der Regel die beste Grundlage für die Aufteilung eines Funktionsumfangs in gute Microservices ist. Dies wiederum bedeutet, dass Sie Geschäftsinhaber und Prozessarchitekten in die Definition der Architektur einbeziehen sollten.

Brauchen wir noch technische Microservices?

Einige Microservices sind eher technisch ausgerichtet und über klare und stabile Request-Reply-Schnittstellen aufrufbar. Wenn eine Funktion für viele Zwecke gleich sein soll und sich nicht sehr oft ändert, kann sie in einen separaten, eher „technischen“ Microservice aufgeteilt werden.

Andere Microservices können integrationsorientiert sein und andere Services orchestrieren oder für die Konnektivität mit einem anderen großen System und/oder externen Anbieter verantwortlich sein. Ein zentraler ESB wird häufig durch verteilte spezialisierte Microservices ersetzt, die ihre eigenen Geschäftsdaten speichern können, wenn dies den Service effizienter macht.

Unternehmen sollten offen dafür sein, was ein Microservice leisten kann und soll. Die beste Microservice-Architektur für einen Geschäftsbereich ist nicht immer ideal für einen anderen Bereich. Dies steht im Einklang mit DevOps, wo wir Designentscheidungen meist auf Teamebene delegieren.

Es ist wichtig, nicht zu viel wiederzuverwenden oder zu denken, dass dies SOA Version 2.0 ist. Wir werden in Kürze in einem separaten Blog näher auf dieses wichtige Thema eingehen.

Welchen Einfluss hat die Größe einer Komponente auf die Geschäftsagilität?

Bei Microservices sagen die meisten, dass ein DevOps-Team aus ein bis zehn Personen etwa ein bis fünf Microservices besitzen, erstellen, betreiben und verwalten sollte. Die Größe ist beim Entwurf von Microservices relativ flexibel.

Bei kleinen bis relativ großen Aufgaben ist es nicht notwendig, die Dinge in kleinere Teile aufzuteilen, als das Unternehmen es verlangt. Beispielsweise können die Teams und die Architektur an den Geschäftsfunktionen ausgerichtet werden, die sie unterstützen. So wird maximale Autonomie erreicht, um sich problemlos weiterzuentwickeln und Wert zu schaffen.

Wenn der Umfang des „Systems“ jedoch sehr groß ist, ist es immer besser, die Funktionalität in separate Microservices aufzuteilen. Die internen und externen Abhängigkeiten wachsen, wenn jahrelange zeitkritische Korrekturen und Abkürzungen unerwünschte Abhängigkeiten erzeugen. Es ist schwierig, das System zu ändern, umfangreiche Regressionstests für jede Version und Bereitstellungen sind kostspielig und riskant.

Abbildung 2: In einer monolithischen Architektur kämpfen die Benutzergruppen um Aufmerksamkeit und die Entwickler treten sich gegenseitig auf die Füße.

Die ideale Größe eines Microservice hängt von der Anzahl der Entwickler ab. Das bedeutet, dass HPA-Plattformen gegenüber Open Source im Vorteil sind, da sie später aufgeteilt werden können, größere Microservices haben oder über kleinere Teams verfügen.

Was ist kein Frontalunterricht. ein Microservice?

Nachdem wir eine flexible Sicht auf Microservices gefördert haben, ist es sinnvoll, sie mit dem zu vergleichen, was kein Frontalunterricht. ein Microservice:

• Monolithen sind keine Microservices, da sie zu groß sind. Sie erfordern Entwicklungsteams mit mehr als 10 Personen und haben (normalerweise) viele funktional getrennte Prozesse im selben Deployment. Dies erfordert mehr Regressionstests und längere Release-Zyklen. Abhängigkeiten wachsen mit der Größe und im Laufe der Zeit und sind nicht explizit über Serviceaufrufe verfügbar, wie dies bei Microservices-Architekturen der Fall ist.
• Mehrschichtige SOA-Architekturen, bei denen die Geschäftsdaten unterhalb des ESB liegen, sind ebenfalls keine Microservices. Sie enthalten nicht die erforderlichen Daten und Funktionen für eine Geschäftsfunktion im selben Deployment. Stattdessen erstreckt sich fast jede Geschäftsfunktion über mehrere technisch ausgerichtete „Schichten“ gemeinsamer Deployment-Einheiten. Laut NGINX: „SOA basiert auf dem Konzept eines Architekturstils, bei dem so viel wie möglich geteilt wird, während Microservices auf dem Konzept eines Architekturstils basieren, bei dem so wenig wie möglich geteilt wird.“ Microservices sollten autonom sein und eine Geschäftsfunktion erfüllen, daher verfügen sie über eine GUI, Logik, einen Workflow und eine Datenbank, um Dinge bei Bedarf zu speichern.

Abbildung 4: Microservices fördern eine bessere Flexibilität und Zusammenarbeit zwischen Unternehmen und IT als die anderen Muster.

Unsere Sicht: Gemeinsame Merkmale für Microservices

Microservices erfüllen eine Geschäftsfunktion und kommunizieren im Rahmen des regulären Geschäftsprozesses miteinander, wodurch sie für Laien leichter verständlich sind. Dies ist eine gute Sache für DevOps und Teamentscheidungen. Aus unserer Sicht sollten gute Microservices die folgenden gemeinsamen Merkmale aufweisen:

1. Prozessorientiert

Funktionale Microservices implementieren in der Regel eine Phase des Geschäftsprozesses oder eine vollständige Geschäftsfunktion. Der Name „Service“ ist irreführend. Der Microservice kann ein aufrufbarer Dienst sein, aber auch eine App, die sich auf die Endbenutzerfunktionalität konzentriert.

2. Autonom und flexibel

Microservices sollten separat entwickelt und bereitgestellt werden und ihre eigenen Daten enthalten. Sie sollten sich mit der Zeit weiterentwickeln und leicht zu ändern und neu bereitzustellen sein.

3. Automatisierung und Steuerung

Microservices sollten über eine gute Test- und Bereitstellungsautomatisierung, Fehlerbehandlung, Überwachung und Warnfunktionen verfügen und Feedback von Benutzern ermöglichen.

4. Die richtige Größe

„Micro“ ist auch etwas irreführend, Microservices sollten weder zu klein noch zu groß sein. Der Service kann mit bis zu 10 Entwicklern relativ groß sein. Er ist kleiner als ein Monolith, muss aber nicht kleiner sein als eine normale App. Wenn Sie eine hochproduktive Plattform wie Mendix, ein Microservice kann beinahe schon das Kernsystem eines mittelständischen Unternehmens sein.

Was bedeuten Microservices für Sie?

Richtig eingesetzte Microservices fördern die Abstimmung zwischen Unternehmen und IT und verbessern die Flexibilität der Betriebsabläufe. Mit früheren Paradigmen war es sehr schwierig, Geschäftsprozesse zu ändern, sodass die Digitalisierung für die meisten etablierten Unternehmen sehr schwierig war. DevOps- und Microservices-Architekturen lösen dieses Problem, indem sie Entscheidungen und Entwicklung lokalisieren: Das DevOps-Team arbeitet direkt mit dem Unternehmen zusammen und kann Entscheidungen autonom treffen. Die Microservices werden separat und mit minimalen Abhängigkeiten entwickelt und separat als autonome Einheiten bereitgestellt.

Mendix bietet Vor-Ort-Workshops und Schulungen zu Microservices an. Wir haben einer großen Anzahl von Kunden bei neuen Programmen und Initiativen geholfen, Unterstützung bei der Entscheidungsfindung geleistet und die optimale Lösung für jedes Geschäftsproblem erarbeitet. Kontaktieren Sie uns für weitere Informationen.