Beruhigt euch alle. Atmet tief durch, und dann begeben wir uns langsam mitten hinein in den im Internet tobenden Streit um Microservices versus Monolithen.
Das Wichtigste:
Amazon hat kürzlich eine Fallstudie veröffentlicht, in der das Unternehmen seine Entscheidung dokumentiert, Microservices aufzugeben und stattdessen auf Monolithen zu setzen, wodurch die Kosten um 90 % gesenkt wurden. Diese Fallstudie sorgte im Internet für heftige Reaktionen in Form von Kommentaren und sarkastischen Tweets, als Microservices und Monolithen in den technischen Boxring geschickt wurden.
Die Realität:
Wenn Sie das Gefühl haben, unter einem schweren Fall von technischem Déjà-vu zu leiden, liegen Sie nicht falsch. In genau dieser Situation befand sich die serviceorientierte Architektur (SOA) etwa im Jahr 2009, als Anne Thomas Manes sie für tot erklärte. Der Link führt zu einem Kommentar von David Linthicum zu Manes’ Beitrag, da das Original offenbar vom Internet verschluckt wurde.
Nun, Manes übertrieb bewusst und äußerte sich etwas sarkastisch, denn wie wir alle wissen, ist die serviceorientierte Architektur nicht gestorben. Sie wurde recht schnell in Form von Microservices wiederbelebt, und dem Wehklagen im Internet nach zu urteilen, haben Entwickler noch immer nicht verstanden, welch große Rolle „das Netzwerk“ für die Performance spielt.
SOA „starb“ aus zwei Gründen:
- Konkurrierende, aufgeblähte XML-basierte Standards, die Architekturen übermäßig komplex machten. Niemand erinnert sich gern an WSDL, SOAP und UDDI. Wirklich niemand.
- Die Gesetze der Physik und Interoperabilitätsstandards begrenzen den Austausch von Netzwerkpaketen auf Lichtgeschwindigkeit und 1.500 Byte.
Die erste Herausforderung haben wir vielleicht gemeistert, aber was ist mit der zweiten? Die einzige Antwort darauf war und ist ein ausgewogenes Verhältnis zwischen der Granularität des Service-Designs und einem guten Verständnis dafür, wie lange die Datenübertragung zwischen Services dauert.
Die Übertragung von Daten ist nicht kostenlos. Sie braucht Zeit. Bei der Kommunikation zwischen Diensten gibt es keine „Nullkosten“. Es dauert, ein Paket auf die Leitung zu bringen, es zu übertragen, die Daten anschließend aus dem Paket zu entnehmen und schließlich zu verarbeiten. Und vergessen Sie nicht, dass auch die Transportkommunikation Zeit in Anspruch nimmt. Das Öffnen von Sockets und das Annehmen von Anfragen ist ebenfalls nicht kostenlos. Gleiches gilt für die Zeit, die benötigt wird, um Nutzdaten in ein Format zu serialisieren und daraus zu deserialisieren, das der Dienst verarbeiten kann.
Multiplizieren Sie nun diese Gesamtkosten mit der Anzahl der Dienste, die Sie nutzen möchten.
Je granularer Sie Ihr System gestalten, desto länger dauert die Verarbeitung einer Anfrage. Mit anderen Worten: Die Gesamtzeit für die Verarbeitung einer Anfrage hängt von der Anzahl der Dienste ab, die diese Anfrage durchlaufen muss.
Höhere Granularität? Längere Verarbeitungszeit. Mehr Dienste? Höhere Netzwerkauslastung, wodurch sich die Verarbeitungszeit letztlich verlängert, da Netzwerkkarten und Geräte versuchen, die Pakete in die richtige Reihenfolge zu bringen und eine erneute Übertragung anzufordern.
Wie SOA können und werden auch Microservices unter Entwurfsmustern leiden, die auf einer zu hohen Granularität beruhen.
Amazon entschied sich dafür, seine Microservices durch einen Monolithen zu ersetzen. Das bedeutet, dass eine monolithische Architektur für diesen Anwendungsfall die beste Option war. Heißt das, dass Microservices tot sind?
Nein. Stattdessen sollten wir daraus zwei wichtige Erkenntnisse mitnehmen:
- Erstens sollten wir uns ein Beispiel an Amazon nehmen und bei der Konzeption von Systemen, die auf Services basieren, bewusster und durchdachter vorgehen. Dabei müssen wir sicherstellen, dass wir verstehen, wie sich die Aufteilung von Aufgaben auf zu viele kleine Services auf die Performance auswirkt.
- Zweitens sollten wir bedenken, dass Monolithen eine praktikable Wahl für die Anwendungsarchitektur sind. Es gibt einen Grund dafür, dass 60 % des Anwendungsportfolios eines Unternehmens aus Anwendungen mit „traditioneller“ Architektur bestehen, und 16 % der Unternehmen planen nicht, diese außer Betrieb zu nehmen.
Anwendungsarchitekturen sind weder gut noch schlecht, noch eignen sie sich für jeden Anwendungsfall. Unternehmen sollten einen Schritt zurücktreten und sorgfältig überlegen, was sie erreichen möchten und welche Architektur diesem Ziel am besten gerecht wird, anstatt sich für die „modernste“ Architektur zu entscheiden, nur weil sie gerade im Trend liegt.
Wenn wir sagen, dass die Zukunft in einer hybriden IT liegt, meinen wir damit mehr als nur eine Mischung aus Multi-Cloud- und On-Premises-Bereitstellungen. Wir meinen auch, dass das Anwendungsportfolio von Unternehmen auf absehbare Zeit hybrid bleiben wird – eine Mischung aus traditionellen und modernen Anwendungen. Deshalb unterstützt das F5-Portfolio weiterhin alle Anwendungen, unabhängig davon, ob sie lokal, in der Public Cloud oder in beiden Umgebungen betrieben werden.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.