Die Softwareentwicklung hängt immer mehr von externen Abhängigkeiten (Dependencies) ab und die Häufigkeit der Deployments nimmt zu. Beide Trends zusammen sind schon eine Anforderung an die bestehenden Infrastrukturen. Ein weiteres Element, das die Bereitstellung von Software in einen Netzwerkengpass verwandelt, ist die Verwendung zusammengesetzter (compounded) Artefakte. Und der vierte Trend, der gegen uns arbeitet, ist die rapide ansteigende Anzahl von Geräten die als Konsumenten in Frage kommen. Alle diese Trends zusammen sind eine Herausforderung für die Infrastruktur. Aber was könnten wir dagegen tun?
Keine Zeit oder Lust zu lesen?Dann geht es hier zu der visuellen online Version auf meinem Youtube Kanal
Edge-Computing
Bevor wir uns die Beschleunigungsstrategien ansehen, werde ich den Begriff Edge oder besser Edge-Computing etwas erläutern, da dies in diesem Zusammenhang häufig verwendet wird.
Was ist Edge oder besser Edge-Computing?
Das Prinzip des Edge-Computing besagt, dass die Datenverarbeitung am Rand des Netzwerks stattfindet. Welches Gerät letztendlich für die Verarbeitung der Daten verantwortlich ist, kann je nach Anwendung und Umsetzung des Konzepts unterschiedlich sein.
Ein Edge-Gerät ist ein Gerät an der Netzwerkperipherie, das selbst Daten generiert, verarbeitet oder weiterleitet. Beispiele für Edge-Geräte sind Smartphones, autonome Fahrzeuge, Sensoren oder IoT-Geräte wie Feuermelder.
Ein Edge-Gateway wird zwischen dem Edge-Gerät und dem Netzwerk installiert. Es empfängt Daten von Edge-Geräten, die nicht in Echtzeit verarbeitet werden müssen, verarbeitet bestimmte Daten lokal oder selektiv und sendet die Daten an andere Dienste oder zentrale Rechenzentren. Edge-Gateways verfügen über drahtlose oder drahtgebundene Schnittstellen zu den Edge-Geräten und den Kommunikationsnetzwerken für private oder öffentliche Clouds.
Vorteile von Edge-Computing
Die Datenverarbeitung findet in der Nähe der Datenquelle statt, wodurch Übertragungs- und Antwortzeiten minimiert werden. Die Kommunikation ist nahezu in Echtzeit möglich. Gleichzeitig reduzieren sich der Datendurchsatz und die Bandbreitennutzung im Netzwerk, da nur bestimmte Daten, die nicht lokal verarbeitet werden sollen, an zentrale Rechenzentren übertragen werden müssen. Viele Funktionen können auch dann beibehalten werden, wenn das Netzwerk oder Teile des Netzwerks ausfallen – die Leistung von Edge-Computing lässt sich durch die Bereitstellung intelligenterer Geräte an der Netzwerkperipherie skalieren.
Nachteile von Edge-Computing
Edge-Computing bietet aufgrund der lokal begrenzten Datenspeicherung mehr Sicherheit. Dies ist jedoch nur dann der Fall, wenn für die dezentralen Geräte geeignete Sicherheitskonzepte verfügbar sind. Aufgrund der Heterogenität und vieler verschiedener Geräte steigt der Aufwand für die Implementierung der Sicherheitskonzepte.
Fog-Computing
Edge-Computing und Fog-Computing sind beide dezentrale Datenverarbeitungskonzepte. Fog-Computing fügt eine weitere Ebene mit den sogenannten Fog-Nodes zwischen den Edge-Geräten und der Cloud ein. Dies sind kleine lokale Rechenzentren in den Zugriffsbereichen der Cloud. Diese Nebelknoten sammeln die Daten von den Randgeräten. Sie wählen die Daten aus, die lokal oder dezentral verarbeitet werden sollen, und leiten sie an zentrale Server weiter oder verarbeiten sie direkt selbst. Wenn wir das Beste aus beiden Welten auswählen, kombinieren wir beide Prinzipien des Edge- und Fog-Computing.
Was sind die Beschleunigungsoptionen für die Software-Verteilung?
Es gibt verschiedene Strategien, um die Verteilung von Binärdateien zu skalieren, und jede Lösung passt zu einem bestimmten Anwendungsfall. Allerdings gibt es auch Umgebungen in denen nicht alle Möglichkeiten zur Verfügung stehen. Das kann die unterschiedlichsten Gründe haben, wie zum Beispiel nicht vorhandene Infrastruktur oder behördliche Vorschriften und Beschränkungen. Zusätzlich zu diesen Einschränkungen möchte ich die Notwendigkeit von Hybridlösungen hervorheben. Zu den Hybridlösungen gehören lokale Ressourcen sowie eine Infrastruktur mit air-gab, die für Hochsicherheitsumgebungen verwendet werden.
a) Benutzerdefinierte Lösung basierend auf Replikations- oder Skalierungsservern
Eine Möglichkeit zur Skalierung innerhalb Ihres Netzwerks / Ihrer Architektur besteht darin, die Hardware zu skalieren und mit der direkten Replikation zu arbeiten. Wenn Sie dies selbst implementieren, wird höchstwahrscheinlich ein höheres Budget an Arbeitskräften, Wissen, Zeit und Geld verbraucht, da dies kein triviales Projekt ist. Gleichzeitig ist dieser Ansatz an die Grenzen der Infrastruktur gebunden, auf die Sie Zugriff haben.
b) P2P-Netzwerke
Der Peer-to-Peer-Ansatz impliziert, dass Sie eine Reihe von Kopien Ihrer Dateien haben. Wenn Sie eine Datei aus dem Netzwerk herunterladen, können alle Knoten Teile unabhängig voneinander bereitstellen. Dieser Ansatz, Dateien aufzuteilen und gleichzeitig von verschiedenen Knoten an den anfordernden Knoten zu liefern, führt zu einer konstanten und effizienten Netzwerknutzung und reduzierten Downloadzeiten.
c) CDN – Content-Delivery-Network
CDNs sind optimiert, um große Dateien über Regionen hinweg zu liefern. Das Netzwerk selbst besteht aus einer großen Anzahl von Knoten, die Dateien für die regionale Bereitstellung zwischenspeichern. Mit dieser Strategie wird der ursprüngliche Server signifikant entlastet.
Schauen Sie sich auf meinem Youtube-Kanaldas Video DevSecOps – Low hanging Fruits an.
Dieses Video beschreibt das Verhältnis zwischen dem eigenen Quelltexten und denhinzugefügten Abhängigkeiten und was dies für DevSecOps bedeutet.
Die JFrog-Lösung
Mit den drei genannten Techniken können Sie eine riesige und leistungsstarke Architektur aufbauen, die Ihren Anforderungen entspricht. Die Integration all dieser Technologien und die Implementierung von Produkten ist jedoch nicht einfach. JFrog hat im Laufe der Jahre Lösungen gefunden und in eine DevSecOps-Plattform namens The JFrog Platform integriert. In diesem Artikel möchte ich mich auf die Komponenten konzentrieren, die nur für die Verteilung der Binärdateien verantwortlich sind.
JFrog-Distribution
Bei der JFrog-Verteilung wird das Wissen über den Inhalt der Repositories und die entsprechenden Metadaten verwendet, um eine Replikationsstrategie bereitzustellen. Die Replikationslösung wurde für interne und externe Repositories entwickelt, um die Binärdateien an den Ort zu bringen, an dem sie benötigt werden. Die Infrastruktur kann in einem Hybridmodell aufgebaut werden, einschließlich On-Prem- und Cloud-Knoten. Mit Import- / Exportmechanismen sind sogar Lösungen mit air-gap möglich. In diesem Szenario jedoch konzentrieren wir uns auf einen skalierbaren Caching-Mechanismus, der für Lesevorgänge optimiert ist.
Was ist ein Release-Bundle?
Ein Release-Bundle besteht aus Binärdateien. Diese Binärdateien können von unterschiedlicher Art sein, z. B. Maven, Debian oder Docker. Das Release-Bundle kann als Stückliste (BOM – Bills of Material) angesehen werden. Der Inhalt und die Release-Bundles selbst sind unveränderlich. Diese Unveränderlichkeit ermöglicht die Implementierung effizienter Caching- und Replikationsmechanismen in verschiedenen Netzwerken und Regionen.
Was ist in diesem Zusammenhang ein Edge-Node?
Ein Edge-Knoten ist in unserem Kontext ein Knoten, der die Funktionalität einer schreibgeschützten Artifactory-Instanz bereitstellt. Mit diesem Edge-Knoten wird der Übermittlungsprozess optimiert, und wir werden sehen, dass die Replikation auf transaktionale Weise erfolgt. Der Unterschied zur ursprünglichen Bedeutung eines Edge-Nodes besteht darin, dass diese Instanz nicht das konsumierende oder produzierende Element ist. Dies kann als Fog-Node angesehen werden, beziehungsweise die erste Schicht über der Ebene der realen Konsumenten.
P2P-Download
Die P2P-Lösung konzentriert sich auf Umgebungen, die Download-Bursts innerhalb desselben Netzwerks oder derselben Region verarbeiten müssen. Diese Download-Bursts können Szenarien wie Aktualisieren einer Serverfarm oder Aktualisieren eines Microservice-Netzes sein. Die Verwendung ist unidirektional, was bedeutet, dass der Verbraucher nicht von seiner Seite aus aktualisiert, sondern lediglich konsumiert. Sie warten nur auf eine neue Version und alle Verbraucher aktualisieren gleichzeitig. Diese Anforderung ist perfekt für die P2P-Lösung.
Der Verbraucher selbst fordert die Binärdatei vom P2P-Knoten und nicht mehr von der Artifactory-Instanz an.
Die verantwortliche Artifactory-Instanz verwaltet die P2P-Knoten. Beachten Sie, dass der RBAC auch an den P2P-Knoten aktiv ist.
CDN-Verteilung
Die CDN-Lösung ist optimiert, um Binärdateien in verschiedene Teile der Welt zu liefern. Dieses gibt es in zwei verschiedenen Ausprägungen. Eine ist für die Öffentlichkeit bestimmt und wird hauptsächlich zum Verteilen von SDKs, Treibern oder anderen frei verfügbaren Binärdateien verwendet. Die andere Variante konzentriert sich auf die Bereitstellung in einem privaten Umfeld.
Unabhängig davon, welche Lösung Sie verwenden, wird der im Zugriffsmodul definierte RBAC eingehalten, einschließlich Lösungen mit Authentifizierung und Autorisierung sowie eindeutiger Links mit integriertem Zugriffstoken.
Fazit
Mit der zunehmenden Anzahl von Abhängigkeiten, einer höheren Häufigkeit von Bereitstellungen und der ständig wachsenden Anzahl von Anwendungen und Edge-Nodes stehen wir vor Herausforderungen hinsichtlich der Skalierbarkeit.
Drei Möglichkeiten, wie Sie Ihre Wertschöpfungskette an dieser Stelle erhöhen können:
Die gezeigte Lösung basiert auf
a) JFrog Distribution hilft Ihnen beim Aufbau einer starken Replikationsstrategie innerhalb Ihrer Hybridinfrastruktur, um den Entwicklungszyklus zu beschleunigen.
b) JFrog P2P, mit dem Sie massive Download-Bursts innerhalb eines Netzwerks oder einer Region verarbeiten können. Diese Lösung eignet sich für Aufgaben, bei denen Binärdateien während Download-Bursts gleichzeitig an eine große Anzahl von Verbrauchern lokal verteilt werden müssen.
c) JFrog CDN liefert Binärdateien weltweit in regionale Rechenzentren, was zu einer globalen Caching-Struktur führt.
Alles zusammen ist in der JFrog-Platform gebündelt. Natürlich kann man auch diese Strukturen aus einzelnen Komponenten selber abbilden. Hier sollte man allerdings die daraus resultierenden Aufwände genau gegenrechnen.
Cheers
Sven Ruppert
Sven Ruppert entwickelt seit 1996 in Java an Industrieprojekten. Er war über 15 Jahre als Berater weltweit in Branchen wie Automobil, Raumfahrt, Versicherungen, Bankwesen, UNO und WorldBank tätig.
Sven ist Groundbreaker Ambassador (ehem. Oracle Developer Champion) und arbeitet als Developer-Advocate für JFrog. Er spricht regelmäßig auf Konferenzen weltweit und schreibt für IT-Zeitschriften sowie Tech-Portalen.
Neben seinem Hauptthema DevSecOps und den Evergreen-Themen Core-Java und Kotlin arbeitet er an Mutationstests von Web-Apps und Distributed UnitTesting.