DE102022126668A1

DE102022126668A1 - Agenten für die verwaltung der infrastruktur, der die parameter für die cloud-basierten rechendienste verwaltet

Info

Publication number: DE102022126668A1
Application number: DE102022126668.0A
Authority: DE
Inventors: Dejan S. Milojicic; Kenneth Leach; Max Alt
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2022-03-07
Filing date: 2022-10-13
Publication date: 2023-09-07
Also published as: US20230281682A1; CN116781438A

Abstract

Beispiele für die Bereitstellung von Cloud-basierten Rechendiensten für eine anfragende Einheit mit einem Infrastrukturverwaltungsagenten. Für die von der anfragenden Einheit in Anspruch genommenen Rechendienste wird eine Umsatzabrechnung für einen ersten Zeitraum durchgeführt. Wenn sich die Einnahmen während des ersten Zeitraums über einen vorgewählten Schwellenwert hinaus verändert haben, passt der Infrastrukturverwaltungsagent die Parameter für die Dienstqualität (QoS) an oder ändert die Abrechnungsrabatte für die Cloud-basierten Rechendienste.

Description

HINTERGRUND
Cloud Computing kann einen On-Demand-Zugang zu Computerressourcen, wie z. B. Rechen- und Speicherressourcen, beinhalten. Die Verbraucher können für Cloud Computing nach verschiedenen Modellen bezahlen. In einem Beispiel können die Zuteilung von Cloud-Computing-Ressourcen und die damit verbundene Abrechnung auf einem Bereich fester Größen von Instanzen virtueller Maschinen (VM) basieren.
KURZBESCHREIBUNG DER ZEICHNUNGEN

1 ist ein konzeptionelles Diagramm einer Infrastruktur, die Dienste zur Unterstützung eines beispielhaften Abrechnungsmechanismus bereitstellt.
2 zeigt eine beispielhafte Kette von Diensten, die von einem Endnutzer genutzt werden und bei denen Informationen über die Leistung des Dienstes erfasst und im Rahmen von Dienstsignaturen weitergegeben werden.
3 zeigt ein Beispiel für die Anpassung der Dienstgüte (QoS) auf der Grundlage von Umsatz- und Rechnungsschwankungen.
4 zeigt ein Beispiel für eine Infrastruktur, die sowohl rabattorientierte als auch QoS-fokussierte Dienstleistungsketten mit mehreren Endnutzern unterstützt.
5 zeigt ein Beispiel für eine Infrastruktur, die dynamisch installierbare Abrechnungsmodule auf der Grundlage von Kunden- und/oder Anbieterpräferenzen unterstützt.
6 ist ein Flussdiagramm einer Beispieltechnik für die Bereitstellung von Diensten, die einen Abrechnungsmechanismus zur Unterstützung des Cloud-basierten Dienstmanagements unterstützen.
7 ist ein Blockdiagramm eines Beispiels eines Verarbeitungssystems zur Bereitstellung von Cloud-basierten Diensten.

DETAILLIERTE BESCHREIBUNG
Anbieter von Cloud-Infrastrukturen können Infrastrukturzugang und/oder - unterstützung in Form von Instanzen virtueller Maschinen (VM), physischen Instanzen oder anderen Infrastruktureinheiten fester Größe anbieten. Ein Nutzer kann über ein Internet-Netzwerk auf die Cloud-basierte Infrastruktur zugreifen. Die Preise für den Zugang/Support richten sich nach der Anzahl und Größe der genutzten Instanzen. Jedes dieser Elemente kann im Laufe der Zeit schwanken, aber in der Regel handelt es sich bei den Änderungen um Modifikationen an den Größen der Instanzen fester Größe und der entsprechenden Preisstruktur.
Mit der zunehmenden Verbreitung von z. B. privaten Clouds, der Einführung neuer oder anderer as a Service (aaS)-Angebote (z. B. High Performance Compute aaS oder HPCaaS) und dem Aufkommen von künstlicher Intelligenz (KI) und heterogenen Beschleunigern ist dieses Modell mit fester Größe jedoch möglicherweise nicht mehr ausreichend. Aufgrund der Granularität der zugewiesenen Ressourcen (z. B. feinkörnige, groß angelegte Zuweisungen, einschließlich heterogener, nach Bedarf zusammengestellter Ressourcen) ist der Spielraum für Fehler bei der Verwaltung der Cloud-Infrastruktur und der Preisgestaltung geringer, und die Auswirkungen einer ineffizienten Zuweisung und/oder Abrechnung können größer sein. Ausgereiftere Cloud-Management-Systeme wären daher von Vorteil.
In den folgenden Beispielen werden ein anpassbares Management und eine entsprechende Preisstruktur beschrieben, die eine flexible Infrastrukturumgebung mit entsprechenden umsatzproportionalen Abrechnungsmechanismen bieten. In einem Beispiel können die Preismechanismen zu einem rabattierten Preis führen, der umgekehrt proportional zur Geschwindigkeit ist, mit der Infrastrukturanbieter Einnahmen von Unternehmen erzielen, die die Infrastruktur nutzen. Automatisierte Infrastrukturmechanismen können eine dynamisch modifizierbare Infrastrukturumgebung (z. B. variable Instanzgröße, variable Instanztypen, variable Anzahl von Instanzen, flexible Instanztopologie) mit entsprechender kontinuierlicher umsatzproportionaler Abrechnung bieten. In alternativen oder zusätzlichen Konfigurationen kann auch ein anderer Abrechnungsansatz (z. B. eine alternative nichtlineare Struktur, eine stufenweise Struktur) unterstützt werden.
Die hier beschriebenen Beispiele beziehen sich auf Beispielinfrastrukturen und - konfigurationen. Die beschriebenen Beispiele können jedoch allgemein auf verschiedene Lieferketten von Anbietern von Rechenzyklen und Verbrauchern/Nutzern anwendbar sein. Ein weiteres Beispiel ist, dass Rabatte, die ein Anbieter (oder ein Endnutzer) von einem anderen Anbieter anbietet und/oder erwirbt, gemeinsam verwaltet werden können.
In einigen unten beschriebenen Beispielen kann die vergangene Leistung eines Dienstes (z. B. generierter Umsatz, Effizienz, erhaltene Rabatte, weitergegebene Rabatte) in den bereitgestellten Dienstsignaturen kodiert werden, um das Infrastrukturmanagement und entsprechende Abrechnungsmechanismen zu vereinfachen. Diese kodierten Informationen können in regelmäßigen Abständen angepasst und/oder aggregiert und zur Steuerung von Richtlinien durch Infrastruktur- oder Service-Management-Mechanismen verwendet werden. Die kodierten Informationen können auch verwendet werden, um statistische Informationen für (oder über) entsprechende Nutzer/Kunden bereitzustellen.
In einigen Beispielen können konstante Abrechnungs-/Preisinformationen zusammen mit offengelegten Dienstgütekontrollen (QoS) Infrastrukturbenutzern oder -anbietern die Möglichkeit bieten, QoS-Parameteranpassungen gegen Preisanpassungen/Überlegungen einzutauschen, was eine größere Kontrolle über die Infrastrukturerfahrung ermöglicht. QoS bezieht sich im Allgemeinen auf das Niveau der angebotenen Leistung, Zuverlässigkeit, Sicherheit und/oder Verfügbarkeit. QoS-Parameter sind also Steuerelemente und/oder Anpassungen verschiedener Merkmale, die zu Änderungen der Leistung, Zuverlässigkeit, des Sicherheitsniveaus und/oder der Verfügbarkeit führen, die dem Nutzer geboten werden. Wie im Folgenden näher beschrieben, kann ein Nutzer beispielsweise durch die Anpassung von QoS-Parametern die Abrechnung trotz Umsatzschwankungen konstant halten. Alternativ kann der Nutzer die Abrechnung innerhalb eines akzeptablen Bereichs halten, indem er in Zeiten von Umsatzschwankungen kleinere Anpassungen an den QoS-Parametern vornimmt.
In einigen Beispielen können verschiedene dynamisch installierbare Module (z. B. Plugins) je nach Benutzerpräferenz verwendet werden, um das gewünschte Infrastrukturerlebnis zu unterstützen. In einem Beispiel kann ein benutzerdefiniertes, dynamisch installierbares Abrechnungs-Plugin verwendet werden, um einige der hier beschriebenen Funktionen zu verwalten. So kann ein Anbieter beispielsweise Rabatte entweder zulassen oder verbieten. Wenn sie erlaubt sind, können die Rabatte z. B. proportional zur Rate der Umsatzgenerierung sein, oder der Rabatt kann ein beschleunigtes Wachstum haben (z. B. linear oder innerhalb von Klammern). In einigen Beispielen kann der Benutzer das Plugin nutzen, um z. B. künftige Umsätze gegen aktuelle Preisnachlässe und/oder QoS einzutauschen.
ist ein konzeptionelles Diagramm einer Infrastruktur, die Dienste zur Unterstützung eines beispielhaften Abrechnungsmechanismus bereitstellt. Das Beispiel in 1 zeigt einen einzelnen Dienst, einen einzelnen Dienstanbieter und einen einzelnen Endbenutzer; es kann jedoch eine beliebige Anzahl von Diensten, Dienstanbietern und Endbenutzern unterstützt werden.
Im Beispiel von 1 stellt der Infrastrukturanbieter 102 eine oder mehrere Einheiten dar, die die Infrastrukturumgebung 104 bereitstellen, z. B. Einheiten, die Hardware-Prozessoren, Speicher, Grafikverarbeitungseinheiten und Speichergeräte bereitstellen, um einen oder mehrere von der Infrastrukturumgebung 104 bereitgestellte Dienste zu unterstützen. Unter Nutzung der Funktionalität der Infrastrukturumgebung 104 können ein oder mehrere Dienstanbieter (z. B. Dienstanbieter 106) Cloud-Dienste bereitstellen, z. B. Cloud-Anwendungen (z. B. SaaS) oder Anwendungspakete. Der Endbenutzer 108 stellt einen oder mehrere Benutzer dar, die die von der Infrastrukturumgebung 104 verfügbaren Dienste über ein entferntes Gerät (d. h. über eine Netzwerkverbindung zur Infrastrukturumgebung 104) nutzen. Wie unten ausführlicher beschrieben, kann jede Einheit (z. B. Endnutzer 108, Dienstanbieter 106, Infrastrukturanbieter 102) Informationen erhalten und/oder Präferenzen oder Parameter bereitstellen, um die Funktionalität der Dienste und die entsprechende Abrechnung der Dienste zu verwalten.
Im Beispiel von 1 kann die Infrastrukturumgebung 104 Dienste (z. B. Dienst 110) für eine beliebige Anzahl von Endnutzern (z. B. Endnutzer 108) bereitstellen. Der Dienst 110 kann jede Art von Cloud-basiertem Dienst sein (z. B. Cloud-Speicher, Rechenressourcen), der durch Hardware, Software oder eine Kombination davon bereitgestellt werden kann. Bei der Infrastrukturumgebung 104 kann es sich zum Beispiel um eine öffentliche Cloud-Umgebung handeln, die auf Servern betrieben wird, die vom Infrastrukturanbieter 102 verwaltet und gewartet werden. Die Infrastrukturumgebung 104 kann z. B. Software als Dienst (SaaS), Plattform als Dienst (PaaS), Infrastruktur als Dienst (IaaS) usw. bereitstellen. Die Infrastrukturumgebung 104 umfasst Plattformen, Hardware, Software und Kombinationen davon, um einen oder mehrere Dienste (z. B. den Dienst 110) und unterstützende Verwaltungsfunktionen (z. B. Infrastrukturverwaltungsagent 112, 114, Dienstverwaltungsagent 116) bereitzustellen.
SaaS bezieht sich im Allgemeinen auf eine Architektur und ein Modell, bei dem die Lizenzierung und die Softwarefunktionalität auf der Grundlage einer Abonnementvereinbarung bereitgestellt werden, wobei die Komponenten, die die Dienste bereitstellen, gehostet werden, um eine „On-Demand“-Softwarevereinbarung anzubieten. In ähnlicher Weise bezieht sich PaaS im Allgemeinen auf eine Cloud-basierte Umgebung, in der ein Kunde (z. B. ein Endnutzer, eine Organisation) eine Plattform mit einer oder mehreren Anwendungen bereitstellen, einrichten und verwalten kann, ohne die unterstützende Infrastruktur aufbauen und warten zu müssen. IaaS bezieht sich im Allgemeinen auf eine Cloud-Orchestrierung, bei der virtuelle Maschinen (VMs) und entsprechende Unterstützungskomponenten (z. B. Speicher, Firewalls) von einem Kunden konfiguriert und nach Bedarf genutzt werden können. Wenn die Infrastrukturumgebung 104 mehrere Dienste bereitstellt, kann jeder Dienst über einen zugehörigen Dienstabrechnungsagenten verfügen (dessen Funktionalität weiter unten ausführlicher beschrieben wird).
In den folgenden Beispielen können ein oder mehrere Nutzer (z. B. der Endnutzer 108) auf einen oder mehrere Cloud-basierte Rechendienste (z. B. den Dienst 110) zugreifen, die von einer Infrastrukturumgebung (z. B. der Infrastrukturumgebung 104) bereitgestellt werden. Bei den von der Infrastrukturumgebung bereitgestellten Diensten kann es sich um alle Arten von On-Demand-Diensten handeln. So kann die Infrastrukturumgebung eine SaaS-Umgebung, eine PaaS-Umgebung oder eine laaS-Umgebung sein, und die bereitgestellten Dienste können Softwareanwendungsdienste, Plattformdienste bzw. Infrastrukturdienste sein.
Der Infrastrukturanbieter 102 kann Anbieterparameter 118 an den Infrastrukturverwaltungsagenten 112 senden. In einem Beispiel können die Anbieterparameter 118 beinhalten, ob ein Rabatt angeboten wird (z. B. ja oder nein), einen Rabattwert (z. B. als Prozentsatz), einen Rabatttyp (z. B. nichtlinear, linear, beschleunigend), QoS-Anpassungen usw. Der Infrastrukturverwaltungsagent 112 kann die Anbieterparameter 118 und die Auslastung der Infrastrukturumgebung 104 nutzen, um eine Übersicht über die Dienstabrechnung 120 für den Dienstanbieter 106 zu erstellen. Die Dienstabrechnungsübersicht 120 kann z. B. Informationen zur Abrechnungsstruktur, zur Ressourcennutzung, zu Abrechnungsrabatten usw. enthalten. Der Infrastrukturmanagement-Agent 112 kann als Hardware oder als eine Kombination aus Hardware und Software bereitgestellt werden.
Als ein Beispiel können die folgenden Gleichungen verwendet werden, um eine umsatzproportionale Abrechnung (RpB) für die Nutzung der Infrastruktur zu unterstützen. In diesem Beispiel kann ein dem Endnutzer 108 angebotener Abrechnungsrabatt auf dem Gewinn und der Änderungsrate der Einnahmen des Endnutzers 108 für die Nutzung der Infrastruktur basieren. Ein Beispiel: $P r i c e_{i n f r a} = γ_{p r o f i t_{i n f r a}} \times ƒ (S e r v i c e_{r e s o u r c e_u s a g e}, R e v e n u e_{i n f r a_{a g g r e g a t e}}, Q o S_{s e r v i c e})$
So kann in einem Beispiel der mit einer Infrastruktur verbundene Preis eine Funktion der Nutzung von Dienstressourcen, der Gesamteinnahmen aus der Infrastruktur und der mit einem Dienst verbundenen Dienstgüte sein, skaliert mit einem Infrastrukturgewinnfaktor. In einem Beispiel können die Gesamteinnahmen aus der Infrastruktur über einen bestimmten Zeitraum hinweg wie folgt beschrieben werden: $R e v e n u e_{i n f r a_{a g g r e g a t e}} = \sum_{t = 0}^{t = N} R e v e n u e_{i n f r a_{t i m e = t}}$
wo: $R e v e n u e_{i n f r a_{t i m e = t}} = P r i c e_{i n f r a_{t i m e = t}} \times R e s o u r c e U s a g e_{t i m e = t} \times Q o S$
In einem Beispiel können die Gesamtkosten über einen bestimmten Zeitraum hinweg wie folgt beschrieben werden: $C o s t_{i n f r a_{a g g r e g a t e}} = \sum_{t = 0}^{t = N} C o s t_{i n f r a_{t i m e = t}}$
wo: $C o s t_{i n f r a_{t i m e = t}} = R e s o u r c e U s a g e_{t i m e = t} \times R e s o u r c e T y p e$
In einem Beispiel kann der Gewinn wie folgt beschrieben werden: $γ_{p r o f i t_{i n f r a}} \sim R e v e n u e_{i n f r a_{a g g r e g a t e}} - C o s t_{i n f r a_{a g g r e g a t e}}$
In einem Beispiel kann ein Infrastrukturrabatt wie folgt beschrieben werden: $D i s c o u n t_{i n f r a} \sim γ_{p r o f i t_{i n f r a}} \times \frac{d (R e v e n u e_{i n f r a_{a g g r e g a t e}})}{d t}$
wobei die Einnahmen auf der Ressourcennutzung, einem Preis für die Ressourcennutzung und QoS-Parametern oder einer Kombination davon basieren und der Infrastrukturgewinn (γinfra) auf den aggregierten Infrastruktureinnahmen und den aggregierten Infrastrukturkosten beruht. In einem Beispiel kann die Information über den Preisnachlass auf Infrastrukturebene auf der Grundlage der Einnahmen, der Nutzung und/oder anderer Faktoren für einen ersten Zeitraum bestimmt werden, und anschließend kann derselbe oder ein ähnlicher Prozess verwendet werden, um einen Preisnachlass für einen zweiten Zeitraum zu bestimmen. In einem Beispiel kann der Rabatt angewendet (oder angeboten) werden, nachdem der Umsatz einen Schwellenwert während des ersten Zeitraums überschritten hat und/oder nachdem die Umsatzrate einen Schwellenwert während des ersten Zeitraums überschritten hat. In einem Beispiel kann der rabattierte Preis umgekehrt proportional zu der Umsatzwachstumsrate des ersten Zeitraums sein. Die obigen Gleichungen stellen ein Beispiel für eine Technik zur Generierung eines anzubietenden Rabatts dar, es können jedoch auch andere Rabattstrukturen unterstützt werden.
In dieser Beispielgleichung für die Preisgestaltung der Infrastruktur kann der Gewinn regelmäßig offline berechnet werden (z. B. durch den Infrastrukturverwaltungsagenten 112 und/oder den Dienstverwaltungsagenten 116) und als Multiplikator auf Rabatte angewendet werden. In der Architektur von 1 kann eine beliebige Anzahl anderer Preisgleichungen für die Infrastruktur verwendet werden. In den folgenden Beispielen können die dem Endbenutzer 108 angebotenen Rabatte auf der obigen Gleichung (oder einer Alternative) basieren und auf der Grundlage der Benutzerpräferenzen 122 und anderer Faktoren angepasst werden, um eine verbesserte
Der Dienstanbieter 106 kann die Übersicht 124 über die Infrastrukturabrechnung vom Infrastrukturverwaltungsagenten 112 nutzen, um die Nutzung der Infrastrukturumgebung 104 bei der Bereitstellung des Dienstes 110 anzupassen, falls gewünscht. Die InfrastrukturAbrechnungsübersicht 124 kann Abrechnungsinformationen enthalten, z. B. die Preise für die aktuelle Nutzung, angewandte Rabatte, verfügbare Rabatte usw. Der Dienstanbieter 106 kann beispielsweise die QoS-Parameter und die angebotenen Rabatte auf der Grundlage der Infrastrukturabrechnungsübersicht 124 des Infrastrukturverwaltungsagenten 112 verwalten. Beispielsweise kann der Dienstanbieter 106 auf der Grundlage von Informationen in der Infrastrukturabrechnungsübersicht 124 feststellen, dass eine angebotene Rabattstruktur nicht wettbewerbsfähig ist, und entsprechende Anpassungen für zukünftige Abrechnungszyklen vornehmen. In einigen Beispielen können Anpassungen des Dienstes 110 (z. B. QoS-Parameter) durch die Verwendung des Infrastruktur-Abrechnungs-Plugins 126 automatisiert werden.
Der Dienst 110 kann Ressourcen der Infrastrukturumgebung 104 umfassen und sowohl dem Endnutzer 108 als auch einer beliebigen Anzahl anderer Endnutzer zur Verfügung gestellt werden. In einem Beispiel stellt der Endnutzer 108 dem Dienst 110 oder dem Dienstverwaltungsagenten 116 eine oder mehrere Benutzereinstellungen 122 zur Verfügung, die für die Verwaltung der Nutzung von Diensten und der entsprechenden Abrechnung verwendet werden können. In einem Beispiel können die Benutzerpräferenzen 122 zum Beispiel Abrechnungspräferenzen enthalten. Der Dienstverwaltungsagent 116 kann als Hardware oder als eine Kombination aus Hardware und Software bereitgestellt werden. In einigen Beispielen kann der Dienstverwaltungsagent 116 RpB auf der Grundlage der folgenden Gleichungen unterstützen, wobei der Preis eines bestimmten Dienstes 110 wie folgt beschrieben werden kann: $P r i c e_{s e r v i c e_{N - 1}} = γ_{p r o f i t_{s e r v i c e_{N - 1}}} \times ƒ (S e r v i c e_{N_{u s a g e}}, R e v e n u e_{s e r v i c e_{N - 1_{a g g r e g a t e}}}, Q o S_{s e r v i c e_{N}})$
So kann in einem Beispiel der Preis für einen einzelnen Dienst eine Funktion der Ressourcennutzung, der Gesamteinnahmen des Dienstes und der mit dem Dienst verbundenen Dienstgüte (QoS) sein, skaliert mit einem Dienstgewinnfaktor.
In einem Beispiel können die Gesamteinnahmen aus Dienstleistungen wie folgt beschrieben werden: $R e v e n u e_{s e r v i c e N - 1_{a g g r e g a t e}} = \sum_{t = 0}^{t = N} R e v e n u e_{s e r v i c e N - 1_{t i m e = t}}$
wo: $R e v e n u e_{s e r v i c e N - 1_{t i m e = t}} = P r i c e_{s e r v i c e N_{t i m e = t}} \times S e r v i c e_{N - 1 u s a g e_{t i m e = t}}$
In einem Beispiel können die Gesamtkosten der Dienstleistung über einen bestimmten Zeitraum hinweg durch folgende Faktoren bestimmt werden: $C o s t_{s e r v i c e N - 1_{a g g r e g a t e}} = \sum_{t = 0}^{t = N} C o s t_{s e r v i c e N - 1_{t i m e = t}}$
wo: $C o s t_{s e r v i c e N - 1_{t i m e = t}} = S e r v i c e_{N - 1 u s a g e_{t i m e = t}} \times S e r v i c e_{Q o S}$
Ferner kann der Gewinn der Dienstleistung ungefähr als die Einnahmen minus die Kosten beschrieben werden: $γ_{s e r v i c e N - 1} \sim R e v e n u e_{s e r v i c e N - 1_{a g g r e g a t e}} - C o s t_{s e r v i c e N - 1_{a g g r e g a t e}}$
In einem Beispiel kann ein Service Level Discount wie folgt beschrieben werden: $D i s c o u n t_{s e r v i c e N - 1} \sim γ_{p r o f i t_{s e r v i c e N - 1}} \times \frac{d (R e v e n u e_{s e r v i c e N - 1_{a g g r e g a t e}})}{d t}$
So kann der Abschlag für das Dienstleistungsniveau auf der Änderungsrate der Dienstleistungseinnahmen im Laufe der Zeit basieren.
In der Architektur von 1 kann eine beliebige Anzahl von anderen Gleichungen für die Preisgestaltung von Diensten verwendet werden. In anderen Beispielen können die Benutzerpräferenzen 122 zusätzliche und/oder andere Präferenzen enthalten, z. B. Präferenzen für die Abrechnung von Termingeschäften, Präferenzen für die Änderung von QoS usw. In einem Beispiel kann die Information über den Service-Level-Rabatt auf der Grundlage der Einnahmen, der Nutzung und/oder anderer Faktoren für einen ersten Zeitraum bestimmt werden, und anschließend kann derselbe oder ein ähnlicher Prozess verwendet werden, um einen Rabatt für einen zweiten Zeitraum zu bestimmen. In einem Beispiel kann der Rabatt angewendet (oder angeboten) werden, nachdem der Umsatz einen Schwellenwert während des ersten Zeitraums überschritten hat und/oder nachdem die Umsatzrate einen Schwellenwert während des ersten Zeitraums überschritten hat. In einem Beispiel kann der Rabatt umgekehrt proportional zu der Umsatzwachstumsrate des ersten Zeitraums sein.
Der Endnutzer 108 kann die Informationen aus der Übersicht 120 zur Dienstabrechnung, die er vom Dienstverwaltungsagenten 116 erhalten hat, nutzen, um den Dienst 110 anzupassen, falls gewünscht. Der Endbenutzer 108 kann auch QoS-Parameter und Rabatte verwalten, die auf der Grundlage der Dienstabrechnungsübersicht 120 des Dienstverwaltungsagenten 116 angeboten werden. In einigen Beispielen können die Anpassungen der Nutzung des Dienstes 110 durch die Verwendung des Dienstabrechnungs-Plugins 128 automatisiert werden.
Es können mehrere verschiedene dynamisch installierbare Abrechnungsmodule (z. B. Service Billing Plugin 128, Infrastructure Billing Plugin 126) unterstützt werden. In verschiedenen Beispielen kann die Funktionalität des Abrechnungs-Plugins auf einer oder mehreren Benutzerpräferenzen 122 und Anbieterparametern 118 basieren. In einigen Beispielen kann der Infrastrukturanbieter 102 und/oder der Dienstanbieter 106 Rabatte entweder zulassen oder nicht zulassen. Wenn beispielsweise Rabatte erlaubt sind, kann der rabattierte Preis umgekehrt proportional zur Geschwindigkeit der Umsatzgenerierung sein. In einem Beispiel kann der Rabattbetrag ein beschleunigtes Wachstumsprofil aufweisen (entweder linear oder innerhalb von Klammerbereichen), wobei die Rabatte im Laufe der Zeit und/oder als Reaktion auf eine erhöhte Umsatzgenerierung ansteigen. Darüber hinaus kann der Endnutzer 108 künftige Einnahmen gegen vergünstigte Preise und/oder QoS eintauschen.
Ein Beispiel für das Zulassen von Plugins ist die Unterstützung von vom Benutzer einsteckbaren Richtlinien, die auf Anbieterressourcen (z. B. Policy Engine 114) ausgeführt werden. Die vom Benutzer einsteckbaren Richtlinien implementieren bestimmte Richtlinien auf der Grundlage von Benutzerspezifikationen innerhalb der Policy Engine 114 oder anderer Komponenten in der Infrastrukturumgebung 104. Eine steckbare Richtlinie kann z. B. eine Datei oder eine andere Komponente sein, die eine Beschreibung einer zu unterstützenden Richtlinie enthält. Richtlinien können z. B. Rabattstrukturen enthalten. Ein weiteres Beispiel: Ein Plugin kann eine Softwarekomponente sein, die zusätzliche Funktionen bereitstellt/unterstützt. Ein Plugin kann z. B. eine Softwarekomponente sein, die von der Policy Engine 114 oder einer anderen Komponente der Infrastrukturumgebung 104 ausgeführt wird.
Weitere Einzelheiten zu einer steckbaren Richtlinienkonfiguration sind in dem in 5 beschriebenen Beispiel zu finden. Beispielsweise kann die Policy Engine 114 verschiedene Schwellenwerte auf der Grundlage der vom Kunden bevorzugten Funktionen (z. B. angegeben durch die Benutzerpräferenzen 122) berechnen. Die Policy Engine 114 kann vom Infrastrukturanbieter 102 festgelegte Randbedingungen auferlegen, so dass die Endbenutzerwerte innerhalb der vom Infrastrukturanbieter 102 erlaubten Bereiche gewichtet werden können. Die Funktionalität der Policy Engine 114 kann als Hardware, Software oder eine Kombination davon bereitgestellt werden.
zeigt eine beispielhafte Kette von Diensten, die von einem Endbenutzer genutzt werden, wobei Informationen über die Dienstleistung in Dienstsignaturen erfasst und weitergegeben werden. Bei den Dienstsignaturen kann es sich beispielsweise um Metadaten handeln, die zwischen den Diensten in der Infrastrukturumgebung 202 weitergegeben werden. In einigen Beispielen können die Dienstsignaturen kryptografisch signiert oder anderweitig gesichert sein. In verschiedenen Beispielen können die verschiedenen Dienste eine hierarchische Dienststruktur aufweisen, um dem Endbenutzer 204 eine gewünschte Gruppe von Diensten anzubieten. Der Dienstverwaltungsagent 206 stellt Informationen zur Dienstabrechnung (208) für die vom Endbenutzer 204 in Anspruch genommenen Dienste bereit.
Im Beispiel von 2 kann der Endnutzer 204 eine hierarchische Struktur von Diensten innerhalb der Infrastrukturumgebung 202 konfiguriert haben. Es kann eine beliebige Anzahl von Cloud-basierten Rechendiensten (z. B. service_1 210, service_2 212, service_n-1 214, service_n 216) unterstützt werden. Jeder der Dienste kommuniziert mit dem Dienstverwaltungsagenten 206, um die oben beschriebenen Abrechnungsfunktionen bereitzustellen. In einem Beispiel kann jeder Dienst dem Dienstverwaltungsagenten 206 Leistungs- und/oder Umsatzinformationen beispielsweise innerhalb einer Dienstsignatur (z. B. service_1 signature, service_2 signature, service_n-1 signature, service_n signature) bereitstellen. Der Servicemanagement-Agent 206 kann dann dem Endbenutzer 204 eine Übersicht 208 über die Serviceabrechnung zur Verfügung stellen, die relevante Informationen einschließlich Preis- und Abrechnungsinformationen enthält. In einem Beispiel können die gemeinsamen Informationen in Dienstsignaturen bereitgestellt werden.
Dienstsignaturen können beispielsweise verwendet werden, um Leistungsinformationen (z. B. generierter Umsatz, Diensteffizienz, erhaltene Rabatte, weitergegebene Rabatte) zwischen einem oder mehreren Diensten (z. B. service_1 210, service_2 212, service_n-1 214, service_n 216) und dem Dienstverwaltungsagenten 206 bereitzustellen. Die Informationen aus den Dienstsignaturen können zur Erstellung und/oder Aktualisierung der Dienstabrechnungsübersicht 208 verwendet werden.
In einem Beispiel können die folgenden Dienstsignaturen mit den in 2 dargestellten Diensten verwendet werden.
Dienst, Unterschrift (unterzeichnet von Dienst₂): {Service₁, Einnahmen; Effizienz, Rabatt _erhalten, Rabatt _{weitergegeben}service_1provider}, {Service₂, Einnahmen; Effizienz, Rabatt _erhalten, Rabatt _{weitergegeben}service_2provider}, {Service_N-1, Einnahmen; Effizienz, Rabatt _erhalten, Rabatt _{weitergegeben}service_N-1provider}, {Service_N, Einnahmen; Effizienz, _Rabatt erhalten, Rabatt weitergegeben}service_Nprovider.
Dienst₂ Unterschrift (unterzeichnet von Dienst₃): {Service₂, Einnahmen; Effizienz, Rabatt _erhalten, Rabatt _{weitergegeben}service_2provider}, {Service₃, Einnahmen; Effizienz, Rabatt _erhalten, Rabatt _{weitergegeben}service_3provider}, {Service_N-1, Einnahmen; Effizienz, Rabatt _erhalten, Rabatt _{weitergegeben}service_N-1provider} {Service_N, Einnahmen; Effizienz, _Rabatt erhalten, Rabatt weitergegeben}service_Nprovider.
Dienst_N-1 Unterschrift (unterzeichnet von Dienst_N): {Dienst_N-1, Einnahmen; Effizienz, _erhaltener Rabatt, weitergegebener _{Rabatt}service_1provider}, {Dienst_N, Einnahmen; Effizienz, _erhaltener Rabatt, weitergegebener Rabatt}service_Nprovider.
Dienst_N Signatur (unterzeichnet vom Infrastrukturanbieter): {Service_N, Revenue; Efficiency, _{Discountreceived}, Discountpassed}infrastructure_provider.
Im Beispiel von 2 kann ein einziger Satz von Benutzereinstellungen für die vom Endbenutzer 204 genutzte Dienstleistungskette verwendet werden. In komplexeren Beispielen können jedoch mehrere Sätze von Benutzereinstellungen unterstützt werden, die an verschiedenen Positionen in der Kette von Diensten verwendet werden. Zum Beispiel kann ein erster Satz von Benutzereinstellungen für service_1 210 und service_2 212 verwendet werden, während ein zweiter Satz von Benutzereinstellungen für service_n-1 214 und service_n 216 verwendet werden kann.
In ähnlicher Weise können mehrere Sätze von Anbieterparametern an verschiedenen Stellen in der Dienstleistungskette verwendet werden. Der Dienstverwaltungsagent 206 kann für die Verwaltung dieses komplexeren Beispiels zuständig sein, oder es können mehrere Dienstverwaltungsagenten unterstützt werden. Die Gruppierung der Anbieterparameter kann sich von der Gruppierung der Benutzerpräferenzen unterscheiden. Beispielsweise kann service_1 210 einen ersten Satz von Anbieterparametern haben und service_2 212, service_n-1 214 und service_n 216 können einen zweiten Satz von Anbieterparametern haben.
In einigen Beispielen mit verketteten Diensten kann eine Umsatzabrechnung an mehreren Stellen in der Kette durchgeführt werden (z. B. zwischen jedem Glied in der Kette oder für jeden Dienst in der Kette), um den Umsatz zu bewerten/zu bestimmen, der durch die Nutzung verschiedener Komponenten innerhalb der Infrastrukturumgebung 202 erzielt wird. In einem Beispiel kann die Umsatzabrechnung für einen ersten Zeitraum durchgeführt werden, und anschließend kann der gleiche oder ein ähnlicher Umsatzabrechnungsprozess für einen zweiten Zeitraum durchgeführt werden.
Die Informationen zur Umsatzabrechnung können in Kombination mit aggregierten oder akkumulierten Informationen (z. B. Ressourcenbedarf) und Benutzerpräferenzen (z. B. Benutzerpräferenzen 122 und Anbieterparameter 118) verwendet werden, um Rabatte und/oder QoS-Anpassungen innerhalb der Dienstleistungskette zu verwalten. In anderen Beispielen können Rabattstufen und QoS-Stufen für den Kauf von (oder die Verhandlung über) Gebote zur Bereitstellung von Rechenressourcen verwendet werden. Konzeptionell können die hier beschriebenen Mechanismen also sowohl zur Unterstützung eines Push-Ansatzes (bei dem Informationen von einer externen Instanz, z. B. den Anbieterparametern 118, bereitgestellt werden) als auch eines Pull-Ansatzes (bei dem Informationen vom Dienst angefordert werden) zur Verwaltung von Rabatten, QoS usw. verwendet werden.
Das Beispiel in 2 umfasst eine einzige hierarchische Dienststruktur für einen einzigen Endbenutzer; es können jedoch beliebig viele hierarchische Dienststrukturen für eine beliebige Anzahl von Endbenutzern unterstützt werden. Komplexere Beispiele werden weiter unten beschrieben.
zeigt ein Beispiel für die Anpassung der Dienstgüte (QoS) auf der Grundlage von Umsatz- und Rechnungsschwankungen. Alternativ kann auch ein Rabatt auf der Grundlage von Umsatz- und QoS-Schwankungen angepasst werden. Das Beispiel in 3 bietet exponierte QoS-Steuerungen, die es einem Endnutzer (oder einer anderen relevanten Einheit) ermöglichen, beispielsweise bei Umsatzschwankungen in einer Umgebung mit umsatzproportionaler Abrechnung (RpB) eine konstante Abrechnung beizubehalten. Zum Beispiel kann die Preisgestaltung bei QoS-Anpassungen (z. B. Anpassungen der Ressourcennutzung, Anpassungen der Ressourcenanforderungen) auf einem konstanten (oder nahezu konstanten) Niveau gehalten werden. In einigen Beispielen können Richtlinien für QoS-Anpassungen zur Aufrechterhaltung der Preisgestaltung auf einem konstanten (oder nahezu konstanten) Niveau durch Ketten von Dienstaufrufen (wie in 2 dargestellt) weitergegeben werden.
Im Beispiel von 3 kann die Infrastrukturumgebung 302 den Dienst 304 (und eine beliebige Anzahl zusätzlicher Cloud-basierter Rechendienstinstanzen, die in 3 nicht dargestellt sind) bereitstellen. Die Infrastrukturumgebung 302 kann ferner einen Infrastrukturverwaltungsagenten 306 (analog zum Infrastrukturverwaltungsagenten 112) enthalten, der Verwaltungs- und Abrechnungsfunktionen bereitstellt. Die Infrastrukturumgebung 302 kann auch den Infrastruktur-QoS-Agenten 308 enthalten, der QoS-Parameter auf der Grundlage von z. B. Dienstsignatur(en) 310 vom Dienst 304, Anbieterparametern 312 vom Infrastrukturanbieter 314 und/oder von der Infrastrukturumgebung 302 erhaltenen Informationen verwalten kann. Ein Agent (z. B. Infrastruktur-Management-Agent 306, Infrastruktur-QoS-Agent 308) kann als Hardware oder als Kombination aus Hardware und Software implementiert werden, um die Funktionalität des Agenten wie beschrieben bereitzustellen.
Im Beispiel von 3 können der Infrastruktur-Management-Agent 306 und der Infrastruktur-QoS-Agent 308 miteinander kommunizieren, um ausgewählte Abrechnungs-/Preisparameter automatisch innerhalb der durch die Provider-Parameter 312 des Infrastruktur-Providers 314 festgelegten Bereiche zu halten. Das Beispiel in 3 zeigt das Beispiel 316 für einen konstanten Rabatt und das Beispiel 318 für eine konstante QoS; andere Parameter können jedoch auf ähnliche Weise verwaltet werden. Der Infrastrukturverwaltungsagent 306 kann dem Infrastruktur-QoS-Agenten 308 Informationen über die Dienstabrechnung zur Verfügung stellen, die es dem Infrastruktur-QoS-Agenten 308 ermöglichen, Änderungen am Betrieb des Dienstes 304 in der Infrastrukturumgebung 302 vorzunehmen.
Im Beispiel 316 mit konstantem Rabatt wünscht sich der Infrastrukturanbieter 314 einen konstanten Rabatt, wenn sich die Einnahmen ändern. Daher überwacht der Infrastruktur-QoS-Agent 308 die mit dem Dienst 304 verbundenen Einnahmen und nimmt QoS-Parameteranpassungen vor, um einen konstanten Rabatt beizubehalten, sofern dies möglich ist. In einem verwandten Beispiel kann der Infrastruktur-QoS-Agent 308 QoS-Parameteranpassungen vornehmen (z. B. Anpassung der Bandbreitennutzung, Speichernutzung, Sicherheitsfunktionen), um den Rabatt innerhalb eines bestimmten Bereichs zu halten (z. B. +/-5 % des Basisrabatts).
Ein weiteres separates Beispiel ist als Beispiel 318 für konstante QoS dargestellt. Der Infrastrukturanbieter 314 wünscht eine konstante QoS-Umgebung, wenn sich die Einnahmen ändern. Daher kann der Infrastruktur-QoS-Agent 308 die QoS-Parameter konstant halten und der Infrastruktur-Management-Agent 306 kann die verfügbaren Rabatte als Reaktion auf Umsatzänderungen anpassen, um die QoS über einen längeren Zeitraum konstant zu halten. Dies kann beispielsweise bedeuten, dass der Infrastrukturverwaltungsagent 306 die Inanspruchnahme eines Rabatts auf einen späteren Zeitpunkt verschieben kann, z. B. bei Erreichen eines höheren Umsatzniveaus. In einem verwandten Beispiel kann der Infrastrukturverwaltungsagent 306 versuchen, die QoS innerhalb eines bestimmten Bereichs zu halten (z. B. +/-5 % der Basislinie).
In den Beispielen von 3 kann ein Endnutzer, der sich für Rabatte entscheidet, bei steigenden Einnahmen die Rabatte erhöhen und umgekehrt, während die QoS konstant (oder annähernd konstant) bleibt. Entscheidet sich der Endnutzer jedoch dafür, sich auf die QoS zu konzentrieren, können die Rabatte festgelegt werden und die QoS kann in Abhängigkeit von Umsatzschwankungen schwanken. Als weiteres Beispiel (in 3 nicht dargestellt) kann eine Kombination der dargestellten Optionen angeboten werden. So können beispielsweise sowohl Rabatte als auch QoS innerhalb vorgewählter Bereiche schwanken, wobei eine Option stärker gewichtet wird als die andere. Außerdem kann der Dienst 304 ein Dienst in einer Kette von Diensten sein (z. B. die in 2 und 4 beschriebenen Dienstketten).
In ist eine Beispielinfrastruktur dargestellt, die sowohl rabatt- als auch qualitätsorientierte Dienstleistungsketten mit mehreren Endnutzern unterstützt. Im Beispiel von können rabatt- und qualitätsorientierte Präferenzen von Endnutzern in Dienstleistungsketten weitergegeben werden. Im Beispiel von 4 können alle Dienste in einer einzigen Infrastrukturumgebung ausgeführt werden. Bei Diensten, die sich am Anfang der Kette befinden, ist es wahrscheinlicher, dass sie weniger Infrastrukturressourcen benötigen, und bei Diensten, die sich am Ende der Kette befinden, ist es wahrscheinlicher, dass sie mehr Infrastrukturressourcen benötigen. Im Beispiel von 4 nutzen rabattorientierte Endbenutzer und qualitätsorientierte Endbenutzer unterschiedliche Instanzen von Diensten, da für rabattorientierte Dienste im Vergleich zu qualitätsorientierten Diensten eine andere Zeitplanung verwendet werden kann.
Im Beispiel von 4 umfasst die Infrastrukturumgebung 402 den Dienstverwaltungsagenten 404 (der analog zum Dienstverwaltungsagenten 116 oder zum Dienstverwaltungsagenten 206 sein kann) und kann mehreren Endnutzern (z. B. den Endnutzern 406, 408, 410, 412) Dienste anbieten. Zwei der Endnutzer (Endnutzer 406 und Endnutzer 408) nutzen rabattorientierte 414-Mechanismen (z. B. analog zu 1 und 2), um Bedingungen zu erreichen, die dem konstanten Rabattbeispiel 316 entsprechen, und zwei der Endnutzer (Endnutzer 410 und Endnutzer 412) nutzen QoS-fokussierte 416-Mechanismen, um Bedingungen zu erreichen, die dem konstanten QoS-Beispiel 318 entsprechen.
Der Endnutzer 406 kann eine Kette von Diensten nutzen, die den Dienst 418 und den Dienst 420 umfasst, während der Endnutzer 408 eine komplexere Kette von Diensten nutzen kann, die den Dienst 422, den Dienst 424 und den Dienst 420 umfasst. Jede dieser Dienstketten kann auf die in 2 beschriebene Weise verwaltet werden. In ähnlicher Weise kann der Endbenutzer 410 eine Kette von Diensten nutzen, die den Dienst 426, den Dienst 428 und den Dienst 430 umfasst, während der Endbenutzer 412 eine Kette von Diensten nutzen kann, die den Dienst 432, den Dienst 428 und den Dienst 430 umfasst. Diese Dienstketten können ebenfalls auf die in 2 beschriebene Weise verwaltet werden. So können eine einzige Infrastrukturumgebung (z. B. Infrastrukturumgebung 402) und ein einziger Dienstverwaltungsagent (z. B. Dienstverwaltungsagent 404) mehrere Endnutzer mit unterschiedlichen Dienstketten und/oder unterschiedlichen Schwerpunkten (z. B. Rabatt, QoS) unterstützen.
Wie in 2 beschrieben, können die von der Infrastrukturumgebung 402 bereitgestellten Dienste komplexe Beziehungen zwischen den verschiedenen bereitgestellten Diensten in Bezug auf die entsprechenden Benutzerpräferenzen und Anbieterparameter unterstützen.
In 5 ist eine Beispielinfrastruktur dargestellt, die dynamisch installierbare Abrechnungsmodule auf der Grundlage von Kunden- und/oder Anbieterpräferenzen unterstützt. Das Beispiel von 5 bietet ein kundenspezifisches Modul (z. B. ein Plugin oder eine andere Datei, die Präferenzen beschreibt) für den Service Management Agent 502. Das kundenspezifische Modul kann verwendet werden, um Richtlinien auf der Grundlage von Benutzerspezifikationen innerhalb der Infrastrukturumgebung 512 zu implementieren. Ein kundenspezifisches Modul kann z. B. eine Softwarekomponente sein, die Funktionen zur Umsetzung der angegebenen Richtlinien hinzufügen kann, eine Datei oder eine andere Komponente, die eine Beschreibung der zu unterstützenden Richtlinien und/oder Abrechnungsstrukturen liefert. Zu den Richtlinien können z. B. Rabattstrukturen gehören. Ein weiteres Beispiel: Ein kundenspezifisches Modul kann eine Softwarekomponente sein, die zusätzliche Funktionen bereitstellt/unterstützt.
In einigen Beispielen könnte das kundenspezifische Modul verwendet werden, um Benutzerpräferenzen 504 (z. B. entsprechend dem Endbenutzer 506) festzulegen, wie z. B. Gebühren, die künftige Einnahmen für reduzierte anfängliche Preisstrukturen ausgleichen. In einigen Beispielen kann das kundenspezifische Modul außerdem Einschränkungen enthalten, die von einem oder mehreren Infrastrukturanbietern (z. B. Infrastrukturanbieter 508) durch die Verwendung von Anbieterparametern (z. B. Anbieterparameter 510) bereitgestellt werden.
Im Beispiel von 5 kann die Infrastrukturumgebung 512 eine beliebige Anzahl von kundenspezifischen Abrechnungsmodulen (z. B. das kundenspezifische Abrechnungsmodul 514) unterstützen, die gemäß den Benutzerpräferenzen 504 (z. B. vom Endbenutzer 506) und/oder Anbieterparametern 510 (z. B. vom Infrastrukturanbieter 508) funktionieren können. Beispielhafte Benutzereinstellungen 516 bieten eine grafische Darstellung der Art von Informationen, die durch Benutzereinstellungen 504 übermittelt werden können, die vom kundenspezifischen Abrechnungsmodul 514 genutzt werden können.
Das kundenspezifische Abrechnungsmodul 514 kann so funktionieren, dass es den Service-Management-Agenten 502 mit Informationen versorgt, um den Service 518 auf der Grundlage der Benutzerpräferenzen 504 und 510 zu verwalten. Bei dem kundenspezifische n Abrechnungsmodul 514 kann es sich beispielsweise um eine kundenspezifische Softwarekomponente handeln, die die Funktionalität des Service-Management-Agenten 502 erweitert. Als weiteres Beispiel kann das kundenspezifische Abrechnungsmodul 514 eine Hardware- oder Firmwarekomponente sein, die die angegebene Abrechnungsfunktionalität bereitstellt.
Im Beispiel von 5 kann die Infrastrukturumgebung 512 zum Beispiel eine öffentliche Cloud-Umgebung sein, die auf Servern betrieben wird, die vom Infrastrukturanbieter 508 verwaltet und gewartet werden. Die Infrastrukturumgebung 512 kann ein beliebiges Angebot als Dienst bereitstellen, wie z. B. SaaS, PaaS, laaS usw. Wenn die Infrastrukturumgebung 512 mehrere Dienste anbietet (in 5 nicht dargestellt), kann jeder Dienst einen zugehörigen Dienstabrechnungsagenten haben.
In einem Beispiel kann das kundenspezifische Abrechnungsmodul 514 und/oder der Servicemanagement-Agent 502 dazu dienen, den Umsatz, die Nutzung und/oder andere Faktoren für einen ersten Zeitraum zu bestimmen, und anschließend kann derselbe oder ein ähnlicher Prozess verwendet werden, um einen Rabatt für einen zweiten Zeitraum zu ermitteln.
Der Dienstverwaltungsagent 502 (der analog zum Dienstverwaltungsagenten 116, Dienstverwaltungsagenten 206 und Dienstverwaltungsagenten 404 sein kann) kann Anbieterparameter 510 und Benutzerpräferenzen 504 zusammen mit der Überwachung des Betriebs des Dienstes 518 verwenden, um eine Dienstabrechnungsübersicht für den Endbenutzer 506 zu erstellen. Das kundenspezifische Abrechnungsmodul 514 kann eine automatisierte Funktionalität bereitstellen, um die Benutzerpräferenzen 504 durch den Service-Management-Agenten 502 und die Nutzung des Dienstes 518 zu erfüllen. Beispielsweise können die Benutzerpräferenzen 504 und/oder das kundenspezifische Abrechnungsmodul 514 Schwellenwerte festlegen, bei deren Überschreitung ein aktuell angebotener Rabatt für die zukünftige Nutzung verzögert wird. Auf diese Weise kann die kombinierte Funktionalität des Service-Management-Agenten 502 und des kundenspezifischen Abrechnungsmoduls 514 eine effizientere und optimierte Erfahrung bieten, als es sonst möglich wäre.
Im Laufe der Zeit kann der Endbenutzer 506 die Benutzerpräferenzen 516 ändern und/oder der Infrastrukturanbieter 508 kann die Anbieterparameter 510 ändern, um die Funktionalität der Infrastrukturumgebung 512 und/oder des Dienstes 518 weiter zu verbessern. Das Beispiel in 5 zeigt nur einen einzigen Dienst, einen Endnutzer, einen Dienstverwaltungsagenten, ein kundenspezifisches Abrechnungsmodul und einen Infrastrukturanbieter; in alternativen Beispielen kann jedoch eine beliebige Anzahl von Diensten, Endnutzern, Dienstverwaltungsagenten, kundenspezifischen Abrechnungsmodulen und Infrastrukturanbietern unterstützt werden.
Im Beispiel von 5 kann der Infrastrukturanbieter 508 entscheiden, ob er Rabatte zulässt oder nicht (z. B. über die Anbieterparameter 510). Wenn Rabatte erlaubt sind, kann der angebotene Rabatt z. B. proportional zur Rate der Umsatzgenerierung sein, oder der Rabatt kann einem beschleunigten Wachstum entsprechen (z. B. linear oder innerhalb eines eingegrenzten Bereichs). Der Endnutzer 506 kann künftige Einnahmen gegen den gegenwärtig rabattierten Preis und/oder die QoS eintauschen (z. B. über die Benutzereinstellungen 504).
In einem Beispiel kann das kundenspezifische Abrechnungsmodul 514 eine Reihe von einsteckbaren Richtlinien für den Benutzer (z. B. den Endbenutzer 506) bereitstellen, die vom Service Management Agent 502 implementiert werden. Diese Richtlinien können dazu dienen, vom Endbenutzer 506 (z. B. über die Benutzereinstellungen) festgelegte Präferenzen oder Funktionen auszuführen (oder durchzusetzen). In manchen Situationen können mehrere Benutzerpräferenzen unterstützt werden. Beispielsweise kann das kundenspezifische Abrechnungsmodul 514 verschiedene Schwellenwerte auf der Grundlage der Benutzerpräferenzen bestimmen, und der Dienstverwaltungsagent 502 kann durch Anbieterparameter des Infrastrukturanbieters 508 festgelegte Grenzen durchsetzen, so dass die Werte der Benutzerpräferenzen 504 innerhalb der vom Infrastrukturanbieter 508 erlaubten Bereiche gewichtet werden können.
In einem anderen Beispiel können die Benutzerpräferenzen 504 durch die Verwendung von Metadaten bereitgestellt und/oder geändert werden, die Teil der Dienstanforderungen für den Zugriff auf den Dienst 518 sind. In einigen Beispielen können die Metadaten dazu dienen, die Funktionalität des kundenspezifischen Abrechnungsmoduls 514 zu aktivieren und zu deaktivieren. In anderen Beispielen können die Metadaten dazu dienen, die Funktionalität des kundenspezifischen Abrechnungsmoduls 514 zu modifizieren, um beispielsweise die Benutzereinstellungen 504 auf der Grundlage der Dienstausführung (z. B. von Dienst 518) anzupassen.
Wie bereits erwähnt, kann der Endbenutzer 506 (z. B. über die Benutzereinstellungen) künftige Einnahmen gegen aktuelle Preisnachlässe und/oder QoS-Änderungen eintauschen. Dies kann höhere Rabatte (im Vergleich zur Basis-Rabattstruktur) zu einem früheren Zeitpunkt im Austausch für geringere Rabatte zu einem späteren Zeitpunkt (z. B. in späteren Abrechnungszeiträumen) ermöglichen. In einem Beispiel kann das kundenspezifische Abrechnungsmodul 514 verwendet werden, um die geänderte Rabattstruktur mit dem Infrastrukturanbieter 508 auszuhandeln, indem z. B. ein erhöhter Rabatt für die nächste Gruppe (z. B. 100, 250, 75) von Serviceanfragen mit einem reduzierten Rabatt für die folgende Gruppe (z. B. 100, 250, 75) von Serviceanfragen festgelegt wird (nachdem Serviceanfragen mit erhöhtem Rabatt ausgeführt wurden, unter der Annahme einer erhöhten Umsatzrate, um sich für den erhöhten Rabatt unter der Basisrabattstruktur zu qualifizieren).
Die spezifischen Beispiele in 5 sind nur einige der Arten von Präferenz-, Preis- und Verhandlungsstrukturen, die unter Verwendung der Architekturen von 1, 2, 3, 4, 5 und 7 unterstützt werden können. Viele andere Variationen können in ähnlicher Weise unterstützt werden.
ist ein Flussdiagramm einer Beispieltechnik zur Bereitstellung von Diensten, die einen Abrechnungsmechanismus zur Unterstützung der cloudbasierten Dienstverwaltung unterstützen. Die Technik 614 kann zum Beispiel von hardwarebasierten Komponenten bereitgestellt oder ausgeführt werden, wie sie in 1, 2, 3, 4, 5 oder 7 dargestellt und beschrieben sind.
In Block 602 können Cloud-basierte Rechendienste von einer Infrastrukturumgebung mit einem Infrastrukturverwaltungsagenten bereitgestellt werden. In einem Beispiel können die Cloud-basierten Rechendienste von einem Infrastrukturanbieter bereitgestellt werden (z. B. Infrastrukturanbieter 102, Infrastrukturanbieter 314, Infrastrukturanbieter 508). In einigen Beispielen können die Infrastrukturanbieter Anbieterparameter oder andere Konfigurationsfunktionen verwenden, um die von der Infrastrukturumgebung bereitgestellten Cloud-basierten Rechendienste zu verwalten.
In Block 604 wird die Umsatzabrechnung für eine erste Zeitperiode durchgeführt. Beispielsweise kann ein Dienstverwaltungsagent (z. B. Dienstverwaltungsagent 116, Dienstverwaltungsagent 206, Dienstverwaltungsagent 404, Dienstverwaltungsagent 502) so funktionieren, dass er einen oder mehrere Dienste überwacht, die von der Infrastrukturumgebung für einen oder mehrere Endnutzer (oder Gruppen von Nutzern, Organisationen usw.) bereitgestellt werden, um verschiedene Umsatzmetriken für den ersten Zeitraum zu bestimmen. In einem Beispiel kann die Umsatzabrechnung dazu verwendet werden, eine Rabattstruktur auf der Grundlage der Geschwindigkeit der Umsatzgenerierung ((d Revenue)/dt) durch die Dienste zu bestimmen. In anderen Beispielen können verschiedene Ansätze zur Verbuchung der Einnahmen verwendet werden.
In Block 606 kann ein Service-Management-Agent feststellen, ob sich die Einnahmen über einen ersten Zeitraum hinweg über die Schwellenwerte hinaus verändert haben. Beispielsweise kann ein Dienstverwaltungsagent (z. B. Dienstverwaltungsagent 116, Dienstverwaltungsagent 206, Dienstverwaltungsagent 404, Dienstverwaltungsagent 502) feststellen, ob sich die überwachten Umsatzbeträge über die Schwellenbeträge für den ersten Zeitraum hinaus verändert haben. Die Schwellenwerte können z. B. durch die Parameter des Anbieters, durch die Benutzereinstellungen oder eine Kombination davon festgelegt werden. Die Verwendung von Schwellenwerten kann dazu beitragen, den Aufwand für die Verwaltung verschiedener Rabattänderungen/-verhandlungen und/oder Änderungen der QoS-Parameter zu reduzieren.
In Block 608 können die Parameter für die Dienstqualität auf der Grundlage der Umsatzabrechnung angepasst werden, wenn sich der Umsatz über die (in Block 606 ermittelten) Schwellenwerte hinaus verändert hat. Beispielsweise kann ein Dienstverwaltungsagent (z. B. Dienstverwaltungsagent 116, Dienstverwaltungsagent 206, Dienstverwaltungsagent 404, Dienstverwaltungsagent 502) und/oder eine andere Komponente innerhalb der entsprechenden Infrastrukturumgebung (z. B. Infrastrukturumgebung 104, Infrastrukturumgebung 202, Infrastrukturumgebung 302, Infrastrukturumgebung 402, Infrastrukturumgebung 512) auf Umsatzänderungen reagieren, um die Dienstgüteparameter für eine oder mehrere Komponenten anzupassen, die an der Bereitstellung angeforderter Dienste beteiligt sind (z. B. über Dienst 110, Dienst 304, Dienst 418, Dienst 518).
In einem Beispiel können Anpassungen der QoS-Parameter auf der Grundlage von Benutzerpräferenzen (z. B. Benutzerpräferenzen 122, Benutzerpräferenzen 504) und/oder Anbieterparametern (z. B. Anbieterparameter 118, Anbieterparameter 312, Anbieterparameter 510) innerhalb bestimmter Grenzen erfolgen. In einem anderen Beispiel können Anpassungen der QoS-Parameter selektiv erlaubt oder nicht erlaubt sein, wie beispielsweise in den entsprechenden Anbieterparametern (z. B. Anbieterparameter 118, Anbieterparameter 312, Anbieterparameter 510) angegeben. Wenn QoS-Parameteranpassungen zulässig sind, können sie beispielsweise innerhalb bestimmter Grenzen erfolgen.
In Block 610 können die Abrechnungsrabatte für laufende Dienste geändert werden, wenn sich der Umsatz über die (in Block 606 ermittelten) Schwellenwerte hinaus verändert hat. In einigen Beispielen werden die Abschläge für die Abrechnung geändert, wenn keine Anpassungen der Dienstgüte erlaubt sind (z. B. wird Block 608 ohne Anpassung der Dienstgüte durchgeführt, z. B. aufgrund von Benutzereinstellungen oder Anbieterparametern, die keine Anpassungen der Dienstgüte zulassen). Beispielsweise kann ein Dienstverwaltungsagent (z. B. Dienstverwaltungsagent 116, Dienstverwaltungsagent 206, Dienstverwaltungsagent 404, Dienstverwaltungsagent 502) und/oder andere Komponenten der Host-Infrastrukturumgebung (z. B. Infrastrukturumgebung 104, Infrastrukturumgebung 202, Infrastrukturumgebung 302, Infrastrukturumgebung 402, Infrastrukturumgebung 512) auf Umsatzänderungen jenseits der Schwellenwerte reagieren, indem sie die Abrechnungsrabatte anpassen, wenn QoS-Änderungen nicht zulässig sind. In einigen Beispielen können Anpassungen sowohl an den QoS-Parametern als auch an den Abschlagszahlungen vorgenommen werden.
Der Infrastrukturanbieter (z. B. der Infrastrukturanbieter 508) kann Bereiche vorgeben, innerhalb derer Abrechnungsrabatte gewährt werden können (z. B. über die Anbieterparameter). Der angebotene Rabatt kann z. B. proportional zur Rate der Umsatzgenerierung sein, oder der Rabatt kann einem beschleunigten Wachstum entsprechen (z. B. linear oder innerhalb eines Klammerbereichs). Ein Nutzer oder eine andere Entität kann diese Rabattangebote nutzen, um künftige Einnahmen gegen einen aktuell ermäßigten Preis und/oder QoS einzutauschen (z. B. über die Nutzerpräferenzen).
In Block 612 werden Cloud-basierte Rechendienste entsprechend den angepassten Dienstqualitätsparametern (z. B. auf der Grundlage von Block 608) und/oder geänderten Abrechnungsrabatten (z. B. auf der Grundlage von Block 610) bereitgestellt. Das Verfahren 614 kann beliebig oft wiederholt werden.
7 ist ein Blockdiagramm eines Beispiels für ein Verarbeitungssystem zur Bereitstellung cloudbasierter Dienste. In einem Beispiel kann das System 714 einen oder mehrere Prozessoren 716 und ein nicht-übertragbares computerlesbares Speichermedium 718 umfassen. Das nicht-transitorische computerlesbare Speichermedium 718 kann Anweisungen 702, 704, 706, 708 und 710 speichern, die, wenn sie von dem/den Prozessor(en) 716 ausgeführt werden, den/die Prozessor(en) 716 veranlassen, verschiedene Funktionen auszuführen. Beispiele für Prozessor(en) 716 können einen Mikrocontroller, einen Mikroprozessor, eine Zentraleinheit (CPU), eine Grafikverarbeitungseinheit (GPU), eine Datenverarbeitungseinheit (DPU), eine anwendungsspezifische integrierte Schaltung (ASIC), ein feldprogrammierbares Gate-Array (FPGA), ein System auf einem Chip (SoC) usw. umfassen. Beispiele für ein nicht transitorisches, computerlesbares Speichermedium 718 umfassen greifbare Medien wie einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), einen elektrisch löschbaren Festwertspeicher (EEPROM), einen Flash-Speicher, ein Festplattenlaufwerk usw.
Die Anweisungen 702 veranlassen den/die Prozessor(en) 716, Cloud-basierte Rechendienste mit einer Infrastrukturumgebung (z. B. Infrastrukturumgebung 104, Infrastrukturumgebung 202, Infrastrukturumgebung 302, Infrastrukturumgebung 402, Infrastrukturumgebung 512) mit einem Infrastrukturverwaltungsagenten (z. B. Infrastrukturverwaltungsagent 112, Infrastrukturverwaltungsagent 306) bereitzustellen. Eine beliebige Anzahl von Prozessoren 716 kann Cloud-basierte Dienste für eine oder mehrere entfernte Entitäten (z. B. Endnutzer 108, Endnutzer 204, Endnutzer 408, Endnutzer 506) bereitstellen.
Die Anweisungen 704 veranlassen den/die Prozessor(en) 716, eine Umsatzabrechnung für einen ersten Zeitraum vorzunehmen. In einem Beispiel kann die Umsatzabrechnung auf der Geschwindigkeit der Umsatzgenerierung ((d Revenue)/dt) basieren. In anderen Beispielen können verschiedene Ansätze zur Abrechnung der Einnahmen verwendet werden.
Die Anweisungen 706 können einen Dienstverwaltungsagenten (z. B. Dienstverwaltungsagent 116, Dienstverwaltungsagent 206, Dienstverwaltungsagent 404, Dienstverwaltungsagent 502) veranlassen, festzustellen, ob sich die überwachten Umsatzbeträge während des ersten Zeitraums geändert haben. Erkannte Änderungen können vom Infrastrukturverwaltungsagenten (z. B. Infrastrukturverwaltungsagent 112, Infrastrukturverwaltungsagent 306) mit z. B. Anbieterparametern verglichen werden, um festzustellen, ob Anpassungen vorgenommen und/oder Benachrichtigungen erzeugt werden sollten.
Die Anweisungen 708 können den Dienstverwaltungsagenten veranlassen, die Dienstqualität auf der Grundlage der Umsatzabrechnung anzupassen, wenn sich der Umsatz geändert hat (wie in den Anweisungen 706 festgelegt). Service-Management-Agenten und/oder andere Komponenten der Infrastrukturumgebung können auf Umsatzänderungen reagieren, indem sie z. B. Rechnungsrabatte auf der Grundlage von Anbieterparametern und/oder Benutzerpräferenzen anpassen. In einigen Beispielen können Anpassungen sowohl an den QoS-Parametern als auch an den Abrechnungsrabatten vorgenommen werden.
Die Anweisungen 710 können den Dienstverwaltungsagenten veranlassen, die Abschläge für die Abrechnung laufender Dienste zu ändern, wenn sich die Einnahmen über die (durch die Anweisungen 706 ermittelten) Schwellenwerte hinaus verändert haben. In einem Beispiel können die Anweisungen 710 ausgeführt werden, wenn festgestellt wird (z. B. bei der Ausführung der Anweisungen 708), dass Anpassungen der Dienstqualität nicht zulässig sind. Dienstverwaltungsagenten und/oder andere Komponenten der Infrastrukturumgebung können auf Umsatzänderungen reagieren, indem sie die Abrechnungsrabatte beispielsweise auf der Grundlage von Anbieterparametern und/oder Benutzerpräferenzen anpassen. In einigen Beispielen können Anpassungen sowohl an QoS-Parametern als auch an Abrechnungsrabatten vorgenommen werden.
Die Anweisungen 712 können den/die Prozessor(en) 716 veranlassen, Cloud-basierte Rechendienste entsprechend den angepassten Dienstqualitätsparametern und ggf. geänderten Abrechnungsrabatten bereitzustellen. Die in den Anweisungen 702, 704, 706, 708, 710 und 712 vorgesehenen Prozesse können wiederholt werden.
In der obigen Beschreibung werden zu Erklärungszwecken zahlreiche spezifische Details aufgeführt, um ein umfassendes Verständnis der beschriebenen Beispiele zu ermöglichen. Einem Fachmann wird jedoch klar sein, dass die Beispiele auch ohne einige dieser spezifischen Details ausgeführt werden können. In anderen Fällen werden bekannte Strukturen und Geräte in Form von Blockdiagrammen dargestellt. Zwischen den dargestellten Komponenten können Zwischenstrukturen vorhanden sein. Die hier beschriebenen oder abgebildeten Komponenten können zusätzliche Eingänge oder Ausgänge haben, die nicht abgebildet oder beschrieben sind.
Verschiedene Beispiele können verschiedene Prozesse umfassen. Diese Prozesse können von Hardware-Komponenten durchgeführt werden oder in Computerprogrammen oder maschinenausführbaren Anweisungen enthalten sein, die verwendet werden können, um Prozessor- oder Logikschaltungen, die mit den Anweisungen programmiert sind, zur Durchführung der Prozesse zu veranlassen. Alternativ können die Prozesse auch durch eine Kombination von Hardware und Software ausgeführt werden.
Teile verschiedener Beispiele können als Computerprogrammprodukt bereitgestellt werden, das ein nichttransitorisches computerlesbares Medium mit darauf gespeicherten Computerprogrammanweisungen enthalten kann, die zur Programmierung eines Computers (oder anderer elektronischer Geräte) zur Ausführung durch einen oder mehrere Prozessoren verwendet werden können, um einen Prozess gemäß bestimmter Beispiele durchzuführen. Das computerlesbare Medium kann Magnetplatten, optische Platten, Festwertspeicher (ROM), Speicher mit wahlfreiem Zugriff (RAM), löschbare programmierbare Festwertspeicher (EPROM), elektrisch löschbare programmierbare Festwertspeicher (EEPROM), magnetische oder optische Karten, Flash-Speicher oder andere Arten von computerlesbaren Medien, die zur Speicherung elektronischer Anweisungen geeignet sind, umfassen, ist aber nicht darauf beschränkt. Darüber hinaus können Beispiele auch als Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer zu einem anfordernden Computer übertragen werden kann. In einigen Beispielen sind auf dem nicht transitorischen, computerlesbaren Speichermedium 718 Daten gespeichert, die Befehlssequenzen darstellen, die, wenn sie von einem oder mehreren Prozessoren 716 ausgeführt werden, den/die Prozessor(en) 716 veranlassen, bestimmte Operationen durchzuführen.
Wenn in der Beschreibung von „einem Beispiel“, „einem Beispiel“, „einigen Beispielen“ oder „anderen Beispielen“ die Rede ist, bedeutet dies, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, die im Zusammenhang mit den Beispielen beschrieben wird, in mindestens einigen, aber nicht unbedingt in allen Beispielen enthalten ist. Darüber hinaus sind solche Merkmale, Strukturen oder Eigenschaften, die im Zusammenhang mit „einem Beispiel“, „einem Beispiel“, „einigen Beispielen“ oder „anderen Beispielen“ beschrieben werden, nicht so auszulegen, dass sie auf diese(s) Beispiel(e) begrenzt oder beschränkt sind, sondern können beispielsweise mit anderen Beispielen kombiniert werden. Die verschiedenen Bezeichnungen „ein Beispiel“, „ein Beispiel“ oder „einige Beispiele“ beziehen sich nicht unbedingt alle auf dieselben Beispiele.

Claims

Ein System, das Folgendes umfasst: einen Prozessor; und ein Speichersystem, das Befehle speichert, die, wenn sie vom Prozessor ausgeführt werden, den Prozessor veranlassen: Bereitstellung eines Satzes von Cloud-basierten Rechendiensten, die eine Vielzahl von Ressourcen nutzen, für eine anfragende Einheit, wobei die Rechendienste von einer Infrastrukturumgebung bereitgestellt werden, die einen Infrastrukturverwaltungsagenten hat, um zumindest Parameter zu verwalten, die ausgewählten Rechendiensten entsprechen, eine Umsatzabrechnung entsprechend einer ersten Zeitperiode für die anfragende Einheit auf der Grundlage der von der anfragenden Einheit in Anspruch genommenen Rechenleistungen durchführen, mit dem Infrastrukturverwaltungsagenten die Parameter der Dienstqualität (QoS) für die cloudbasierten Rechendienste auf der Grundlage der Umsatzabrechnung anpassen, wenn sich der Umsatz im ersten Zeitraum geändert hat, Abschläge für die Abrechnung aktueller Cloud-basierter Rechendienste mit dem Infrastrukturmanagement-Agenten zu ändern, wenn sich die Einnahmen über den ersten Zeitraum verändert haben, und Bereitstellung des Satzes wolkengestützter Rechendienste für die anfragende Einheit gemäß der Anpassung der QoS-Parameter und gemäß den geänderten Abrechnungsrabatten über einen zweiten Zeitraum.
System nach Anspruch 1, wobei die Anweisungen, wenn sie ausgeführt werden, den Prozessor veranlassen, künftige Abrechnungsrabatte für die wolkenbasierten Rechendienste mit dem Infrastrukturverwaltungsagenten zu modifizieren, wenn sich die Einnahmen über die erste Zeitspanne geändert haben, die QoS-Anpassung nicht erlaubt ist und die Modifikation von Abrechnungsrabatten für künftige wolkenbasierte Rechendienste erlaubt ist.
System nach Anspruch 1, wobei das Modifizieren von Abrechnungsrabatten für die Cloud-basierten Rechendienste darin besteht, dass der Prozessor veranlasst wird, die Ressourcenabrechnung zu modifizieren, wobei ein rabattierter Preis umgekehrt proportional zu einer Geschwindigkeit der Umsatzgenerierung ist.
Das System nach Anspruch 1, wobei die QoS-Anpassung zumindest Änderungen an einem oder mehreren der folgenden Punkte umfasst: zulässiger Durchsatz, zulässige Verzögerung, Sicherheitsstufe, Datenschutzstufe, Prioritätsstufe und Ressourcenverfügbarkeit.
System nach Anspruch 1, wobei die Bestimmung, ob sich die Einnahmen während der ersten Zeitspanne über vorgewählte Schwellenwerte hinaus verändert haben, den Prozessor veranlasst, dies zu tun: eine Änderungsrate der Einnahmen im ersten Zeitraum zu bestimmen; die Änderungsrate der Einnahmen mit einer vorgewählten oberen Änderungsrate und einer vorgewählten unteren Änderungsrate vergleichen.
System nach Anspruch 1, wobei die Anweisungen, wenn sie ausgeführt werden, den Prozessor veranlassen, Anbieterparameter zu verwenden, die den wolkenbasierten Rechendiensten entsprechen und angeben, ob ein Rabatt angeboten wird, einen Rabattwert, einen Rabatttyp und zulässige QoS-Anpassungen.
Ein nicht-transitorisches computerlesbares Medium, auf dem Anweisungen gespeichert sind, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen: Bereitstellung eines Satzes von Cloud-basierten Rechendiensten, die eine Vielzahl von Ressourcen nutzen, für eine anfragende Einheit, wobei die Rechendienste von einer Infrastrukturumgebung bereitgestellt werden, die einen Infrastrukturverwaltungsagenten hat, um zumindest Parameter zu verwalten, die ausgewählten Rechendiensten entsprechen; eine Umsatzabrechnung entsprechend einer ersten Zeitperiode für die anfragende Einheit auf der Grundlage der von der anfragenden Einheit in Anspruch genommenen Rechenleistungen durchführen; mit dem Infrastrukturverwaltungsagenten die Parameter der Dienstqualität (QoS) für die cloudbasierten Rechendienste auf der Grundlage der Umsatzabrechnung anpassen, wenn sich der Umsatz im ersten Zeitraum geändert hat; Abschläge für die Abrechnung aktueller Cloud-basierter Rechendienste mit dem Infrastrukturmanagement-Agenten zu modifizieren, wenn sich die Einnahmen während des ersten Zeitraums geändert haben; und Bereitstellung des Satzes wolkengestützter Rechendienste für die anfragende Einheit gemäß der Anpassung der QoS-Parameter und gemäß den geänderten Abrechnungsrabatten über einen zweiten Zeitraum.
Das nicht-transitorische computerlesbare Medium nach Anspruch 7 umfasst ferner Anweisungen, die, wenn sie ausgeführt werden, den Prozessor veranlassen, künftige Abrechnungsrabatte für die wolkenbasierten Rechendienste mit dem Infrastrukturverwaltungsagenten zu modifizieren, wenn sich die Einnahmen während des ersten Zeitraums geändert haben, die QoS-Anpassung nicht zulässig ist und die Modifizierung von Abrechnungsrabatten für künftige wolkenbasierte Rechendienste zulässig ist.
Nicht-transitorisches computerlesbares Medium nach Anspruch 7, wobei das Modifizieren von Abrechnungsrabatten für aktuelle Cloud-basierte Rechendienste das Modifizieren der Ressourcenabrechnung umfasst, bei der ein rabattierter Preis umgekehrt proportional zu einer Geschwindigkeit der Umsatzgenerierung ist.
Nicht-transitorisches computerlesbares Medium nach Anspruch 7, wobei das Bestimmen, ob sich die Einnahmen über die erste Zeitspanne über vorgewählte Schwellenwerte hinaus verändert haben, umfasst: Bestimmung einer Änderungsrate der Einnahmen während des ersten Zeitraums; Vergleich der Änderungsrate der Einnahmen mit einer vorgewählten oberen Änderungsrate und mit einer vorgewählten unteren Änderungsrate.
Das nicht-transitorische computerlesbare Medium nach Anspruch 7 umfasst ferner Anweisungen, die, wenn sie ausgeführt werden, den Prozessor veranlassen, Anbieterparameter für Dienste, auf die zugegriffen wird, zu analysieren, wobei die Anbieterparameter zumindest angeben, ob eine QoS-Anpassung erlaubt ist, ob eine QoS-Anpassung erlaubt ist und ob eine Modifikation von Abrechnungsrabatten für zukünftige Cloud-basierte Rechendienste erlaubt ist.
Das nicht-transitorische computerlesbare Medium nach Anspruch 7 umfasst ferner Anweisungen, die, wenn sie ausgeführt werden, den Prozessor veranlassen, Anbieterparameter von Infrastrukturanbietern, die die wolkenbasierten Rechendienste bereitstellen, zu analysieren, wobei die Anbieterparameter den wolkenbasierten Rechendiensten entsprechen und angeben, ob ein Rabatt angeboten wird, einen Rabattwert, einen Rabatttyp und zulässige QoS-Anpassungen.
Nicht-transitorisches computerlesbares Medium nach Anspruch 7, wobei die QoS-Anpassung mindestens Modifikationen an einem oder mehreren der folgenden Elemente umfasst: zulässiger Durchsatz, zulässige Verzögerung, Sicherheitsstufe, Datenschutzstufe, Prioritätsstufe und Ressourcenverfügbarkeit.
Ein Verfahren, das Folgendes umfasst: Bereitstellen eines Satzes von Cloud-basierten Rechendiensten, die eine Vielzahl von Ressourcen nutzen, für eine anfragende Einheit, wobei die Rechendienste von einer Infrastrukturumgebung bereitgestellt werden, die einen Infrastrukturverwaltungsagenten hat, um zumindest Parameter zu verwalten, die ausgewählten Rechendiensten entsprechen; Durchführung einer Umsatzabrechnung entsprechend einer ersten Zeitperiode für die anfragende Einheit auf der Grundlage der von der anfragenden Einheit in Anspruch genommenen Rechenleistungen; Anpassung der Parameter für die Dienstqualität (QoS) für die cloudbasierten Rechendienste mit dem Infrastrukturverwaltungsagenten auf der Grundlage der Umsatzabrechnung, wenn sich der Umsatz im ersten Zeitraum geändert hat; Ändern der Abrechnungsrabatte für aktuelle wolkenbasierte Rechendienste mit dem Infrastrukturverwaltungsagenten, wenn sich die Einnahmen über den ersten Zeitraum geändert haben; und Bereitstellung des Satzes von Cloud-basierten Rechendiensten für die anfragende Entität gemäß der Anpassung der QoS-Parameter und gemäß den modifizierten Abrechnungsrabatten über einen zweiten Zeitraum.
Das Verfahren nach Anspruch 14 umfasst ferner das Modifizieren künftiger Abrechnungsrabatte für die wolkenbasierten Rechendienste mit dem Infrastrukturverwaltungsagenten, wenn sich die Einnahmen über den ersten Zeitraum geändert haben und die Modifizierung von Abrechnungsrabatten für künftige wolkenbasierte Rechendienste zulässig ist.
Verfahren nach Anspruch 14, bei dem das Modifizieren von Abrechnungsrabatten für aktuelle Cloud-basierte Rechendienste das Modifizieren der Ressourcenabrechnung umfasst, bei der ein rabattierter Preis umgekehrt proportional zu einer Geschwindigkeit der Umsatzgenerierung ist.
Verfahren nach Anspruch 14, wobei das Bestimmen, ob sich die Einnahmen während der ersten Zeitspanne geändert haben, umfasst: Bestimmung einer Änderungsrate der Einnahmen während des ersten Zeitraums; Vergleich der Änderungsrate der Einnahmen mit einer vorgewählten oberen Änderungsrate und mit einer vorgewählten unteren Änderungsrate.
Das Verfahren nach Anspruch 14 umfasst ferner das Analysieren von Anbieterparametern für Dienste, auf die zugegriffen wird, wobei die Anbieterparameter zumindest angeben, ob eine QoS-Anpassung erlaubt ist, ob eine QoS-Anpassung erlaubt ist und ob eine Modifikation von Abrechnungsrabatten für künftige Cloud-basierte Rechendienste erlaubt ist.
Das Verfahren nach Anspruch 18 umfasst ferner das Analysieren von Anbieterparametern von Infrastrukturanbietern, die die wolkenbasierten Rechendienste bereitstellen, wobei die Anbieterparameter den wolkenbasierten Rechendiensten entsprechen und angeben, ob ein Rabatt angeboten wird, einen Rabattwert, einen Rabatttyp und zulässige QoS-Anpassungen.
Verfahren nach Anspruch 14, wobei die QoS-Anpassung mindestens Modifikationen an einem oder mehreren der folgenden Elemente umfasst: zulässiger Durchsatz, zulässige Verzögerung, Sicherheitsstufe, Datenschutzstufe, Prioritätsstufe und Ressourcenverfügbarkeit.