Microservice-Architektur-Beratung
Schnellere Feature-Entwicklung mit einer Service-Architektur
Warum Microservice-Architekturen sinnvoll sind
Die Microservices-Architektur ist eine Software-Designentscheidung. Sie strukturiert eine Anwendung in eine Sammlung granularer Microservices, die jeweils für bestimmte Teile der Anwendung zuständig sind. Viele digital ausgerichtete Unternehmen haben sich für eine Microservices-Architektur entschieden, da sie ihnen mehr Freiheit und Leistung bei der Softwareentwicklung bietet: Freiheit, Entscheidungen zu treffen, auf notwendige Änderungen zu reagieren oder neue Technologien einzuführen und zu nutzen. Die potentielle Leistungsfähigkeit einer Anwendung wird verstärkt, da es möglich wird, dem Kunden schneller einen Mehrwert zu bieten.
Microservices und ihre wichtigsten Vorteile
Um eine Microservices-Architektur aufzubauen, muss man zunächst einmal Microservices haben. Aber was sind Microservices? Im Wesentlichen sind Microservices kleine, autonome Softwareanwendungen, die darauf ausgelegt, eine spezifische Aufgabe besonders gut zu meistern. Aus Sicht der Softwareentwicklung sind sie nichts Besonderes. Es ist die Denkweise, die Microservices definiert - und den daraus resultierenden Fokus, Umfang und die Eigenschaften bedingt.
Das Denken in Microservices bekämpft die Herausforderungen und Probleme, die viele Unternehmen bei der Entwicklung monolithischer Anwendungen haben. Selbst bei guten Entwicklungspraktiken kann es bei großen monolithischen Codebasen äußerst schwierig sein, die Weiterentwicklung aktiv voranzutreiben, neue Funktionen einzubauen und sich an Änderungen anzupassen. Wo müssen neue Funktionen implementiert werden? Gibt es bereits ähnliche Funktionen? Welche Teile der Anwendung sind gekoppelt und müssen geändert werden? Die Entwicklung wird zunehmend schwieriger und komplexer, so dass große monolithische Anwendungen stagnieren oder sogar in ihrem Fortschritt einfrieren.
Microservices sind kleine, unabhängige Dienste, deren Servicegrenzen sich an den Unternehmensgrenzen orientieren. Diese expliziten Grenzen verhindern, dass sie über ihren Rahmen hinauswachsen. Microservices sind eigenständige Dienste, die als unabhängige Einheiten betrachtet werden können. Sie können unabhängig voneinander entwickelt und eingesetzt werden. Daraus ergeben sich viele und vielfältige Vorteile, die ihre Grundlage in verteilten Systemen haben. Zu den wichtigsten Vorteilen gehören:
Die Vorteile
Heterogenität
Jeder Microservice kann potenziell eine andere Technologie nutzen. So ist es möglich, für jede Aufgabe das richtige Werkzeug auszuwählen, Technologien schneller zu übernehmen oder auszuprobieren oder Dienste nach Bedarf zu optimieren.
Resilienz
Leistungsprobleme können leichter erkannt und behoben werden, Fehler werden besser isoliert und das Risiko von Anwendungsausfällen wird reduziert.
Skalierbarkeit
Die Dienste können unabhängig voneinander skaliert werden. Damit lässt es sich besser auf Änderungen der Nachfrage, in bestimmten Bereichen deiner Anwendung, reagieren.
Produktivität
Microservices sind auf eine bestimmte Aufgabe innerhalb der Anwendung ausgerichtet. Das macht es für Entwickler einfacher, sich mit den Diensten vertraut zu machen, sie schneller zu verstehen und Änderungen am Code durchzuführen. Außerdem können die Aufgaben unter den Entwicklungsteams aufgeteilt werden. Damit wird die Zeit wesentlich verkürzt, in der Änderungen, neue Funktionen oder Bugfixes, die Kunden erreichen.
Wie startet man mit Microservices?
Jetzt haben wir die Vorteile von Microservices verstanden und möchten gerne loslegen. Aber wie strukturieren wir Softwareanwendungen in kleine, autonome Dienste? Was müssen wir dabei beachten? Zwei Schlüsselaspekte, die einen guten Microservice ausmachen, sind lose Kopplung und hoher Zusammenhalt - zwei Aspekte, die eng mit der Gesamtarchitektur zusammenhängen, die wir anstreben.
Lose Kopplung & hohe Kohäsion (Zusammenhalt)
Lose Kopplung bedeutet, dass Änderungen innerhalb eines Dienstes nicht dazu führen, dass auch andere Dienste geändert werden müssen. Daher sollte ein Dienst so wenig wie möglich über die Dienste wissen, mit denen er kommuniziert, oder nur so viel wie nötig. Wir wollen keine geschwätzige Kommunikation zwischen Diensten, da dies ihre Kopplung erhöht.
Eine hohe Kohäsion ermöglicht es uns, ein Verhalten innerhalb genau eines Dienstes zu bündeln. Geändertes Anwendungsverhalten sollte zu Änderungen in genau einem Microservice führen. Wir wollen nicht gezwungen sein, mehr als einen Dienst auf einmal anzupassen, um Änderungen im Anwendungsverhalten zu erreichen.
Begrenzung der Dienste
Um eine lose Kopplung und eine hohe Kohäsion zu erreichen, ist es wichtig, die Begrenzung für Dienste richtig zu setzen. Leichter gesagt als getan. Die Begrenzungen hängen von der Gesamtstruktur, dem Angebot an Diensten und dem Ziel der Organisation ab. Die Grenzen eines Microservice müssen bestehende Dienste respektieren und berücksichtigen. Außerdem werden sich die Grenzen verschieben, Dienste werden ersetzt, aufgeteilt oder ganz entfernt. Veränderungen sind unvermeidlich. Nicht jede Microservice-Grenze wird sich als perfekt erweisen. Mit Microservices hast du jedoch die Flexibilität, zu reagieren und dich anzupassen. Wir unterstützen dich gern mit unserem Wissen und unserer Erfahrung beim Einstieg in Microservices.
Vom Microservice zur Microservices-Architektur
Du verstehst, ein einzelner Microservice macht noch keine Architektur aus und ist isoliert ohnehin nicht sehr nützlich. Nachdem du einen Microservice erstellt hast, musst du ihn in eine bestehende Architektur integrieren, um ihn zu nutzen. Der Begriff Microservices-Architektur bezieht sich daher auf eine Systemarchitektur, die aus vielen integrierten Microservices besteht.
Die richtige Integration von Microservices ist ein wichtiger Punkt, dem besondere Aufmerksamkeit gewidmet werden sollte. Es ist wichtig, die Autonomie und Unabhängigkeit zwischen den Diensten zu ermöglichen. Falsch umgesetzt, kann sie die Vorteile von Microservices im Kern zunichte machen und sie unflexibel und gekoppelt machen. Es gibt verschiedene Technologien, die für die Integration verwendet werden können, wie REST, GraphQL, Protocol Buffers und mehr. Die Wahl der besten Technologie hängt jedoch von der Gesamtarchitektur und der Anwendung ab.
Generell ist es ratsam, die für die Integration verwendeten (APIs technologieunabhängig zu halten, Änderungen zu vermeiden, sie für die Nutzer/innen einfach zu gestalten und interne Implementierungsdetails zu verbergen. Außerdem sollte eine gemeinsame Datenbank vermieden werden und die Kommunikation sollte vorzugsweise choreografiert statt orchestriert werden.
Einen Monolithen aufspalten
Auch wenn Unternehmen die Vorteile von Microservices-Architekturen erkannt haben, kann die Entscheidung zur Umsetzung schwer fallen. Die Klärung der folgenden Fragen kann zum zögern führen:
- Was sollen wir mit unserem aktuellen Monolithen machen?
- Müssen wir alles von Grund auf neu implementieren?
- Wo sollen wir anfangen?
Das sind alles berechtigte Fragen und die Antwort hängt stark von der Struktur und den technischen Fähigkeiten des Unternehmens ab. Wenn du ohne Vorkenntnisse oder Erfahrung mit der Einführung von Microservices in einem Unternehmen beginnst, ist es ratsam, Schritt für Schritt vorzugehen. Du musst die aktuelle monolithische Architektur analysieren und, wie oben beschrieben, potenzielle Grenzen für die Dienste identifizieren, die deine Codebasis in unabhängige, entkoppelte Teile aufteilen.
Nachdem du potenzielle Microservices definiert hast, solltest du einen Schritt zurückgehen und dich fragen: Welchen Nutzen will ich aus der Aufspaltung des Monolithen ziehen? Sicherlich sollte niemand einen funktionierenden Monolithen ohne Grund aufspalten.
Identifiziere und antizipiere potenzielle Dienste, die sich in naher Zukunft voraussichtlich ändern werden. Teile die Verantwortung für die Dienste entsprechend deiner Teamstruktur auf. Berücksichtige sicherheitskritische Aspekte oder technologische Überlegungen. Es ist wichtig, die oben genannten Hauptvorteile von Microservices auf potenzielle Dienste zu übertragen. Was willst du erreichen? Durch die Beantwortung dieser Frage sollte der zukünftige Nutzen einer Abspaltung des identifizierten Microservices vom Monolithen klar werden!
Beginne mit dem Microservice, der in Bezug auf Wert und Komplexität am sinnvollsten ist. Sammle Erfahrungen und trenne/ersetze deinen bestehenden Monolithen Schritt für Schritt.
Bereitstellung, Testing, Überwachung und Sicherheit
Der Umgang mit der Bereitstellung, dem Testen, der Überwachung und der Sicherheit von Microservices innerhalb einer Microservices-Architektur kann sehr komplex und einschüchternd wirken. Anstelle einer einzigen Softwareanwendung müssen nun viele verschiedene Microservices unabhängig voneinander verwaltet werden. Auch wenn es bestimmte Aspekte gibt, die spezifisch für Microservices sind, kann der Gesamtansatz weitgehend von der Softwareentwicklung im Allgemeinen übernommen werden.
Um die steigende Anzahl von Diensten zu bewältigen, ist es jedoch sehr ratsam, separate Repositories vor dem Microservice anzulegen und den gesamten Prozess so weit wie möglich zu automatisieren - am besten vollständig. Jeder Microservice sollte über eine funktionierende und gut geplante Continuous Integration and Continuous Delivery (CICD) Pipeline verfügen. Automatisierung ist dein Freund. Automatisiere alles!
Cloud-native projects
Das Aufsetzen unserer Kundenprojekte nach dem Cloud-Native-Ansatz hilft uns dabei, komplexe Systeme schnell und effizient zu entwickeln und kurze, effiziente Release-Zyklen umzusetzen. Die folgenden Projekte sind ein kleiner Auszug aus unseren vergangenen Cloud-Native-Projekten.
Fondsfinanz - Automation Hub
Django CMS | Redis | Bootstrap | VueJS | Docker | KubernetesInfrastruktur für automatisiertes Seminar- und Webinar-Management. Inklusive Einwilligungsmanagement, Anbindung an bestehende Systeme und Schnittstellen zu externen Anwendungen wie Go2Webinar.
Neubau der Website mit Service-Architektur
Django | Python | Kubernetes | Docker | GKEWichtige Komponenten der Website wurden als individuelle Dienste entwickelt die in einer Service-Architektur miteinander vernetzt sind. Die komplette Infrastruktur wurde auf Kubernetes und GKE aufgesetzt.
UNSER KUBERNETES-PODCAST (EN)
TftC - E2: Remote Kubernetes development environments
In der zweiten Ausgabe unseres Podcasts "Tools for the Craft: Navigating the Kubernetes ecosystem" beschäftigen sich Michael und Robert mit den verschiedenen Optionen für Remote Kubernetes Entwicklung und zeigen einige Beispiele aus der Praxis.
Weitere Ausgaben unseres Podcasts findest du hier:
ADRESSE
