Längst sind Container die Standard-Virtualisierung für Microservices geworden. Bei Softwareentwicklern deshalb beliebt und bei Cloud-Anwendungen somit allgegenwärtig. Tools zur Orchestrierung von Containern sind etabliert. Seit zwei, drei Jahren kommen mit Programmen wie Istio weitere Tools hinzu, die diese Orchestrierung der Container erweitern, um gezielt zwischen den Microservices zu routen, den Verkehr zu verschlüsseln und die Konnektivität zu überwachen.
Programme in autarke Teileinheiten aufzuteilen, die sich dann bei Bedarf gegenseitig aufrufen, ist nicht sonderlich neu. Wer erinnert sich an Sendmail? Es war Anfang der 90er gefühlt das Standardprogramm für den Mailversand und -empfang unter Unix und Linux, außerdem war es sicherheitstechnisch eine Katastrophe. Für ein Programm, das mit dem Internet verbunden ist, ist das kein haltbarer Zustand. Eine Alternative, die Ende der 90er auf den Open-Source-Markt kam, war Postfix. Ein wesentlicher Unterschied zu Sendmail ist der modulare Aufbau: Empfangen, Speichern, Abgleichen mit diversen Listen etc. wird bei Postfix von unterschiedlichen Dämonen übernommen. Diese kommunizieren untereinander über Queues oder über TCP/IP. Der Vorteil ist, dass der Code für diese Dämonen übersichtlicher ist als für das gesamte Projekt wie bei Sendmail. Bei Sicherheitsupdates müssen auch nur die betroffenen Dämonen gepatcht werden.
Dieser Trend weg von monolithischen Monsterprogrammen hin zu immer kleiner werdenden, mehr oder weniger autarken Diensten hält bis heute an. Insbesondere in der Cloud wird in vielen Projekten oft nur noch mit Microservices gearbeitet. Eine eng mit Microservices verknüpfte Technik sind Container. In den Containern laufen die von Programmierern geschriebenen Microservices. Da diese allein nur sehr selten bereits eine Anwendung darstellen, werden sie mit weiteren Services in anderen Containern, Datenbanken und ggf. anderen Cloud-Diensten zu einer Anwendung kombiniert. Dazu ist es notwendig, dass die Container untereinander und mit anderen Diensten Daten austauschen. Das geschieht über Netzwerkprotokolle und, sofern sie nicht auf demselben Host laufen, auch über das Netzwerk.
Vor- und Nachteile von Containern
Diese Architektur hat eine Reihe von Vorteilen:
Um nur einige der vielen Vorzüge zu nennen.
Paralleler Test- und Live-Betrieb
Aber Container haben auch Nachteile: ganz so einfach kann man Container nämlich nicht austauschen oder verschieben. Ebenso reicht es nicht aus, weitere Container zu starten, um einen erhöhten Bedarf bearbeiten zu können. Mit den Änderungen müssen oft auch Anpassungen an anderen Containern oder an Loadbalancern vorgenommen werden, um die Netzwerkkommunikation sicherzustellen. Startet man beispielsweise einen weiteren Container eines bereits laufenden Dienstes, so müssen die Loadbalancer entsprechend angepasst werden. Für eben diese Orchestrierung hat sich schon vor Längerem eine Reihe von Tools wie Kubernetes oder Apache Mesos durchgesetzt.
Mit der Nutzung von Microservices haben sich bei der Softwareentwicklung weitere Vorgehensweisen etabliert: so sollen „Canary Releases“ verhindern, dass es zum „Knall“ kommt. Der Name leitet sich von den Kanarienvögeln ab, die früher beim Bergbau mit in den Stollen genommen wurden und deren Tod die Bergarbeiter vor schlechter Luft warnen sollten. Bei Canary Releases werden einige Anwender zu den neuen Diensten geroutet, während alle anderen noch auf die Container mit den alten Diensten zugreifen. Wenn diese Anwender die Testphase „überleben“, so kann der Dienst für die Masse freigegeben werden. Ein ähnliches Verfahren ist der A/B-Test: dabei werden zwei Alternativen gegeneinander getestet, um zu sehen, welche besser ankommt. Beispielweise können für eine Webseite zwei unterschiedliche Designs angeboten werden, um herauszufinden, welches dem Publikum besser gefällt. Ebenso wäre es möglich, dass man User, je nach Browser, zu unterschiedlichen Diensten weiterleiten möchte, um das bestmögliche Ergebnis zu erzielen.
Abbildung 1: Routing durch Control- und Data-Plane im Service-Mesh
Microservices im Service-Mesh
Eine Orchestrierung allein reicht nicht aus, um das noch zu beherrschen. Zusätzlich benötigt man die Möglichkeit, eintreffende Anfragen gezielt nach bestimmten Kriterien (Username, IP-Adresse, Browsertyp…) routen zu können. Abbildung 1 zeigt wie so etwas im Kleinen aussehen kann: den Containern werden Proxies als „Sidecars“ zur Seite gestellt. Diese übernehmen die Kommunikation mit anderen Diensten und Containern. Der einzelne Container kommuniziert nur mit „seinem“ Proxy. So kann der Programmierer sich wieder ganz auf den Dienst konzentrieren, ohne etwaige Kommunikationsabhängigkeiten beachten zu müssen. Die Proxies werden durch die Control-Plane gesteuert. In den letzten zwei, drei Jahren sind dafür einige Programme auf den Markt gekommen, meist im Open-Source Umfeld. Istio ist wohl aktuell am bekanntesten, da es aus einer Verschmelzung der Ansätze von Google, IBM und Lyft hervorgegangen ist.
Neben der Verwaltung von Containern und dem Routing der Kommunikationsbeziehungen ermöglicht dieser Ansatz weitere Lösungen von Problemen, die mit der Containerisierung einhergegangen sind. Ein Beispiel wäre die zentrale Verteilung von Zertifikaten für eine TLS-verschlüsselte Kommunikation.
Wenn man sich Abbildung 1 anschaut, so denkt man als Netzwerker unwillkürlich an Software-defined Networking (SDN). Selbst die Begriffe „Control-Plane“ und „Data-Plane“ sowie „Routing“ tauchen auf. Und letztlich ist es auch genau das: ein Controller-gesteuertes, http-basiertes Overlay.
Bedenkt man, dass Container nicht auf die Cloud beschränkt sind, sondern auch Software im einen Rechenzentrum gemäß dem Microservice-Ansatz entwickelt wird, so muss man diese Entwicklung im Auge behalten, da sie unmittelbar Einfluss auf die bestehenden Sicherheitsarchitekturen, das Troubleshooting und den so genannten Ost-West-Traffic im Rechenzentrum hat.
Diese und viele weitere Zukunftsthemen, die Sie und uns in den kommenden Jahren beschäftigen werden, stellen wir Ihnen gerne auf unseren Technologietagen 2019 vor. Die Technologietage haben unter unseren Veranstaltungen das Alleinstellungsmerkmal der Anwesenheit fast des gesamten Teams aus erfahrenen ComConsult-Referenten. Dort haben Sie also die Gelegenheit, die für Sie interessanten Themen mit unseren jeweiligen Experten zu diskutieren.
ComConsult GmbH
Pascalstraße 27
DE-52076 Aachen
Telefon: 02408/951-0
Fax: 02408/951-200
E-Mail: info@comconsult.com
Sie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen