Microservices

menu icon

Microservices

Microservices-Architektur ist eine Lösung, bei der eine einzelne Anwendung aus vielen lose aneinander gekoppelten und unabhängig voneinander einsetzbaren kleineren Services zusammengesetzt ist.

Was sind Microservices?

Microservices (oder auch Microservices-Architektur) sind eine cloudnative Architekturlösung, bei der eine einzelne Anwendung aus vielen lose aneinander gekoppelten und unabhängig voneinander einsetzbaren kleineren Services zusammengesetzt ist. Diese Services besitzen im Allgemeinen

  • ihren eigenen Technologiestack, einschließlich Datenbank-und Datenmanagementmodell;
  • kommunizieren miteinander über eine Kombination von REST-APIs, Event-Streaming und Message Broker; und
  • werden nach Geschäftsfunktion organisiert, wobei die Trennlinie, die die Services voneinander abgrenzt, oft als „begrenzter Kontext bezeichnet" wird.

Während sich ein Großteil der Debatte zum Thema Microservices um Architekturdefinitionen und -charakteristika dreht, kann ihr Wert allgemeiner anhand relativ einfacher geschäftlicher und organisatorischer Vorteile verstanden werden:

  • Code kann einfacher aktualisiert werden – neue Features oder Funktionen können hinzugefügt werden, ohne dass die Anwendung als Ganzes zu berührt werden muss.
  • Teams können verschiedene Stacks und verschiedene Programmiersprachen für verschiedene Komponenten verwenden.
  • Komponenten können unabhängig voneinander skaliert werden, wodurch Ineffizienzen und Kosten reduziert werden, die mit dem Skalieren ganzer Anwendungen verbunden sind, wenn eine einzelne Funktion möglicherweise zu stark belastet wird.

Microservices lassen sich auch dadurch verstehen, was sie nicht sind. Die beiden am häufigsten gezogenen Vergleiche in Bezug auf die Microservices-Architektur sind die monolithische Architektur und die serviceorientierte Architektur (SOA).

Der Unterschied zwischen Microservices und monolithischer Architektur besteht darin, dass Microservices eine einzelne Anwendung aus vielen kleineren, lose miteinander verknüpften Services zusammensetzen, im Gegensatz zum monolithischen Ansatz, der in einer großen, eng miteinander verknüpften Anwendung besteht.

Mehr Informationen zu den Unterschieden zwischen Microservices und monolithischer Architektur erhalten Sie in diesem Video (6:37):

 

Die Unterschiede zwischen Microservices und SOA sind möglicherweise weniger eindeutig. Obwohl es technische Unterschiede zwischen Microservices und SOA gibt, und zwar insbesondere in Bezug auf die Rolle des Enterprise Service Bus (ESB), ist es einfacher, den Unterschied als einen Unterschied in Bezug auf den Umfang zu definieren. SOA war ein unternehmensweites Bestreben, die Art und Weise zu standardisieren, wie alle Webdienste in einem Unternehmen miteinander kommunizieren und miteinander integriert sind, während die Microservices-Architektur anwendungsspezifisch ist.

Der Beitrag „SOA im Vergleich zu Microservices: Was ist der Unterschied?" geht tiefer ins Detail.

Wie Microservices dem Unternehmen nützen

Microservices sind wahrscheinlich bei Führungskräften und Projektleitern mindestens genauso beliebt wie bei Entwicklern. Dies ist eine der etwas ungewöhnlicheren Eigenschaften von Microservices, da Begeisterung für eine bestimmte Architektur normalerweise nur in Softwareentwicklungsteams zu finden ist. Der Grund dafür ist, dass Microservices besser die Art und Weise widerspiegeln, wie viele Führungskräfte in Unternehmen ihre Teams und Entwicklungsprozesse strukturieren und betreiben wollen.

Anders ausgedrückt: Microservices sind ein Architekturmodell, das die Umsetzung des gewünschten Betriebsmodells einfacher macht. In einer aktuelle IBM-Befragung von über 1.200 Entwicklern und IT-Managern waren sich 87 % der Nutzer von Microservices einig, dass die Einführung von Microservices die Kosten und den Aufwand wert ist. Weitere Perspektiven zu den Vorteilen und Herausforderungen von Microservices können Sie mit dem untenstehenden interaktiven Tool erkunden:

(Quelle: „Microservices im Unternehmen 2021: Echte Vorteile, die die Herausforderungen wert sind" [Microservices in the enterprise 2021: Real benefits, worth the challenges].)

Hier sind nur einige der Vorteile von Microservices für Unternehmen.

Unabhängig voneinander bereitstellbar

Die vielleicht wichtigste Eigenschaft von Microservices ist, dass die Services kleiner sind und unabhängig voneinander bereitgestellt werden können, so dass es nicht mehr erheblichen Aufwand bedeutet, eine Codezeile zu ändern oder eine neue Funktion in die Anwendung einzufügen.

Microservices sind daher für Unternehmen ein Gegenmittel gegen die tiefsitzende Frustration, die dann entsteht, wenn kleine Änderungen eine riesige Menge Zeit in Anspruch nehmen. Man braucht keinen Doktortitel in der Informatik, um den Wert eines Ansatzes zu sehen oder zu verstehen, der Geschwindigkeit und Agilität besser unterstützt.

Aber Geschwindigkeit ist nicht der einzige Vorteil aus dieser Art der Servicegestaltung. Ein oft anzutreffendes, neu entstehendes Organisationsmodell besteht darin, funktionsübergreifende Teams rund um ein Geschäftsproblem, eine Dienstleistung oder ein Produkt zusammenzubringen. Das Microservices-Modell passt gut zu diesem Trend, da es einer Organisation ermöglicht, kleine, funktionsübergreifende Teams um einen Dienst oder eine Sammlung von Diensten herum zu bilden und sie auf agile Art und Weise arbeiten zu lassen.

Da Microservices nur lose miteinander verknüpft sind, ist automatisch auch ein gewisses Maß an Fehlerisolierung und bessere Ausfallsicherheit in Anwendungen gegeben. Und die geringe Größe der Dienste, verbunden mit ihren klaren Grenzen und Kommunikationsmustern, macht es neuen Teammitgliedern leichter, die Codebasis zu verstehen und schnell zu ihr beizutragen – ein klarer Vorteil in Bezug auf Geschwindigkeit und Mitarbeitermoral.

Das richtige Werkzeug für den Job

In traditionellen Architekturmustern mit x Ebenen teilt sich eine Anwendung typischerweise einen gemeinsamen Stack, wobei eine große, relationale Datenbank die gesamte Anwendung unterstützt. Dieser Ansatz hat mehrere offensichtliche Nachteile – und der Hauptnachteil ist, dass jede Komponente einer Anwendung einen gemeinsamen Stack, ein gemeinsames Datenmodell und eine gemeinsame Datenbank nutzen muss, selbst wenn es für bestimmte Elemente ein Werkzeug gibt, dass eindeutig besser für diese Aufgabe geeignet ist. Ein solcher Ansatz führt daher zu einer schlechten Architektur und ist frustrierend für die Entwickler, die natürlich immer genau wissen, dass es einen besseren und effizienteren Weg gibt, diese Komponenten zu bauen.

Im Gegensatz dazu werden in einem Microservices-Modell die Komponenten unabhängig voneinander bereitgestellt und kommunizieren über eine Kombination aus REST, Event-Streaming und Message Brokern. Und daher kann der Stack jedes einzelnen Services für diesen Service optimiert werden. Die Technologie wandelt sich ständig, und eine Anwendung, die aus mehreren, kleineren Services besteht, lässt sich wesentlich einfacher und kostengünstiger mit besseren Technologien weiterentwickeln, sobald diese verfügbar sind.

Präzise Skalierung

Mit Microservices können individuelle Services individuell eingesetzt werden –aber auch individuell skaliert werden. Der daraus resultierende Vorteil liegt auf der Hand: Korrekt implementiert, erfordern Microservices weniger Infrastruktur als monolithische Anwendungen, da sie eine präzise Skalierung nur der Komponenten ermöglichen, die sie benötigen, anstatt eine Skalierung der gesamten Anwendung im Fall von monolithischen Anwendungen.

Es gibt auch Herausforderungen

Die wichtigsten Vorteile aus dem Einsatz von Microservices sind mit erheblichen Herausforderungen verbunden. Die Umstellung einer monolithischen Umgebung auf Microservices bedeutet wesentlich mehr Management-Komplexität – wesentlich mehr Services, von wesentlich mehr Teams erstellt, und an wesentlich mehr Standorten. Probleme in einem Service können Probleme in anderen Services verursachen oder von diesen verursacht werden. Protokolldaten (die für Überwachung und Problemlösung verwendet werden) sind umfangreicher und können außerdem zwischen verschiedenen Services inkonsistent sein. Neue Versionen können Probleme mit der Abwärtskompatibilität verursachen. Anwendungen sind mit mehr Netzwerkverbindungen verbunden, was zusätzliche Möglichkeiten für Latenz-und Konnektivitätsprobleme verursachen kann. Eine DevOps-Lösung (wie weiter unten zu lesen) kann viele dieser Probleme beheben, aber die Einführung von DevOps bringt eigene Herausforderungen mit sich.

Dennoch halten diese Herausforderungen die Nichtbenutzer nicht von der Einführung von Microsdervices ab - und auch nicht Benutzer davon, ihre Investitionen in Microservices auszubauen. Neue IBM-Umfragedaten belegen, dass 56 % der derzeitigen Nichtbenutzer in den nächsten zwei Jahren wahrscheinlich oder sehr wahrscheinlich Microservices einführen werden, und 78 % der derzeitigen Nutzer von Microservices geben an, dass ihr Unternehmen wahrscheinlich mehr Zeit, Geld und Aufwand in Microservices investieren wird (siehe Abbildung 1).

Drei Kreisdiagramme mit 56 Prozent, 78 Prozent und 59 Prozent

Abbildung 1: Microservices sind nicht mehr wegzudenken. Innerhalb der kommenden zwei Jahre werden voraussichtlich 56 % der Nichtbenutzer Microservices einführen, 78 % der Nutzer werden ihre Investitionen in Microservices erhöhen, und 59 % der Anwendungen werden voraussichtlich mit Microservices erstellt. (Quelle: „Microservices im Unternehmen 2021: Echte Vorteile, die die Herausforderungen wert sind" [Microservices in the enterprise 2021: Real benefits, worth the challenges].)

Microservices ermöglichen DevOps und erfordern sie gleichzeitig

Microservices Architektur wird oft als optimiert für DevOps und Continuous Integration/Continuous Delivery (CI/CD) beschrieben, und im Kontext von kleinen Services, die häufig eingesetzt werden können, ist der Grund hierfür einfach zu verstehen.

Eine andere Möglichkeit, die Beziehung zwischen Microservices und DevOps zu betrachten, ist die Tatsache, dass Microservices-Architekturen tatsächlich DevOps erfordern, um erfolgreich zu sein. Während monolithische Anwendungen eine Reihe von Nachteilen haben, die bereits in diesem Artikel erläutert wurden, besitzen sie den Vorteil, dass sie kein komplexes, dezentrales System mit mehreren variablen Komponenten und unabhängigen Tech-Stacks sind. Im Gegensatz dazu wäre es angesichts der massiven Zunahme von Komplexität, variablen Komponenten und Abhängigkeiten, die mit Microservices einhergehen, nicht ratsam, Microservices ohne nennenswerte Investitionen in Bereitstellung, Überwachung und Lifecycle-Automatisierung umzusetzen.

Andrea Crawford bietet einen tieferen Einblick in DevOps im folgenden Video:

Schlüsseltechnologien und -tools

Während im Prinzip jedes moderne Tool oder Sprache in einer Microservices-Architektur verwendet werden kann, bestehen eine Handvoll wichtiger Tools, die essentiell geworden sind und definitorisch an Microservices angrenzen:

Container, Docker und Kubernetes

Eines der Schlüsselelemente eines Microservice ist, dass es im Allgemeinen ziemlich klein ist. (Es gibt keine willkürliche Menge an Code, anhand der festgelegt wird, ob etwas ein Microservice ist oder nicht, aber "micro" ist direkt im Namen enthalten.)

Als Docker in der Ära des modernen Containers im Jahr 2013 eingeläutet wurde, wurde damit auch das Rechenmodell eingeführt, das mit Microservices am stärksten in Verbindung gebracht werden sollte. Da einzelne Container nicht über den Systemaufwand ihres eigenen Betriebssystems verfügen, sind sie kleiner und leichter als herkömmliche virtuelle Maschinen und können schneller den Betrieb aufnehmen und beenden, was sie zur perfekten Ergänzung für kleinere Services mit weniger Speicherbedarf macht, die im Inneren von Microservices-Architekturen zu finden sind.

Mit der Verbreitung von Dienstleistungen und Containern wurde die Orchestrierung und Verwaltung großer Containergruppen schnell zu einer der kritischen Herausforderungen. Kubernetes, eine Open-Source-Plattform für Containerorchestrierung, hat sich zu einer der beliebtesten Orchestrierungslösungen entwickelt, weil sie sich hervorragend bewährt hat.

In dem Video "Kubernetes erklärt", gibt Sai Vennam eine umfassende Sicht auf alles rund um Kubernetes:

 

API-Gateways

Microservices kommunizieren häufig über API, insbesondere beim erstmaligen Einrichten des Zustands. Es stimmt zwar, dass Clients und Services direkt miteinander kommunizieren können, aber API-Gateways stellen oft eine nützliche Zwischenschicht dar, insbesondere da die Anzahl der Services innerhalb einer Anwendung im Laufe der Zeit zunimmt. Ein API-Gateway fungiert als Reverse Proxy für Clients, weil er Anforderungen weiterleitet, sie über mehrere Services hinweg ausfächert und zusätzliche Sicherheit und Authentifizierung bereitstellt.

Es gibt mehrere Technologien, die für die Implementierung von API-Gateways, einschließlich API-Management-Plattformen, verwendet werden können. Wenn jedoch die Microservices-Architektur mit Containern und Kubernetes implementiert wird, erfolgt die Implementierung des Gateway in der Regel mit Ingress oder neuerdings mit Istio.

Messaging-und Eventstreaming

Es wäre vielleicht das beste Verfahren, zustandsunabhängige Services zu konzipieren, dennoch existiert der Zustand, und Services müssen ihn beachten. Und obwohl ein API-Aufruf oftmals eine effektive Methode ist, den Zustand für einen bestimmten Service zu etablieren, ist es keine besonders effektive Möglichkeit, um auf dem neuesten Stand zu bleiben. Der permanente "sind wir da schon da?"-Abruf, um die Services auf dem neuesten Stand zu halten, ist einfach nicht praktikabel.

Stattdessen ist es erforderlich, die State-API-Aufrufe mit Messaging-oder Eventstreaming zu koppeln, damit die Services Änderungen im Status übertragen können, und andere interessierte Parteien auf diese Änderungen achten und entsprechend anpassen können. Diese Aufgabe eignet sich wahrscheinlich am besten für einen allgemeinen Message Broker, aber es gibt Fälle, in denen eine Eventstreaming-Plattform, wie z. B. Apache Kafka, eine passende Wahl sein könnte. Und durch die Kombination von Microservices mit ereignisgesteuerter Architektur können Entwickler dezentralisierte, hoch skalierbare, fehlertolerante und erweiterbare Systeme erstellen, die sehr große Mengen an Ereignissen oder Informationen in Echtzeit nutzen und verarbeiten können.

Serverlos

Serverlose Architekturen berufen sich bei ihrer logischen Schlussfolgerung auf einige der zentralen Cloud-und Microservices-Muster. Bei "Serverless" ist die ausführende Einheit nicht nur ein kleiner Service, sondern eine Funktion, die oftmals lediglich aus wenigen Zeilen Code besteht. Die Linie, die serverlose Funktionen von Microservices trennt, ist verschwommen, aber Funktionen werden im Allgemeinen sogar als kleiner als Microservices.

Die Schnittstelle der Affinität von serverlosen Architekturen und Functions-as-a-Service (FaaS) Plattformen mit Microservices ist, dass beide daran interessiert sind, kleinere Bereitstellungseinheiten zu erstellen und präzise in Übereinstimmung mit der Nachfrage zu skalieren.

Microservices und Cloud-Services

Microservices sind nicht zwangsläufig ausschließlich relevant für Cloud-Computing, aber es gibt einige wichtige Gründe, warum sie so häufig Hand in Hand gehen - Gründe, die darüber hinausgehen, dass Microservices ein beliebter Architektur-Stil für neue Anwendungen ist und die Cloud ein beliebtes Hosting-Ziel für neue Anwendungen darstellt.

Zu den primären Vorteilen der Microservices-Architektur gehören die Auslastung und Kostenvorteile, die mit der individuellen Bereitstellung und Skalierung von Komponenten verbunden sind. Obwohl diese Vorteile noch in gewissem Maße mit einer On-Premises-Infrastruktur vorhanden wären, stellt die Kombination von kleinen, unabhängig skalierbaren Komponenten, die mit einer nutzungsorientierten On-Demand-Infrastruktur verbunden sind, die Basis für reelle Kostenoptimierungen dar.

Der zweite, und vielleicht noch wichtigere Hauptvorteil von Microservices besteht darin, dass jede einzelne Komponente den für ihre spezifische Aufgabe am besten geeigneten Stapel übernehmen kann. Die zunehmende Verbreitung von Stack kann bei Selbstverwaltung zu schwerwiegender Komplexität und Systemaufwand führen, der Verwaltungsaufwand lässt sich jedoch drastisch minimieren, wenn der Supporting Stack als Cloud-Services genutzt wird. Anders formuliert: Es ist zwar nicht unmöglich, eine eigene Microservices-Infrastruktur umzusetzen, aber es ist nicht ratsam, insbesondere, wenn man gerade am Anfang steht.

Allgemeine Muster

Innerhalb von Microservices-Architekturen gibt es viele allgemeine und nützliche Design-, Kommunikations-und Integrationsmuster, die dabei helfen, einige der häufiger auftretenden Herausforderungen und Chancen, wie beispielsweise die Folgenden, zu beheben:

  • Back-End-for-Frontend (BFF) -Muster: Dieses Muster fügt eine Schicht zwischen dem Benutzererlebnis und den Ressourcen ein, auf denen das Erlebnis beruht. Eine App, die auf einem Desktop verwendet wird, verfügt beispielsweise über eine andere Bildschirmgröße, Anzeige und Leistungsgrenzen als bei Nutzung eines mobilen Geräts. Das BFF-Muster ermöglicht es Entwicklern, einen Back-End-Typ pro Benutzerschnittstelle unter Verwendung der besten Optionen für diese Schnittstelle zu erstellen und zu unterstützen, anstatt zu versuchen, ein generisches Back-End zu unterstützen, das mit jeder beliebigen Schnittstelle arbeitet, aber das Frontend-Leistungsverhalten negativ beeinflussen kann.
  • Entitäts-und Aggregatmuster: Eine Entität ist ein Objekt, das sich durch seine Identität auszeichnet. Auf einer E-Commerce-Site kann z. B. ein Produktobjekt durch Produktnamen, Typ und Preis unterschieden werden. Ein Aggregat ist eine Sammlung zusammengehöriger Entitäten, die als eine Einheit behandelt werden sollen. Für die E-Commerce-Site wäre also eine Bestellung eine Sammlung (Aggregat) von Produkten (Entitäten), die von einem Käufer bestellt wurden. Diese Muster werden verwendet, um Daten in aussagekräftigen Methoden zu klassifizieren.
  • Serviceerkennungsmuster: Diese Hilfsanwendungen und -services finden einander. In einer Microservices-Architektur ändern sich Serviceinstanzen dynamisch und abhängig von Skalierung, Upgrades, Servicefehlern und sogar Servicebeendigung. Diese Muster stellen Erkennungsmechanismen bereit, um diese Flüchtigkeit zu bewältigen. Lastausgleich kann Service-Erkennungsmuster verwenden, indem Statusprüfungen und Servicefehler als Auslöser für die Neuverteilung des Datenverkehrs verwendet werden.
  • Microservices-Muster für Adapter: Denken Sie bei Adaptermustern an Steckadapter, die Sie bei der Reise in ein anderes Land verwenden. Der Zweck von Adaptermustern besteht darin, zu helfen, Beziehungen zwischen Klassen oder Objekten zu übersetzen, die andernfalls nicht kompatibel sind. Eine Anwendung, die auf APIs anderer Anbieter angewiesen ist, muss möglicherweise ein Adaptermuster verwenden, um sicherzustellen, dass die Anwendung und die APIs miteinander kommunizieren können.
  • Strangler-Anwendungsmuster: Diese Muster unterstützen die Umstrukturierung einer monolithischen Anwendung in Microservices-Anwendungen. Der anschauliche Name bezieht sich darauf, wie sich eine Weinrebe (Microservices) langsam und allmählich um einen Baum (eine monolithische Anwendung) windet und ihn umschlingt.

Erfahren Sie mehr über diese Muster in "Erkennungsmuster mit Microservices verwenden (Teil 4)". IBM Developer stellt zudem viele Informationen bereit, wenn Sie an Informationen zu anderen Codemustern für Microservices interessiert sind.

Anti-Muster

Es gibt zwar zahlreiche Muster für die erfolgreiche Bereitstellung von Microservices, jedoch besteht eine ebenso signifikante Anzahl von Mustern, die jedes Entwicklerteam schnell in Schwierigkeiten bringen können. Einige von ihnen - als Microservices "don'ts" bezeichnet - sind wie folgt:

  • Die erste Regel von Microservices lautet, keine Microservices zu erstellen: Präziser formuliert, beginnen Sie nicht mit Microservices. Microservices sind ein Methode zur Verwaltung der Komplexität, sobald die Anwendungen zu groß und unübersichtlich sind, um sie auf einfache Weise aktualisieren und warten zu können. Erst wenn sich langsam die monolithische Schwerfälligkeit und Komplexität ausbreitet, wird es erwägenswert, wie man diese Anwendung in kleinere Dienste umstrukturieren könnte. Solange man diese Beschwerden nicht fühlt, hat man nicht einmal wirklich einen Monolithen, der einer Umstrukturierung bedarf.
  • Keine Microservices ohne DevOps-oder Cloud-Services durchführen: Microservices zu erstellen bedeutet, verteilte Systeme zu erstellen, und verteilte Systeme sind schwierig (und sie sind besonders schwierig, wenn Sie Entscheidungen treffen, die es noch schwieriger machen). Wenn man versucht, Microservices ohne a) eine geeignete Implementierung und Überwachung auszuführen oder b) nicht über Managed Cloud-Services verfügt, um die nunmehr ausufernde, heterogene Infrastruktur zu unterstützen, drohen Ihrem Unternehmen dadurch eine Menge unnötiger Probleme. Sparen Sie sich den Ärger, damit Sie Zeit haben, sich über den Zustand Gedanken zu machen.
  • Stellen Sie nicht zu viele Microservices her, indem Sie sie zu klein gestalten: Wenn Sie das "Micro" in Microservices zu wörtlich nehmen, werden Sie womöglich schnell mit Systemaufwand und Komplexität konfrontiert, die den Gesamtnutzen der Bereitstellung einer Microservices-Architektur überwiegen. Es ist besser, sich auf größere Dienste zu stützen und sie dann erst herunterzubrechen, wenn sie beginnen, Eigenschaften zu entwickeln, die sich mit Microservices lösen lassen - nämlich, wenn es schwierig wird, Änderungen zu implementieren, wenn ein gemeinsames Datenmodell zu komplex wird oder wenn verschiedene Servicebestandteile unterschiedliche Anforderungen an das Laden/Skalieren haben.
  • Microservices nicht in SOA verwandeln: Microservices und serviceorientierte Architektur (SOA) werden oft miteinander verbunden, da beide auf ihrer grundlegendsten Ebene an der Erstellung wiederverwendbarer Einzelkomponenten interessiert sind, die von anderen Anwendungen genutzt werden können. Der Unterschied zwischen Microservices und SOA besteht darin, dass Microservices-Projekte in der Regel die Umstrukturierung einer Anwendung zwecks einfacherer Verwaltung erfordern, während es bei SOA um die Änderung der Art und Weise geht, wie IT-Services unternehmensweit arbeiten. Ein Microservices-Projekt, das in ein SOA-Projekt umgewandelt wird, wird wahrscheinlich unter seinem eigenen Gewicht zusammenbrechen.
  • Versuchen Sie nicht, Netflix zu sein: Netflix war einer der frühen Pioniere der Microservices-Architektur beim Erstellen und Verwalten einer Anwendung, die ein Drittel des gesamten Internetverkehrs ausmachte - eine Art perfekter Sturm, der sie dazu brachte, eine Vielzahl von benutzerdefiniertem Code und Services zu erstellen, die für die durchschnittliche Anwendung unnötig sind. Sie sind wesentlich besser damit beraten, in einem Tempo zu beginnen, das für Ihr Unternehmen angemessen ist. Vermeiden Sie Komplexität, und verwenden Sie so viele Standardtools wie möglich.

Lernprogramme: Aufbau von Microservices-Know-how

Wenn Sie bereit sind, mehr über die Verwendung von Microservices zu erfahren, oder wenn Sie auf Ihrem Know-how über Microservices aufbauen müssen, versuchen Sie es mit einem dieser Lernprogramme:

Microservices und IBM Cloud

Microservices ermöglichen innovative Entwicklung im Tempo des modernen Unternehmens. Erfahren Sie, wie Sie die Skalierbarkeit und Flexibilität der Cloud durch die Bereitstellung unabhängiger Microservices in Cloud-Umgebungen optimal nutzen können. Erfahren Sie, wie die Modernisierung Ihrer Anwendungen mit Hilfe von IBM aussehen könnte.

Machen Sie den nächsten Schritt:

  • Befreien Sie Ihre Entwicklungsteams und setzen Sie auf automatisierte Iteration mit Hilfe von cloudnativen IBM Entwicklungstools setzen.
  • Sie erhalten weitere Informationen zu Managed Kubernetes, indem Sie mit Red Hat OpenShift on IBM Cloud oder IBM Cloud Kubernetes Service loslegen. Sehen Sie sich ebenfalls IBM Cloud Code Engine an, um mehr über Serverless Computing zu erfahren.
  • Bei Microservices geht es gleichermaßen um Zusammenarbeit als Team und Organisation wie um Technologie. Planen Sie Ihre DevOps-Lösung strategisch mit Unterstützung von IBM DevOps.

Starten Sie noch heute mit einem IBM Cloud-Konto.