In diesem Artikel möchte ich die konzeptionellen Änderungen am Ambassador Pattern erläutern, die sich im gemeinsamen Microservices Projekt der LeanIX GmbH und der codecentric AG ergeben haben.
Docker bietet mit dem Konzept Docker Link die Möglichkeit, zwei Container miteinander per Netzwerk kommunizieren zu lassen. Dabei werden IP und exportierte Ports des Zielcontainers als Umgebungsvariablen im nutzenden Container zur Verfügung gestellt. Der Container, der den Link erzeugt, kann in seiner Konfiguration auf diese Umgebungsvariablen zugreifen und muss nicht IP und Port direkt verwenden.
Diese Möglichkeit besteht allerdings nur, wenn sich die Docker-Container auf dem gleichen Server befinden. Möchte man sie über mehrere Server verteilt verbinden, ist die einfachste Variante, die Docker-Container direkt über IP und Port zu verbinden:
Dies ist prinzipiell möglich, setzt aber eine sehr statische Umgebung voraus. Sollten sich IP oder Port des Zielcontainers ändern, müsste auch der zugreifende Container angepasst und neu gestartet werden.
Um auch in dynamischeren Umgebungen die Servergrenzen überwinden zu können, eignet sich das Ambassador Pattern. Die Flexibilität wird dabei in zwei Schritten erreicht: Es werden zwei zusätzliche Container, die Ambassadors eingefügt, die die Netzwerkkommunikation stellvertretend übernehmen. Der zweite Aspekt ist, dass die Ambassador Container ihre Konfiguration ändern können, ohne neu gestartet werden zu müssen. Die ursprünglichen Container greifen dabei wieder über einen Docker Link auf die Ambassador Container zu. Ich möchte in diesem Artikel nicht weiter auf die Details des Originalpatterns eingehen, sondern die Unterschiede erläutern, die wir in einem Projekt umgesetzt haben.
Zuerst einmal werfen wir einen Blick auf die beiden zusätzlichen Container. Viele Blogartikel im Internet erläutern den Aufbau des Ambassador Pattern wie folgt:
Der Simple Ambassador auf Server #2 übernimmt lediglich die Bereitstellung des Ports und reicht eingehende Verbindungen direkt an den DB Container weiter. Dieser Ambassador ermöglicht keine weitere Flexibilität oder Vereinfachung. Um dem KISS-Prinzip zu folgen, wird dieser Container gestrichen:
In manchen Artikeln wird der Simple Ambassador auch noch dazu verwendet, um mit etcd zu sprechen. Diese Aufgabe ist in einem eigenen Container besser aufgehoben bzw. kann auch von systemd, upstart oder ähnlichen Diensten übernommen werden. Um Funktionen zu kapseln, sollten die Ambassador Container nur die Aufgabe übernehmen, für die sie gedacht sind: Netzwerkkommunikation.
Eine weitere Änderung, die im Projekt gegenüber dem Originalpattern vorgenommen wurde, ist die Vorbereitung auf Skalierung. Im Original wird das Pattern mit einer 1:1-Beziehung zwischen Applikations- und Ambassador-Container dargestellt. Es gibt sogar Implementierungen des Patterns, die auch technisch nur eine 1:1-Beziehung ermöglichen. Verwendet man für den Dynamic Ambassador aber einen HAProxy, so kann man den Ambassador auch für dynamische Skalierung verwenden:
Es spielt dabei keine Rolle ob die Container auf einen oder mehrere Server verteilt sind. Dieses Konzept erlaubt an jeder Stelle einer Anwendung eine Skalierung und liefert somit eine sehr hohe Flexibilität und Ausnutzung der vorhandenen Serverressourcen.
Beide Änderungen am Originalpattern erlauben LeanIX somit die Komplexität ihrer Anwendung niedrig zu halten und an jeder Stelle nach Bedarf skalieren zu können.
Über die LeanIX GmbH :
LeanIX bietet eine innovative Lösung für das Enterprise Architecture Management (EAM) als Software-as-a-Service in der Public-Cloud oder im Rechenzentrum des Kunden. Die web-basierte Plattform besticht gegenüber traditionellen Ansätzen durch eine intuitive Benutzeroberfläche, ein flexibles Reporting und offene APIs. Dadurch lässt sich leanIX mit minimalem Trainingsaufwand schnell im Unternehmen einführen und nach kurzer Zeit Mehrwert generieren. Sowohl kleine bis mittlere als auch große Unternehmen aus verschiedenen Branchen vertrauen auf die Lösung, wie z.B. Axel Springer, Helvetia, RWE, Vaillant und Trusted Shops. Unabhängig von der Unternehmensgröße werden immer mehr Unternehmen als Kunden gewonnen, die bisher Berührungsängste mit dem Thema EAM hatten oder frustriert sind von schwerfälligen Tools. Gegründet wurde die LeanIX GmbH 2012 von Jörg G. Beyer und André Christ. Der Sitz der Gesellschaft befindet sich in Bonn, unterstützt von einem breiten Partnernetzwerk in Europa, Australien und Amerika.
Über die codecentric AG :
Als Experte für individuelle Software-Entwicklungen ist die codecentric AG der Vordenker für agile Software-Entwicklung und innovative Technologien in Deutschland. Rund 280 Mitarbeiter an dreizehn europäischen Standorten entwickeln Software-Lösungen der Zukunft. Dafür kombiniert codecentric das Know-how der besten IT-Architekten und Software-Entwickler mit dem Praxiswissen aus zahlreichen Projekten in den Bereichen Continuous Delivery, Big Data, Performance Solutions, Agile und Enterprise Development. Für optimale Java Performance, Skalierbarkeit und Stabilität haben codecentric-Kunden Zugriff auf umfassende Risiko-Management-, Troubleshooting-, Java-Optimierungs- und Performance-Management-Services nebst Werkzeugen.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Christian Zunker
9.8.2021 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Christian Zunker
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.