Inhaltsübersicht
Einleitung
Die Definition des Edge ist seit jeher mit der Evolution der Rechenzentrumsarchitektur verwoben. In den letzten zehn Jahren hat sich die Architektur der Unternehmensinfrastruktur rasant verändert, von lokalen Rechenzentren hin zu den heutigen verteilten Cloudarchitekturen. Wir sehen Edge 2.0 als einen technologischen Wandel, der es Anwendungen ermöglicht, eine verteilte Cloud-Architektur zu nutzen.
Jede Person, Organisation oder Einrichtung hat ein anderes Verständnis des Begriffs „Edge“. Für die einen ist der Edge ein Mobilfunkmast, für die anderen ihr mobiles Gerät. Für Cloud-Service-Provider (CSPs) ist der Edge eine verwaltete Infrastruktur, die sich nahtlos in ihr Backend integriert. Für militärische Anwendungen ist der Edge der Ort des Geschehens, sei es zu Lande, zu Wasser oder in der Luft. Wenn wir über den Edge lesen, wird er im Allgemeinen als Rechen-, Netzwerk- und Speicherressourcen der Infrastruktur und/oder deren Standort betrachtet.
Wir sehen Edge 2.0 aber auch als die Erfahrung, die es allen Beteiligten im Ökosystem bietet, nicht nur als Infrastrukturanlage oder deren Standort.
In diesem Dokument wird beschrieben, welche Funktionalität der Edge 2.0 bieten sollte, unabhängig von seiner physischen oder virtuellen Infrastruktur oder davon, wo er sich befindet oder instanziiert wird. Es geht nicht darum, zu erklären, wie man eine bessere verteilte Anwendung erstellt, sondern darum, die Funktionen zu beleuchten, die im Edge 2.0 vorhanden sein müssen, um die Erstellung optimaler verteilter Anwendungen zu unterstützen, die eine gegebene Anforderung erfüllen.
Was ist Edge 2.0?
Aus der Sicht einer Entität, die sich in dieser verteilten Cloud befindet, ist der Edge der Ort, an dem sich die Einheit gerade befindet. Wir schlagen daher eine Definition von Edge 2.0 vor, die sich hauptsächlich an der Erfahrung orientiert und nicht nur an den Standort der Infrastruktur, die Art der Infrastruktur oder die kontrollierende Entität gebunden ist.
Der Schwerpunkt von Edge 2.0 liegt auf der Verbesserung der anwendungs-, betriebs- und entwicklerzentrischen Erfahrungen. Der Edge 2.0 muss die Meta-Eigenschaften (wie SLAs und SLOs) der Anwendung berücksichtigen, indem es sich an die wechselnden Anforderungen der Anwendung anpasst. Edge 2.0 muss einfach zu bedienen sein und die Operationsteams von der Erstellung neuer Automatisierungen für jede verteilte Anwendung entlasten. Edge 2.0 muss die Reibung für Entwickler bei der Entwicklung und Bereitstellung verteilter Anwendungen stark reduzieren, indem es nahtlos Sicherheits-, Governance- und Service-Level-Ziele unterstützt.
Nehmen wir als Beispiel eine Bankanwendung. Das Ziel von Edge 2.0 besteht nicht darin, die geschäftliche Logik der Transaktion zu verbessern. Es geht darum, sie je nach Anforderung sicherer, schneller, privater, geografisch übergreifend nutzbar und je nach Bedarf zur Unterstützung der Geschäftsziele nach oben oder unten skalierbar zu machen.
Konzepte und Aussagen
Im Folgenden werden die wichtigsten Begriffe und Aussagen dieses Papers erläutert:
- Erfahrungszentrischer Edge: Grundlage für Edge 2.0 ist die gelieferte Erfahrung und nicht Infrastruktur oder ihre Standorte.
- Designüberlegungen: Wichtige Designüberlegungen für eine erfolgreiche Implementierung der Edge-2.0-Architektur.
- Heterogene Infrastruktur: Die Entwicklung einer verteilten Cloud erfordert eine dezentralisierte Kontrolle der Infrastruktur.
- Telemetrie als Grundlage: Telemetrie ist ein grundlegender Baustein, der auf allen Ebenen der Infrastruktur unterstützt werden muss. Keine Telemetrie bedeutet die Verwässerung einer datenzentrischen Strategie.
- Herausforderung clusterübergreifendes Computing: Eine grundlegende Herausforderung des Edge 2.0 besteht darin, dass er clusterübergreifend statt clusterintern ist.
- Adaptive Schnittstellen: Einführung in die adaptiven Schnittstellen und deutlicher Vergleich mit deklarativen und imperativen Schnittstellen.
- Edge 2.0-Anwendungsplattform (EAP): Vorstellung der EAP als Framework, mit dem der Edge 2.0 sich an die Anforderungen der Anwendungen anpassen kann.
Nicht behandelte Themen
Es gibt mehrere Themen, die wir in diesem Paper noch nicht behandelt haben:
- Verteilung von Anwendungsdaten: Hier gibt es viele Unterthemen wie Content Delivery Networks (CDNs), Storage-Verteilung, Datenverteilung, Caching usw. Es gibt auch neue Technologien wie Conflict-free Replicated Datatype (CRDT). Ein Edge-2.0-Framework sollte auch die Verteilung von Anwendungsdaten in seinem Geltungsbereich unterstützen.
- Verteilung von Funktionen: Die Weiterentwicklung des Edge-Compute kann als Verlagerung von Cloud-Kernfunktionen und -Logik näher an den Ereignis- oder Datenspeicherort betrachtet werden. Wenn wir die beträchtliche Menge an Rechenleistung, die am Edge verfügbar wird, nutzen wollen, sollten wir jetzt ähnliche Probleme lösen wie sie in Legacy-Cloud-Architekturen zu lösen sind. Zum Beispiel Overlay Networking, Middleware-Workloads und andere Arten von Workloads, die miteinander verflochten und komplexer sind als die ursprünglichen Anwendungsfälle der frühen Edge-Architekturen – zum Beispiel Storlets, die zustandslose, einfache Flows sind, die neben den Daten ausgeführt werden.
- Wahrscheinlich gibt es noch weitere Bereiche, die nicht erörtert wurden. Das Ziel des Frameworks ist es, so erweiterbar zu sein, dass die Zuständigkeiten je nach Bedarf hinzugefügt werden können.
Evolution des Edge
Abbildung 1 veranschaulicht die gemeinsame Entwicklung der Edge- und Rechenzentrumsarchitekturen. Edge 1.0 und 1.5 basierten auf dem Konzept eines Ursprungsstandorts und der Verlagerung der Daten und Dienste vom Ursprung zum Verbraucher. Edge 1.0 war die Bereitstellung einer Internet-Infrastruktur, die sich in erster Linie auf die Optimierung der Bandbreitennutzung mit verteiltem Content-Caching, auch bekannt als Content Distribution Networks, konzentrierte. CDNs sind ein grundlegendes Entwurfsmuster, da die Summe der zu übertragenden Inhalte immer größer ist als die verfügbare Bandbreite.
Als die CPU- und Speicherkosten immer weiter sanken, entstanden Rechenfarmen mit CDN-Knoten. Anwendungen wurden als Dienste über serviceorientierte Architekturen (SOA, Service Oriented Architecture) genutzt. Daher kann Edge 1.5 als Service Distribution Network bezeichnet werden.
Ein gemeinsames Merkmal von Edge 1.0 und Edge 1.5 ist die Idee eines Ursprungsstandorts. Vor dem Mobilgeräte-Boom luden Menschen, Geräte und Dinge in erster Linie Inhalte herunter oder fungierten als Verbraucher des Dienstes. Der Standort, von dem aus der Dienst erbracht wurde, unterschied sich noch von dem des Verbrauchers.
Bei Edge 2.0 kann jedoch jede Entität als Ursprungsort oder als Verbraucher auftreten. Der Datenverkehrsfluss hat sich verändert. Menschen, Handys und Geräte produzieren aktiv Daten, wenn sie Inhalte hochladen oder regelmäßige Daten erzeugen. Anwendungen werden zu Verbrauchern, da sie von anderen Anwendungen abhängig sind. Alle Entitäten können als Produzenten oder Konsumenten eines Dienstes agieren – APIs, Menschen, IoT-Geräte oder Web-, Backend- und Headless-Anwendungen. Aus eigener Sicht befindet sich jede in der Infrastruktur befindliche Entität am Edge.
Die verteilte Cloud ist die neueste Stufe in der Entwicklung des Rechenzentrums. Die Datenverarbeitung ist inzwischen wirklich allgegenwärtig, von mobilen Geräten bis hin zu Alltagsgegenständen, die mit dem Netz verbunden sind. Parallel dazu haben sich Softwarearchitekturen entwickelt, die verteilte und skalierbare Anwendungen ermöglichen.
Folge des Edge: erhöhte Komplexität
Die äußerst starke Verteilung von Rechen- und Speicherkapazitäten an jedem Ort hat die Möglichkeit für eine schnelle digitale Transformation des Unternehmens geschaffen. Doch diese rasante Entwicklung hat ihre Folgen.
Die meisten Unternehmen bestehen in der Regel aus heterogenen Infrastrukturen mit uneinheitlichen Umgebungen. Die effektive Skalierung solcher Umgebungen erfordert eine komplexe Orchestrierung und Automatisierung der bereitgestellten Systeme. Schnelle Änderungen der Anwendungsanforderungen, wie z. B. Änderungen der CPU- und Bandbreitenanforderungen, erhöhen die Komplexität des Betriebs in einer verteilten Cloud. Dies bedeutet eine zusätzliche Belastung für die Operationsteams, die möglicherweise nicht gut gerüstet sind, um effizient auf die sich ändernden Anforderungen der Anwendung oder des Endkunden zu reagieren.
Durch diese Probleme entsteht betriebstechnische Komplexität, die alle potenziellen Vorteile für ein Unternehmen, das die digitale Transformation durchläuft, zunichte macht.
Einige der miteinander verflochtenen Probleme und Artefakte, die durch Komplexität entstehen, werden im Folgenden vorgestellt.
Hybride Clouds bedeuten eine größere Angriffsfläche die durch eine Vielzahl von Angriffsvektoren anfällig ist. Unterschiedliche Anwendungsbereiche verursachen verschiedene Sicherheitsherausforderungen, und da sich die Infrastruktur weiterentwickelt, ist es schwer, Schritt zu halten. Es stellt sich also folgende Frage: Werden sich nur die Technologieempfehlungen häufig ändern, oder werden sich auch die Entwurfsmuster für die Implementierung der Sicherheit ändern?
Hier sind einige der Probleme mit den bestehenden Ansätzen:
- Software Defined Perimeter (SDP) sind nicht einfach zu skalieren, da die gängigen Lösungen agentenbasiert und daher nicht einfach zu implementieren sind.
- Die Implementierung von Zero Trust Network Access (ZTNA) ist oft nicht praktikabel, da ZTNA-Lösungen eine Konstellation von implementierten Produktionsdiensten wie Traffic Inspection, zentralisierte Protokollverwaltung, globale PKI, Identitätsmanagement und weiteres erfordern.
- Secure Access Service Edge (SASE) kombiniert Network-as-a-Service und Security-as-a-Service, eine Kombination aus mehreren Technologien, die nicht trivial zu implementieren sind. Darüber hinaus liegt der Schwerpunkt von SASE auf Software-definierten Wide-Area-Netzwerken (SD-WAN), die nur einen kleinen Teil der Edge-Anwendungsfälle im Unternehmensnetzwerk abdecken.
- Durch unterschiedliche Infrastrukturen verschiedener Public-Cloud-Anbieter und bereits komplexe Sicherheitsmodelle, z. B. für die Identitäts- und Zugriffsverwaltung (IAM, Identity and Access Management), ist die Sicherheitshärtung häufig ein Flickenteppich aus Lösungen verschiedener Anbieter und umständlicher Multi-Cloud-Konfigurationen.
Eine der größten Herausforderungen der Nutzung hochgradig verteilter, energie- und kostensparender Rechenleistung am Edge ist die Fähigkeit, die Infrastruktur einheitlich zu orchestrieren und zu planen. Mit der Skalierung und Unterstützung von Anwendungen, die die verteilte Cloud nutzen, haben Ops-Teams oft hart zu kämpfen, da diese Anwendungen in der Regel heterogene Technologien mit unterschiedlichen Verwaltungsanforderungen umfassen.
Zwar stellen Automatisierungsplattformen wie Terraform ein ausgeklügeltes Mittel zur Anpassung der Automatisierung dar, doch müssen Ops-Teams immer noch Skripte für mehrere Permutationen pflegen: zum Beispiel fünf verschiedene Arten von Compute-Ressourcen, vier verschiedene Arten von Firewalls und drei Arten von Lastenausgleichen. Die Personalkosten für die Verwaltung und Pflege der Automatisierungsskripte skalieren nicht.
Dies führt dazu, dass der Infrastrukturkunde weiterhin über ticketgesteuerte Systeme mit den Betriebsteams interagiert, die ein Hindernis für die Automatisierung bestehender Arbeitsabläufe darstellen. Der Servicedesk wird mit Tickets überhäuft und muss der Sicherheit und Stabilität Vorrang vor der Agilität einräumen.
Microservices-Architekturen sind mit der Entwicklung hin zu Multi-Cloud bereits zum De-facto-Standard für die Entwicklung neuer Anwendungen geworden. APIs werden veröffentlicht und können jederzeit und überall instanziiert werden, was zu einem API-Wildwuchs führt. Die Erkennung, Konnektivität und Verwaltung dieser APIs auf autonome Weise wird zu einer großen Herausforderung.
Es ist ein Paradigmenwechsel erforderlich, um dem API-Wildwuchs entgegenzuwirken. Unsere internen Modelle zeigen, dass selbst moderate Annahmen von Parametern, wie die Anzahl der weltweiten API-Entwickler, die Anzahl der pro Entwickler pro Jahr entwickelten APIs und die API-Lebensdauer, dazu führen, dass bis 2030 mehrere hundert Millionen (wenn nicht Milliarden) APIs gleichzeitig aktiv sein werden (Abbildung 2). Der Bericht zum API-Wildwuchs von 2021 bietet einen umfassenden Überblick über dieses aufkommende Thema.
Wegen der zunehmenden Komplexität brauchen Unternehmen eine granulare und aussagekräftige Sichtbarkeit des Gesamtsystems. In verteilten Cloud-Umgebungen durchlaufen Anwendungen mehrere heterogene Infrastrukturen, die von unterschiedlichen Unternehmen verwaltet werden.
Darüber hinaus hat heute keiner der Betreiber einen Anreiz, den Unternehmenskunden über ihre Infrastruktur native Telemetriedaten zur Verfügung zu stellen. Unternehmen sind bei der Bereitstellung von Anwendungen in einer verteilten Cloud im Grunde blind und müssen auf mehrere Überwachungstools zurückgreifen. Um diese blinden Flecken zu schließen, stammen die Tools in der Regel von verschiedenen Anbietern, die an unterschiedlichen Stellen in der Infrastruktur oder in den Anwendungs-Stacks arbeiten.
Nicht standardisierte Infrastrukturmetriken verschlimmern die Probleme innerhalb eines Unternehmens. In der Regel sind die Metriken aufgrund von Technologiesilos und anderen Faktoren wie uneinheitlicher Infrastruktur in verschiedenen Infrastrukturumgebungen nicht einheitlich. So unterscheiden sich beispielsweise die Metriken von Public-Cloud-Anbietern, und auch die vor Ort eingesetzten Rechenzentrumstechnologien folgen keinen Standards für Metriken.
Geschäftsergebnis: Verschlechtertes Erlebnis
Umsatzbringende Workloads und unternehmenskritische Systeme beanspruchen in der Regel den größten Teil der betriebstechnischen Ressourcen und des Budgets, die in einem Unternehmen zur Verfügung stehen. Hingegen machen kleinere Projekte, auch wenn sie weniger komplex sind, in der Regel den größten Teil der Unternehmensanwendungen aus. In Abbildung 3 ist dies als Long-Tail-Verteilung der Anzahl der Projekte dargestellt, die ein Unternehmen im Vergleich zu seiner betrieblichen Komplexität wahrscheinlich hat.
Kleinere Anwendungen mögen zwar eine geringere Komplexität im Betrieb aufweisen, aber die Prozesse und Arbeitsabläufe zur Inbetriebnahme sind in vielen Fällen immer noch manuell, und es kann Wochen dauern, bis Servicetickets mehrere Operations-Teams erfolgreich durchlaufen. Bei der Bereitstellung einer Anwendung, die dedizierte Netzwerkressourcen mit detaillierten Sicherheitsrichtlinien erfordert, müssen beispielsweise zunächst die globalen Sicherheitsteams die Genehmigungen der Sicherheitsrichtlinien bearbeiten. Anschließend kann das Serviceticket an das Netzwerkteam weitergeleitet werden, um die erforderlichen Subnetz- und Routenkonfigurationen zu planen. Schließlich kann die Validierung der Firewall-Regeln von einem weiteren Operations-Team, das für das Firewall-Management zuständig ist, nötig sein.
Stellen wir uns nun vor, dass die oben beschriebene Komplexität für jede Anwendung, die in einer verteilten Cloud bereitgestellt wird, deren zugrunde liegende Infrastruktur nicht Besitz des Unternehmens ist, bewältigt werden muss. Die schiere Menge an kleinen Projekten oder Anwendungen, die eingebunden und unterstützt werden müssen, macht es für die Betriebsteams unrealistisch, jedes Projekt zu unterstützen, wodurch ein Problem der Priorisierung entsteht und Selbstbedienung begünstigt wird.
Dieses Problem der Priorisierung macht sich besonders bemerkbar, da sich die Investitionen der Infrastrukturteams auf die Unterstützung kritischer und umsatzbringender Systeme konzentrieren und nur wenig Zeit oder Budget für neue Projekte mit eigenen Lebenszyklus von Entwicklung, Test und Staging vor der Produktion übrig bleibt. Dies führt zu verminderten Fähigkeiten und Investitionen in neue Funktionen, Anpassungen und Innovationen zur Unterstützung neuer Produkte, wodurch letztlich das Unternehmen und seine Angebote stagnieren.
Edge-Lösungsraum
Die Entwicklung des Edge-Ökosystems erweitert den Lösungsraum erheblich durch Schaffung einer Anwendungsplattform zum Umgang mit diesen Herausforderungen.
Abbildung 4 zeigt den Edge-2.0-Lösungsraum. Es soll hier festgestellt werden, dass alles, was unter eine verteilte Cloud-Architektur fällt, die Gesamtheit des Lösungsraums darstellt.
Im Kontext des Lösungsraums muss Edge 2.0 also die von allen folgenden Entitäten gewünschte Erfahrung bieten:
- Allen Entitäten innerhalb des Lösungsbereichs – Anwendungen, Menschen und Geräte, die als Verbraucher fungieren, oder Web-Backend- und Headless-Anwendungen, die die Dienste bilden.
- Den SRE-Teams und die Anwendungseigentümern dieser Anwendungen, während die von der Infrastruktur erwarteten Sicherheits- und regulatorischen Vorschriften einhalten werden.
Edge 2.0 wird einfach zu betreiben, sicher und konform sein und allen am Ökosystem beteiligten Unternehmen eine hochwertige Erfahrung bieten.
Designüberlegungen für Edge 2.0
Standardmäßig sicher
Eine verteilte Cloud verstärkt das Problem der skalierbaren Sicherheit noch, da die Anzahl der Endpunkte exponentiell ansteigt. Mit einer solchen Größenordnung steigt auch die Komplexität der Implementierung einer Lösung. Der Sicherheitszustand sollte so sein, dass die Anwendung davon ausgeht, dass die Umgebung, in der sie gerade eingesetzt wird, bereits kompromittiert ist. Ebenso darf die Infrastruktur keiner Anwendung vertrauen, die in ihr läuft.
Diese Ideen beruhen auf dem Zero-Trust-Ansatz, und das BeyondCorp1-Beispiel demonstriert diese Konzepte für das Szenario des Anwendungszugriffs. Mit Edge 2.0 wird dieses Modell auf der Grundlage der folgenden fünf Kernprinzipien weiter ausgebaut:
- Identität ist essenziell: In Edge 2.0 hat jede Entitätsinstanz ihre eigene, weltweit eindeutige Identität, aber auch ihren Platz in der Organisationshierarchie sowie ihre Berechtigungsstufe. Die Identität sollte nicht nur für den Nord-Süd-Verkehr, sondern auch intern für den Ost-West-Zugang eine essenzielle Rolle spielen.
- Least Privilege (geringstmögliche Privilegien): Die einem Akteur erlaubten Aktionen sollten auf diejenigen beschränkt werden, die der Akteur benötigt, um seine Rolle im System zu erfüllen. Ein Beispiel hierfür ist, die Workloads, die mit dem Datenbankserver kommunizieren dürfen, auf der Grundlage der Entwurfsspezifikation auf eine Untergruppe zu reduzieren.
- Kontinuierliche Authentifizierung: Jeder Nachweis, den ein Systemakteur vorlegt, muss verifizierbar sein und sollte jedes Mal, wenn ein solcher Nachweis erfolgt, explizit überprüft werden. Die Authentifizierung sollte nicht nur explizit durch gemeinsame Geheimnisse oder Vertrauensketten erfolgen, sondern auch implizite Verhaltensmuster und kontextbezogene Metadaten berücksichtigen.°
- Ständige Überwachung und Bewertung: Die Aktionen aller Akteure im System müssen überwacht werden, was die Schlüsselrolle der Datenerfassungs- und Data Warehousing-Technologien in einer Edge-2.0-Architektur unterstreicht. Darüber hinaus müssen diese Aktivitäten kontinuierlich bewertet werden, um Versuche, verbotene oder gefährliche Aktionen durchzuführen, zu erkennen und zu bekämpfen. Die Bewertung muss nahezu in Echtzeit und in großem Umfang erfolgen, was eine großzügige Nutzung von Automatisierung und maschinellen Lernverfahren erfordert.
- Annahme der Kompromittierung: In Anbetracht der Ressourcen, die den raffinierten Angreifern von heute zur Verfügung stehen, muss man davon ausgehen, dass jedes System auf irgendeine Weise kompromittiert wurde. Daher reichen die rein deterministischen, auf Workload- und Benutzeridentitäten basierenden Richtlinien, die den privilegienbasierten Zugang, dargestellt durch a und b, erzwingen, oft nicht aus, um alle Angriffe zu verhindern. Daher muss ein ausgereiftes Edge-2.0-System auch in der Lage sein, auf der Grundlage einer kontinuierlichen Überwachung und Bewertung eine Risiko-/Nutzenbewertung in Echtzeit vorzunehmen.
Native Beobachtbarkeit
Edge 2.0 muss die Telemetrie als essenzielles Element tief in den Infrastruktur-Stack integrieren, einfache und skalierbare Möglichkeiten zur Erfassung schichtenübergreifender Telemetrie innerhalb der Infrastruktur bieten und diese auf einer gemeinsamen Plattform veröffentlichen. Dies hilft den Beobachtungsteams, den „Infrastrukturzustand“ bei Bedarf abzufragen. So können sich die Anwendungsteams auf die Geschäftslogik konzentrieren, ohne ihre Anwendungsstacks explizit zu instrumentieren.
Der derzeitige Stand der Beobachtungstechnologie ist weitgehend anbieterspezifisch und proprietär. Dies hat dazu geführt, dass viele herstellerspezifische Agenten ähnliche Signale sammeln, die sich um teuren Speicher und CPU streiten.
Der nächste logische Schritt ist der Einsatz eines herstellerunabhängigen Telemetriesammlers, der Infrastruktur- und Verkehrsdaten an eine zentrale Datenplattform überträgt.
Vielen Produktteams fällt es schwer, Investitionen in die Instrumentierung zu rechtfertigen, da der Aufwand mit einer Umsatzchance verknüpft sein muss. Die Infrastruktur sollte wie jede andere Geschäftsfunktion oder jeder andere Prozess instrumentiert werden, da das Team ihr Verhalten verstehen muss, um sie für die Unternehmensziele zu optimieren. Die Debatte sollte sich also eher darum drehen, was vorrangig instrumentiert werden sollte, und weniger um die Notwendigkeit der Instrumentierung.
Um granulare und genauere Messungen des Anwendungsverhaltens zu erhalten, gehen wir davon aus, dass sich die Instrumentierung „nach links verschiebt“, indem sie zur Zeit des Codes aufgerufen wird (Abbildung 5).
Unterstützung adaptiver Schnittstellen
Dem Konzept der verteilten Cloud entsprechend hat jede Cloud auf den tieferen Ebenen innerhalb ihres Geltungsbereichs (lokal oder global) ihren eigenen Manager, Administrator, Orchestrator und mehr. Jede dieser Entitäten verhält sich unabhängig, trifft ihre eigenen Entscheidungen, stellt aber bei Bedarf Schnittstellen für andere Entitäten zur Verfügung.
Der Begriff der verteilten Cloud bedeutet also im Wesentlichen eine dezentrale Verwaltung und Kontrolle. Diese Tatsache muss unbedingt berücksichtigt und verstanden werden, um die Nuancen von adaptiven gegenüber deklarativen und imperativen Schnittstellen besser zu verstehen.
Um die Edge 2.0-Infrastruktur effektiv zu nutzen, reichen imperative und deklarative Schnittstellen nicht aus, da sie immer noch auf handgefertigten Artefakten beruhen, die im Wesentlichen statische Konstrukte sind, die sich nicht schnell genug an rasante Änderungen der Bedingungen anpassen.
Wir müssen ergebnisorientiert arbeiten, und die Systeme müssen so intelligent sein, dass sie die Maßnahmen in der gesamten Infrastruktur (End-to-End) anpassen können, um diese Ergebnisse zu erreichen. Wir nennen dies adaptive Schnittstellen.
Zur Klarstellung: Imperative, deklarative und adaptive Schnittstellen schließen sich nicht gegenseitig aus
Imperativ: Kann sehr präskriptiv sein und definiert eine Reihe detaillierter Aktionen, um den gewünschten Zustand zu erreichen. Die Konfiguration eines Routers ist beispielsweise eine imperative Aktion. Im obigen Szenario sind die präskriptiven Aktionen präzise – welches Rechenzentrum, wie viel CPU/Speicher, welche Bandbreite, bestimmte Routen und mehr. Die Eingabequalität des Datenmodells ist sehr hoch und erfordert daher ein tieferes Fachwissen über die Infrastruktur. Es wird erwartet, dass sowohl das Modell als auch die Struktur der Infrastruktur bekannt ist.
Deklarativ: Der deklarative Ansatz bietet Spielraum, da er sich auf die Beschreibung des gewünschten Zustands konzentriert, statt konkrete den Aktionen zu diesem Zweck vorzuschreiben. Die Qualität der Eingabe ist geringer, obwohl die Anwendung zumindest die Struktur der zugrunde liegenden Infrastruktur kennen muss.
Adaptiv: Unterscheidet sich von imperativ oder deklarativ. Eine adaptive Schnittstelle konzentriert sich auf das gewünschte Ziel und nicht auf den Zustand. Das Ziel der adaptiven Schnittstelle ist es, das Ziel des Stakeholders zu erfassen, der die Anwendung einsetzen möchte, und nicht, sich auf ein Vorwissen über das zugrunde liegende System zu konzentrieren. Der Unterschied zur adaptiven Schnittstelle besteht darin, dass sie keine Vorstellung von den Fähigkeiten der zugrunde liegenden Infrastruktur hat. Es gibt keine Einschränkungen, wie die Aufgabe zu erledigen ist, und das ist die Besonderheit.
Bei der adaptiven Methode ist die Qualität der Eingabe gering und nähert sich der natürlichen Sprache an. Die Eigentümer der Anwendung können dem Infrastruktur-Controller durch eine Anfrage mitteilen, welches Ergebnis sie erwarten, anstatt die erforderliche Funktionalität zu deklarieren oder eine Ressource speziell zu konfigurieren.
Lösung des Problems des clusterübergreifenden Computings
Eine verteilte Cloud eignet sich per Definition für alle Arten von Anwendungsarchitekturen: monolithisch, Microservices oder serverlos. Unabhängig von der Architektur verwenden die Anwendungen APIs, um die Dienste anzubieten.
Die Probleme der API-Erkennung, Konnektivität und Netzwerksicherheit werden durch die Verwendung eines Service Mesh weitgehend gelöst, aber ein Service Mesh löst diese Probleme nur innerhalb des Clusters (clusterintern).
Edge 2.0-Anwendungen hingegen nutzen APIs über eine hyperverteilte Cloud-Infrastruktur, die im Wesentlichen eine Multi-Cluster-Umgebung ist. Neue Anwendungen werden mit APIs geschrieben, die organisatorische und geografische Grenzen überschreiten. Einige der APIs können private oder Partner-APIs sein, die sich hinter mehreren Firewalls befinden und zwischen denen es keine explizite Route gibt, selbst wenn sie erkennbar sind. Für dieses Problem der heterogenen (clusterübergreifenden) Cluster gibt es keine elegante, leichtgewichtige, skalierbare und sichere Lösung, die praktikabel ist.
| Szenario/Eigenschaften | Imperativ | Deklarativ | Adaptiv |
|---|---|---|---|
| Definition | Eine imperative Schnittstelle definiert den detaillierten Kontrollfluss auf der Grundlage der spezifischen Fähigkeiten der zugrunde liegenden Ressource. |
Eine deklarative Schnittstelle definiert die Logik, aber nicht den Kontrollfluss. Programmtechnisch gesehen handelt es sich um Pseudocode. |
Eine adaptive Schnittstelle drückt den gewünschten Zustand als Anforderung aus, ohne Annahmen über die Fähigkeiten der zugrunde liegenden Ressourcen zu treffen. Eine adaptive Schnittstelle gehört der Infrastruktur und ermöglicht es dieser, dynamisch auf die sich ändernden Anforderungen der Anwendung zu reagieren. |
Beispiel 1: Ein Paket soll von San Francisco (SFO) nach New York (NYC) gehen. |
Jane sagt zu Mark: (a) den Versandaufkleber ausdrucken, (b) zum UPS-Laden gehen, (c) die 72-Stunden-Zustellung wählen, (d) bezahlen und versenden. Mark muss eine bestimmte Reihe spezifischer Schritte befolgen. |
Jane bittet Mark: (a) Bitte dieses Paket per Kurier an diese Adresse senden, (b) das Paket muss innerhalb von 72 Stunden ankommen. Mark kann jedes beliebige Kurierunternehmen wählen (UPS, FedEx, DHL usw.). |
Jane sagt zu Mark: (a) Dieses Paket muss bis Samstag in New York ankommen. Mark kann machen, was er will. Möglicherweise nimmt er das Paket sogar selbst mit, fliegt nach New York City und liefert es persönlich aus. |
Beispiel 2: Load Balancing |
Ein Load Balancing ist bereits vorhanden. Aufgabe: Er soll mit dieser Richtlinie konfiguriert werden. In diesem Beispiel ist die Aufgabe spezifisch für die Marke, das Modell, die Version usw. des Loadbalancings. |
Ein Load Balancing ist nicht vorhanden. Aufgabe: Load Balancing der Anwendung mit einer gegebenen offenen Richtlinie. Die Aufgabe setzt voraus, dass eine Orchestrierungs- |
Keine Annahmen über die zugrunde liegende Infrastruktur. Bitte stellen Sie sicher, dass die Anwendung nach Bedarf skaliert, mit einer maximalen Latenz von 10 ms. |
Teamzuweisung: |
Gemeinsame Zuweisung: Anwendungs- und Infrastrukturteams |
Gemeinsame Zuweisung: Anwendungs- und Infrastrukturteams |
Nur das Infrastrukturteam |
Qualität der Eingabe |
Äußerst hoch. Erfordert tiefgreifende Kenntnisse über den zugrunde liegenden Bereich. Es muss z. B. bekannt sein, welcher F5-Load Balancer, welche Softwareversion usw. verwendet wird. Obligatorische Schnittstellen wären beispielsweise eine CLI oder ein NMS. |
Hoch: Erfordert Kenntnisse darüber, wozu die Infrastruktur in der Lage ist. Im obigen Beispiel gibt es zum Beispiel Vorkenntnisse über die Infrastruktur, die einen Lastenausgleich unterstützt. |
Gering: Erfordert keine Kenntnisse über die Fähigkeiten der Infrastruktur. Die Eingabequalität entspricht in etwa der natürlichen Sprache. |
Fähigkeitsstufe (Persona) |
Funktionsspezifische Kenntnisse. Zum Beispiel: Netzwerkadministrator, Compute-Administrator, Storage-Administrator. Jeder Aspekt der Infrastruktur erfordert, dass der Benutzer ein Experte auf diesem Gebiet ist. |
Fähigkeiten zur Anwendungsbereitstellung. Der Benutzer kennt die Art der Funktion, die für die Bereitstellung der Anwendung erforderlich ist. Wie im obigen Fall weiß der Anwendungsmanager, dass ein Load Balancer benötigt wird, und er kennt die High-Level-Richtlinien, für die er konfiguriert werden muss, um die automatische Skalierung zu unterstützen. |
Anwendungsingenieur. Kann der Infrastruktur lediglich signalisieren, was die nichtfunktionalen Anforderungen an die Anwendung sind. In diesem Fall, wie schnell die Anwendung auf eine Kundenanfrage reagieren soll. Andere Faktoren wie geografische Lage, Kosten usw. können nach Bedarf hinzugefügt werden. |
Geltungsbereich |
Die obligatorischen Schnittstellen haben |
Der deklarative Geltungsbereich ist größer. In der Regel ist er mit einer Orchestrierungs-Engine verbunden, die mit mehreren imperativen Schnittstellen kommuniziert, um das gewünschte Ergebnis zu erzielen. |
Sehr großer Geltungsbereich, da die Ausgabe |
Beispiel |
- name: update web servers hosts: webservers remote_user: root tasks: - name: ensure apache is at the latest version yum: name: httpd state: latest - name: write the apache config file template: src: /srv/httpd.j2 dest: /etc/httpd.conf |
apache-server: version: “latest” |
application-latency: - lt: 10ms infrastructure-cost: - lt: $200 - billing: monthly |
Wir haben APIs ausführlich im Bericht zum API-Wildwuchs von 2021² behandelt und darin viele Fragen angesprochen, die auftauchen könnten. Abbildung 6 zeigt den Unterschied zwischen clusterübergreifendem und clusterinternem Computing.
Clusterintern: In einer monolithischen Architektur gibt es möglicherweise nur sehr wenige APIs, wenn die interne Kommunikation zwischen Modulen über andere prozessübergreifende Kommunikationsmethoden erfolgt. Eine Mikroservice-Architektur hingegen unterteilt sich in Dutzende, wenn nicht Hunderte von APIs.
In jedem Fall wird jeder Anwendungscluster auf eine explizite Art und Weise entwickelt und verwaltet. In Fällen von Microservice-Architekturen kann ein Team beispielsweise jede Art von Service Mesh verwenden – Istio, Linkerd, Aspen Mesh oder andere. Jeder Ansatz verfügt über seine eigenen Mittel zur Verwaltung und Steuerung der APIs innerhalb seines Clusters, also sozusagen clusterintern.
Hier gibt es viele Lösungen, und das Ziel von Edge 2.0 besteht nicht darin, Unternehmen oder Entwicklungsteams zu zwingen, eine weitere neue Technologie zu übernehmen.
Clusterübergreifend: Da die Zahl der über APIs bereitgestellten Dienste zunimmt, werden neue Anwendungen unter Verwendung von Diensten erstellt, die bereits von verschiedenen Anwendungsteams innerhalb des Unternehmens entwickelt oder übernommen wurden, da das Rad schließlich nicht neu erfunden werden muss.
Neue Anwendungen werden auch aus verschiedenen Kombinationen von öffentlichen und privaten APIs erstellt. Aus Sicht der Architektur nutzen moderne Anwendungen Dienste, die von anderen Clustern bereitgestellt werden. In einer verteilten Cloud werden diese Cluster weltweit eingesetzt und können sich daher auf jeder Infrastruktur befinden, die die Anwendung hosten kann oder Teil des Anwendungsclusters ist.
Um es noch einmal zu betonen: Der Geltungsbereich eines Clusters ist nicht nur auf ein Unternehmen beschränkt. Cluster können zwei Netzwerke, Anwendungen, organisatorische Silos oder sogar Unternehmen überspannen.
Der Bereich umfasst die gesamte Bandbreite aller Permutationen und Kombinationen, was die Komplexität der Vorgänge exponentiell erhöht. Abbildung 7 zeigt die Permutationen des Verkehrs innerhalb des Geltungsbereichs.
In einem typischen Unternehmen gibt es unterschiedliche Anwendungsarchitekturen. Je nachdem, welches Team sie entwickelt und einsetzt, kann es verschiedene Arten von Service Meshes geben, etwa eine Web 2.0-Anwendung auf Grundlage einer serviceorientierten Architektur oder eine monolithische Softwarebereitstellung. Die APIs, sind also über das gesamte Unternehmen verstreut, sei es durch Nutzung öffentlicher APIs oder privater APIs. Dieses Problem ist noch nicht gelöst. Die API-Kommunikation zwischen mehreren Standorten ist kritisch und ein Problem, das in Unternehmen jeder Größe nur schwer lösbar ist.
Es gibt mehrere Lösungen für das Management von APIs innerhalb eines Clusters (z. B. Ingress-Controller, API-Gateways usw.), während die clusterübergreifende API-Kommunikation nicht auf praktische, skalierbare und sichere Weise gelöst ist. Daher konzentrieren wir uns bei der einheitlichen API-Kontrolle und -Verwaltung nur auf die Probleme zwischen den Clustern.
Schaffung von Autonomie
Ein unterschätzter Nutzen der Cloud ist die Autonomie, die sie dem „Cloud-Kunden“ bietet. Unternehmen und Unternehmer können ihre eigenen Infrastrukturen nach Bedarf einrichten und haben dabei zumindest scheinbar die volle Kontrolle.
Eine Edge-2.0-Plattform dient im Grunde dazu, dem Cloud-Kunden ein autonomes Erlebnis zu bieten und gleichzeitig die richtigen Schutzmechanismen zu implementieren. Da die Entitäten in jeder (vertrauenswürdigen oder nicht vertrauenswürdigen) Infrastruktur auftreten können, müssen die Schutzmechanismen so implementiert werden, dass sie die Abteilung oder das für die Erstellung der Anwendung zuständige DevOps-Team nicht belasten.
Mit dem Edge 2.0 kommen die Herausforderungen der Erkennung, Identität, Beobachtbarkeit und des Vertrauens zwischen verschiedenen Diensten.
Schon in mittelgroßen Unternehmen ist die Zahl der jährlich erstellten APIs groß. Wie können Teams diese Dienste im Unternehmen erkennen? Oder anders gefragt, woher wissen sie, ob die Dienste noch gültig sind und wem sie gehören? Können sie sicher sein, dass es sich um einen validierten Dienst handelt, der als vertrauenswürdig gilt? Das Problem wird noch verschärft, wenn Teams Dienste nutzen möchten, die von Clustern außerhalb der Unternehmensgrenzen bereitgestellt werden, z. B. SaaS oder Anwendungen, die auf Edge-Geräten ausgeführt werden, über die die Infrastrukturteams keinerlei administrative Kontrolle haben.
Edge 2.0-Anwendungsplattform
In Anbetracht der in den vorangegangenen Abschnitten dargestellten Herausforderungen sollten wir die gesamte verteilte Cloud als eine Plattform betrachten. Auf oberster Ebene formulieren wir das Ziel der Lösung: die autonome Erkennung (ohne menschliches Eingreifen), Skalierung und Sicherung verteilter Anwendungen in einer dezentralen Infrastruktur.
Im Wesentlichen lässt sich die Aufgabe der Edge 2.0-Anwendungsplattform (EAP) wie folgt beschreiben:
- API-Ermittlung, -Identität und -Vertrauen
- Planung und Orchestrierung der Infrastruktur
- Sichere Anwendungskonnektivität
EAP-Geltungsbereich
Die Infrastruktur ist die Gesamtheit des Lösungsraums, in dem Infrastrukturelemente kontinuierlich erscheinen und verschwinden können. Die Infrastruktur und ihre Ressourcen zu besitzen ist etwas anderes als sie zu verwalten und zu kontrollieren. Ein Infrastruktureigentümer kann eine bestimmte Infrastruktur oder eine Instanz davon einer anderen Organisation zuweisen, die sie verwaltet und konfiguriert, oder er kann bei Bedarf die Kontrolle zurückerlangen. Die Organisation, die die Elemente verwaltet und konfiguriert, kann sie außerdem einzelnen Projekten oder Anwendungen zuweisen. Dieses Konzept ist nicht neu; beispielsweise bieten Cloudservice-Anbieter eine hierarchische Administration an, die von den IT-Teams eines Unternehmens genutzt werden kann, um internen Geschäftseinheiten, Teams usw. Infrastructure-as-a-Service (IaaS) bereitzustellen. Die Hauptüberlegung bezüglich Edge 2.0 ist die Frage, wie dies in einer hochgradig verteilten Cloud, dem aktuellen und zukünftigen Zustand der Edge-Infrastruktur, umfassend umgesetzt werden kann.
An dieser Stelle kommt der Geltungsbereich der EAP ins Spiel. Abbildung 8 unten zeigt den Geltungsbereich der EAP im Kontext verschiedener Arten von Schnittstellen. Jede EAP orchestriert ihren lokalen Geltungsbereich mit deklarativen und imperativen Schnittstellen. In diesem Fall:
- Deklarative/imperative Schnittstellen wären die AWS-APIs, Azure-APIs usw.
- Adaptive Schnittstellen wären etwas Neues, das von Fall zu Fall definiert werden müsste.
Um die Vorteile der verteilten Cloud zu nutzen, sollte die EAP in der Lage sein, alle über eine verteilte Cloud verfügbaren Knoten und Einheiten zu nutzen. Unsere Vision ist, dass die einzelne EAP das Äquivalent des autonomen system3-Konzepts für IP-Netze wird, allerdings für die Anwendungsschicht.
Aus diesen Elementen (Abbildung 9 unten) können wir nun eine Übersicht darüber erstellen, wie mehrere EAPs in einer dezentralen Cloud-Infrastruktur eingesetzt werden können und autonom miteinander interagieren.
Adaptive Schnittstellen erleichtern auch die Integration von CI/CD- und anderen Anwendungen für den Anwendungslebenszyklus in die verteilte Cloud. CI/CD-Plattformen können über einfache adaptive Schnittstellen, die nur das gewünschte Ergebnis angeben, direkt mit der EAP verbunden werden.
Es sollte bedacht werden, dass die Kommunikation zwischen EAPs auch über adaptive Schnittstellen erfolgen kann.
Das EAP-Framework
Das EAP-Framework organisiert, wie in Abbildung 10 dargestellt, die Verantwortlichkeiten bezüglich der Funktionen der einzelnen EAP-Instanzen. Die Aufgabe der EAP besteht darin, eine Schnittstelle zu den zugrunde liegenden Infrastruktur-Controllern zu bilden – sei es Infrastructure as a Service (IaaS), Platform as a Service (PaaS) oder Software as a Service (SaaS) – und die entsprechenden Ressourcen nach Bedarf zu orchestrieren und zu planen.
Einheitliche API-Steuerung und -Verwaltung
Die Zukunft gehört einer API-gesteuerten Wirtschaft, in der APIs mehr als nur ein Softwarearchitekturkonzept sind, das durch ein Service Mesh vereinfacht wird. APIs werden das wichtigste Mittel sein, mit dem Unternehmen, die an einer verteilten Cloud teilnehmen, ihre Dienste anbieten.
Wie bereits festgestellt, wird die Zahl der weltweit verfügbaren öffentlichen und privaten APIs in den nächsten zehn Jahren in die Hunderte von Millionen, wenn nicht Milliarden gehen. APIs werden unsere Wirtschaft umgestalten und daher sollte genau betrachtet werden, was die EAP zur Unterstützung dieser Wirtschaft leisten muss.
Um den zunehmenden API-Wildwuchs zu bewältigen, sollte jede API innerhalb und außerhalb der EAP erkennbar sein. Bei einer verteilten Cloud können sich die APIs überall in mehreren Clustern befinden.
Die zugrunde liegende Annahme ist, dass das API-Ermittlungsproblem wirklich ein Problem des clusterübergreifenden Computings ist. Der Geltungsbereich einer EAP kann sich über viele Anwendungscluster erstrecken, die unterschiedliche Softwareansätze (von Microservices bis monolithisch) verwenden und jeweils ihre eigene API-Gateway-Strategie implementieren. Eine EAP bietet ein gemeinsames Repository für alle APIs, die innerhalb ihres Geltungsbereichs registriert und auffindbar sind, nicht nur innerhalb eines Clusters. Diese Unterscheidung ist der Schlüssel, um die Grenzen bestehender API-Gateway-Strategien, wie z. B. dem Service Mesh, aufzuzeigen.
Die Herausforderung für die EAP besteht darin, die Erkennung von APIs zu ermöglichen, die richtige Dokumentation über ihre Verwendung bereitzustellen und den Lebenszyklus der API im Hinblick auf Konsistenz, Genauigkeit und Versionskontrolle zu verwalten. Die EAP implementiert eine Funktionalität, mit dem Entitäten, die ihre APIs nutzen, über den aktuellen Stand der jeweils verwendeten APIs informiert werden. Dies könnte einfach durch die Festlegung von Verfallsdaten oder durch explizite Information über ein Nachrichtensystem geschehen.
Bei der zu implementierenden Sicherheitsstrategie gehen Anwendungen davon aus, dass die Infrastruktur, in der sie derzeit eingesetzt wird, bereits kompromittiert ist.
Die wichtigste Säule bei der Umsetzung dieser Sicherheitsstrategie ist die Identität. Jeder API-Endpunkt muss eine weltweit eindeutige Identität haben. Die Sicherheitsrichtlinien und -Steuerelemente werden separat in einem zentralen Repository verwaltet.
APIs müssen als öffentlich oder privat gekennzeichnet werden, sodass die zugrunde liegenden Sicherheitskomponenten der Infrastruktur automatisch für die jeweilige API konfiguriert werden.
Kommunikation zwischen Anwendungen beginnt mit einer „deny-all“-Richtlinie (alles zurückweisen). Nur weil eine API sichtbar ist, heißt das nicht, dass eine andere Anwendung sie verwenden kann. Dies muss ausdrücklich in der Sicherheitsrichtlinie der Anwendung konfiguriert werden.
Die EAP muss sicherstellen, dass allen APIs innerhalb ihres Geltungsbereichs vertraut werden kann und dass gleichzeitig alle externen APIs, die von den Diensten innerhalb ihres Geltungsbereichs verwendet werden, vertrauenswürdig sind.
„Vertrauenswürdigkeit kann nicht bewiesen werden, und genau das macht „Vertrauen“ aus.“ – „Verräter“ auf Netflix
Vertrauenswürdigkeit ist im Wesentlichen die „Reputation im Laufe der Zeit“, und muss ständig neu überprüft werden, um sicherzustellen, dass sie nicht unter ein akzeptables Niveau gefallen ist. Dies ist zunehmend ein gängiger Ansatz bei der Modellierung und Implementierung von Vertrauen in Systemen. Es wird eine kontinuierliche Bewertung des Vertrauens erfordert, anstatt es statisch bei der ersten Ausführung zu bestätigen.
Der Wandel des Vertrauens im Laufe der Zeit kann für einige Unternehmen eine Herausforderung darstellen, die nicht den Luxus langfristiger Aufzeichnungen haben, anhand derer eine gegenseitige Reputation zwischen ihren Systemen und denen von Drittanbietern etabliert wird. Sowohl die Infrastruktur als auch APIs können Schäden anrichten, wenn die Reputation nicht genau beobachtet wird.
Wenn ein Dienst innerhalb des EAP-Geltungsbereichs auf eine externe API zugreift, muss die Plattform eine Funktionalität implementieren, mit dem der aufrufende Dienst sich der Richtigkeit der von der externen API erhaltenen Antwort versichern kann. Nur weil die API-Antwort gültig aussieht, heißt das nicht, dass man ihr vertrauen kann. Entweder könnte die Antwort aufgrund von Qualitätsproblemen ungenau sein, oder es könnten beabsichtigte Ungenauigkeiten eingefügt worden sein, um das betreibende Unternehmen weniger wettbewerbsfähig zu machen. Die Möglichkeit, jeder API, ob intern oder extern, einen Vertrauensfaktor zuzuweisen, ist eine einzigartige Fähigkeit des EAP-Konstrukts.
Eine mögliche Strategie zur Implementierung des Vertrauens besteht darin, den Durchschnitt über den jüngsten Zeitraum statt über die gesamte Geschichte des Dienstes zu ermitteln. Das ist so, als würde man bei einem Produkt auf Amazon die „Top-Bewertungen“ mit den „aktuellsten“ vergleichen. Das Produkt kann durchaus vier Sterne haben, aber wenn die meisten negativen Bewertungen in den letzten sechs Monaten abgegeben wurden, deutet dies auf einen aktuellen Vertrauensbruch hin, während ein Zustrom positiver Kommentare in den letzten sechs Monaten auf eine Behebung oder Wiederherstellung des Vertrauens hinweisen würde.
Der Faktor Vertrauen bezieht sich nicht nur darauf, ob eine API eine bekannte Quelle falscher oder irreführender Daten ist oder nicht. Der Ruf einer EAP hängt auch davon ab, wie gut sie die APIs in ihrem Geltungsbereich verwaltet und aktualisiert. Außerdem ist „Vertrauen“ auch relativ. Dienst A kann Dienst C vertrauen, aber Dienst B hat möglicherweise andere Erfahrungen mit Dienst C gemacht.
Edge-Infrastrukturmanager
Da eine verteilte Cloud die Grundlage der Edge-2.0-Infrastruktur bildet, müssen die Ressourcen innerhalb des Geltungsbereichs einer EAP unbedingt leicht auffindbar, sicher und instrumentiert sein. Die folgenden Ausführungen können als eine Reihe von Empfehlungen verstanden werden, die die Fähigkeiten des Edge-Infrastrukturmanagers betreffen.
Innerhalb einer EAP können Ressourcen nach Bedarf eingeplant werden. Neue Ressourcen können aufgrund von Mobilität dynamisch hinzukommen oder weggehen. Eine EAP kann auch Anfragen von anderen EAPs senden oder empfangen, um in ihrem Namen Ressourcen zu finden und zu planen.
Wie gesagt ist der angenommene Sicherheitszustand prekär: Die Infrastruktur, auf der die Anwendung bereitgestellt wird, muss als bereits kompromittiert angesehen werden. Daher muss die EAP die Sicherheit von in ihrem Geltungsbereich bereitgestellten Anwendungen gewährleisten.
Unabhängig von der Verwaltungsebene muss das EAP-Framework mehrere Aspekte der Sicherheit berücksichtigen, wie z. B. (aber nicht ausschließlich):
Externe Bedrohungen: Zum Beispiel Distributed-Denial-of-Service-Angriffe (DDoS) und Advanced Persistent Threats (APT). Diese können durch bewährte Sicherheitsverfahren wie DDoS-Prävention, Firewalling usw. eingedämmt werden. Dies wird für den gesamten Datenverkehr empfohlen.
Man-in-the-Middle: Der gesamte Datenverkehr muss verschlüsselt sein und kann nicht davon ausgehen, dass die Anwendungsschicht das Richtige tut. Dies gewährleistet die grundlegende Vertraulichkeit der Daten gegenüber allen Geräten, die den Datenverkehr ausspähen können, und schützt die Integrität der Daten vor Manipulationen während der Übertragung.
Interne Bedrohungen: Der Anwendungsbereich der Infrastrukturebene muss eingeschränkt werden und in erster Linie auf den eigenen Schutz ausgerichtet sein. Die Empfehlung lautet, einer Ressource innerhalb der Infrastruktur nicht zu erlauben, einen internen Angriff auf den Infrastrukturmanager auszuführen.
Wenn es bei Edge 2.0 um die gebotene Erfahrung geht und nicht um Infrastruktur oder deren Standort, dann ist es nur logisch, dass auch die Telemetrie auf die Erfahrung ausgerichtet sein muss.
Es stellt sich nur die Frage, wessen Erfahrung gemeint ist. Wir behaupten, dass die Erfahrung diejenige ist, die sich einer jeglichen Entität, die sich in einer Infrastruktur befindet oder diese nutzt, um einen Dienst bereitzustellen, bietet: Anwendungen, Geräte, Menschen, Backend-Anwendungen, Datenbanken und mehr. Die Erfahrung ergibt sich also aus Sicht der Entität. Ein Dienst, den eine Entität produziert oder nutzt, steht in direktem Zusammenhang mit den ihm zugewiesenen Rechen-, Speicher- und Netzwerkressourcen.
Aber man darf sich nicht darauf beschränken, die Erfahrung zu messen; es muss auch ein Mittel geben, um sie zu verbessern.
Jede Entität, die einen Dienst in Anspruch nimmt oder anbietet, kann herausfinden, ob sie die gewünschte Erfahrung erhält. In verteilten Cloud-Umgebungen kann es jedoch nahezu unmöglich sein, zu erklären, was in der Infrastrukturebene passiert ist, das zu der schlechten Erfahrung geführt hat.
High-Level-Metriken wie CPU-Auslastung, Arbeitsspeicher, Bandbreite und Latenz reichen nicht aus, um festzustellen, warum eine Anwendung nicht die gewünschte3 Leistung erbringt. Die Metriken müssen zeitlich granular sein und tief im Anwendungs-Stack gesammelt werden. Wenn möglich, sollten sie auf verschiedenen Ebenen des Infrastrukturstapels erfasst werden.
Eine robuste, skalierbare und erweiterbare Telemetrie- und Datenstrategie ist essenziell für die EAP. Strategien des maschinellen Lernens (ML) und der künstlichen Intelligenz (KI) können dann genutzt werden, um die beste Entscheidung über die Reservierung neuer Ressourcen oder die Optimierung der Nutzung vorhandener Ressourcen zu treffen.
Softwaredefinierte Anwendungskonnektivität
Zwar gelten Konnektivität und Erreichbarkeit als gelöste Probleme, doch kämpfen viele Netzwerkteams noch immer damit, ihre Netzwerkstruktur mit den dynamischen Anforderungen der Anwendungsschicht zu rationalisieren. Eine Plattform muss auch diese Herausforderungen meistern.
Das Problem bei den bestehenden Ansätzen ist, dass die Anforderungen an die Anwendungskonnektivität auf die WAN-Konnektivität des Unternehmens übertragen werden, insbesondere in einer verteilten Cloud. Ansätze zur Realisierung eines verteilten Cloud-Netzwerks könnten verschiedene SDN-Strategien oder reine Routing-basierte Methoden verwenden. Diese Lösungen sind jedoch stark von der Homogenität der Infrastruktur abhängig und können daher kein einheitliches Verhalten bieten.
Das einzige Mittel, mit dem ein global skalierbares, sicheres und stabiles Netzwerk für Anwendungen geschaffen werden kann, ist die Trennung der Anwendungskonnektivitätsebene vom zugrunde liegenden Netzwerk, wie sie im Folgenden beschrieben wird.
In der Entwicklung hin zu einer verteilten Cloud-Architektur kristallisiert sich ein SDN-Muster heraus, das sowohl die Underlay- als auch die Overlay-Netzwerke gemeinsam orchestriert und eine End-to-End-Programmierbarkeit des Anwendungspfads ermöglicht.
Mit Edge 2.0 müssen wir diese scheinbare Stabilität auch bei der Verbindung von Unternehmensnetzen herstellen. Wir fordern, dass die Konnektivitätsebene der Anwendung von der Konnektivität des Unternehmensnetzwerks getrennt werden muss. Das Konnektivitätsmuster der Anwendung kann, muss aber nicht demselben SDN-Konnektivitätsmuster folgen, wie es beim Overlay für Rechenzentren (z. B. VXLAN, NVGRE oder andere) oder BGP-basierten SDN-Mustern zu sehen ist.
Nicht alle Netze wurden in Overlay und Underlay getrennt. Netzwerkteams sehen nun die Notwendigkeit dieser gemeinsamen Programmierbarkeit als wichtige Voraussetzung für die End-to-End-Automatisierung an, für die die Trennung von Underlay- und Overlay-Netzwerk entscheidend ist.
Durch die Trennung der Anwendungsebene vom Underlay-Netzwerk und dem Transport entfällt die Notwendigkeit für die Netzteams, aktiv auf jede Anwendungsanforderung zu reagieren. Ihr Aufgabenbereich beschränkt sich auf die Bereitstellung robuster, stabiler und genau definierter Pfade, wobei der Schwerpunkt auf der Optimierung der Nutzung der Gesamtbandbreite bei möglichst geringen Latenzen liegt
Adaptives Schnittstellenmodell
Das Hauptmerkmal einer EAP ist, dass sie unabhängig und eigenständig ist und eine Teilmenge des gesamten Lösungsraums verwaltet. EAPs brauchen jedoch ein Mittel, um zu kommunizieren und ihre Ressourcen anzubieten oder Ressourcen von anderen EAPs anzufordern. Dieser Ansatz hat mehrere Vorteile.
Bei einer ergebnisbasierten Schnittstelle braucht die EAP die Details der anderen Infrastruktur nicht zu kennen. Angenommen, es gibt zwei EAPs: A und B. Jede EAP hat einen lokalen Infrastruktur-Geltungsbereich, um Ressourcen zu planen und zu reservieren. EAP A muss die von EAP B bereitgestellten Ressourcen nicht kennen. Wenn z. B. EAP A die Anforderungen der Anwendung nicht erfüllen kann und Ressourcen benötigt, die im Infrastrukturbereich von EAP-B liegen, kann sie EAP-B einfach ihr gewünschtes Ziel mitteilen. Es liegt dann in der Verantwortung von EAP-B, deklarative oder imperative Schnittstellen aufzurufen, um freie Ressourcen aus ihren freien Beständen zu reservieren, zuzuweisen und zu konfigurieren. EAP-B ist auch dafür verantwortlich, dass die SLOs für diesen Dienst innerhalb seiner Infrastruktur erfüllt werden.
Eine einheitliche Syntax ist zwar hilfreich, um eine erste Reihe adaptiver APIs zu erstellen, allerdings wird die Implementierung im Laufe der Zeit durch den Einsatz natürlicher Sprachverarbeitung und künstlicher Intelligenz anspruchsvoller und ausgereifter werden, um die erforderliche Qualität der Eingaben zu verringern.
Verschiedene Betriebsmuster werden auch simplifiziert, wenn nur der gewünschte Zustand angegeben werden muss. Ausfallsicherheitsmuster können zum Beispiel lediglich auf einem erwarteten SLO basieren. Es liegt in der Verantwortung der EAP, die den Dienst bereitstellt, sicherzustellen, dass die Ressourcen in ihrem Geltungsbereich so zugewiesen werden, dass die Service Level-Ziele erreicht werden. Die aufrufende EAP muss sich nicht darum kümmern, muss aber wahrscheinlich die Dienstmetriken überwachen, um zu wissen, ob sie erfüllt werden oder nicht.
EAP-Merkmale
- Mehrmandantenfähig: Das in Abbildung 9 gezeigte Netz von EAPs bezieht sich zwar auf eine einzige Bereitstellung, es sind jedoch mehrere EAPs pro Cloud möglich. Eine andere Anwendung könnte mit einer anderen EAP oder einem Netz von EAPs kommunizieren.
- Auf Skalierung ausgelegt: Jedes Netz ist ein Peer-to-Peer (P2P) Netz und kann horizontal skaliert werden. Die EAPs von Peers können unabhängig voneinander verfolgen, welche EAPs über welchen Ressourcentyp verfügen und wie sie sich mit der Ressource verbinden können. AI/ML wird die Art und Weise, wie jede EAP Ressourcen innerhalb seines eigenen Bereichs einplant oder bei Bedarf andere EAPs erreicht, weiter verbessern.
- Integrierte Vernetzung: Damit sich Anwendungen über die verteilte Cloud verbinden können, muss die EAP integrierte Netzwerkfunktionen unterstützen, die unabhängig von der zugrunde liegenden Infrastruktur sind.
Zusammenfügen der Elemente
Abbildung 12 veranschaulicht die Rolle der verschiedenen Schichten bei der Bereitstellung einer Anwendung in einer verteilten Cloud.
Die hervorgehobenen Elemente dieser Darstellung sind:
- Jeder EAP hat einen lokalisierten Geltungsbereich, und alle ihre Fähigkeiten sind in Abbildung 10 nicht angegeben. Die EAP muss die Funktionen der Ressourcenermittlung und Zeitplanung unterstützen. EAPs planen Ressourcen, indem sie über adaptive APIs eine Schnittstelle zum entsprechenden Infrastruktur-Controller herstellen.
- Anwendungskonnektivität ist nicht dasselbe wie Netzwerkkonnektivität – wie beim Service-Mesh-Sidecar-Modell müssen die Ressourcen zur Verbindung von Anwendungen über mehrere Clouds hinweg Teil der Anwendungsinfrastruktur sein. Man könnte argumentieren, dass die Infrastrukturebene auch die Anwendungsnetzwerkkonnektivität bereitstellt und daher unterhalb der Netzwerkschicht liegen sollte. Das wäre technisch auch richtig, aber wir haben uns dafür entschieden, sie unter der Ebene „Anwendungskonnektivität“ zusammenzufassen, da es sich in erster Linie um Netzwerkfunktionen handelt.
- Die Infrastrukturebene ist separat von der Anwendungsebene.
- Die Netzwerkkonnektivität unterscheidet sich vom Transport, da es sich im Wesentlichen um spezifische routingfähige Netzwerke handelt, die von der Anwendungskonnektivität getrennt sind.
- Die Transportebene kann als aggregierte Backbone-Netze betrachtet werden, die bereitgestellt werden kann, sofern der Telekommunikationsanbieter Prozesse und APIs zur Verbindung der darüber liegenden Netzwerkebene einsetzt.
Zusammenfassung
In diesem Whitepaper soll das ursprüngliche Edge 2.0-Manifest um einige Ebenen erweitert werden. Wir haben einige neue Themen eingeführt, mit dem Ziel, verschiedene Stakeholder innerhalb interner Organisationen und extern in der Branche zu informieren.
Edge 2.0 basiert auf dem Konzept einer verteilten Cloud, an der jede Einheit sowohl als Quelle als auch als Ziel von Diensten teilnehmen kann. Unsere Hauptaussage ist, dass es bei Edge 2.0 um das Erlebnis geht und nicht um Infrastruktur oder deren Standort.
Die Edge-Anwendungsplattform (EAP) wird als ein Stack von Funktionen vorgestellt, mit denen Edge 2.0 in einer verteilten Cloud realisiert werden kann.
Auf Implementierungsdetails wurde absichtlich verzichtet, um eine herstellerunabhängige Sichtweise vorzustellen.
Ressourcen
2 https://www.f5.com/pdf/reports/f5-office-of-the-cto-report-continuous-api-sprawl.pdf
3 Wikipedia – „An autonomous system (AS) is a collection of connected Internet Protocol (IP) routing prefixes under the control of one or more network operators on behalf of a single administrative entity or domain that presents a common, clearly defined routing policy to the Internet.“ (Ein autonomes System (AS) ist eine Sammlung verbundener Internet Protocol (IP)-Routing-Präfixe unter der Kontrolle eines oder mehrerer Netzwerkbetreiber im Namen einer einzigen Verwaltungseinheit oder Domäne, die dem Internet eine gemeinsame, klar definierte Routingrichtlinie vorgibt.)