Source-linked AI summary
A Penalty-Aware, Blockchain-based Cloud Monitoring System
Christian Dienbauer, Benedikt Pittl, Erich Schikuta
TL;DR
Dynamic cloud markets create heterogeneous infrastructures that complicate monitoring and transparent penalty management. The paper uses blockchain-hosted smart contracts to monitor traded cloud services and automatically transfer penalties, demonstrating technical feasibility with Hyperledger Fabric for Amazon and Azure. The approach still faces scope and adoption boundaries involving service-type registration, metric unification, and token exchange rates.
Problem
Heterogeneous, decentralized cloud infrastructures make transparent service monitoring and penalty management difficult, leaving consumers to gather reliable evidence and bear additional costs.
Method
The paper registers cloud services and SLAs in bilateral smart contracts that use agreed monitoring services as oracles to detect violations and transfer penalties on a blockchain.
Results
The implemented Hyperledger Fabric system demonstrates technical feasibility by monitoring virtual-machine availability for Amazon and Azure, illustrating the approach’s generic applicability.
Takeaways & Limitations
Autonomous blockchain-based penalty transfers can benefit consumers through immediate payments and providers through transparent monitoring.
Takeaways & Limitations
Industry adoption requires unified service-performance metrics and predictable token exchange rates, while the current service-type design can require many static smart contracts across providers.
Abstract
from arXiv · showhide
Today, traded cloud services are governed by service-level agreements that specify providers' obligations, such as availability and reliability. Violations of service-level agreements result in penalty payments. The recent development of prominent cloud platforms, such as the redesign of Amazon's spot marketspace, underpins a trend towards dynamic cloud markets where consumers continuously migrate their services across different marketspaces and providers to reach a cost optimum. This leads to a heterogeneous IT infrastructure and, consequently, complicates monitoring of delivered service quality. Hence, there is a need for a transparent penalty management system that ensures consumers automatically receive penalty payments from providers for service violations. In this paper, we present a cloud monitoring system that can autonomously execute penalty payments. In this regard, we use smart contracts hosted on blockchains that continuously monitor cloud services and trigger penalty payments to consumers in the event of service violations. For justification and evaluation, we implement our approach using the IBM Hyperledger Fabric framework and create a use case with Amazon and Azure cloud services to illustrate the universal design of the presented mechanism.
1 Introduction
Dynamic, heterogeneous cloud markets make service-quality monitoring and penalty management harder. The paper proposes a blockchain-based platform using smart contracts to monitor services and automatically transfer penalties.
- 1 Introduction: SLAs define obligations such as availability and reliability, while violations can require penalty payments that consumers therefore need to monitor.Cloud providers expose performance metrics through monitoring platforms such as Amazon CloudWatch.
- 1 Introduction: Existing penalty-management research covers calculation, cost-aware resource management, and economic analysis, but not a monitoring platform that also manages payments.The paper identifies transparent penalty management as necessary alongside machine-readable SLAs.
- 1 Introduction: The paper develops a blockchain-based, penalty-aware cloud monitoring platform for dynamically traded services.Its implementation uses IBM Hyperledger Fabric with Amazon EC2 and Azure as a universal-design use case.
- 1 Introduction: The paper is organized around foundations and related work, the monitoring concept, its Hyperledger Fabric implementation for Amazon EC2 and Azure, findings, and future work.Implementation details are provided in an appendix.
2 Foundations and Related Work
This section reviews blockchain foundations and cloud-monitoring approaches against requirements for multi-provider, distributed, confidential, transparent, and scalable monitoring. It identifies a gap in implemented mechanisms that inject monitoring data into smart contracts and trigger penalties deterministically.
- Foundations: Blockchain systems provide decentralized transaction handling without intermediaries, while shifting trust toward technical implementation and facing scalability, energy-use, and complexity limitations.Blockchain data is immutable, but retrieved results must remain deterministic across queriers and times.
- Related Work: Trusted auditing is required for legally binding SLAs, motivating smart-contract approaches that reduce reliance on a single trusted party.Prior work includes smart-contract-based SLA definitions across several blockchain platforms.
- Related Work: Smart-contract SLA lifecycles can cover service discovery and negotiation, deployment, monitoring, billing and penalty enforcement, and termination.Related systems also address fog-node selection and service exploration through smart contracts.
- Related Work: Current monitoring systems struggle with heterogeneous infrastructures, transparency, and reliable historical information, leaving consumers to gather evidence at additional cost.Approaches use centralized or distributed agents but are typically isolated under a single entity.
- Related Work: Existing smart-contract SLA approaches are often conceptual or omit implemented penalty mechanisms and deterministic injection of service metrics.The paper therefore implements SLA definition and penalty triggering for violations.
- Foundations: The research requirements include monitoring multiple providers, avoiding a single point of failure, maintaining confidentiality, avoiding reliance on one participant, ensuring transparency, and supporting scalability.These requirements motivate a distributed monitoring design with effective communication models.
- Foundations: Trust in the system can support automatic dispute settlement based on terms that participants agreed upon earlier.
3 Cloud Monitoring with Smart Contract
The paper proposes a blockchain-based monitoring platform in which smart contracts use service metrics to identify SLA violations and execute penalty payments. The design combines monitoring services, a contract wallet, and deterministic off-chain data access for cloud-service agreements.
- 3 Cloud Monitoring with Smart Contract: Smart contracts process monitoring data and automatically execute penalty payments when cloud-service violations are identified.The blockchain-based platform is designed to replace conventional penalty handling that relies on provider action and trusted payment intermediaries.
- 3 Cloud Monitoring with Smart Contract: A monitoring service supplies performance metrics because smart contracts cannot monitor cloud services directly.Consumers and providers agree on the monitoring service, and multiple services may be used with a rule for resolving contradictory values.
- 3 Cloud Monitoring with Smart Contract: The contract wallet holds prepaid service tokens, returns penalties to consumers after violations, and transfers the remainder to providers at contract end.This arrangement makes the smart contract a neutral payment entity between consumer and provider.
- 3.1 Forming an Agreement: Consumers and providers register SLA terms, monitoring endpoints, wallet addresses, and service fees in a smart contract during subscription.The contract is deployed automatically after SLA acceptance, with service properties and selected metrics shaping its enforcement logic.
- 3 Cloud Monitoring with Smart Contract: Compared with non-blockchain penalty software, the approach provides neutral execution, direct token transfers, immediate payments, and immutable contracts for untrusted parties.For high fees or long contracts, complete upfront prepayment may cause financial strain, motivating agreements to transfer only part of the payment.
- 3.2 Retrieving Data Off-Chain: Oracles provide external service data to smart contracts, and deterministic behavior is required so network participants obtain the same result.Hyperledger-style systems can query trusted third-party services at runtime, while multiple organizations execute the same contract to validate stored data.
4 Implementation
The implementation realizes the monitoring scenario with Hyperledger Fabric, provider-specific monitoring integrations, smart contracts, and a user-facing environment. It retrieves service metrics, compares availability with SLA commitments, and records credits when violations occur.
- Scenario: The system models one consumer and Amazon and Microsoft Azure as providers, with smart contracts instantiated for each cloud service.The consumer uses virtual machines as the traded services, while provider monitoring services act as oracles for the contracts.
- Blockchain environment: The implementation uses a private permissioned blockchain with channels and shared ledgers separating each provider’s service information.Certificates authenticate organizations, and channel policies restrict participation and access to provider-specific data.
- Architecture: The technical architecture consists of smart contracts, monitoring-service integration code, and a core environment providing registration and service-state access.The implementation includes a React interface and APIs for interacting with contracts, while Hyperledger Fabric channels host the contracts and ledgers.
- Monitoring integration: Provider monitoring data are retrieved through service-specific integrations and stored in the ledger for subsequent SLA evaluation.Amazon EC2 metrics use the provider’s Node.js SDK and CloudWatch credentials stored with the registered service; Azure uses its monitoring interface instead.
- Penalty handling: If measured availability falls below the promised availability, the smart contract increases the service credit recorded in the ledger.The logic considers past service states and the promised availability registered for the service.
- Scope and operation: The current implementation supports two service types from two providers and can be extended modularly to additional service types and metrics.New measurements are initiated by the user because smart contracts are not self-executing programs.
5 Findings and Future Work
The system demonstrates decentralized SLA monitoring and penalty management using provider APIs, smart contracts, and Hyperledger Fabric. Findings also identify token, deployment, and multi-service design boundaries for future work.
- Findings: The approach deploys service-specific smart contracts in a self-hosted Hyperledger Fabric network, shared between providers and consumers through private channels.The design supports other providers when APIs expose the required service-performance metrics, but assumes both parties participate in the blockchain network.
- Future Work: The local Docker-based Hyperledger deployment can be difficult to configure because documentation for settings and operations is limited.Managed blockchain-as-a-service offerings from Amazon, Microsoft, and IBM are suggested for future projects.
- Findings: Provider monitoring APIs serve as deterministic oracles, querying current and past service states at one-minute granularity for availability assessment.The implementation uses an AWS JavaScript SDK and an Azure REST API, currently querying only one metric.
- Future Work: The system deploys one smart contract per provider-consumer service type, which supports multiple services from one provider but scales statically across providers and service varieties.A generic service-type registration approach is proposed to reduce contract proliferation and simplify onboarding.
- Findings: SLA violations currently credit consumers through a ledger variable, with future work targeting token transfers between dedicated user wallets.The transfer mechanism would replace ledger-based credit increases and allow consumers to retain the penalty tokens.
- Future Work: Blockchain tokens enable traceable, tamper-resistant compensation, but conversion to global currencies introduces exchange-rate volatility for industrial users.State-supported blockchain networks are identified as one possible way to address this currency risk.
6 Summary and Conclusion
The paper addresses dynamic, heterogeneous cloud markets by using blockchain smart contracts for continuous SLA monitoring and automatic penalties. An IBM Hyperledger Fabric implementation with Amazon and Azure virtual machines demonstrates technical feasibility, while adoption still requires metric unification and predictable token exchange rates.
- Summary and Conclusion: Dynamic cloud markets create heterogeneous infrastructures that complicate service-performance monitoring and increase the need for autonomous, transparent penalty management.Consumers may purchase services ad hoc from potentially unknown providers while remaining exposed to SLA violations and penalties.
- Summary and Conclusion: Smart contracts register traded services, continuously monitor performance, and transfer penalty payments to consumers when violations are identified.The design also supports transparent and reasonable assessment for providers and consumers.
- Summary and Conclusion: An IBM Hyperledger Fabric implementation monitoring Amazon and Azure virtual-machine availability demonstrates the approach’s technical feasibility and generic applicability.The scenario illustrates the design across two cloud providers.
- Summary and Conclusion: Immediate industrial adoption requires unified service-performance metrics and a predictable exchange rate between tokens and global currencies.These requirements are stated as remaining practical conditions for deployment.
Setup of the System
The system setup uses Hyperledger Fabric command-line tools and Docker containers to create a network for university, Amazon, and Azure organizations. Separate channels and smart contracts connect the relevant peers and services.
- Setup of the System: The network is operated through Hyperledger CLI commands collected in sms.sh, which supports up, down, and generate options.The script composes commands for the network and peer nodes.
- Setup of the System: Users must install Hyperledger Fabric prerequisites, generate organization wallets, and configure identity certificates and permissions for SDK access.Wallets authenticate applications to peers and manage transactions, while endorsement policies determine user permissions.
- Setup of the System: Running sms.sh up generates certificates and channel artifacts, starts Docker services, creates two channels, and joins the relevant organization peers.The channels are channel-aws and channel-azure, with the University peer participating in both.
- Setup of the System: The EC2 smart contract is installed and instantiated on the University and AWS peers, while the Azure VM contract is deployed on the University and Azure peers.Each service contract is associated with its corresponding provider channel.
API of the System
The system exposes organization-specific REST APIs for AWS and Azure services, with the University interface covering both provider routes. Separate API addresses support each organization.
- API of the System: A Node.js Express REST API provides AWS routes, Azure routes, or both, depending on the organization operating the interface.The University exposes both service interfaces, while Azure and Amazon expose their respective service routes.
- API of the System: The API defines separate endpoint groups for EC2 instances and Azure virtual machines.The paper presents the endpoint specifications independently for each service type.