Inhaltsverzeichnis
Einführung
Die Definition des Edge war schon immer mit der Entwicklung der Rechenzentrumsarchitektur verknüpft. Im letzten Jahrzehnt kam es zu einem rasanten Wandel in der Infrastrukturarchitektur von Unternehmen, von lokalen Rechenzentren hin zu den heutigen verteilten Cloud-Architekturen. Wir betrachten Edge 2.0 als einen Technologiewandel, der es Anwendungen ermöglicht, eine verteilte Cloud-Architektur zu nutzen.
Jede Person, Organisation oder Entität interpretiert den Begriff „Kante“ anders. Für manche ist der Rand ein Mobilfunkmast, für andere ist der Rand ihr Mobilgerät. Für Cloud-Service-Provider (CSPs) ist der Edge ein verwalteter Infrastruktur-Footprint, der sich nahtlos in ihr Back-End integrieren lässt. Bei militärischen Anwendungen ist die Kante der Schauplatz des Gefechts – sei es zu Land, zu Wasser oder in der Luft. Jedes Mal, wenn wir über den Rand lesen, wird die Interpretation im Allgemeinen als Rechen-, Netzwerk- und Speicherkapazität der Infrastruktur und/oder ihres Standorts zusammengefasst.
Für uns ist Edge 2.0 aber auch das Erlebnis, das es allen Beteiligten im Ökosystem bietet, und nicht nur den Infrastrukturressourcen oder deren Standorten.
Dieses Dokument beschreibt, welche Funktionalität Edge 2.0 bieten sollte, unabhängig von seiner physischen oder virtuellen Infrastruktur oder davon, wo es sich befindet oder instanziiert ist. Die Absicht besteht nicht darin, zu erklären, wie eine bessere verteilte Anwendung erstellt wird, sondern darin, die Funktionen aufzuzeigen, die in Edge 2.0 enthalten sein müssen, um die Erstellung optimaler verteilter Anwendungen zu unterstützen, die einer bestimmten Anforderung entsprechen.
Was ist Edge 2.0?
Aus der Sicht einer Entität, die sich in dieser verteilten Cloud befindet, befindet sich der Rand dort, wo sich die Entität aktuell befindet. Daher schlagen wir eine Definition von Edge 2.0 vor, die erlebnisorientiert ist und nicht nur an den Standort der Infrastruktur, den Infrastrukturtyp oder die kontrollierende Einheit gebunden ist.
Der Schwerpunkt von Edge 2.0 liegt auf der Verbesserung der anwendungszentrierten, betriebszentrierten und entwicklerzentrierten Erfahrungen. Edge 2.0 muss die Metaeigenschaften (wie SLAs und SLOs) der Anwendung berücksichtigen, indem es sich an die ändernden Anforderungen der Anwendung anpasst. Edge 2.0 muss einfach zu bedienen sein und Betriebsteams davon entlasten, für jede verteilte Anwendung eine neue Automatisierung erstellen zu müssen. Edge 2.0 muss die Reibungspunkte reduzieren, mit denen Entwickler bei der Entwicklung und Bereitstellung verteilter Anwendungen im großen Maßstab konfrontiert werden, indem es Sicherheit, Governance und Service-Level-Ziele nahtlos unterstützt.
Nehmen wir als Beispiel eine Bankanwendung. Das Ziel von Edge 2.0 besteht nicht darin, die Geschäftslogik der Transaktion zu verbessern. Es geht darum, die Sicherheit, Geschwindigkeit und Privatsphäre zu erhöhen, die Nutzung in allen Regionen (nach Bedarf) zu ermöglichen und sie je nach Bedarf nach oben oder unten skalierbar zu machen, um die Geschäftsziele zu unterstützen.
Konzepte und Behauptungen
Im Folgenden sind die Schlüsselkonzepte und Behauptungen dieses Dokuments aufgeführt:
- Erlebniszentrierter Vorteil: Schafft eine Grundlage für Edge 2.0 rund um das Erlebnis, das es liefert, statt um einen Vermögenswert oder dessen Standorte.
- Überlegungen zum Entwurf: Gibt wichtige Designüberlegungen für eine erfolgreiche Implementierung der Edge 2.0-Architektur an.
- Heterogene Infrastruktur: Hebt hervor, dass beim Entwurf einer verteilten Cloud eine dezentrale Steuerung der Infrastruktur berücksichtigt werden muss.
- Telemetrie als Grundlage: Betont die Telemetrie als grundlegenden Baustein, der auf allen Ebenen der Infrastruktur unterstützt werden muss. Ohne Telemetrie wird eine Daten-zuerst-Strategie verwässert.
- Herausforderungen zwischen den Clustern: Unterstreicht eine grundsätzliche Herausforderung bei Edge2.0, da es sich um eine Cluster-übergreifende statt einer Cluster-internen Ebene handelt.
- Adaptive Schnittstellen: Führt die adaptiven Schnittstellen ein und bietet einen deutlichen Vergleich mit deklarativen und imperativen Schnittstellen.
- Edge 2.0-Anwendungsplattform (EAP): Führt das EAP als Framework ein, um Edge 2.0 an die Anforderungen der Anwendungen anpassen zu können.
Unbeantwortete(s) Thema(n)
Es gibt mehrere Themen, die wir in diesem Dokument noch nicht behandelt haben:
- Verteilung der Anwendungsdaten: Es gibt hier viele Unterthemen wie Content Delivery Networks (CDNs), Speicherverteilung, Datenverteilung, Caching usw. Es gibt auch neue Technologien wie Conflict-free Replicated Datatype (CRDT). Ein Edge 2.0-Framework sollte in seinem Umfang Unterstützung für die Anwendungsdatenverteilung beinhalten.
- Funktionsverteilung: Man kann sich die Weiterentwicklung von Edge Computing so vorstellen, dass zentrale Cloud-Funktionen und -Logik näher an den Ort heranrücken, an dem das Ereignis generiert wird oder die Daten gespeichert sind. Da am Rand eine erhebliche Menge an Rechenleistung verfügbar wird, sollten wir jetzt ähnliche Probleme lösen, wie sie normalerweise in älteren Cloud-Architekturen gelöst werden, wenn wir diese Rechenleistung nutzen möchten. Beispiele hierfür sind Overlay-Networking, Middleware-Workloads und andere Arten von Workloads, die miteinander verknüpft und komplexer sind als die naiven Anwendungsfälle, die wir in den frühen Edge-Phasen gesehen haben – etwa Storlets, zustandslose einfache Flows, die neben den Daten ausgeführt werden.
- Es gibt wahrscheinlich noch weitere Bereiche, die nicht besprochen wurden. Das Ziel des Frameworks besteht darin, erweiterbar zu sein, sodass die Verantwortlichkeiten nach Bedarf hinzugefügt werden können.
Edge-Entwicklung
Abbildung 1 veranschaulicht die Koevolution der Edge- und Rechenzentrumsarchitekturen am besten. Edge 1.0 und 1.5 basierten auf dem Konzept eines Ursprungsstandorts und der Verschiebung der Daten und Dienste vom Ursprung zum Verbraucher. Bei Edge 1.0 handelte es sich um die Bereitstellung einer Internet-Infrastruktur, bei der der Schwerpunkt in erster Linie auf der Optimierung der Bandbreitennutzung durch verteiltes Inhalts-Caching (auch als Content-Distribution-Networks bekannt) lag. CDNs sind ein grundlegendes Designmuster, da der zu übertragende Gesamtinhalt immer größer sein wird als die verfügbare Bandbreite.
Als die CPU- und Speicherkosten rapide sanken, entstanden neben CDN-Knoten auch Computerfarmen. Anwendungen wurden als Dienste über serviceorientierte Architekturen (SOA) genutzt. Daher der Verweis auf Edge 1.5 als Service Distribution Network.
Ein gemeinsames Merkmal von Edge 1.0 und Edge 1.5 ist die Idee einer Ursprungssite. Vor dem Aufstieg des Mobilfunks luden Menschen, Geräte und Dinge in erster Linie Inhalte herunter oder fungierten als Konsumenten des Dienstes. Die Site, von der der Dienst ausging, war immer noch nicht mit der Site des Verbrauchers identisch.
In Edge 2.0 kann jedoch jede Entität als Ursprungssite oder als Verbraucher fungieren. Der Verkehrsfluss hat sich geändert. Menschen, Telefone und Geräte produzieren aktiv Daten, wenn sie Inhalte hochladen oder regelmäßig Daten generieren. Apps werden zu Konsumenten, da sie von anderen Apps abhängig sind. Alle Entitäten können als Produzenten oder Konsumenten eines Dienstes agieren – APIs, Menschen, IoT-Geräte oder Web-, Back-End- und Headless-Anwendungen. Aus seiner eigenen Sicht glaubt jedes Element der Infrastruktur, es befinde sich am Rand.
Die verteilte Cloud ist die neueste Stufe in der Entwicklung des Rechenzentrums. Computer sind mittlerweile allgegenwärtig – von Mobilgeräten bis hin zu Alltagsgegenständen, die mit dem Netzwerk verbunden sind. Parallel dazu wurden Softwarearchitekturen entwickelt, die verteilte und skalierbare Anwendungen ermöglichen.
Randfolgen: Erhöhte Komplexität
Die Fülle und Hyperverteilung von Rechen- und Speicherkapazitäten überall hat die Möglichkeit für eine schnelle digitale Transformation des Unternehmens geschaffen. Doch diese rasante Entwicklung hat ihre Konsequenzen.
Die meisten Unternehmen verfügen typischerweise über eine heterogene Infrastruktur mit nicht einheitlichen Umgebungen. Die effektive Skalierung solcher Umgebungen erfordert eine komplexe Orchestrierung und Automatisierung der eingesetzten Systeme. Schnelle Änderungen der Anwendungsanforderungen, beispielsweise Änderungen der CPU- und Bandbreitenanforderungen, erhöhen die Komplexität der Vorgänge in einer verteilten Cloud. Dies bedeutet zusätzlichen Stress für die Betriebsteams, die möglicherweise nicht ausreichend gerüstet sind, um effizient auf die sich ändernden Anforderungen der Anwendung oder des Endkunden zu reagieren.
Die Folgen dieser Probleme sind eine höhere betriebliche Komplexität, die alle potenziellen Vorteile für ein Unternehmen bei der digitalen Transformation zunichte macht.
Im Folgenden werden einige der miteinander verknüpften Probleme und Artefakte hervorgehoben, die sich aus der Komplexität ergeben.
Hybrid Clouds führen zu einer größeren Oberfläche, die durch eine Vielzahl von Angriffsvektoren gefährdet werden kann. Verschiedene Anwendungsfälle bringen unterschiedliche Sicherheitsherausforderungen mit sich und während sich die Infrastruktur weiterentwickelt, sind wir ständig auf der Jagd nach dem Puck. Daher erwarten wir folgendes Problem: Werden sich nur die Technologieempfehlungen häufig ändern oder werden sich auch die Entwurfsmuster zur Implementierung der Sicherheit ändern?
Hier sind einige der Probleme mit bestehenden Ansätzen:
- Software Defined Perimeter (SDP) lässt sich nicht leicht skalieren, da beliebte Lösungen agentenbasiert sind, was sich nicht für einfache betriebliche Bereitstellungen eignet.
- Die Implementierung von Zero Trust Network Access (ZTNA) ist oft nicht praktikabel, da ZTNA-Lösungen eine Konstellation aus bereitgestellten Produktionsdiensten erfordern, wie etwa Verkehrsprüfung, zentrales Protokollmanagement, globales PKI- und Identitätsmanagement und mehr.
- Secure Access Service Edge (SASE) kombiniert Network-as-a-Service und Security-as-a-Service, eine Abkürzungssuppe aus mehreren Technologien, deren Implementierung nicht trivial ist. Darüber hinaus liegt der Schwerpunkt von SASE tendenziell auf softwaredefinierten Weitverkehrsnetzen (SD-WAN) und deckt nur einen kleinen Teil der Edge-Anwendungsfälle von Unternehmensnetzwerken ab.
- Unterschiede zwischen der Infrastruktur verschiedener öffentlicher Cloud-Anbieter und bereits komplexe Sicherheitsmodelle, beispielsweise Identity and Access Management (IAM), führen häufig dazu, dass die Teams eine Flickenteppich-Härtung der Anbieter und umständliche Multi-Cloud-Konfigurationen vornehmen.
Eine der größten Herausforderungen bei der Hyperverteilung von stromsparenden und kostengünstigen Computern am Rand ist die Fähigkeit, die Infrastruktur einheitlich zu orchestrieren und zu planen. Ops-Teams haben Probleme mit der Skalierung und Unterstützung von Anwendungen, die die verteilte Cloud nutzen, da diese Anwendungen normalerweise heterogene Technologien mit unterschiedlichen Verwaltungsanforderungen umfassen.
Während Automatisierungsplattformen wie Terraform eine ausgereifte Möglichkeit zur individuellen Anpassung der Automatisierung bieten, müssen Betriebsteams dennoch Skripte für mehrere Permutationen pflegen: zum Beispiel fünf verschiedene Arten von Computern, vier verschiedene Firewall-Typen und drei Arten von Lastenausgleichsmodulen. Der Personalaufwand für die Verwaltung und Wartung der Automatisierungsskripte ist nicht skalierbar.
Dies führt dazu, dass der Infrastrukturkunde weiterhin über ticketgesteuerte Systeme mit den Betriebsteams interagiert, was die Automatisierung vorhandener Arbeitsabläufe behindert. Der Service Desk wird mit Tickets überschwemmt und muss Sicherheit und Stabilität gegenüber Agilität priorisieren.
Mit der Entwicklung hin zur Multi-Cloud sind Microservices-Architekturen bereits zur De-facto-Methode für die Erstellung neuer Anwendungen geworden. APIs werden veröffentlicht und können jederzeit und überall nach Bedarf instanziiert werden, was zu einer unkontrollierten Ausbreitung der APIs führt. Das Entdecken, Verbinden und Verwalten dieser APIs auf autonome Weise wird zu einer großen Herausforderung.
Um der API-Ausbreitung entgegenzuwirken, ist ein Paradigmenwechsel erforderlich. Unsere internen Modelle zeigen, dass selbst moderate Annahmen bei Parametern wie der Anzahl der weltweiten API-Entwickler, der Anzahl der pro Entwickler und Jahr entwickelten APIs und der API-Haltbarkeit dazu führen, dass bis 2030 viele Hundertmillionen (wenn nicht Milliarden) APIs gleichzeitig aktiv sein werden (Abbildung 2). Der API Sprawl-Bericht 2021 bietet einen umfassenden Überblick über dieses aufkommende Thema.
Aufgrund der zunehmenden Komplexität müssen Unternehmen eine detaillierte und aussagekräftige End-to-End-Sichtbarkeit des End-to-End-Systems ermöglichen. In verteilten Cloud-Umgebungen überschreiten Anwendungen mehrere heterogene Infrastrukturstapel, die von separaten Einheiten verwaltet werden.
Darüber hinaus besteht für keinen der Betreiber heute ein Anreiz, Unternehmenskunden native Telemetriedaten seiner Infrastruktur zugänglich zu machen. Unternehmen agieren beim Einsatz von Anwendungen in einer verteilten Cloud im Wesentlichen im Blindflug und müssen auf mehrere Beobachtungstools zurückgreifen. Um diese Sichtbarkeitslücken zu schließen, stammen die Tools typischerweise von verschiedenen Anbietern und arbeiten an unterschiedlichen Punkten der Infrastruktur oder der Anwendungsstapel.
Nicht standardisierte Infrastrukturmetriken verschlimmern die Probleme eines Unternehmens. Normalerweise sind die Messwerte aufgrund von Betriebssilos und anderen Faktoren wie einer uneinheitlichen Infrastruktur in unterschiedlichen Infrastrukturumgebungen nicht einheitlich. Beispielsweise sind die Messgrößen bei den verschiedenen öffentlichen Cloud-Anbietern unterschiedlich und auch für die Technologien lokaler Rechenzentren gelten keine Standardmessgrößen.
Geschäftsergebnis: Verminderte Erfahrung
Umsatzgenerierende Workloads und unternehmenskritische Systeme beanspruchen typischerweise den Großteil der Betriebsressourcen und des Budgets eines Unternehmens. Mittlerweile machen kleinere Projekte, wenn auch von geringerer Komplexität, den Großteil der Unternehmensanwendungen aus. Abbildung 3 stellt dies als Long-Tail-Verteilung der Anzahl der Projekte dar, die ein Unternehmen wahrscheinlich im Vergleich zu seiner betrieblichen Komplexität hat.
Während bei kleineren Anwendungen die betriebliche Komplexität geringer sein kann, erfolgen die Prozesse und Arbeitsabläufe zur Betriebsaufnahme in vielen Fällen immer noch manuell und es kann Wochen dauern, bis Servicetickets mehrere Betriebsteams erfolgreich durchlaufen. Wenn Sie beispielsweise eine Anwendung bereitstellen, die dedizierte Netzwerkressourcen mit detaillierten Sicherheitsrichtlinien erfordert, müssen die globalen Sicherheitsteams möglicherweise zunächst die Genehmigungen für die Sicherheitsrichtlinien ausarbeiten. Anschließend wird das Serviceticket möglicherweise an das Netzwerkteam weitergeleitet, das die erforderlichen Subnetz- und Routenkonfigurationen plant. Schließlich ist möglicherweise die Validierung der Firewall-Regeln durch ein weiteres Betriebsteam erforderlich, das für die Firewall-Verwaltung verantwortlich ist.
Stellen wir uns nun vor, dass die oben genannte Komplexität für jede Anwendung berücksichtigt werden muss, die in einer verteilten Cloud bereitgestellt wird, wobei das Unternehmen keinen Teil der zugrunde liegenden Infrastruktur besitzt. Die enorme Menge an kleinen Projekten oder Anwendungen, die integriert und unterstützt werden müssen, macht es für Betriebsteams unrealistisch, jedes Projekt zu unterstützen. Dadurch entstehen Priorisierungsprobleme und die Möglichkeit zur Selbstbedienung.
Dieses Priorisierungsproblem ist besonders deutlich, da sich die Investitionen der Infrastrukturteams auf die Unterstützung kritischer und umsatzgenerierender Systeme konzentrieren und kaum Zeit oder Budget für völlig neue Projekte bleiben, die ihren eigenen Lebenszyklus aus Entwicklung, Tests und Bereitstellung vor der Produktion umfassen. Dies führt zu verminderten Fähigkeiten und Investitionen in die Funktionsgeschwindigkeit, Anpassung und Innovation, die neue Produkte unterstützt, was wiederum in einer Stagnation des Geschäfts und seiner Angebote gipfelt.
Edge-Lösungsraum
Die Entwicklung des Edge-Ökosystems erweitert den Lösungsraum erheblich, indem sie die Möglichkeit bietet, diese Herausforderungen mit einer Anwendungsplattform zu bewältigen.
Abbildung 4 zeigt den Edge 2.0-Lösungsraum. Hier stellen wir fest, dass alles, was unter eine verteilte Cloud-Architektur fällt, die Gesamtheit des Lösungsraums ist.
Daher muss Edge 2.0 im Rahmen des Lösungsraums die von allen folgenden Personen gewünschte Erfahrung bieten:
- Alle Entitäten, die sich im Lösungsbereich befinden – Apps, Menschen und Geräte, die als Verbraucher fungieren, oder Web-Backend- und Headless-Anwendungen, aus denen die Dienste bestehen.
- Die SRE-Teams und Anwendungseigentümer dieser Apps müssen gleichzeitig die Sicherheits- und behördlichen Schutzmaßnahmen einhalten, die von der Infrastruktur erwartet werden.
Edge 2.0 wird betriebstechnisch einfach, sicher und konform sein und allen daran teilnehmenden Einheiten des Ökosystems ein qualitativ hochwertiges Erlebnis bieten.
Designüberlegungen zu Edge 2.0
Standardmäßig sicher
Eine verteilte Cloud verstärkt dieses Sicherheitsproblem im großen Maßstab, da die Anzahl der Endpunkte exponentiell zunimmt. Bei einem derart großen Maßstab steigt auch die Komplexität der Implementierung einer Lösung. Die Sicherheitslage sollte so aussehen, dass die Anwendung davon ausgeht, dass die Umgebung, in der sie aktuell bereitgestellt wird, bereits kompromittiert ist. Ebenso darf die Infrastruktur keiner Anwendung vertrauen, die in ihr ausgeführt wird.
Die Grundlage dieser Ideen sind in den Konzepten der Zero-Trust-Denkweise erfasst, und das BeyondCorp1-Beispiel demonstriert diese Konzepte für den Anwendungsfall des Anwendungszugriffs. Edge 2.0 erweitert dieses Modell künftig auf der Grundlage der folgenden fünf Kernprinzipien:
- Identität ist grundlegend: In Edge 2.0 ist die Identität tief verwurzelt: Jede Entitätsinstanz hat nicht nur ihre eigene, global eindeutige Identität, sondern 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 zentrale Überlegung sein.
- Geringste Privilegien: Die einem Akteur gestatteten Aktionen sollten auf diejenigen beschränkt werden, die der Akteur zur Erfüllung seiner Rolle im System benötigt. Ein Beispiel hierfür ist die Beschränkung der Teilmenge an Workloads, die basierend auf der Entwurfsspezifikation mit dem Datenbankserver kommunizieren dürfen.
- Kontinuierliche Authentifizierung: Für jede von einem Systemakteur vorgenommene Bestätigung muss eine Verifizierungsmöglichkeit bestehen und sie sollte bei jeder solchen Bestätigung explizit verifiziert werden. Die Authentifizierung sollte nicht ausschließlich explizit über gemeinsame Geheimnisse oder eine Vertrauenskette 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 -speichertechnologien 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 einzudämmen. Die Bewertung muss nahezu in Echtzeit und im großen Maßstab erfolgen, was einen großzügigen Einsatz von Automatisierungs- und maschinellen Lerntechniken erfordert.
- Verstoß annehmen: Angesichts der Ressourcen, die hochentwickelten Angreifern heute zur Verfügung stehen, muss man davon ausgehen, dass jedes System in irgendeiner Form kompromittiert wurde. Daher sind die vollständig deterministischen Richtlinien, die auf Arbeitslast und Benutzeridentitäten basieren und einen durch a und b dargestellten, berechtigungsbasierten Zugriff erzwingen, häufig nicht in der Lage, alle Angriffe zu verhindern. Daher muss ein vollständig ausgereiftes Edge 2.0-System auch in der Lage sein, Risiko-/Ertragsbewertungen in Echtzeit auf der Grundlage kontinuierlicher Überwachung und Bewertung vorzunehmen.
Bietet native Beobachtbarkeit
Edge 2.0 muss die Telemetrie als erstklassige Komponente tief in den Infrastruktur-Stack integrieren, eine einfache und skalierbare Möglichkeit bieten, schichtübergreifende Telemetrie innerhalb der Infrastruktur zu erfassen und diese auf einer gemeinsamen Plattform bereitzustellen. Dies hilft den Beobachtungsteams, bei Bedarf Abfragen zum „Zustand der Infrastruktur“ durchzuführen. Dadurch können sich Anwendungsteams auf die Geschäftslogik konzentrieren, ohne ihre Anwendungsstapel explizit zu instrumentieren.
Der aktuelle Stand der Observability-Technologie ist weitgehend anbieterspezifisch und proprietär. Dies hat dazu geführt, dass viele anbieterspezifische Agenten ähnliche Signale sammeln, die um teuren Speicher und CPU konkurrieren.
Der nächste logische Schritt ist die Verwendung eines herstellerunabhängigen Telemetrie-Sammlers, der das Streamen von Infrastruktur- und Verkehrsdaten auf eine zentrale Datenplattform ermöglicht.
Vielen Produktteams fällt es schwer, die Investition in Instrumentierung zu rechtfertigen, da der Aufwand einer Umsatzchance entsprechen muss. Die Infrastruktur sollte wie jede andere Geschäftsfunktion oder jeder andere Geschäftsprozess instrumentiert werden, da das Team ihr Verhalten verstehen muss, um sie für die Geschäftsziele zu optimieren. Die Debatte sollte sich daher weniger auf die Notwendigkeit als vielmehr darauf konzentrieren, was bei der Instrumentierung Priorität haben sollte.
Um detailliertere und genauere Messungen des Anwendungsverhaltens zu erreichen, gehen wir davon aus, dass die Instrumentierung durch Aufruf zum Zeitpunkt der Codeerstellung „nach links verschoben“ wird – Abbildung 5.
Unterstützt adaptive Schnittstellen
Im Einklang mit der verteilten Cloud verfügt jede Cloud innerhalb ihres Bereichs (lokal oder global) über einen eigenen Manager, Administrator, Orchestrator und mehr, wenn man ein paar Schichten tiefer geht. Jedes verhält sich unabhängig und trifft seine eigenen Entscheidungen, stellt aber bei Bedarf Schnittstellen für die Verwendung durch andere Entitäten bereit.
Das Konzept einer verteilten Cloud besteht im Wesentlichen aus einer dezentralen Verwaltung und Kontrolle. Dieser Tatsache kann man nicht entgehen und es ist wichtig für uns, sie zu erkennen, um die Nuancen zwischen adaptiven, 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 basieren, die im Wesentlichen statische Konstrukte sind, die sich nicht schnell genug an rasch ändernde Bedingungen anpassen.
Wir müssen ergebnisorientiert vorgehen und die Systeme müssen intelligent genug sein, um Richtlinien über die gesamte Infrastruktur hinweg (Ende-zu-Ende) anzupassen, um diese Ergebnisse zu erreichen. Wir nennen diese adaptive Schnittstellen.
Um es klar zu sagen: imperative, deklarative und adaptive Schnittstellen schließen sich nicht gegenseitig aus:
Imperativ: Ist sehr normativ und definiert detailliert eine Reihe von Aktionen, um den gewünschten Zustand zu erreichen. Die Konfiguration eines Routers ist beispielsweise eine zwingend erforderliche Aktion. Im obigen Szenario werden die vorgeschriebenen Aktionen präzise sein: welches Rechenzentrum, wie viel CPU/Speicher, erforderliche Bandbreite, bestimmte Routen und mehr. Die Eingabequalität des Datenmodells ist sehr hoch und erfordert daher tiefere Kenntnisse und Fachkenntnisse über die Infrastruktur. Es wird erwartet, dass sowohl das Modell als auch die Struktur der Infrastruktur bekannt sind.
Deklarativ: Die Nuance des deklarativen Ansatzes besteht darin, dass er sich auf die Beschreibung des gewünschten Zustands konzentriert, im Gegensatz zu Aktionen, die den gewünschten Zustand erreichen. Die Qualität der Eingaben ist geringer, allerdings muss die Anwendung dennoch zumindest die Struktur der zugrunde liegenden Infrastruktur kennen.
Anpassungsfähig: Steht getrennt vom Imperativ oder Deklarativ. Eine adaptive Schnittstelle konzentriert sich auf das gewünschte Ziel und nicht auf den Zustand. Das Ziel der adaptiven Schnittstelle besteht darin, die Ziele des Stakeholders zu erfassen, der die Anwendung bereitstellen möchte, anstatt sich auf Vorkenntnisse des zugrunde liegenden Systems zu konzentrieren. Beim Adaptive-Ansatz ist der Unterschied, dass er keine Vorstellung von den Fähigkeiten der zugrunde liegenden Infrastruktur hat. Es gibt keine Einschränkungen hinsichtlich der „Erledigung der Arbeit“, daher ist das Konzept eigenständiger Natur.
Bei adaptiver Eingabe ist die Qualität der Eingabe gering und nähert sich der natürlichen Sprache an. Anwendungsbesitzer können eine Anfrage senden, um dem Infrastrukturcontroller mitzuteilen, welches Ergebnis sie erwarten, anstatt die erforderliche Funktion deklarieren oder eine Ressource speziell konfigurieren zu müssen.
Löst das Inter-Cluster-Problem
Eine verteilte Cloud unterstützt per Definition alle Arten von Anwendungsarchitekturen: monolithisch, Microservices oder serverlos. Unabhängig von der Architektur verwenden Anwendungen APIs, um die Dienste anzubieten.
Die Probleme der API-Erkennung, Konnektivität und Netzwerksicherheit werden größtenteils durch die Verwendung eines Service Mesh gelöst, ein Service Mesh löst diese jedoch nur innerhalb des Clusters (intra-Cluster).
Edge 2.0-Anwendungen hingegen nutzen APIs über eine hyperverteilte Cloud-Infrastruktur, im Wesentlichen eine Multi-Cluster-Umgebung. Neue Anwendungen werden mit APIs geschrieben, die organisatorische und geografische Grenzen überschreiten. Bei einigen der APIs kann es sich um private APIs oder Partner-APIs hinter mehreren Firewall-Ebenen ohne explizite Route zwischen ihnen handeln, selbst wenn sie erkennbar sind. Für dieses heterogene Cluster-Problem (Inter-Cluster-Problem) gibt es keine elegante, leichte, skalierbare und sichere Lösung, die praktikabel ist.
| Szenario/Eigenschaften | Imperativ | Deklarativ | Anpassungsfähig |
|---|---|---|---|
| Definition | Die imperative Schnittstelle definiert den detaillierten Kontrollfluss basierend auf den spezifischen Fähigkeiten der zugrunde liegenden Ressource. |
Die deklarative Schnittstelle definiert die Logik, aber nicht den Kontrollfluss. Aus der Programmiersprache ist es der Pseudocode. |
Die 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 ist Eigentum der Infrastruktur und ermöglicht es der Infrastruktur, dynamisch auf die sich ändernden Anforderungen der Anwendung zu reagieren. |
Szenario 1: Das Paket muss von SFO nach NYC |
Jane sagt Mark: (a) Drucke das Versandetikett aus, (b) Gehe zum UPS-Geschäft, (c) Wähle die 72-Stunden-Lieferung, (d) Bezahle und versende es Markieren: Muss einer Reihe sehr spezifischer Schritte folgen |
Jane bittet Mark: (a) Bitte schicken Sie dieses Paket per Kurier an diese Adresse. (b) Das Paket muss innerhalb von 72 Stunden ankommen. Markieren: Sie können jedes beliebige Kurierunternehmen auswählen (UPS, FedEx, DHL usw.). |
Jane erklärt Mark: (a) Dieses Paket muss bis Samstag in NYC ankommen. Markieren: Kann machen was er will. Möglicherweise nimmt er das Paket sogar persönlich entgegen, fliegt nach New York und übergibt es dort persönlich. |
Szenario 2: Beispiel für einen Load Balancer |
Der Load Balancer ist bereits vorhanden. Aufgabe: muss mit dieser Richtlinie konfiguriert werden. Hier ist die Aufgabe spezifisch für Marke, Modell, Version usw. des Load Balancers. |
Ein Loadbalancer ist nicht vorhanden. Aufgabe: Lastausgleich der Anwendung mit einer bestimmten offenen Richtlinie. Aufgabe geht davon aus, dass eine Orchestrierung |
Keine Annahmen über die zugrunde liegende Infrastruktur. Bitte stellen Sie sicher, dass die Anwendung bei Bedarf mit einer maximalen Latenz von 10 ms skaliert wird. |
Eigentum |
Gemeinsames Eigentum: Anwendung und Infrastruktur |
Gemeinsames Eigentum: Anwendung und Infrastruktur |
Nur die Infrastruktur |
Qualität der Eingabe |
Extrem hoch. Erfordert fundierte Kenntnisse des zugrunde liegenden Umfangs. Sie müssen beispielsweise wissen, welcher F5-Load Balancer, welche Softwareversion usw. Eine CLI oder ein NMS wären ein Beispiel für imperative Schnittstellen. |
Hoch: Erfordert Kenntnisse über die Leistungsfähigkeit der Infrastruktur. Im obigen Beispiel gibt es beispielsweise Vorkenntnisse über die Infrastruktur, die einen Load Balancer unterstützt. |
Niedrig: Erfordert keine Kenntnisse über die Fähigkeiten der Infrastruktur. Die Eingabequalität nähert sich dem Äquivalent natürlicher Sprache an. |
Fähigkeitsstufe (Persona) |
Funktionsspezifische Fähigkeiten. Beispielsweise Netzwerkadministrator, Computeradministrator, Speicheradministrator. Jeder Aspekt der Infrastruktur erfordert, dass der Benutzer ein Experte auf dem jeweiligen Gebiet ist. |
Kenntnisse im Bereich Anwendungsbereitstellung. Der Benutzer kennt den Funktionstyp, der zum Bereitstellen der Anwendung erforderlich ist. Wie im obigen Fall weiß der Anwendungsmanager, dass ein Lastenausgleich erforderlich ist, und dass es Richtlinien auf hoher Ebene gibt, auf deren Grundlage der Lastenausgleich konfiguriert werden muss, um die automatische Skalierung zu unterstützen. |
Anwendungstechniker. Kann der Infrastruktur lediglich signalisieren, was die nicht-funktionalen Anforderungen der Anwendung sind. In diesem Fall, wie schnell die Anwendung auf eine Kundenanfrage reagieren soll. Andere Faktoren wie geografische Lage, Kosten usw. können bei Bedarf hinzugefügt werden. |
Umfang |
Die zwingend erforderlichen Schnittstellen haben |
Der deklarative Umfang ist größer. Normalerweise mit einer Orchestrierungs-Engine verbunden, die mit mehreren imperativen Schnittstellen kommuniziert, um das gewünschte Ergebnis zu erzielen. |
Sehr großer Spielraum, da das Ergebnis |
Beispiel |
- Name: Webserver aktualisieren Hosts: Webserver Remote-Benutzer: Root Aufgaben: - Name: Sicherstellen, dass Apache auf der neuesten Version ist Yum: Name: httpd Status: neueste - Name: Apache-Konfigurationsdatei schreiben Vorlage: Quelle: /srv/httpd.j2 Ziel: /etc/httpd.conf |
Apache-Server: Version: „neueste“ |
Anwendungslatenz: - lt: 10 ms Infrastrukturkosten: - lt: 200 $ - Abrechnung: monatlich |
Wir haben uns im API Sprawl-Bericht 20212 ausführlich mit APIs befasst und gehen darin auf viele Fragen ein, die möglicherweise auftauchen. Abbildung 6 zeigt den Unterschied zwischen Inter-Cluster und Intra-Cluster.
Innerhalb des Clusters: In einer monolithischen Architektur sind möglicherweise nur sehr wenige APIs verfügbar, die eine interne Kommunikation zwischen Modulen über andere Methoden der Interprozesskommunikation ermöglichen. Während eine Mikroservice-Architektur in Dutzende, wenn nicht Hunderte von APIs unterteilt ist.
Wie dem auch sei, jeder Anwendungscluster wird eigenständig entwickelt und verwaltet. Beispielsweise kann ein Team im Fall einer Microservice-Architektur jede beliebige Art von Service Mesh verwenden – Istio, Linkerd, Aspen Mesh oder andere. Jeder Ansatz verfügt über eigene Mittel zum Verwalten und Steuern der APIs innerhalb seines Clusters, also intra-cluster.
Hierfür gibt es viele Lösungen, und das Ziel von Edge 2.0 besteht nicht darin, Organisationen oder Entwicklungsteams neu zu erfinden oder sie zur Einführung einer weiteren neuen Technologie zu zwingen.
Inter-Cluster: Da die Anzahl der über APIs bereitgestellten Dienste zunimmt, werden neue Anwendungen unter Verwendung von Diensten erstellt, die bereits von verschiedenen Anwendungsteams im Unternehmen entwickelt oder übernommen wurden, da das Rad nicht neu erfunden werden muss.
Neue Anwendungen werden auch durch unterschiedliche Kombinationen öffentlicher und privater APIs erstellt. Aus architektonischer Sicht nutzen moderne Anwendungen die Dienste anderer Cluster. In einer verteilten Cloud werden diese Cluster global eingesetzt und können sich daher an jedem Standort befinden, der die Anwendung hosten oder Teil des Anwendungsclusters sein kann.
Um es noch einmal zu wiederholen: Der Umfang eines Anwendungsclusters beschränkt sich nicht nur auf eine Organisation. Cluster können sich über zwei beliebige Netzwerke, Anwendungen, Organisationssilos oder sogar zwischen zwei Unternehmen erstrecken.
Der Umfang erstreckt sich über die gesamte Bandbreite aller Permutationen und Kombinationen, wodurch die Komplexität der Operationen exponentiell zunimmt. Abbildung 7 zeigt die Verkehrspermutationen innerhalb des Bereitstellungsumfangs der Anwendung.
Ein typisches Unternehmen verfügt über unterschiedliche Anwendungsarchitekturen. Es könnte verschiedene Varianten von Service Meshes geben, oder eine Web 2.0-Anwendung auf Basis einer serviceorientierten Architektur, oder eine monolithische Softwarebereitstellung, je nachdem, welches Team sie entwickelt und bereitstellt. APIs sind daher über das gesamte Unternehmen verstreut, egal ob es sich um private APIs oder die Verwendung öffentlicher APIs handelt. Dieses Problem ist noch nicht gelöst. Die API-Kommunikation zwischen mehreren Standorten ist kritisch und stellt in Unternehmen jeder Größe ein Problem mit schwer fassbarer Lösung dar.
Es gibt mehrere Lösungen zum Verwalten von APIs innerhalb eines Clusters (z. B. Ingress-Controller, API-Gateway und mehr), während die API-Kommunikation zwischen Clustern nicht auf praktische, skalierbare und sichere Weise gelöst ist. Daher konzentrieren wir den Umfang der einheitlichen API-Steuerung und -Verwaltung darauf, nur Cluster-übergreifende Probleme zu beheben.
Bietet Autonomie
Ein unterschätzter Wert der Cloud ist die Autonomie, die sie dem „Cloud-Verbraucher“ bietet. Unternehmen und Unternehmer können bei Bedarf ihre eigene Infrastruktur erstellen und dabei den Eindruck vollständiger Kontrolle erlangen.
Das grundlegende Designprinzip, dem eine Edge 2.0-Plattform folgen muss, besteht darin, dem Cloud-Kunden ein autonomes Erlebnis zu bieten und gleichzeitig die richtigen Leitplanken zu implementieren. Da die Entitäten in jeder beliebigen Infrastruktur (vertrauenswürdig oder nicht vertrauenswürdig) auftreten können, müssen die Leitplanken so implementiert werden, dass sie die BU oder das für die Erstellung der Anwendung verantwortliche DevOps-Team nicht belasten.
Die neue Herausforderung bei Edge 2.0 wird die Erkennung, Identität, das Vertrauen und die Beobachtbarkeit zwischen verschiedenen Diensten sein.
Selbst in mittelgroßen Unternehmen wäre die Anzahl der jährlich produzierten APIs groß. Wie entdecken Teams diese Dienste innerhalb des Unternehmens? Oder wie können sie überhaupt wissen, ob die Dienste noch gültig sind und wem sie gehören? Können sie sicher sein, dass es sich um einen validierten Dienst mit etabliertem Vertrauen handelt? Das Problem wird noch größer, wenn Teams Dienste nutzen möchten, die von Clustern außerhalb des Unternehmens erstellt wurden, z. B. von SaaS-Anbietern oder Apps, die auf Edge-Geräten ausgeführt werden, die sich vollständig der administrativen Kontrolle der Infrastrukturteams des Unternehmens entziehen.
Edge 2.0-Anwendungsplattform
Angesichts der in früheren Abschnitten dargestellten Herausforderungen müssen wir die gesamte verteilte Cloud als Plattform betrachten. Auf einer übergeordneten Ebene formulieren wir das Ziel der Lösung: die autonome Erkennung (ohne menschliches Eingreifen), Skalierung und Sicherung verteilter Anwendungen über eine dezentrale Infrastruktur hinweg.
Im Wesentlichen können wir die Verantwortung der Edge 2.0 Application Platform (EAP) wie folgt beschreiben:
- API-Erkennung, Identität und Vertrauen
- Infrastrukturplanung und -orchestrierung
- Sichere Anwendungskonnektivität
EAP-Umfang
Die Infrastruktur ist die Gesamtheit des Lösungsraums, in dem Infrastrukturelemente kontinuierlich erscheinen und verschwinden können. Der Besitz der Infrastruktur und ihrer Ressourcen sowie die Verwaltung und Kontrolle dieser Ressourcen sind zwei getrennte Konstrukte. Ein Infrastrukturbesitzer kann eine bestimmte Infrastruktur oder eine Instanz davon einer anderen Organisation zuweisen, die sie verwaltet und konfiguriert, oder der Infrastrukturbesitzer kann bei Bedarf die Kontrolle zurückerlangen. Die Organisation, die die Elemente verwaltet und konfiguriert, kann sie zudem einzelnen Projekten oder Anwendungen zuordnen. Dieses Konzept ist nicht neu. Beispielsweise bieten Anbieter von Cloud-Diensten eine hierarchische Verwaltungskontrolle an, die von den IT-Teams eines Unternehmens genutzt werden kann, um internen Geschäftseinheiten, Teams usw. Infrastructure-as-a-Service (IaaS) anzubieten. Die Hauptsorge bei Edge 2.0 besteht darin, dies umfassend in einer hyperverteilten Cloud umzusetzen, die den aktuellen und zukünftigen Zustand der Edge-Infrastruktur darstellt.
Hier kommt der Umfang des EAP ins Spiel. Abbildung 8 unten zeigt den Umfang von EAP im Kontext verschiedener Schnittstellentypen. Jeder EAP orchestriert mit seinem lokalen Bereich unter Verwendung deklarativer und imperativer Schnittstellen. In diesem Fall:
- Deklarative/imperative Methoden wären die AWS-APIs, Azure-APIs usw.
- Eine Neuheit wären adaptive Schnittstellen, die im Einzelfall definiert werden müssten.
Um die Vorteile der verteilten Cloud zu nutzen, sollte das EAP in der Lage sein, alle über eine verteilte Cloud verfügbaren Knoten und Entitäten zu nutzen. Die Vision besteht darin, dass das einzelne EAP dem autonomen Systemkonzept3 in IP-Netzwerken entspricht, jedoch für die Anwendungsschicht.
Durch die Zusammenführung (Abbildung 9 unten) können wir nun eine Übersicht darüber erstellen, wie mehrere EAPs in einer dezentralen Cloud-Infrastruktur bereitgestellt werden können und dabei autonom miteinander interagieren.
Adaptive Schnittstellen erleichtern zudem die Integration von CI/CD und anderen Apps des Anwendungslebenszyklus in die verteilte Cloud. CI/CD-Plattformen können über einfache adaptive Schnittstellen, die nur das gewünschte Ergebnis angeben, direkt mit dem EAP interagieren.
Es ist wichtig zu beachten, dass die Inter-EAP-Kommunikation auch über adaptive Schnittstellen erreicht werden kann.
Das EAP-Framework
Das EAP-Framework, wie in Abbildung 10 dargestellt, organisiert die Verantwortlichkeiten hinsichtlich der Fähigkeiten jeder EAP-Instanz. Die Rolle des EAP besteht darin, eine Schnittstelle zu den zugrunde liegenden Infrastruktur-Controllern herzustellen (sei es Infrastructure as a Service (IaaS), Platform as a Service (PaaS) oder Software as a Service (SaaS)) und bei Bedarf die entsprechenden Ressourcen zu orchestrieren und einzuplanen.
Einheitliche API-Steuerung und -Verwaltung
Die Zukunft wird eine API-gesteuerte Wirtschaft sein, in der APIs mehr sind als nur ein durch Service Mesh vereinfachter Softwarearchitekturansatz. Eine API wird zum primären Mittel, mit dem jede an einer verteilten Cloud teilnehmende Entität ihre Dienste bereitstellt.
Wie bereits erwähnt wird die weltweite Anzahl öffentlicher und privater APIs, die innerhalb des Jahrzehnts verfügbar sein werden, Hunderte Millionen, wenn nicht sogar Milliarden betragen. APIs werden unsere Wirtschaft umgestalten und erfordern daher einen genaueren Blick darauf, was das EAP umsetzen muss, um diese Wirtschaft zu unterstützen.
Die drohende Ausbreitung der APIs erfordert, dass jede API innerhalb und außerhalb des EAP auffindbar sein muss. Mit der verteilten Cloud können sich die APIs an beliebiger Stelle in mehreren Clustern befinden.
Die zugrunde liegende Annahme ist, dass es sich bei dem API-Erkennungsproblem tatsächlich um ein Cluster-übergreifendes Problem handelt. Der Umfang eines EAP kann sich über viele Anwendungscluster erstrecken, die unterschiedliche Softwareansätze (von Microservices bis monolithisch) verwenden und jeweils ihre eigene API-Gateway-Strategie implementieren. Ein EAP bietet ein gemeinsames Repository für alle APIs, die in seinem Bereich registriert und gefunden werden können, nicht nur innerhalb des Clusters. Diese Unterscheidung ist der Schlüssel zur Ableitung der Einschränkungen bestehender API-Gateway-Strategien, beispielsweise im Service Mesh.
Die Herausforderung für das EAP besteht darin, die Erkennung einer API zu ermöglichen, die richtige Dokumentation zu ihrer Verwendung bereitzustellen und den Lebenszyklus der API im Hinblick auf Konsistenz, Genauigkeit und Versionierung zu verwalten. Das EAP implementiert eine Möglichkeit, Entitäten, die seine APIs verwenden, über den aktuellen Status bestimmter verwendeter APIs zu informieren. Dies könnte einfach durch das Festlegen von Ablaufdaten oder durch eine explizite Information über ein Nachrichtensystem geschehen.
Die eingenommene Sicherheitshaltung besteht darin, dass eine Anwendung davon ausgeht, dass die Infrastruktur, in der sie aktuell bereitgestellt wird, bereits kompromittiert ist.
Die wichtigste Säule zur Umsetzung dieser Sicherheitslage ist identitätsbasiert. Jeder API-Endpunkt muss eine global eindeutige Identität haben. Sicherheitsrichtlinien und -kontrollen werden separat in einem zentralen Repository verwaltet.
APIs müssen als öffentlich oder privat gekennzeichnet werden, wodurch die zugrunde liegenden Sicherheitskomponenten der Infrastruktur automatisch für die jeweilige API konfiguriert werden.
Alle App-App-Konversationen beginnen mit einer Deny-All-Richtlinie. Nur weil eine API sichtbar ist, bedeutet das nicht, dass eine andere Anwendung sie aufrufen kann. Dies muss in der Sicherheitsrichtlinie der Anwendung explizit konfiguriert werden.
Das EAP muss sicherstellen, dass alle APIs in seinem Geltungsbereich vertrauenswürdig sind und dass gleichzeitig auch alle externen APIs vertrauenswürdig sind, die von Diensten in seinem Geltungsbereich verwendet werden.
„Vertrauen kann man nicht beweisen, erst dadurch wird es zu ‚Vertrauen‘“ – Aus Traitors @ Netflix
Vertrauen ist im Wesentlichen ein „Ruf über einen längeren Zeitraum“, und Sie müssen dieses Vertrauen kontinuierlich neu bestätigen, um sicherzustellen, dass es nicht unter ein akzeptables Niveau gesunken ist. Dieser Ansatz hat sich bei der Modellierung und Implementierung von Vertrauen in Systemen zunehmend durchgesetzt und erfordert eine kontinuierliche Bewertung des Vertrauens, anstatt es bei der ersten Ausführung statisch geltend zu machen.
Die Fluktuation des Vertrauens im Laufe der Zeit kann für einige Unternehmen eine Herausforderung darstellen, da ihnen der Luxus der Zeit fehlt, um ein gegenseitiges Vertrauen zwischen ihren Systemen und denen von Drittanbietern aufzubauen. Sowohl die Infrastruktur als auch die APIs können verheerende Schäden anrichten, wenn ihr Ruf nicht sorgfältig überwacht wird.
Angenommen, ein Dienst im EAP-Bereich greift auf eine externe API zu. Dann muss die Plattform einen Mechanismus implementieren, mit dem der aufrufende Dienst die Genauigkeit der empfangenen Antwort von der externen API sicherstellen kann. Nur weil die API-Antwort gültig aussieht, heißt das nicht, dass sie vertrauenswürdig ist. Entweder ist die Antwort aufgrund von Qualitätsproblemen ungenau, oder es wurden möglicherweise absichtlich Ungenauigkeiten eingefügt, um die Wettbewerbsfähigkeit des Unternehmens zu beeinträchtigen. Die Möglichkeit, jeder API – intern oder extern – einen Vertrauensfaktor zuzuweisen, ist einzigartig für die EAP-Konstruktion.
Eine Strategie zur Implementierung von Vertrauen besteht darin, den Durchschnitt über einen jüngsten „Zeitraum“ statt über die gesamte Historie des Dienstes zu ermitteln. Dies ist, als würde man bei Amazon die „Top-Bewertungen“ im Vergleich zu den „Neuesten“ für ein Produkt betrachten. Das Produkt kann zwar vier Sterne haben, aber wenn die meisten negativen Bewertungen aus den letzten sechs Monaten stammen, deutet dies auf einen kürzlichen Vertrauensverlust hin, während eine Flut positiver Kommentare in den letzten sechs Monaten auf eine Behebung oder Wiederherstellung des Vertrauens schließen lässt.
Der Vertrauensfaktor hängt nicht nur davon ab, ob eine API eine bekannte Quelle falscher oder irreführender Daten ist oder nicht. Der Ruf eines EAP hängt auch davon ab, wie gut es die APIs in seinem Rahmen verwaltet und aktualisiert. Darüber hinaus ist „Vertrauen“ auch relativ. Dienst A kann Dienst C vertrauen, aber Dienst B hat mit Dienst C möglicherweise andere Erfahrungen gemacht.
Edge-Infrastrukturmanager
Da eine verteilte Cloud die Grundlage der Edge 2.0-Infrastruktur bildet, ist es zwingend erforderlich, dass die Ressourcen im Rahmen eines EAP leicht zu entdecken, zu sichern und zu instrumentieren sind. Das Folgende kann als eine Reihe von Empfehlungen gelesen werden, die an die Fähigkeiten des Edge-Infrastrukturmanagers gestellt werden.
Innerhalb eines EAP können Ressourcen nach Bedarf eingeplant werden. Aufgrund der Mobilität können neue Ressourcen dynamisch hinzukommen oder abreisen. Ein EAP kann auch Anfragen an andere EAPs senden oder von ihnen empfangen, um in seinem Namen nach Bedarf Ressourcen zu ermitteln und zu planen.
Um die Sicherheitslage noch einmal zu wiederholen: Die Infrastruktur, auf der die Anwendung bereitgestellt wird, ist bereits kompromittiert. Der EAP muss daher die Sicherheit der in seinem Rahmen eingesetzten Anwendung gewährleisten.
Unabhängig von der Verwaltungsebene muss das EAP-Framework mehrere Aspekte der Sicherheit berücksichtigen, beispielsweise (jedoch nicht beschränkt auf):
Externe Bedrohungen: Zum Beispiel Distributed-Denial-of-Service-Angriffe (DDoS) und Advanced Persistent Threats (APT). Diese können durch den Einsatz bestehender bewährter Sicherheitsmethoden wie DDoS-Prävention, Firewalls usw. gemildert werden. Es wird empfohlen, dass es für den gesamten Datenverkehr erforderlich ist.
Man-in-the-Middle: Der gesamte Datenverkehr muss verschlüsselt werden und es kann nicht davon ausgegangen werden, dass die Anwendungsschicht das Richtige tut. Dadurch wird die grundlegende Vertraulichkeit der Daten gegenüber Geräten gewährleistet, die den Datenverkehr abhören, und die Integrität der Daten wird während der Übertragung vor Manipulation geschützt.
Interne Bedrohungen: Der Umfang der Infrastrukturschicht muss eingeschränkt werden und in erster Linie auf den Selbstschutz ausgerichtet sein. Die Empfehlung besteht darin, zu verhindern, dass eine Ressource innerhalb der Infrastruktur einen internen Angriff auf den Infrastrukturmanager startet.
Wenn es bei Edge 2.0 um das Erlebnis geht, das es liefert, und nicht um das Asset oder seinen Standort, folgt daraus natürlich, dass auch die Telemetrie erlebnisorientiert sein muss.
Die Frage ist, auf wessen Erfahrung beziehen wir uns? Es handelt sich um die Erfahrung aller Entitäten, die sich in einer Infrastruktur befinden oder diese verwenden, um einen Dienst zu erstellen oder zu nutzen: Apps, Geräte, Menschen, Back-End-Anwendungen, Datenbanken und mehr. Der Erfahrungsstandpunkt ist somit der des Wesens. Ein von einer Entität erstellter oder genutzter Dienst steht in direktem Zusammenhang mit den ihr zugewiesenen Rechen-, Speicher- und Netzwerkressourcen.
Doch es reicht nicht, die Erfahrungen zu messen; es müssen auch Mittel und Wege zu ihrer Beseitigung gefunden werden.
Jede Entität, die einen Dienst nutzt oder bereitstellt, kann feststellen, ob sie die gewünschte Erfahrung macht. In verteilten Cloud-Umgebungen kann es jedoch nahezu unmöglich sein, zu erklären, was in der Infrastrukturebene passiert ist und zu der schlechten Erfahrung geführt hat.
Um zu ermitteln, warum eine Anwendung nicht die gewünschte3 Leistung erbringt, reichen umfassendere Kennzahlen wie CPU-Auslastung, Arbeitsspeicher, Bandbreite und Latenzmessungen nicht aus. Metriken müssen zeitgranular sein und tief im Anwendungsstapel und, wann immer verfügbar, aus verschiedenen Schichten des Infrastrukturstapels gesammelt werden.
Eine robuste, skalierbare und erweiterbare Telemetrie- und Datenstrategie ist für das EAP von zentraler Bedeutung. Strategien des maschinellen Lernens (ML) und der künstlichen Intelligenz (KI) können dann genutzt werden, um die beste Entscheidung hinsichtlich der Reservierung neuer Ressourcen oder der Optimierung der Nutzung vorhandener Ressourcen zu treffen.
Konnektivität softwaredefinierter Anwendungen
Während die Probleme der Konnektivität und Erreichbarkeit als gelöst gelten, haben viele Netzwerkteams immer noch Probleme damit, ihre Netzwerkstruktur an die dynamischen Anforderungen der Anwendungsschicht anzupassen. Eine Plattform muss auch diese Herausforderungen bewältigen.
Das Problem bei bestehenden Ansätzen besteht darin, dass wir die Anforderungen an die Anwendungskonnektivität in WAN-Konnektivität für Unternehmen übersetzen, insbesondere in einer verteilten Cloud. Ansätze zur Adressierung eines verteilten Cloud-Netzwerks könnten verschiedene SDN-Strategien oder rein routingbasierte Methoden verwenden. Diese Lösungen sind jedoch in hohem Maße auf die Homogenität der Infrastruktur angewiesen und können daher kein konsistentes Verhalten liefern.
Die einzige Möglichkeit, ein global skalierbares, sicheres und stabiles Netzwerk für die Anwendung zu erreichen, besteht darin, die Anwendungskonnektivitätsebene vom zugrunde liegenden Netzwerk zu trennen, wie im Folgenden erläutert.
Bei der Entwicklung hin zu einer verteilten Cloud-Architektur besteht das neue SDN-Muster darin, sowohl die Underlay- als auch die Overlay-Netzwerke gemeinsam zu orchestrieren und eine durchgängige Programmierbarkeit des Anwendungspfads zu ermöglichen.
Mit Edge 2.0 müssen wir diesen Anschein von Stabilität auch bei der Verbindung von Unternehmensnetzwerken erreichen. Wir schlagen vor, dass die Anwendungskonnektivitätsebene von der Unternehmensnetzwerkkonnektivität getrennt werden muss. Das Anwendungskonnektivitätsmuster folgt möglicherweise derselben SDN-Konnektivität wie bei Rechenzentrums-Overlays (z. B. VXLAN, NVGRE oder andere) oder BGP-basierten SDN-Mustern, muss dies jedoch nicht.
Nicht alle Netzwerke wurden in Overlay und Underlay getrennt. Netzwerkteams sehen diese gemeinsame Programmierbarkeit mittlerweile als wichtige Voraussetzung für eine durchgängige Automatisierung an, für die die Trennung des Underlay- und des Overlay-Netzwerks von entscheidender Bedeutung ist.
Durch die Trennung der Anwendungsebene vom zugrunde liegenden Netzwerk und Transport entfällt für die Netzwerkteams die Notwendigkeit, aktiv auf jede Anwendungsanforderung zu reagieren. Der Umfang beschränkt sich auf die Bereitstellung robuster, stabiler und klar definierter Pfade mit dem Schwerpunkt auf der Optimierung der Nutzung der Gesamtbandbreite bei geringsten Latenzen.
Adaptives Schnittstellenmodell
Der zentrale Grundsatz eines EAP besteht darin, dass es unabhängig und autonom ist und eine Teilmenge des gesamten Lösungsraums verwaltet. EAPs benötigen jedoch eine Möglichkeit, zu kommunizieren und ihre Ressourcen anzubieten oder Ressourcen von anderen EAPs anzufordern. Dieser Ansatz bietet mehrere Vorteile.
Eine auf Ergebnissen basierende Schnittstelle macht es für das EAP überflüssig, die Details der anderen Infrastruktur zu kennen. Angenommen, es gibt zwei EAPs: A und B. Jeder EAP verfügt über einen lokalen Bereich seiner Infrastruktur, um Ressourcen zu planen und zu reservieren. EAP-A muss die von EAP-B bereitgestellten Ressourcen nicht kennen. Wenn beispielsweise EAP-A die Anforderungen der Anwendung nicht erfüllen kann und Ressourcen in der Infrastruktur benötigt, die im Rahmen von EAP-B liegen, kann es EAP-B einfach sein gewünschtes Ziel mitteilen. Es liegt dann in der Verantwortung von EAP-B, deklarative oder imperative Schnittstellen aufzurufen, um aus seinem Pool freier Ressourcen zu reservieren, zuzuweisen und zu konfigurieren. EAP-B ist außerdem dafür verantwortlich, sicherzustellen, dass die SLOs für diesen Dienst innerhalb seiner Infrastruktur eingehalten werden.
Eine gemeinsame Syntax ist zwar hilfreich, um einen ersten Satz adaptiver APIs zu starten, doch mit der Zeit wird die Implementierung durch die Verwendung natürlicher Sprachverarbeitung und künstlicher Intelligenz zur Reduzierung der erforderlichen Eingabequalität komplexer und ausgereifter.
Auch verschiedene Betriebsmuster werden einfach, wobei nur der gewünschte Zustand angegeben werden muss. Resilienzmuster können beispielsweise lediglich auf einem erwarteten SLO basieren. Es liegt in der Verantwortung des EAP, das den Dienst bereitstellt, sicherzustellen, dass die Ressourcen innerhalb seines Geltungsbereichs so zugewiesen werden, dass die Service-Level-Ziele erreicht werden. Der anrufende EAP muss sich nicht darum kümmern, müsste aber wahrscheinlich die Servicemetriken überwachen, um zu wissen, ob sie erfüllt werden oder nicht.
EAP-Funktionen
- Mehrere Mandanten: Während das in Abbildung 9 dargestellte EAP-Netz für eine einzelne Bereitstellung gedacht ist, sind mehrere EAPs pro Cloud möglich. Eine andere Anwendung könnte mit einem anderen EAP oder einem Netz von EAPs kommunizieren.
- Auf Skalierung ausgelegt: Jedes Mesh ist ein Peer-to-Peer-Mesh (P2P) und kann horizontal skaliert werden. Peer-EAPs können unabhängig voneinander verfolgen, welche EAPs über welchen Ressourcentyp verfügen und wie die Verbindung mit der Ressource hergestellt wird. KI/ML wird die Art und Weise weiter verbessern, wie jedes EAP Ressourcen in seinem eigenen Umfang plant oder bei Bedarf auf andere EAPs zugreift.
- Integriertes Netzwerk: Damit Anwendungen eine Verbindung über die verteilte Cloud herstellen können, muss das EAP integrierte Netzwerkfunktionen unterstützen, die unabhängig von der zugrunde liegenden Infrastruktur sind.
Zusammenfügen
Abbildung 12 visualisiert die Rolle der verschiedenen Ebenen beim Bereitstellen einer Anwendung in einer verteilten Cloud.
Die Highlights dieser Darstellung sind:
- Jedes EAP verfügt über einen lokalisierten Umfang und nicht alle seiner Funktionen sind in Abbildung 10 angegeben. Das EAP muss die Ressourcenerkennungs- und Planungsfunktion unterstützen. EAPs planen Ressourcen, indem sie über adaptive APIs mit dem entsprechenden Infrastruktur-Controller interagieren.
- Anwendungskonnektivität ist nicht dasselbe wie Netzwerkkonnektivität – wie beim Service-Mesh-Sidecar-Modell müssen die Ressourcen zum Verbinden von Anwendungen über mehrere Clouds hinweg Teil der Anwendungsinfrastruktur sein. Man könnte argumentieren, dass die Infrastrukturebene auch die Netzwerkkonnektivität der Anwendung bereitstellt und sich daher unterhalb der Netzwerkebene befinden sollte. Technisch wäre das auch richtig, wir haben uns jedoch dazu entschieden, es in die Ebene der „Anwendungskonnektivität“ einzuordnen, da es sich hierbei in erster Linie um Netzwerkfunktionen handelt.
- Die Infrastrukturebene muss von der Anwendungsebene getrennt betrachtet werden.
- Die Netzwerkkonnektivität unterscheidet sich vom Transport, da es sich im Wesentlichen um bestimmte routingfähige Netzwerke handelt, die von der Anwendungskonnektivität getrennt sind.
- Man kann sich die Transportebene als aggregierte Backbone-Netzwerke vorstellen, die bereitgestellt werden können, sofern der Telekommunikationsanbieter Prozesse und APIs aktiviert, um die darüber liegende Netzwerkschicht zu verbinden.
Zusammenfassung
In diesem Whitepaper wird versucht, noch einige weitere Ebenen des ursprünglichen Edge 2.0-Manifests zu untersuchen. Wir haben einige neue Themen eingeführt, mit dem Ziel, verschiedene Interessengruppen innerhalb interner Organisationen und außerhalb der Branche zu informieren.
Edge 2.0 basiert auf dem Konzept einer verteilten Cloud, an der jede Entität sowohl als Quelle als auch als Ziel von Diensten teilnehmen kann. Das Hauptthema ist, dass es bei Edge 2.0 um das Erlebnis und nicht um den Vermögenswert oder den Standort geht.
Die Edge Application Platform (EAP) wird als Funktionsstapel eingeführt, um die Realisierung von Edge 2.0 über eine verteilte Cloud zu ermöglichen.
Auf Implementierungsdetails wurde bewusst verzichtet, um eine anbieterunabhängige Ansicht zu präsentieren.
Ressourcen
2 https://www.f5.com/pdf/reports/f5-office-of-the-cto-report-continuous-api-sprawl.pdf
3 Wikipedia – Ein autonomes System (AS) ist eine Sammlung verbundener Internet Protocol (IP)-Routing-Präfixe unter der Kontrolle eines oder mehrerer Netzwerkbetreiber im Auftrag einer einzelnen Verwaltungseinheit oder Domäne, die eine gemeinsame, klar definierte Routing-Richtlinie für das Internet präsentiert.