Microservices und die Zukunft

Service Mesh, Istio und Co.: Was ist das eigentlich?

Ranga Rajagopalan

© Shutterstock / ktsdesign

Was ist eigentlich ein Service Mesh? Ranga Rajagopalan, CTO und Mitbegründer von Avi Networks, gibt einen kurzen Überblick darüber, was hinter dem Begriff steht und wofür das Open-Source-Tool Istio eingesetzt wird. Er geht dabei zudem auf die Notwendigkeit und die Zukunft eines Service Mesh für Cloud-basierte Anwendungen ein.

Cloud-basierte Anwendungen, heutzutage realisiert in Containern und Microservices, haben technologisch sehr viele Vorteile zu bieten. Die meisten Vorteile ergeben sich aus ihrer Fähigkeit, Entwicklungs- und Testprozesse zu beschleunigen. Verschiebt man diese Anwendungen jedoch aus der sicheren Dev&Test-Sandbox in die reale Produktion, kommen regelmäßig Probleme in Bezug auf Skalierbarkeit, Sicherheit und Verwaltung zum Vorschein, die die Vorteile wieder aufwiegen können. Die Lösung für dieses Problem ist ein Service Mesh. Ein Service Mesh ist jedoch keine Lösung, kein Produkt, das man einfach einkauft und dem System hinzufügt, um die Produktion für Cloud-native Komponenten vorzubereiten. Ein Service Mesh ist vielmehr eine Art Rahmen, innerhalb dessen Cloud-native Komponenten, mit ihren benötigten Diensten verbunden werden können, und das auf unterschiedliche Weise bereitgestellt werden kann.

Effektive Verwaltung Cloud-basierter Anwendungen mit dem Service Mesh

Skalierbarkeit ist eines der größeren Probleme Cloud-basierter Technologien, die Anwendungen in viele kleine Teile (Microservices) zerlegen, welche jeweils in einer eigenen schlanken und sehr portablen virtuellen Umgebung (Container) untergebracht sind. Während eine herkömmliche Anwendung eine Handvoll virtueller Maschinen umfassen kann, kann eine native Cloud-Applikation eine Sammlung von Hunderten oder sogar Tausenden von Microservices umfassen, die jeweils in einem eigenen Container irgendwo in einer hybriden Cloud-Infrastruktur laufen.

Container haben den Vorteil, dass sie sehr schnell ein- und ausgeschaltet, gepatcht, aktualisiert und verschoben werden können, ohne die Verfügbarkeit der gesamten Anwendung zu beeinträchtigen. Jeder Container muss jedoch seine begleitenden Komponenten und gemeinsame Load-Balancing-, Management-, Sicherheits- und andere Anwendungsdienste suchen und mit ihnen kommunizieren. Das ist angesichts der schieren Anzahl der beteiligten Container und ihrer potenziell hohen Änderungsrate alles andere als einfach.

Dieses Bedürfnis nach Kommunikation kann cloudbasierte Anwendungen zu einem Verwaltungsalbtraum machen, versucht man sie auf traditionelle Art zu skalieren. Hier setzt das Service Mesh an, das eine eigene Infrastrukturebene für Anwendungsdienste darstellt. Es verbindet die einzelnen Teile cloudbasierter Anwendungen effektiv, indem es ein zentral verwaltetes Service-Ökosystem bereitstellt. Dieses Ökosystem steht Containern zur Verfügung, die so einfach ihre Dienste erhalten und ihre Aufgabe erledigen können.

Der Stand der Dinge des Service Mesh

So viel zur Theorie, was ein Service Mesh ist. Noch entwickelt sich der Markt für diese Technologie und bis zur umfassenden Produktionsreife gibt es noch viel zu tun, sowohl von Technologieanbietern im Bereich der Bereitstellung von Anwendungsdiensten (insbesondere Application Delivery, Traffic- und Security-Management) als auch auf der Seite der namenhaften Cloud-Anbieter.

Auch eine Reihe proprietärer „Produkte“ wurden vorgestellt, wobei das vielversprechendste wohl die Open-Source-Initiative Istio darstellt. Ursprünglich von Google, IBM und Lyft gestartet, wächst die Liste anderer bekannter Unternehmen, die zur Entwicklung von Istio beitragen ständig. Darunter weitere Schwergewichte der Industrie wie Cisco, Pivotal, Red Hat und VMware. Diese Kombination aus etablierten Technologieriesen und innovativen Startups wird Istios Service Mesh weiter fördern und entwickeln, um kontinuierlich mehr Funktionen und Anwendungen zu unterstützen. Dank dieser Unterstützung ist Istio heute fast gleichbedeutend mit „Service Mesh“, genau wie Kubernetes mit „Container-Orchestrierung“. Nicht zufällig sind die ersten Implementierungen von Istio sehr stark an Kubernetes und die native Anwendungsarchitektur der Cloud gebunden und innerhalb eines Kubernetes-Clusters kann ein Istio Service Mesh bereits heute schon sinnvoll eingesetzt werden.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Der Nutzen der Technologie wird über Kubernetes hinaus weiter wachsen. Und durch die Erweiterung von Istio mit anderen bewährten Technologien wird man irgendwann in nicht allzu ferner Zukunft problemlos eine Cluster- und sogar Cloud-übergreifende Kommunikation zwischen cloudbasierten Anwendungen und ihren Diensten durchführen können. Dies öffnet die Tür, um den Wert des Service Mesh dann auf alle bestehenden Anwendungen im Rechenzentrum anwenden zu können. Die Idee granularer Anwendungsdienste, die in der Nähe der Anwendung bereitgestellt werden, lässt sich nämlich auch problemlos auf traditionelle Anwendungen anwenden, die auf virtuellen Maschinen oder Bare-Metal-Infrastrukturen laufen.

Fazit

Aufgrund der Zersplitterung von Anwendungskomponenten durch die containerisierte Microservices-Architektur wird die Bereitstellung von Anwendungsdiensten über ein Service Mesh, über kurz oder lang, zur Notwendigkeit. Sie wird wohl schon bald, über Kubernetes Cluster hinaus, über alle Anwendungsarten hinweg allgegenwärtig werden.

Unternehmen, die Cloud-basierte Technologien einsetzen wollen, werden mit ziemlicher Sicherheit ein Service Mesh benötigen. Derzeit sieht es danach aus, als würde Istio das Rennen machen und das Service Mesh der Zukunft sein. Ganz unabhängig vom Format muss ein gewähltes Service Mesh jedoch einen Mehrwert bieten, der zu neuen und bestehenden Anwendungen passt.

Geschrieben von
Ranga Rajagopalan

In den letzten 15 Jahren vor der Mitbegründung von Avi Networks war Ranga Architekt und Entwickler mehrerer leistungsstarker verteilter Betriebssysteme sowie Netzwerk- und Speicher-Rechenzentrumsprodukte. Vor seiner jetzigen Funktion als CTO war er Senior Director bei Cisco’s Data Center Business Unit, verantwortlich für Plattform-Software der Nexus 7000 Produktlinie. Ranga kam durch die Übernahme von Andiamo zu Cisco, wo er einer der führenden Architekten für das SAN-OS-Betriebssystem war, und begann seine Karriere bei SGI als IRIX-Kernelingenieur für die Origin-Serie der ccNUMA-Server. Begonnen hat er seine Reise mit einem Master of Science-Abschluss in Elektrotechnik von der Stanford University und einem Bachelor of Engineering in EEE von BITS, Pilani, Indien, und verfügt nun über mehrere Patente im Bereich Networking und Storage.

Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: