Umstellung auf Microservices: Es ist schwieriger als Sie denken

Okt 25, 2021

Alle versuchen es. Viele scheitern.
Wie Sie Ihre Chancen erhöhen können.

Seit Martin Fowler im Jahr 2014 die Konzepte von Microservices beschrieben hat, wächst die Akzeptanz von Microservices in großen und kleinen Unternehmen. Die Prozessautomatisierung Plattform Camunda schätzte 2018, dass 63% der Unternehmen Microservices nutzen und weitere 28% die Migration einiger Anwendungen auf Microservices in Erwägung ziehen.

Trotz des Enthusiasmus rund um Microservices hat das O’Reilly-Radar ergeben, dass nur 10% der Leser von einem vollständigen Erfolg bei der Einführung von Microservices berichten. Tatsächlich berichten 45 %, dass sie nicht den vollen Nutzen aus Microservices-Architekturen ziehen konnten, sondern nur „etwas Erfolg“ hatten, während 8% sogar einen völligen Misserfolg zugaben! Angesichts der zunehmenden Zahl von Blogs über Unternehmen, die den umgekehrten Weg von Microservices zurück zu Monolithen einschlagen, ist es kein Wunder, dass Gartner Microservices in diesem Jahr auf den letzten Platz der Desillusionierung gesetzt hat.

Kurz gesagt, wenn Unternehmen massenhaft Microservices einführen, scheitern viele auch daran. Dies ist ein Realitätscheck für Unternehmen, die ihre digitale Transformation vorantreiben wollen. Diese Unternehmen sind nicht inkompetent – die meisten haben große Architekturübergänge erfolgreich gemeistert, von zentralisierten Großrechnern über verteilte Kunden/Server bis hin zum Internet und der Cloud. Der nächste Übergang, Cloud Native, ist jedoch schwierig – und zwar von Natur aus.

Die gute Nachricht ist, dass erfolgreiche Pioniere in den letzten zehn Jahren klare bewährte Cloud-Native-Praktiken entwickelt haben, die das Risiko eines Scheiterns erheblich verringern. Tipp: Digitale Führungskräfte verlassen sich auf eine DevOps Value Stream Delivery Platform (DevOps VSDP) für die Routinearbeit. Hey, es ist immer noch schwer. Aber man kann es sich leichter machen.

Was macht Cloud Native besonders schwierig? Wie kann man die Vorteile von Cloud Native nutzen und gleichzeitig die Nachteile minimieren? Im Folgenden informieren wir Sie über die Komplexität von Cloud-Native-Architekturen, die für Misserfolge verantwortlichen Anti-Patterns und die bewährten Praktiken von Digital Leaders.

Inhaltsverzeichnis

Es geht um das Geschäft, Dummkopf!

„Die Wirtschaft ist schuld, Dummkopf!“. Dieser Satz wird James Carville zugeschrieben, einem Strategen in Bill Clintons Präsidentschaftswahlkampf 1992. Er sollte eine von drei Botschaften sein, auf die sich die Wahlkampfmitarbeiter bei ihrer Kommunikation nach außen konzentrieren sollten. Die stärkere Fokussierung würde wiederum die Erfolgsaussichten der Kampagne erhöhen. Bei der Implementierung von Microservices-Architekturen verhält es sich nicht anders. Es gibt fünf Botschaften, die IT- und Unternehmensleiter bei der Umstellung auf Microservices im Auge behalten sollten:

  • Es geht um das Geschäft, Dummkopf!
  • Sie brauchen vielleicht keine Microservices
  • Microservices = komplexe verteilte Systeme
  • Hüten Sie sich vor Antipatterns
  • Folgen Sie den Führern

Gehen wir auf diese Botschaften nacheinander ein.

Erste Botschaft: Es geht um das Geschäft! Viele Unternehmen verstehen nicht, welche geschäftlichen Anforderungen mit Microservices-Architekturen erfüllt werden können. Es gibt mehrere. Lassen Sie uns die beiden erörtern, die für den Microservices-Ansatz von zentraler Bedeutung sind.

Die erste geschäftliche Notwendigkeit ist die flexible Softwarebereitstellung. Einerseits wird Software immer mehr zu einem zentralen Bestandteil von Produkten und Dienstleistungen. Das Internet und die Cloud haben neue digitale Dienste ermöglicht, die über neue digitale Kanäle vertrieben werden. Flinkere Wettbewerber haben sich diese Kanäle zunutze gemacht, um mit den etablierten Anbietern zu konkurrieren und innovative Dienste schneller bereitzustellen. Die Erwartungen der Kunden haben sich infolge dieser Trends geändert: Sie sind daran gewöhnt, dass ihnen maßgeschneiderte Produkte, Dienstleistungen und Funktionen dort angeboten werden, wo sie sie wünschen, über den Kanal ihrer Wahl und zu jeder Tageszeit. Das Fehlen oder Vorhandensein eines einzigen Merkmals kann dazu führen, dass sie zur Konkurrenz abwandern.

Um Kunden zu verstehen, Kundenbedürfnisse zu erkennen und neue digitale Dienste und Funktionen in einem komplexen, sich schnell verändernden Geschäftsumfeld bereitzustellen, müssen Unternehmen mehr denn je agil sein. Sie müssen schneller innovieren. Sie müssen schneller auf Veränderungen reagieren. Da Software in jedem Dienst enthalten ist, müssen sie Software viel schneller, häufiger und zuverlässiger bereitstellen.

Die zweite geschäftliche Notwendigkeit ist die Fähigkeit, die Leistung je nach Bedarf zu erhöhen oder zu verringern. Damit wird in erster Linie sichergestellt, dass die Kunden bei jeder Nachfrage eine zuverlässige Dienstqualität erhalten. Unter dem Gesichtspunkt der Dienstqualität ist die Skalierbarkeit die wichtigste Fähigkeit. Es gibt aber auch eine Kostendimension. Digitale Produkte und Dienste beruhen auf einer Infrastruktur. Diese Infrastruktur hat eine Kapazität und verursacht Kosten. Die Skalierung nach unten, um ungenutzte Kapazitäten an die Infrastrukturanbieter zurückzugeben, ist der Schlüssel, um die Kosten unter Kontrolle zu halten. Denken Sie daran, dass Sie nicht nur immer verfügbare stellare Dienste anbieten wollen. Sie wollen dies auch auf kostenoptimierte Weise tun.

Skalierung fördert sowohl die Qualität der Dienste als auch die Kosteneffizienz

Skalierung fördert sowohl die Qualität der Dienste als auch die Kosteneffizienz

Diese beiden geschäftlichen Anforderungen lassen sich direkt mit den wichtigsten architektonischen Faktoren für die Einführung von Microservices vergleichen. Bevor Microservices populär wurden, mussten sich Unternehmen mit Anwendungen begnügen, die aus einem einzigen bereitstellbaren Modul bestanden, das passenderweise als Monolith bezeichnet wird. Monolithische Anwendungen beginnen im Allgemeinen als kleine Anwendungen, die von einem kleinen Team von Entwicklern gepflegt werden. Diese Entwickler haben ein mentales Modell, das die gesamte Software umfasst; die Kommunikations- und Koordinationskosten sind gering, und die Entwicklungsgeschwindigkeit (z. B. die Zeit zum Hinzufügen einer neuen Funktion) ist hoch.

Diese Geschwindigkeit verlangsamt sich jedoch unweigerlich. Das Team wächst. Die Anwendung wächst und passt nicht mehr in den Kopf einer einzelnen Person. Die Kommunikations- und Koordinationskosten explodieren – zusammen mit den Softwarefehlern. Da Monolithen nun einmal monolithisch sind, erfordert jede neue Funktion einen Neuaufbau, ein erneutes Testen und eine erneute Bereitstellung des gesamten Artefakts – was zu weiteren Verlangsamungen, längeren Ausfallzeiten und einem höheren Risiko von Bereitstellungs Fehlern führt.

Robert C. Martin, einer der Unterzeichner des einflussreichen Agilen Manifests, empfahl modulare Architekturen, um die Geschwindigkeit zu erhöhen:

Diese Art von Flexibilität und Entkopplung macht Sie immer schneller. Wenn wir in den letzten fünfzig Jahren eines über die Kopplung gelernt haben, dann, dass nichts besser ist als eine Verlangsamung.

Nun, genau. Microservices-Architekturen sind entkoppelte, modulare Architekturen. Ein Microservice ist ein unabhängig einsetzbares Modul. Die Anwendungen sind als Microservices konzipiert, die zusammenarbeiten, um Geschäftsanforderungen zu erfüllen. Diese Microservices sind kleiner als der funktional gleichwertige Monolith und sollten so konzipiert sein, dass sie von einem einzigen, unabhängigen Team gewartet werden können. Ein Team, das für einen Microservice verantwortlich ist, sollte nur minimalen Koordinationsaufwand mit anderen Teams haben. Die Kommunikationskosten sind wieder überschaubar.

Microservices-Architekturen bieten also die Flexibilität, die Unternehmen benötigen, um im digitalen Zeitalter wettbewerbsfähig zu sein. Was ist mit dem anderen Bedürfnis der Unternehmen: Skalierbarkeit? Zunächst erleichtern Microservices die horizontale Skalierung. Denn Microservices sind klein(er) und unabhängig einsetzbar, Instanzen können schnell hinzugefügt – oder entfernt – werden.

Zweitens können Sie genau steuern, welche Teile Sie vergrößern oder verkleinern wollen. Bei einem Monolithen hingegen müssten Sie die gesamte Anwendung skalieren, auch wenn nur wenige Teile davon stark genutzt werden. Das ist nicht nur nicht kosteneffizient und verschwendet Ressourcen.

Die erste Option, die vertikale Skalierung, ist einfach genug, hat aber Obergrenzen, die von der Hardware diktiert werden (z. B. Speicher, CPU). Außerdem kann es bei großen Monolithen, die Hunderte von Funktionen enthalten, 20-40 Minuten dauern, bis sie neu gestartet sind, was die Ausfallzeiten des Dienstes erhöht. Die andere Option, die horizontale Skalierung, ist komplex – mit Load Balancern, Sitzungsreplikation, Datenbankreplikation und mehr – und leidet unter Kostenineffizienzen. Es sei denn, Ihr Monolith ist bereits modular aufgebaut und verfügt über gut gestaltete Grenzen zwischen lose gekoppelten internen Modulen – es sei denn, Sie sind architektonisch bereits sehr nah an Microservices dran.

Microservices bieten also die Flexibilität und kosteneffiziente Skalierbarkeit, die viele Unternehmen benötigen, dank ihrer unabhängigen Einsatzfähigkeit und feinkörnigen Skalierbarkeit. Warum scheitern dann so viele Unternehmen daran, die Vorteile von Microservices-Architekturen zu nutzen? Einige Unternehmen führen Microservices ein, obwohl ihre architektonischen Anforderungen durch andere Ansätze besser erfüllt werden. Sie stellen fest, dass sie Microservices von vornherein nicht gebraucht haben.

Andere Unternehmen entscheiden sich aus den richtigen geschäftlichen Gründen für Microservices. Einige von ihnen fallen jedoch entweder direkt in gängige Anti-Muster, die sie daran hindern, die erwarteten Geschäftsergebnisse zu erzielen. Andere erreichen in gewissem Maße die angestrebten Geschäftsergebnisse, scheitern aber daran, diese zu maximieren, weil sie die von den digitalen Führungskräften ermittelten bewährten Verfahren nicht übernehmen. Dies liegt zum Teil daran, dass sie die Komplexität verteilter Systeme nicht richtig einschätzen – und darauf reagieren.

Diese Realität ist in unseren letzten vier Botschaften enthalten. Weiter mit der nächsten!

Sie brauchen vielleicht keine Microservices

Anfang letzten Jahres kündigte Craig Box, Kubernetes/Istio Advocacy Lead bei Google, an, dass die Istio-Kontrollebene von Microservices zurück zu einer einzigen, monolithischen Binärdatei migriert (Hervorhebung durch uns):

Microservices sind ein großartiges Muster, wenn sie Dienste den verschiedenen Teams zuordnen, die sie bereitstellen, oder wenn der Wert eines unabhängigen Aufbaus und der Wert einer unabhängigen Skalierung größer sind als die Kosten der Orchestrierung. Wir sprechen regelmäßig mit Kunden und Teams, die Istio in der realen Welt einsetzen, und sie sagten uns, dass dies bei der Istio-Kontrollebene nicht der Fall ist. Daher haben wir in Istio 1.5 die Paketierung von Istio geändert und die Funktionalität der Steuerebene in einer einzigen Binärdatei namens istiod zusammengefasst.

In seinem Ankündigungspost erklärt Box weiter, dass die feinkörnige Skalierbarkeit und die unabhängige Bereitstellung von Microservices nicht den tatsächlichen Geschäftsanforderungen von Istio entsprachen:

Microservices ermöglichen es Ihnen, Komponenten unabhängig voneinander zu skalieren. In Istio 1.5 werden die Kosten der Steuerebene von einem einzigen Funktionsmerkmal dominiert […] Jedes andere Funktionsmerkmal hat marginale Kosten, was bedeutet, dass es sehr wenig Wert hat, diese Funktionen in separat skalierbaren Microservices zu haben.

Microservices ermöglichen es Ihnen, Versionen zu entkoppeln und verschiedene Komponenten zu unterschiedlichen Zeitpunkten freizugeben. Alle Komponenten der Steuerungsebene wurden immer in der gleichen Version und zur gleichen Zeit veröffentlicht. Wir haben den Betrieb verschiedener Versionen von (zum Beispiel) Citadel und Pilot nie getestet oder unterstützt.

Wie in einer entsprechenden IEEE-Publikation erläutert, verursachte die Architektur der Istio-Kontrollebene in Form von fünf unabhängig voneinander einsetzbaren Microservices einen Wartungs- und Leistungs-Overhead für typische Istio-Nutzer.

Botify, eine SEO-Plattform für Unternehmen, erzählt eine ähnliche Geschichte über den Wechsel zurück zu einem Monolithen. Sie brauchten die Skalierbarkeit, die durch Microservices erreicht wird, nicht. Tatsächlich verursachten die Microservices einen Leistungsverlust:

Die richtige Lösung für die richtigen Probleme: Es ist wichtig, sich an unsere Anwendungsfälle zu erinnern und daran, wem Botify dient […] Die Beantwortung von Metadaten für einige zehntausend Kunden in Millisekunden ist keine Aufgabe, die eine hoch skalierbare Microservice-Architektur erfordert. Ganz im Gegenteil, unsere Backend-zu-Backend-Kommunikation verlangsamte diese leichten Abrufprozesse und führte dazu, dass diese Anfragen mehr Zeit in Anspruch nahmen.

Lektion gelernt: Überlegen Sie genau, ob Ihr Unternehmen die Skalierbarkeit und Agilität von Microservices benötigt.

Prüfen Sie Ihre Geschäftsanforderungen anhand der Treiber der Microservices-Architektur

Auswahl von Microservices aus den richtigen Gründen / Implementierung von Best Practices

Microservices bilden ein verteiltes System, und Sie müssen die zusätzliche Komplexität, die damit einhergeht, verstehen und bewältigen. Das ist unsere dritte Botschaft. Lassen Sie uns das jetzt näher erläutern.

Microservices = komplexe verteilte Systeme!

Der Turing-Preisträger Fred Brooks erklärte in einem viel beachteten Aufsatz, dass es zwei Arten von Komplexität in der Softwareentwicklung gibt: wesentliche Komplexität und zufällige Komplexität. Wesentliche Komplexität ergibt sich aus dem Problem und lässt sich nur schwer reduzieren, ohne die Eigenschaften des Problems zu verändern. Wenn ein Programm X und dann Y tun muss, gibt es keine Möglichkeit, dies zu vereinfachen. Die zufällige Komplexität hingegen hat ihren Ursprung in der Lösung und kann durch bessere, optimierte Lösungen verbessert werden.

Die wesentliche Komplexität, die mit Microservices verbunden ist, besteht darin, dass sie ein dynamisches verteiltes System bilden. Was früher eine zusammenhängende große Anwendung (Monolith) war, kann jetzt aus 15 unabhängig voneinander einsetzbaren, lose gekoppelten, kleineren Microservices bestehen. Sie müssen nun gegen partielle Kommunikationsausfälle zwischen den Prozessen oder extrem hohe Latenzzeiten zwischen den Diensten programmieren.

Wenn Instanzen von Diensten dynamisch hoch- und runtergefahren werden, brauchen Sie entweder Standort Transparenz oder Erkennungsdienste. Sie müssen die Aufrufe zwischen den Microservices minimieren, um die Latenzzeit zu verringern, oder Sie erhalten eine weniger reaktionsschnelle Anwendung.

Sie müssen immer noch Transaktionen und Abfragen implementieren, die sich über mehrere Dienste erstrecken. Aber jetzt ist Ihre Datenbank über Microservices verteilt. Wie viel von ACID können Sie beibehalten, ohne die Leistung zu beeinträchtigen? Außerdem müssen Sie Ihre verteilte Anwendung gegen neue Arten von Bedrohungen absichern. Die Liste lässt sich fortsetzen. Und keiner der Punkte wird verschwinden.

Die unbeabsichtigte Komplexität ergibt sich aus den verschiedenen Lösungen, die wir anwenden, um die vorherigen Probleme zu lindern. Sollten Sie 15 Microservices haben oder 55 oder 7? Welche Verantwortlichkeiten weisen Sie jedem Microservice zu? Wie skaliert man sie? Wie testet und debuggt man ein verteiltes System? Wie werden Fehler erkannt und behoben? Wie stellen Sie sicher, dass es keine Ausfallzeiten gibt?

AWS hat heute über 200 Produkte in seinem Portfolio. Für Ihre 15 Microservices müssen Sie möglicherweise 20 weitere Tools von Anbietern erlernen, konfigurieren und bedienen, um Fehler, Skalierbarkeit, Bereitstellung und mehr zu verwalten. Die Rekrutierung, Fortbildung und Umschulung von Produktteams ist ein Problem, das von großen und kleinen Unternehmen immer wieder genannt wird.

Es geht nicht nur um die Technologien. Es sind auch die Muster. In der Tat sind es in erster Linie die Muster. AWS App Mesh ist Amazons Version des Service-Mesh-Musters. Aber zuerst müssen Sie Service Meshes verstehen. Warum gibt es sie überhaupt? Welches Problem lösen sie? Brauchen Sie sie für Ihren speziellen Anwendungsfall? Wie kann man sie konfigurieren und betreiben?

Sie müssen all dies tun und dabei die Gesamtkosten und die Qualität im Auge behalten. Die Bindung an einen bestimmten Anbieter (ein weiterer von Unternehmen geäußerter Schmerzpunkt) kann Ihre Fähigkeit zur Optimierung Ihrer Cloud-Ausgaben beeinträchtigen. Während Ihre unabhängigen Teams die Kosten lokal optimieren können, müssen Sie auch global optimieren (z. B. doppelte Arbeit vermeiden). Wir haben noch gar nicht darüber gesprochen, wie eine geordnete und für die Benutzer transparente Migration von einer Architektur zur anderen erfolgen kann.

Kurzum: Unterschätzen Sie nicht die Herausforderungen, die mit der Einführung von Microservices verbunden sind. Sie sind genauso real wie die Vorteile. Wenn Sie den einfachen Weg wählen, verfallen Sie in Anti-Muster, die eher Werte zerstören als Geschäftsergebnisse liefern.

Vorsicht vor Anti-Mustern

Die Softwarearchitekten Srini Penchikala und Marcio Esteves beschrieben vier Kategorien von Anti-Patterns, die Unternehmen unbedingt vermeiden müssen: Monolithische Hölle, Todesstern, Jenga-Turm und Quadratisches Rad. Es gibt noch weitere.

Um ein relativ häufig auftretendes Muster herauszugreifen: Das Muster des verteilten Monolithen (Teil der Familie der monolithischen Hölle) tritt auf, wenn eine monolithische Anwendung in mehrere Einzelinstanz Dienste aufgeteilt wird – die meisten Dienste bleiben jedoch eng gekoppelt.

Beispiel für mikrolithische Architektur

Verteiltes monolithisches Anti-Muster

Quelle: Reaktive Mikrosysteme – Entwicklung von Microservices in großem Maßstab, von Jonas Boner

Die vorherige Abbildung zeigt einen Monolithen, der in drei Mikrolithen zerlegt wurde. Um Jonas Boner, Geschäftsführer und Gründer der serverlosen und Cloud-Plattform Lightbend, zu zitieren:

Ein Mikrolith ist definiert als ein Dienst mit einer einzigen Instanz, bei dem synchrone Methodenaufrufe in synchrone REST-Aufrufe umgewandelt wurden und der blockierende Datenbankzugriff blockiert bleibt. Dadurch wird eine Architektur geschaffen, die die starke Kopplung beibehält, von der wir wegkommen wollten, jedoch mit einer höheren Latenz, die durch die Kommunikation zwischen den Prozessen (IPC) entsteht. Das Problem mit einer einzelnen Instanz ist, dass sie per Definition nicht skalierbar oder verfügbar ist. Ein einzelnes monolithisches Ding, was auch immer es sein mag (ein Mensch oder ein Softwareprozess), kann nicht skaliert werden und kann nicht verfügbar bleiben, wenn es ausfällt oder stirbt.

Mit anderen Worten, ein verteilter Monolith ist im Gegensatz zu einem Einzelprozess-Monolithen eine Anwendung, die auf mehrere Prozesse verteilt, aber wie ein Monolith aufgebaut ist. Sie können separate Teams haben, die kleinere Teile des Monolithen warten, aber die motivierenden architektonischen Faktoren, die wir zu Beginn dieses Artikels erwähnt haben, fehlen. Mikrolithische Systeme sind weder skalierbar noch widerstandsfähig. Oft muss das gesamte System gemeinsam bereitgestellt werden. Sie erhalten die Komplexität verteilter Systeme und die Nachteile von Monolithen – und haben im Gegenzug wenig vorzuweisen.

Wie machen es also die digitalen Führungskräfte? Was sind die besten Praktiken, um die Herausforderungen von Microservices-Architekturen zu meistern?

Folgen Sie den Anführern

Anstatt Ihren Monolithen in einem Zug zu migrieren, sollten Sie zunächst klein anfangen. Extrahieren Sie einen vernünftig kleinen Microservice aus Ihrem Monolithen. Das ist der Ratschlag, den Sam Newman, der Autor des Buches Monolith To Microservices, gibt:

Die Analogie, die ich bei der Einführung von Microservices immer versucht habe zu verwenden, ist, dass es nicht so ist, als würde man einen Schalter umlegen. Es ist nicht aus oder an. Es ist viel mehr wie ein Drehknopf. Wenn Sie daran interessiert sind, Microservices auszuprobieren, dann erstellen Sie einfach einen Dienst. Erstellen Sie einen Dienst. Integrieren Sie ihn in Ihr bestehendes monolithisches System. Das ist ein kleiner Dreh am Rad. Probieren Sie einfach einen aus und sehen Sie, wie er funktioniert. Denn die meisten Probleme, die mit einer Microservice-Architektur verbunden sind, zeigen sich erst in der Produktion. Selbst wenn Sie glauben, dass Microservices das Richtige für Sie sind, sollten Sie sich nicht darauf stürzen. Tauchen Sie erst einmal den Zeh ins Wasser und sehen Sie, wie es läuft, bevor Sie den Regler hochdrehen.

Viele Unternehmen haben ihre Migration zu Microservices erfolgreich und schrittweise mit dem Strangler-Muster abgeschlossen. Behalten Sie Ihren Monolithen bei, beginnen Sie klein mit einigen ausgewählten Microservices (so wenig wie einer) und setzen Sie eine Strangler-Fassade zwischen Ihren Monolithen und Ihre neuen Services. Die Strangler-Fassade leitet einen Teil der Anfragen an Ihre neuen Dienste um, während Sie ansonsten weiterhin Ihren bestehenden Monolithen verwenden. Während Sie immer mehr Dienste hinzufügen, wird Ihr Altsystem immer weniger in Anspruch genommen. Am Ende der Migration laufen alle Anfragen über Ihre Microservices, und Sie können Ihren Monolithen für immer loswerden (oder ihn für ältere Kunden behalten). Ihre Kunden werden davon nichts mitbekommen. Um das Strangler-Pattern zu verwenden, müssen die Anfragen an Ihr Backend-System allerdings von Ihrer Strangler-Fassade abgefangen werden.

Das Strangler-Muster hilft, schrittweise von einem Monolithen wegzukommen

Schrittweise Migration von einem Monolithen zu Microservices

Dies ist nur eines der vielen Muster, die die erfolgreiche Umsetzung von Microservices-Architekturen gewährleisten. Ereignisgesteuerte Architekturen minimieren die Kopplung zwischen den Teilnehmern an einem verteilten System. Ereignisproduzenten wissen nicht, welche Ereignisverbraucher auf ein Ereignis warten, und schon gar nicht, wo sie sich befinden. Auch die Ereignisverbraucher kennen die Ereignisproduzenten nicht. Komponenten einer Architektur, die über Ereignisse kommunizieren, sind also lose gekoppelt. Wir haben bereits erwähnt, dass diese lose Kopplung entscheidend für die feinkörnige Skalierbarkeit ist, eine wichtige architektonische Voraussetzung für Microservices.

Dies führt natürlich zu weiteren Problemen, die bei synchronen anforderungsgesteuerten Modellen nicht auftreten. Ereignisse können gesendet und nie empfangen werden. Ereigniskonsumenten können ausfallen oder nicht verfügbar sein. Ereignisse können dupliziert werden. Die gute Nachricht ist, dass sich andere Muster herausgebildet haben, die diese Probleme angehen. Um es kurz zu machen: Dies sind die wichtigsten Muster, die den gesamten Lebenszyklus der Softwarebereitstellung abdecken, die Sie kennen müssen und die die Leistung Ihrer Microservices-Implementierung beeinflussen werden:

DevOps VSDPs implementieren die bewährten Praktiken der cloud nativen

DevOps VSDPs implementieren die bewährten Praktiken der cloud nativen

Das ist es, was digitale Marktführer tun. Auf diese Weise stellen sie mehrmals täglich Funktionen für die Produktion bereit, erkennen und beheben Ausfälle innerhalb weniger Minuten – ohne dass der Endnutzer etwas davon merkt. Sie optimieren die Cloud-Ausgaben und erhalten gleichzeitig die Servicequalität, indem sie automatisch hoch- und herunterskalieren, ohne die Zuverlässigkeit der Website oder DevOps-Ingenieure zu monopolisieren. Für jedes dieser Muster gibt es einen Grund. Dies ist zum Beispiel, was Leif Barton, Senior Solutions Architect bei NGINX, über Observability, ein zentrales Überwachungsmuster, zu sagen hatte (Hervorhebung durch uns):

Überwachung, Nachverfolgung und dergleichen sind natürlich von entscheidender Bedeutung, wenn man sich auf [Microservices] zubewegt, denn die Kommunikation in der gesamten Anwendung ist kein Funktionsaufruf […] Es ist ein Netzwerkaufruf, der auf dem System, mit dem man gerade spricht, lokal sein kann oder nicht. Die Möglichkeit, die Kommunikation innerhalb einer Anwendung zu überwachen, zu verfolgen und nachzuvollziehen, ist absolut entscheidend. Ohne dies ist es so, als würde man mit verbundenen Augen versuchen, eine schwarze Katze in einem dunklen Raum zu finden.

Ja, um ein Leistungsniveau zu erreichen, das dem der digitalen Marktführer entspricht, müssen Sie all diese Dinge tun. Viele Unternehmen unterschätzen, was alles nötig ist, um durch eine hervorragende Softwarebereitstellung überzeugende Geschäftsergebnisse zu erzielen. Wie können Unternehmen dies alles meistern?

Sie verwenden eine DevOps Value Stream Delivery Platform (abgekürzt DevOps VSDP). CodeNOW, unsere DevOps VSDP, wurde in einer Tochtergesellschaft der Société Générale geboren, um genau die gleichen Probleme zu lösen, mit denen große Unternehmen bei der Skalierung ihrer digitalen Transformation konfrontiert sind.

Wie ein leitender Architekt der Komercni Banka, einer der größten Banken der Tschechischen Republik, es ausdrückte:

Ich habe zu viele Entwickler weinen sehen, als sie versuchten, ein HA/DR [High Availability/Disaster Recovery]-fähiges SAGA-Muster mit Java/Spring Boot ohne buchstäbliche Framework-/Infra-Unterstützung zu liefern – und die Möglichkeit, von ACID zu BASE zu wechseln, ist einer der Eckpfeiler der Cloud Native Architecture.

Amazon, Google, IBM und Oracle haben ihre eigene, unternehmenseigene DevOps VSDP. Sie haben ihre Plattform ähnlich wie CodeNOW über Jahre des Experimentierens, des Ausprobierens und der schrittweisen Einbeziehung der besten Praktiken verfeinert. Wie CodeNOW sind auch diese Unternehmen Mitglieder der Cloud Native Computing Foundation, die mit den Best Practices von Cloud Native experimentiert und deren Einführung vorantreibt.

DevOps VSDPs vereinheitlichen und integrieren mehrere Einzellösungen, die die meisten Unternehmen bereits für die Bereitstellung von Software verwenden. DevOps VSDPs bieten Entwicklern ein einziges Self-Service-Portal, über das sie ihre Software programmieren, erstellen, testen, bereitstellen, betreiben und überwachen können. DevOps VSDPs bieten mit ihrer integrierten DevOps-Pipeline eine End-to-End-Ansicht des Softwarebereitstellungsprozesses. Mit DevOps VSDPs können Sie Ihre Bereitstellungs-KPIs kontinuierlich überwachen und sicherstellen, dass Sie auf dem richtigen Weg sind – und bleiben -, um Spitzenleistungen zu erbringen. All das sollte für Sie von Bedeutung sein. Aber wir möchten noch etwas anderes hervorheben.

Abgesehen von der Welt der Softwaremuster ist eine der größten Herausforderungen, die von Unternehmen, die Microservices einführen, genannt wird, die Qualifizierung/Umschulung ihrer Mitarbeiter. Die überwiegende Mehrheit der Unternehmen hat weder die Mitarbeiter noch das Kapital, um eine eigene DevOps-VSDP aufzubauen. Die Mitarbeiter, die sie haben, haben nicht die Muße, 20 herstellerspezifische Tools für die Bereitstellung von Software zu erlernen. Die begrenzten finanziellen Ressourcen, die sie nur mühsam aufbringen können, sollten in erster Linie in die Analyse der Kundenbedürfnisse, in Innovationen, in den Aufbau von Wettbewerbsvorteilen und in die Bewältigung geschäftsspezifischer Probleme fließen, anstatt von unbedeutenden, automatisierbaren Softwarebereitstellungsaufgaben verschlungen zu werden.

Microservices sind schwieriger als Sie denken. Wir haben unseren DevOps VSDP CodeNOW entwickelt, damit Sie die Mitarbeiter, die Sie bereits haben, in den Konzepten, Prinzipien und Mustern schulen können, die eine Spitzenleistung bei der Softwarebereitstellung ermöglichen. CodeNOW bietet eine Sandbox-Umgebung, in der Dev-, Ops-, DevOps- und SRE-Teams in einer echten Cloud lernen können. Aus unserer Erfahrung bei der Entwicklung von CodeNOW wissen wir, wie schwierig es für Entwickler ist, hochverfügbare, wiederherstellungsfreundliche, ereignisgesteuerte Architekturen auf Ihrem Notebook oder mit einer einzigen VM bereitzustellen.

Wir können verteilte Systeme nicht einfacher machen. Das kann niemand. Sie haben ihre wesentliche Komplexität. Deshalb haben wir sehr hart daran gearbeitet, die zufällige Komplexität zu reduzieren, die durch die von uns verwendeten Technologien entsteht. Der DevOps VSDP von CodeNOW ist Cloud-agnostisch. CodeNOW ist vielleicht die einzige DevOps-Plattform, die nicht an einen bestimmten Anbieter gebunden ist. CodeNOW-Benutzer verwenden ausschließlich vollständig quelloffene Stacks, die bereits millionenfach eingesetzt werden – und von denen sie viele bereits kennen.

Wie wir schon sagten, lernen CodeNOW-Nutzer Konzepte, Prinzipien und Muster. Konzepte, Prinzipien und Muster bleiben bestehen, Technologien kommen und gehen. Wir möchten, dass Sie sich auf Ihr Geschäft konzentrieren. Sprechen Sie mit Ihren Kunden. Entwickeln Sie die digitalen Dienste, die den Bedürfnissen Ihrer Kunden entsprechen, innovieren Sie, vertreiben Sie Ihre Produkte über neue Kanäle. Das ist es, was Ihr Geschäft ausmacht. Wir übernehmen die Bereitstellung der Software für Sie. Wir helfen Ihnen, von den Kundenbedürfnissen zu den bereitgestellten Funktionen zu gelangen.

Wert. Geliefert. JETZT.