Container haben es satt, auf bestimmte Typen festgelegt zu werden

Thanksgiving und … Truthahn. Weihnachten und … Bäume. Container und … Microservices.

Wenn das erste Wort, das Ihnen zu jedem dieser Begriffe eingefallen ist, mit meinen Erwartungen übereinstimmt, sind Sie auf dem heutigen Technologiemarkt einer Überassoziation zum Opfer gefallen. Es besteht die Tendenz, in praktisch jeder Diskussion, bei der es um das eine oder das andere geht, Microservices sofort zusammen mit Containern zu nennen. Das liegt teilweise daran, dass Microservices, ein architektonischer Ansatz zur Zerlegung von Applications in fokussierte, agile Dienste, gut zur agilen Natur containerbasierter Bereitstellungsmodelle passt. Aber vergessen wir nicht, dass Container eine eigene Technologie sind. Sie existierten schon lange bevor Microservices für irgendjemanden zum architektonischen Augenzwinkern wurden und sie sind nicht darauf beschränkt, für die Bereitstellung von Apps auf Basis von Microservices von Vorteil zu sein.

Beachten Sie diesen Leckerbissen aus den Enterprise Development Trends 2016 , einer Umfrage unter 2.100 JVM-Entwicklern, aus der Lightbend (der sich selbst als stolzer Anbieter der weltweit führenden reaktiven Application bezeichnet) eine Reihe von Erkenntnissen zu den Themen Cloud, Container und Microservices gewann. Interessanterweise möchte die Mehrheit (59 %) brandneue Applications in Containern packen, während 41 % „vorhandene Applications“ in Containern konsolidieren möchten.

Dies ist überhaupt keine Anomalie. Ein kurzer Blick auf eine Umfrage von Mesosphere unter 500 Mesos-Benutzern vom August 2016 zeigt, dass 51 % monolithische und Legacy- Applications auf Mesos ausführen. 85 % verwenden, wie vielleicht erwartet, Microservices-Architekturen.

Container sind eindeutig nicht nur für neue Apps gedacht, sondern werden auch genutzt, um älteren und monolithischen Applications viele der Vorteile von Containern zu bieten, wie etwa Portabilität, schnelle Skalierbarkeit und eine bessere Anpassung an DevOps-gesteuerte Vorgänge. Schließlich wurde uns reibungslose Portabilität versprochen, was wir jedoch bekamen, waren lange Reimaging-Zeiten, da jeder öffentliche Cloud-Anbieter ein anderes Imaging-Format standardisierte. Die Pflege mehrerer Gold-Images (eines pro Umgebung, pro untergeordnetem Zweig, pro Hauptzweig, pro … Sie verstehen schon) wurde zu einem betrieblichen Albtraum. Behältern, wie dem Honigdachs, ist das egal. Sie wechseln von Betriebssystem zu Betriebssystem, von virtuelle Maschine zu virtuelle Maschine, von Cloud zu Cloud. Sie gehören zu den besten Möglichkeiten, die bislang angeboten wurden, um das Nirwana einer kostenbasierten, nahtlosen Cloud-Migration im Handumdrehen zu ermöglichen (das sind für diejenigen unter Ihnen, die mitgezählt haben, etwa 400 ms).

Dennoch sollten wir Container nicht als eine Art „Cloud“-Technologie bezeichnen. Zwar ermöglicht es sicherlich viele der lange angepriesenen, aber selten realisierten Portabilitäten zwischen Cloud-Anbietern, es ist jedoch nicht auf Cloud- oder sogar Cloud-ähnliche Umgebungen beschränkt. Container werden definitiv „in der Cloud“ verwendet, wie aus dem jüngsten Bericht von Sumo Logic hervorgeht. Darin wurde festgestellt, dass bei 15 % der untersuchten Apps Docker in der Produktion verwendet wird. Dies bedeutet jedoch nicht, dass Container nicht auch anderswo, beispielsweise vor Ort, verwendet werden. Tatsächlich wurde im oben erwähnten Mesosphere-Bericht festgestellt, dass fast die Hälfte (45 %) der Benutzer „nur vor Ort“ arbeitet, wobei die Mehrheit zwischen „Hybrid“- und „Nur-Cloud“-Benutzern aufgeteilt ist. Interessanterweise wurde auch festgestellt, dass „größere Unternehmen (mit 500 oder mehr Mitarbeitern) eher vor Ort arbeiten.“

Container sind eine interessante Bereitstellungsoption, die, wenn sie von Container-Orchestrierungslösungen (wie Docker, Docker Swarm, Mesos und Marathon, Kubernetes usw.) unterstützt werden, eine sehr agile Umgebung bieten, in der Applications automatisch bereitgestellt und nach oben und unten skaliert werden können. Es handelt sich dabei um eine Mikro-Cloud oder zumindest eine Cloud-ähnliche Umgebung, die in einer öffentlichen Cloud, einer privaten Cloud oder ohne jegliche „Cloud“ bereitgestellt werden kann. Mit Containern können monolithische Apps, moderne Apps, auf Microservices basierende Apps und APIs bereitgestellt und skaliert werden. Sie sind äußerst flexibel, da ihr Schwerpunkt auf der Normalisierung der Betriebssystemebene liegt, sodass Apps nicht eng an die Umgebung gekoppelt sind.

Container sind, um es kurz zu machen, eine Abstraktionsschicht, die es Apps ermöglicht, Honigdachse zu sein und sich nicht um Einzelheiten auf niedrigerer Ebene zu kümmern. Bei Überwachung und Verwaltung durch Container-Orchestrierungslösungen ermöglicht diese Abstraktion ein automatisches Hoch- und Herunterskalieren sowie Skalieren nach innen und außen, und zwar auf eine Weise, die für eine höhere Ressourceneffizienz in der gesamten Anwendungsinfrastruktur sorgt.

Container, Microservices und die Cloud mögen zwar beste Freunde sein, doch handelt es sich jeweils um individuelle Einheiten, die auch für sich allein bestehen können. Alle bieten Vorteile, die sich gegenseitig ergänzen und manchmal, wenn ich das sagen darf, Synergieeffekte miteinander erzeugen. Wir sollten Container jedoch nicht auf die sehr enge Form „nur“ für Microservices und „nur“ für die Cloud beschränken.

Container haben es satt, auf einen bestimmten Typ festgelegt zu werden. Lassen Sie sie in Ihren Architekturen verschiedene Rollen ausprobieren und Sie werden möglicherweise feststellen, dass sie mehr als in der Lage sind, in jeder davon eine führende Rolle zu spielen.