Damals, im Jahr 1983, als ich noch lernte, wie man auf meinem Apple ][e mittels PEEK und POKE direkt auf die Hardware zugreift, schloss sich eine Gruppe Gleichgesinnter aus der Computer- und Telekommunikationsbranche zusammen, um eine detaillierte Spezifikation zu erarbeiten, die sie Open Systems Interconnection (OSI) nannten. Was als Versuch begann, konkrete Schnittstellen auszuarbeiten, entwickelte sich schließlich zu einem gemeinsamen Referenzmodell, das wiederum von anderen – etwa der IETF – zur Entwicklung von Schnittstellen genutzt werden konnte. Diese Schnittstellen konnten schließlich zu Standards werden – und wurden es auch: IP, TCP, HTTP usw. …
Dieses Referenzmodell wurde den meisten von uns vermittelt, die sich an der Hochschule durch Informatikkurse gequält haben. Wir lernten die „sieben Schichten des OSI-Modells“ kennen, nur um später in der Praxis festzustellen, dass sich tatsächliche Implementierungen nur selten eindeutig dem OSI-Netzwerkmodell zuordnen lassen.
Dennoch lässt es sich gut genug auf die Praxis übertragen, sodass wir es weiterhin als das Referenzmodell verwenden, als das es gedacht war. Die meisten von uns verstehen, dass Schicht 4 für TCP, Schicht 7 für HTTP und die Schichten 2/3 für Ethernet und IP stehen. Die Begriffe sind nahezu austauschbar.
Vor einigen Jahren diskutierten wir sogar darüber, welcher Schicht die mit SDN und virtuellen Netzwerken verbundenen Overlay-Protokolle genau zuzuordnen seien. Sie gehörten weder wirklich zu Schicht 2 noch eindeutig zu Schicht 3. Sie lagen gewissermaßen dazwischen.
Das konnten wir größtenteils ignorieren, indem wir nur vage auf die beiden Schichten verwiesen und das Ganze schlicht als „Overlay Networking“ bezeichneten. Jeder wusste, was damit gemeint war, und wir hatten andere Dinge, über die wir streiten konnten – etwa die Definition von Cloud und die Frage, ob DevOps für Unternehmen geeignet war oder nicht.
Nun kommen Container ins Spiel – genauer gesagt: Container-Netzwerke. Die hochdynamische und automatisierte Welt der Container-Orchestrierungsumgebungen (COE) hat weitere Schichten im Netzwerk-Stack erforderlich gemacht.
Wie beim Overlay-Networking sind wir wenig geneigt, neue Schichten im OSI-Modell zu schaffen, denn schließlich ist es inzwischen ein Standardreferenzmodell, und Standards zu ändern, kann lange dauern. Sehr. Sehr. Sehr. Lange. Doch wie beim Overlay-Networking existieren diese Schichten weiterhin als eigenständige Schnittstellen im Netzwerk-Stack. Und wie beim Overlay-Networking neige ich dazu, ihnen „halbe“ Schichten zuzuweisen, weil sie für die Zukunft der Vernetzung in COE so wichtig sind.
SCHICHT 4.5: SERVICE MESH
Der erste „Halbschritt“ liegt zwischen den Schichten 4 und 5. Hier kommen die Ausführung und Automatisierung des Service Mesh ins Spiel. Kurz gesagt besteht ein Service Mesh aus als Sidecars bereitgestellten Proxys, die jede Anfrage abfangen. Dadurch können sie für Dienste in der gesamten Containerumgebung domänenspezifisches Routing durchführen. Dabei wird vorausgesetzt, dass Protokolle niedrigerer Schichten vorhanden sind, die dadurch effektiv erweitert werden. Dies ist notwendig, weil alle darunterliegenden Netzwerkschichten davon ausgehen, dass Konnektivität und Routing ausschließlich auf IP-Adressen basieren. Und obwohl dies letztlich bestimmt, wie Pakete in einer Containerumgebung übertragen werden, basiert die Entscheidung, an welche IP-Adresse und welchen Port eine bestimmte Anfrage gesendet wird, nicht auf diesen Informationen. Sie beruht auf einer Vielzahl von Variablen, die mit dem Status und dem Standort des Dienstes und der Anwendung zusammenhängen. Im Wesentlichen betrachten wir Metainformationen zu einer Anfrage und bestimmen anhand dieser, wie sie weitergeleitet werden soll. Diese Metainformationen sind entscheidend für den Aufbau des „Mesh“, das wiederum die Verfügbarkeit und Skalierbarkeit jedes Dienstes gewährleistet.
SCHICHT 7.5: SERVICE-TAGS
Der zweite „Halbschritt“ befindet sich weit oben, oberhalb von Schicht 7. Abgesehen von allen Scherzen über die „menschliche Schicht (Schicht 8)“ legt ein COE tatsächlich eine Metadatenschicht über die Anwendung, die als „Bindeglied“ fungiert und die Skalierung in containerisierten Umgebungen ermöglicht. Dabei handelt es sich um Anwendungs- oder Dienst-„Tags“, mit denen einzelne Dienste identifiziert werden, für die das COE eine automatische Skalierung bereitstellt. Ohne diese Tags ist es nahezu unmöglich, eine Anwendung von einer anderen zu unterscheiden. Das liegt daran, dass alle Schichten des OSI-Modells anhand bestimmter Merkmale wie IP-Adresse und Port identifiziert werden können. Architekturen, bei denen diese Merkmale außerhalb der Umgebung gemeinsam genutzt werden (virtuelle Server und hostbasierte Netzwerke), sind zwar seit Langem bekannt, doch Container haben dieselben Probleme auch innerhalb der Umgebung geschaffen. Durch die gemeinsame Nutzung von Ports und IP-Adressen ist es schwierig, Dienste mit der erforderlichen Geschwindigkeit voneinander zu unterscheiden.
Durch das Hinzufügen von „Tags“ auf Schicht 7,5 in containerisierten Umgebungen können Netzwerkdienste wie Lastverteilung und Routing Ressourcen eindeutig identifizieren und gleichzeitig Skalierbarkeit und Verfügbarkeit gewährleisten.
Die neuen „Container-Schichten“ ermöglichen es der Umgebung, sich von Netzwerkkonstrukten zu entkoppeln und dadurch eine höhere Portabilität zu gewährleisten als frühere Technologien, die weiterhin eng an andere Schichten des Netzwerk-Stacks gebunden waren. Indem containerisierte Umgebungen auf „Halbschichten“ operieren und die Existenz der herkömmlichen Schichten voraussetzen, werden sie von bestimmten Netzwerkkonzepten oder -architekturen unabhängig und können gleichermaßen problemlos zwischen Entwicklungs- und Testumgebung, Test- und Produktionsumgebung sowie lokaler Infrastruktur und Cloud verschoben werden.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...