SolisImages - stock.adobe.com
Microservices mit serverlosen Funktionen bereitstellen
Microservices ermöglichen es IT-Teams, flexible, einheitliche Systeme zu erstellen. Doch was passiert, wenn IT-Teams serverlose Funktionen für Microservices verwenden?
Die Welt bewegt sich weg von der Ära der großen, monolithischen Unternehmensanwendungen hin zu flexibleren Systemen, die auf Marktveränderungen reagieren können. Dieser Wandel hin zu einem Microservices-Modell hat auch die Herangehensweise der Entwickler an ihre Aufgaben verändert, wobei die kontinuierliche Entwicklung und Bereitstellung (Continuous Development und Delivery) über DevOps diesem Ansatz weitaus besser entspricht.
In einem Microservices-Modell erstellen IT-Teams eigenständige funktionale Dienste, die bei Bedarf von anderen Diensten aufgerufen werden können. Anstatt beispielsweise mehrere Instanzen eines Abrechnungssystems zu hosten, die in verschiedene monolithische Anwendungen in einem Unternehmen eingebettet sind, kann ein einziger Abrechnungsdienst verwendet werden, der einen universellen Standard schafft. Es ist viel einfacher, nur einen Abrechnungsdienst zu aktualisieren und zu verbessern.
Durch die Einheitlichkeit wird die Konsistenz im gesamten Unternehmen gewahrt.
Microservices
Durch die Zusammenfassung solcher Dienste zur Erfüllung eines bestimmten Prozesses gewinnt ein Unternehmen an Flexibilität und kann einen einzelnen Microservice nach Bedarf ändern – oder einen Dienst durch einen anderen ersetzen. Die Abhängigkeit von einem einzelnen Dienst ist jedoch ein Rezept für eine Katastrophe: Der Ausfall einer einzelnen Instanz wirkt sich auf alle von ihr abhängigen Composite Apps aus.
Neben diesem Problem gibt es auch Probleme mit dem Aufbau einer Microservices-Architektur. Mit dem zunehmenden Einsatz virtualisierter Plattformen, wie zum Beispiel Cloud-Plattformen und -Services, sind traditionelle Bereitstellungsansätze – bei denen eine Abhängigkeit von den physischen Eigenschaften der Plattform besteht – nicht mehr zweckmäßig.
Mittlerweile gibt es Orchestrierungssysteme, die es IT-Teams ermöglichen, Microservices bereitzustellen, ohne die zugrundeliegenden physischen Attribute verstehen zu müssen. Stattdessen bieten sie Funktionen rund um die Verwendung von Metadaten, die definieren, welche Ressourcen die Plattform bereitstellen muss, mit Orchestrierungssoftware, um die verfügbaren virtuellen Ressourcen anzupassen.
Damit sind jedoch noch nicht alle Probleme gelöst. So kann beispielsweise die Verknüpfung von Microservices mit festen Verbindungen die Funktionalität der Composite App beeinträchtigen. Jede Änderung der beteiligten Microservices, zum Beispiel der Wechsel von einem Plattformbereich zu einem anderen, führt nun zu einem Bruch der Verbindung, was unweigerlich zu einem vollständigen Funktionsausfall führt.
Um dem Problem der festen Verbindung zu entgehen, ist eine vollständige Abstraktion von den physischen Hardwareanforderungen erforderlich. Hier sollten IT-Teams auf serverlose Funktionen zurückgreifen.
Serverless
Serverless ist ein Konzept, das die vollständige Automatisierung von Diensten auf einer Plattform sowie die hochgradig reaktionsschnelle Flexibilisierung von Ressourcen umfasst. Die gesamte zusammengesetzte Anwendung basiert auf ereignisgesteuerten Interaktionen.
Große Cloud-Dienste wie AWS Lambda, Microsoft Azure Functions und Google Cloud Functions haben serverlose Funktionen in ihre Cloud-Plattformen integriert. Serverlose Funktionen ermöglichen es IT-Teams, mehrere Instanzen identischer Funktionen rund um den Globus in verschiedenen Rechenzentren auszuführen. Administratoren können Workloads in Echtzeit dorthin verlagern, wo ein Dienst am besten unterstützt werden kann, und neue Funktionen einführen, ohne die aktuelle Funktionalität zu Testzwecken oder zur Erfüllung der Anforderungen bestimmter Kunden zu opfern. Unternehmen können serverlose Funktionen in ihren eigenen Rechenzentrumsumgebungen nutzen, wenn diese als stark abstrahierte virtuelle Umgebungen konzipiert sind.
Serverlose Funktionen sind unabhängig von allem, was sie umgibt: Die Ressourcen – CPU, Speicher oder Netzwerk – sind alle abstrahiert. Die Verbindungen zwischen den Diensten werden durch lose Kopplung aufrechterhalten. Dies basiert auf Metadatenverzeichnissen und Codierungskonzepten in der Entwicklung.
Für das IT-Betriebsteam wird die Bereitstellung und Verwaltung dadurch einfacher. Solange IT-Administratoren das gewählte serverlose Orchestrierungssystem mit den richtigen Informationen füttern, wird es versuchen, automatisch das richtige Ergebnis zu erzielen. Dies wird als idempotenter Ansatz bezeichnet. Das System führt eine definierte Reihe von Aktionen aus, um ein bestimmtes Ergebnis zu erzielen.
Änderungen an der Plattform – sei es auf der physischen Ebene durch Hinzufügen von Ressourcen oder auf der virtuellen Ebene durch Verschieben von Diensten – werden alle automatisch verwaltet. IT-Administratoren können also eine neue Instanz eines Dienstes einrichten, und die Plattform erkennt sie. Administratoren können einen Dienst auch auf einen anderen Teil der Plattform oder auf eine völlig neue Plattform verschieben, ohne das System zu verwirren.
Anwendungsfälle für serverlose Microservices
Idempotenz ist das ideale Ergebnis. Sie muss jedoch im Lichte aller beteiligten Abhängigkeiten betrachtet werden. Wenn ein Microservice beispielsweise schlecht kodiert ist und physisch abhängige Aufrufe enthält, werden serverlose Funktionen nicht helfen – im Gegenteil, er wird bei der ersten Änderung zusammenbrechen.
Wenn viele Microservices eine zusammengesetzte Anwendung bilden, kann die Anzahl und Häufigkeit der Änderungen zu Leistungs- und Verwaltungsproblemen führen. Die Abhängigkeit von einzelnen Diensten wird nicht funktionieren. Serverlose Managementsysteme müssen Hochverfügbarkeit über mehrere Serviceinstanzen und Lastausgleich ermöglichen, wie sie AWS, Microsoft und Google in ihren Systemen implementiert haben. IT-Teams können diese Einrichtung mit zustandsloser Logik verwalten, das heißt sie sind nicht vom physischen Standort abhängig.
Serverless allein reagiert möglicherweise nicht schnell genug auf den Ressourcenbedarf von Microservices, was zu einer schlechten Leistung führt. Wenn der Änderungszyklus zu umfangreich oder zu schnell ist, kann diese Architektur die Audit-Fähigkeiten des Unternehmens beeinträchtigen und möglicherweise rechtliche Konsequenzen nach sich ziehen.
In solchen Fällen ist die Containerisierung ein besserer Ansatz. Die verfügbaren Container-Orchestrierungssysteme haben eine beträchtliche Zeit gebraucht, um zu reifen. Überwachung und Berichterstattung sowie die Erstellung und Verwaltung von Prüfpfaden gehören heute zu den Stärken von Containern. Die Elastizität der Ressourcenanwendung bei Containern ist in der modernen IT ein bekanntes Konzept. Insgesamt befinden sich Container in ihrer Entwicklung an einem reiferen Punkt als Serverless.
Das bedeutet jedoch nicht, dass Serverless, Microservices und Containerisierung sich gegenseitig ausschließen. Die Kombination der besten Aspekte dieser Ansätze – gut kodierte Microservices in Containern, die einfach bereitgestellt, überwacht und verwaltet werden können – führt zu einer schnelleren, flexibleren Gesamtplattform. Im Laufe der Zeit werden die Reifegrade beider Ansätze zusammenkommen und sich wahrscheinlich zu einer einzigen zusammengesetzten Anwendungsarchitektur verbinden.
