A Penalty-Aware Cloud Monitoring System based on Blockchains Christian Dienbauer Benedikt Pittl [email protected] [email protected] University of Vienna University of Vienna Vienna, Austria Vienna, Austria Werner Mach Erich Schikuta [email protected] [email protected] University of Vienna University of Vienna Vienna, Austria Vienna, Austria

ABSTRACT Applications & Services (iiWAS ’20), November 30-December 2, 2020, Chiang Today, traded cloud services are described by service level agree- Mai, Thailand. ACM, New York, NY, USA, 9 pages. https://doi.org/10.1145/ 3428757.3429130 ments that specify the obligations of providers such as availability or reliability. Violations of service level agreements lead to penalty payments. The recent development of prominent cloud platforms 1 INTRODUCTION such as the re-design of Amazon’s spot marketspace underpins a Cloud providers such as Amazon and Azure sell their datacenter trend towards dynamic cloud markets where consumers migrate resources in the form of services. For the description of the services, their services continuously to different marketspaces and providers so-called Service Level Agreements (SLAs) are used [17]. They are to reach a cost-optimum. This leads to a heterogeneous IT infrastruc- specifications that define, inter alia, details about the offered service ture and consequently aggravates the monitoring of the delivered such as availability and reliability. Violations of SLAs lead to penalty service quality. Hence, there is a need for a transparent penalty payments, and so consumers are interested in monitoring the ser- management system, which ensures that consumers automatically vice performance. Therefore, cloud providers such as Amazons offer get penalty payments from providers in case of service violations. monitoring platforms like Amazon Cloudwatch that provide APIs to In the paper at hand, we present a cloud monitoring system that query the performance metrics of the service. Besides, several third- is able to execute penalty payments autonomously. In this regard, party cloud monitoring platforms are existing such as dynatrace1, we revert to smart contracts hosted on blockchains. They contin- datadog2 or AppDynamics3. The vision of a monitoring platform uously monitor cloud services and trigger penalty payments to that also manages penalty payments is still unrivaled [13]. For the consumers in case of service violations. We implemented the pre- establishment of such a platform in industry not only machine- sented approach with the IBM Hyperledger Fabric framework and readable SLAs such as described in [13] are necessary, but also the created a use case with Amazon’s cloud services as well as Azures transparent management of penalty payments has to be ensured. cloud services to illustrate the universal design of the introduced Hence, in the last years, neutral third parties were introduced that approach. are responsible for confirming service violations and transferring penalty payments to consumers [11, 28]. Even such neutral third CCS CONCEPTS party approaches have structural weaknesses as Robert Sams sum- • Information systems → Information systems applications; marizes with three sins [12]: sin of commission, sin of deletion and • Computer systems organization → Architectures. sin of omission. Nowadays, the scientific community reverts to neu- tral consensus finding approaches among untrusted participants KEYWORDS which are technically realized by the blockchain technology. For Cloud Monitoring, Smart Contracts, Cloud Computing example, the authors of [21] introduced an approach for managing and modifying SLA terms with blockchains - penalty management ACM Reference Format: for SLA violations was neglected. Christian Dienbauer, Benedikt Pittl, Werner Mach, and Erich Schikuta. 2020. The paper at hand focuses on the development of a blockchain- A Penalty-Aware Cloud Monitoring System based on Blockchains. In The based, penalty-aware cloud monitoring platform. Thereby we apply 22nd International Conference on Information Integration and Web-based so-called smart contracts, which are programs executed on the Permission to make digital or hard copies of all or part of this work for personal or blockchain. A first step towards such systems was introduced in classroom use is granted without fee provided that copies are not made or distributed the short paper [15] where a pure provider-centric smart contract for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM was introduced - see related work. In contrast to that, the approach must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, introduced in that paper treats a smart contract as a bilateral agree- to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. ment between consumers and providers. Therefore, consumers and iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand © 2020 Association for Computing Machinery. 1https://www.dynatrace.com ACM ISBN 978-1-4503-8922-8/20/11...$15.00 2https://www.datadoghq.com/ https://doi.org/10.1145/3428757.3429130 3https://www.appdynamics.com/ iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand Dienbauer et al. providers have to register the SLAs of the traded cloud services in is queried and regardless of time, the results need to be the same to a smart contract, including corresponding commonly trusted cloud ensure a deterministic behavior of the blockchain. monitoring authorities. The smart contract uses them to monitor Today, most of the monitoring platforms are cloud provider- the performance of the cloud services and automatically transfers specific, limiting the monitoring of heterogeneous IT infrastruc- penalties to the consumer in case of SLA violations. This ensures tures, as can be found in smart city architectures and industry 4.0 [4]. that consumers get penalties immediately for service violations This can enable data-driven applications that require reliable com- while providers can profit from a clear and transparent monitoring munication models to operate more efficiently9 [ ]. Complex cloud approach. The technical feasibility of our approach is demonstrated service compositions are currently hard to monitor with existing by a smart contract deployed on the Hyperledger Fabric Blockchain4 monitoring platforms, and so in [16] a generic framework to moni- that uses arbitrary monitoring services for detecting SLA violations tor the performance of services deployed on different providers is and consequently executing penalty payments. Within this paper, presented. To collect data from the services, the framework suggests we use cloud services as well as monitoring APIs both from Amazon a client-server approach, where agents are deployed together with and from Azure. the service that should be monitored: Those agents can be accessed The remainder of the paper is structured as follows: Founda- by a centralized monitoring platform to retrieve data of a monitored tions and related work are introduced in Section 2. The concept service. A similar approach in the context of edge computing is of the penalty-aware cloud monitoring platform is presented in presented in [4]. There, an architecture divided into management Section 3, followed by an introduction of our implementation with and worker layer is suggested. The management layer provides the IBM Hyperledger Fabric Blockchain, Amazon EC2, and Azure functionalities to measure the activities of the edge nodes in the in Section 4. A discussion about the presented concept is given in network to distribute workloads based on different algorithms. Section 5. The paper closes with a conclusion in Section 6. An approach for monitoring data streams in distributed systems with the focus on communication-efficiency and data privacy can 2 FOUNDATIONS AND RELATED WORK be found in [19]. The system collects information about different This section is structured along two parts. The first part describes components and sets the granularity based on a given threshold by foundations of the blockchain technology. In the second part, re- a centralized monitoring unit. Such centralized monitoring systems lated cloud monitoring approaches are introduced. suffer from a single point of failure and therefore a distributed With the rising popularity of the Bitcoin in mid-2017, the under- agent-based monitoring system to handle multi-tenant service- lying blockchain technology gained in attraction. This technology based systems can be used [27]. As a challenge of service monitoring is not limited to cryptocurrencies and so organizations from various is the system overhead of monitoring tools and so that the collection domains started to identify reliable business models enabled by the of data should be done in a resource-effective manner [23]. blockchain [5]. A typology of emerging blockchain applications To foster the quality of services and the reliability business pro- with regards to the domains where they are applied is presented cesses that are based on those, Service Level Agreements (SLAs) in [8, 29]. Due to the decentralized nature with no need for inter- between a service provider and consumer are defined7 [ ]. As SLAs mediaries, the blockchain technology can handle transactions in are legally binding contracts, they should be audited by an in- different markets and consequently reduces friction costs[5, 6]. stance that is trusted by all participants. While conventional SLA An Economist article, The Trust Machine, considers the blockchain trust models are centrally configured, deployed, and maintained, technology as a solution for establishing trust and the antecedents approaches to define SLAs using smart contracts can be found of trust including confidence, integrity, reliability, responsibility in [1, 7, 14, 18, 20, 25]. A conceptual blockchain-based framework for and predictability [5]. While sometimes blockchains are described SLA management is presented in [1] that gives a general overview as trust-less [2], other authors such as [10] state that there is a shift of this topic and addresses the challenge of trust between all par- of trust from current intermediaries to the technical implementa- ticipants and argues that no single party should have control over tion of blockchain systems. Limitations of the blockchain such as the SLA lifecycle. While in traditional SLA approaches service con- scalability, energy usage, and growing complexity are summarized sumer need to detect abnormalities and check SLA violations this in [24]. While data once stored within a blockchain is immutable, leads to an extensive manual process including personnel and cap- it does not mean that this data is always valid. Therefore, current ital resources [1, 14]. An approach for automated compensation research investigates in incentive-based blockchains to provide data of SLAs based on smart contracts can be found in [18] and com- quality [2]. When a blockchain needs to query data from the outside pare their approach to existing solutions with regards to human- world, it uses so-called oracles. The capabilities of oracles slightly computer interaction. A system architecture in the context of fog differ: For example, Ethereum5 prohibits that smart contracts can computing can be found in [7] that provides IoT client devices query external sources, and so the data needs to be stored within a with the means to explore the best-suited fog nodes via smart con- smart contract first3 [ ]. The smart contract with the injected data tracts by considering the reputation and credibility based on SLA can then be used as an oracle and queried by other smart contracts. requirements. Hyperledger Fabric, as a contrary example, uses general-purpose Current approaches try to address today’s requirements of het- programming languages and allows that data can be retrieved from erogeneous and decentralized infrastructures by agent-based sys- anywhere. Important thereby is, that no matter by whom this data tems with either a centralized unit or a wholly distributed approach and mention the challenges of data privacy and communication 4https://www.ibm.com/blockchain/hyperledger efficiency. Those approaches are usually isolated systems asthe 5https://ethereum.org/ data is subject to a single entity with a lack of transparency. It is A Penalty-Aware Cloud Monitoring System based on Blockchains iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand hard for organizations to get reliable information about the cur- the rest of the paper, the monitoring services are explicitly rent and past state of their IT infrastructure [22]. Consequently, referred to as monitoring services to distinguish them from consumers are forced to implement systems to gather information, the traded cloud service, which is termed service. which results in additional costs and the burden of proofing the • Wallet. lack of quality [1, 14]. The smart contract is a neutral entity that is trusted by both, While approaches exist to define Service Level Agreements us- consumer and provider. To guarantee transparent and fast ing smart contracts without the need to rely on a single party and penalty payments, the smart contract needs a wallet. In- automate the way to identify SLA violations, these approaches are stead of directly transferring the service fee to the provider, either conceptual or lack the implementation of a penalty mech- the consumer has to pay it by transferring tokens8 to the anism. Approaches mentioned in [1, 18] would use Ethereum as smart contract. Those tokens are stored in the wallet of the the underlying blockchain technology but miss the part on how to smart contract. In the case of service violations, tokens are inject service metrics into smart contracts to trigger events while transferred back to the consumer. The remaining tokens are preserving a deterministic behavior of the blockchain. Our goal was transferred to the provider after the contract period expired. to implement a monitoring system for a multiple service provider Figure 1b introduces an exemplary scenario in which a cloud where SLA can be defined. Compared to reviewed approaches we provider hosts the service used by the consumer. The numbers in implemented a mechanism to define SLAs and trigger penalties the following enumeration refer to the numbers in the figure. if those are violated. The authors of [15] introduce a concept of (1) A consumer decided to use a cloud service from a provider a blockchain based cloud monitoring system without a concrete for a certain period of time. For the autonomous penalty implementation. Thereby, the provider creates a smart contract management, the consumer and the provider create a smart that manages a list of consumers - in case of a service violation ser- contract. The provider adds endpoints of the used monitor- vice coins are transferred to consumers. Motivated by the vision of ing services to it. They are used by the smart contract for billing consumers with smart contracts, the role of the consumer monitoring the service performance. The consumer agrees is neglected: it neither has to acknowledge the smart contract nor to use the service by transferring the service fee in the form does it acknowledge the used monitoring services. of tokens to the smart contract. They are stored in the smart contract’s wallet. 3 CLOUD MONITORING WITH SMART (2) The consumer uses the service. The service is monitored by CONTRACT the monitoring services defined in the smart contract. A traditional cloud monitoring scenario is presented in Figure 1a. (3) Service violations detected by the monitoring service are First, the consumer purchases a service from a provider (1) then accessible for the smart contract. If multiple monitoring both, consumer and provider use services to monitor the perfor- services are used, the smart contract has to resolve contra- mance of traded service (2). As soon as the consumer observes a dictory results to determine if a service violation occurred. service violation, it claims a penalty payment from the provider This conflict resolution is part of the smart contract, soboth (3). Finally, the provider transfers the penalty payments to the con- the consumer and the provider are aware of it. sumers’ bank (4). The traditional monitoring scenario comes with (4) If the smart contract detects a service violation, it automati- two drawbacks: First, the identification of a service violation can cally transfers penalty payments from its wallet to the con- lead to contradictions results as both, the consumer and the provider sumer. After the contract period between consumers and could use separate monitoring services. Second, the scenario re- providers expired, the remaining tokens in the wallet of the quires a trusted third party such as the bank which is responsible smart contract are transferred to the provider. If no service transferring penalty payments. violations occur, all tokens representing the service fee are To tackle those issues the paper introduces a cloud monitoring transferred to the provider. system based on blockchains. It uses smart contracts that are respon- The introduced approach has several benefits over approaches sible for processing data from monitoring services and executing where non-blockchain based software solutions are employed for penalty payments in case of identified cloud service violations. The penalty management. (i) First of all, smart contracts are deployed following two parts are essential for such a smart contract. and executed on the blockchain and consequently on a neutral plat- • Monitoring Service. form while typical software solutions have to be hosted on a server. A smart contract cannot monitor the cloud service directly. There, the availability, as well as the execution, are not guaranteed. Therefore, it has to make use of a monitoring service that (ii) Further, smart contracts are participants of the blockchains, returns performance metrics. Such services are offered by which means that they can send and receive tokens such as money. cloud providers such as Amazon6 but also by independent For the realization of non-blockchain based software, a trusted monitoring service providers such as datadoghq7. Both, the third party such as a bank would be necessary. (iii) Trusted third consumer and the provider have to agree on the selected parties charge fees and require time for executing payments. On the monitoring service. Even multiple monitoring services could blockchain, these fees for trusted third parties are not relevant. The be used in parallel, whereby the smart contract has to decide consumer gets penalty payments automatically and immediately which value is used in the case of contradictory results. In on detected service violations. (iv) Smart contracts are immutable, which means that the code cannot be modified after it is deployed 6https://aws.amazon.com/de/cloudwatch/ 7https://www.datadoghq.com 8tokens could be money but also other trade-able entities iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand Dienbauer et al.

(a) Traditional cloud monitoring scenario (b) Blockchain-based cloud monitoring scenario

Figure 1: Cloud monitoring scenarios and so the approach is appropriate for untrusted consumers and Peer Nodes, or short peers, are a fundamental part of a blockchain providers. network and inherit a cryptographic identity given by a certificate The consumers have to transfer the service fee upfront to the authority. With this identity, peers can be authenticated in the smart contract. This implies that the consumer has to pre-pay the network and, with regards to the endorsement policy, join certain complete service fee while the provider gets the remaining service channels. A channel is a sub-net of the blockchain network and fee at the end of the contract period. Especially for high service fees enables private communication between peers. Members of the or long contract periods, this might cause financial embarrassment. channel share a distributed ledger to store confidential transactions. In such cases, the consumer and the provider could agree to transfer Smart contracts are deployed on channels and can be executed by only parts of the payments to the smart contract. its peers to interact with the ledger. In our example, the service con- sumer shares a separate ledger with each provider. Each participant 4 IMPLEMENTATION deploys a graphical user interface and an API via a docker-compose This section introduces the implementation of the scenario that is file in its environment. Communication with the participants ofthe shown in Figure 2. It distinguishes between three organizations: network is only done via smart contracts. two cloud service providers and one consumer. In the scenario, one • Smart Contract. service provider is Amazon, the other service provider is Microsoft For the implementation of the smart contracts we decided Azure. The consumer uses a virtual machine, which represents the to use JavaScript, as Hyperledger Fabric officially supports traded cloud service, from both providers. For each cloud service, a an SDK for Node.js. If a consumer would consume multiple smart contract is instantiated. It has access to a monitoring service services from a provider, one smart contract is sufficient as that is hosted by the corresponding provider. Those monitoring ser- it can handle multiple services of the same type by linking vices act as oracles for the smart contract and enable a deterministic the measurements to a single instance via a unique service behavior of the states in the blockchain. key. In Listing 1 an excerpt of a smart contract is shown Different blockchain technologies can be used for the implemen- for retrieving measurements. The credentials are stored in tation of the scenario. For the selection of appropriate blockchain the ledger and will be used for querying the Amazon EC2 technology to implement the envisioned penalty-aware cloud mon- Oracle. itoring platform, we considered the blockchain-selection guide- line [26]. As the participants’ identities will be established before Listing 1: Retrieve data from oracle based on service key purchasing a service and data of services does not need to be pub- async updateService(ctx, serviceKey, startTime, endTime) { licly verified, we decided to use a private permissioned blockchain. A private permissioned blockchain will guarantee that service data const serviceAsBytes = await ctx.stub.getState(serviceKey); will only be accessible for the users specified in an endorsement if (!serviceAsBytes || serviceAsBytes.length === 0) { policy: In the implemented scenario these are the service provider throw new Error(`${serviceKey} does not exist`); and the consumer. Transaction fees for processing data are not } relevant for private blockchains. For the presented use-case we let service = JSON.parse(serviceAsBytes.toString()); used the Hyperledger Fabric framework9, which supports the us- ... age of general-purpose programming language for writing smart // query the oracle contracts, or chaincode as they call them, to implement any con- service.data = await this.getMetricsDataEC2( ceivable logic. service.accessKeyId, Figure 3 shows the technical architecture of the implemented service.secretAccessKey, scenario. It consists of the smart contracts, monitoring service service.region, integration code and the core environment, which are described in the following section. service.dimensionName, service.dimensionValue, 9https://www.hyperledger.org/use/fabric startTime, A Penalty-Aware Cloud Monitoring System based on Blockchains iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand

Figure 2: Scenario of the cloud monitoring system

Figure 3: Technical architecture of the cloud monitoring system

endTime // give credit if availability is to low ); if (currentAvailability < service.promisedAvailability) { // calculate availability service.credit += PENALTY_AMOUNT; if (service.cpuUtilization >= 0) { } service.timesAvailable += 1; await ctx.stub.putState( console.log("Connection good"); service.name, } else { Buffer.from(JSON.stringify(service))); service.timesNotAvailable += 1; • Monitoring Service Integration. console.log("No connection"); The smart contracts require access to the monitoring ser- } vices. In blockchain-environments, accessing such external ... services is technically challenging: The Node.js SDK provided by Amazon is used to retrieve metrics of the service form iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand Dienbauer et al.

their monitoring tool Cloudwatch. When a service is regis- types as well as a variety of service metrics that are provided by the tered to our monitoring system, an unique service key with oracles. All this information can then be used to define SLAs via all the necessary information to retrieve metrics from Cloud- the monitoring system. If an SLA agreement is violated, the current watch, is stored within the ledger. This enables retrieving approach will trigger a penalty by increasing the credit of variables information from Cloudwatch and storing the information within the ledger that is shared between the service provider and into the ledger running purely inside a smart contract by the consumer. To change the value of this variable a predefined just passing the service key for identification. logic within the smart contract is used that considers all the past An update function is used to retrieve the information about states of service as well as the promised availability passed on the the service metrics of the latest time interval. At the regis- registration of the service in the system. As smart contracts are not tration of a service, in our system, the availability promised self-executable programs, the process of retrieving new states of a by the service provider is passed as a parameter and stored service needs to be started by the user. Currently, this is done via together with the credentials and information of the service a button in the user interface but can be automated using a cron in the ledger. As the update function queries the informa- job. For this purpose, we created a RESt API as it was necessary to tion about the service from Cloudwatch we see from the implement the JavaScript SDK to interact with the smart contracts. response if a service is available or not. Within the smart The first attempt of using the SDK within the React application led contract we mark this requested interval as either available to importing errors as the JavaScript standard used by React (ES6) or unavailable and compare it to the total run-time of the did not match with the standard used by the SDK (ES5). In listing 2 service. If a service’s downtime exceeds the promised avail- shows the endpoint of the API that is used by the frontend, or a cron ability of a service provider, the customer will receive a job, to query the smart contract to retrieve new states of service. certain amount of credit for this service. This credit can then The user interface is deployed locally without any direct connection be used as an offset during settlement. As smart contracts to the internet. All the information that is shown is retrieved from are not self-executable programs, the update function needs the blockchain network by using smart contracts. In Figure 4 a to be requested from outside of the network. To prevent a form can be seen to register new services to the system. As in our user from requesting the service’s status for the same time scenario, Univie has used services from Amazon and Microsoft, and interval twice, the smart contracts check at each request of can choose between two registration forms. This form contains the update function if the time of the last state in the ledger information for authentication to the oracles as well as information will not overlap with the times in the request. about the SLA. If the entered information is correct, the credentials The same logic is used for the implementation of the smart will be stored in a smart contract. Underneath the form, a list of all contract for Azure VM services. registered services of a provider can be seen. When clicking on the services, the details page of the service 5 opens: Here a user can • Core Environment. see information about the retrieved measurements of the service. To provide users of the system a convenient way to register By clicking on the button, new measurements can be retrieved. If services and explore their current and past state together the service is more often unreachable than promised, the customer with actual availability and possible credits, we created a will receive a credit. graphical user interface with React. We developed a REST API which uses the SDK to interact with the blockchain Listing 2: API that implements the application SDK for in- network and provides endpoints that can be requested by teracting with the smart meters the React application. This API has another advantage as it can be used by a cron job, to automatically query the latest app.put('/aws/services/:serviceKey', async (req, res) => { states of a registered service. console.log(req.body) A reference to the complete script to reproduce the created setup let serviceKey = JSON.parse(req.params.serviceKey) can be found on GitHub10.The most important contents of the script are as follows: const gateway = new Gateway() (1) Generate x.509 certificates, (2) Configuration of the channels, (3) Creation of the peer nodes, try { (4) Joining the peers to the channels, and console.log('CONNECT TO NETWORK') (5) Instantiating the smart contracts in the channels await gateway.connect(connectionProfile, connectionOptions) The current implementation of the monitoring service is capable const network = await gateway.getNetwork('channel−aws') of retrieving information about two service types of two different const contract = network.getContract('ec2contract') service providers. To proof the feasibility of integrating service level agreement we started with the implementation of the promised const endTime = new Date() availability that is passed to the system on the registration process. const startTime = new Date(endTime.getTime() − 30 ∗ 60000) Though, as this logic is deployed via smart contracts the system can be extended in a modular manner to support additional service await contract.submitTransaction( 10https://github.com/dieni/blockchain-based-cloud-monitoring 'updateService', A Penalty-Aware Cloud Monitoring System based on Blockchains iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand

serviceKey, of a request will be done by a single node and the results startTime.toISOString(), distributed through the network. To prevent the owner of a endTime.toISOString() node making changes to the request, the oracle might sign ) the reply with its private key so that other nodes can verify the validity of the data. • Multiple service types. console.log('SERVICE UPDATED') We decided to deploy one smart contract between a ser- } finally { vice provider and consumer for each service type. This en- // Disconnect from the gateway ables a consumer to monitor multiple services from the same console.log('Disconnect from Fabric gateway.') provider using a single smart contract. It should be inves- gateway.disconnect() tigated how to enable the monitoring of multiple services } from different types between a service provider and con- }) sumer. One approach would be to use one smart contract for each additional service type that should be monitored. 5 DISCUSSION AND FUTURE WORK Resulting in very static design and a large number of smart contracts when supporting several service providers where This paper is part of a research project aiming on using blockchain each provides a variety of services. In a generic approach of technology for monitoring services of different service providers. registering different service types should be investigated to Thereby, we aim on a decentralized architecture to enable penalty limit the number of smart contracts and have a more flex- payments if service level agreements are violated. This concept was ible way of onboarding new service providers with there realized with the presented implementation, where for each service services. type a smart contract was deployed in a self hosted Hyplerledger • Service Level Agreements. Fabric network and shared between service provider and consumer For this project, we used a single metric to determine the via private channels. However, the design of the implemented ap- availability of the service and compared it to the promised proach would work for any other provider as long as an API is availability from the service provider which was defined on existing that returns the required service performance metrics. the registration process. On each request to an oracle, the • Hyperledger Fabric Network. state of the service was compared with all past events. As The network was created using the CLI tools provided by smart contracts are not self-executable, we had to consider Hyperledger and deployed locally running the components that requests are not made twice for the same time interval. within docker containers. Hyperledger provides via docker We solved this by checking the last time interval stored in hub the containers for all necessary components to run a net- the ledger before retrieving new measurements from the work. Though, the configuration of the network can be quite oracle. For more sophisticated SLA’s we need to consider difficult as documentation about different settings and oper- more metrics for the service providers and let the users define ations is quite rare. A recommended approach for a future the appropriate levels for those. The best case would be to project is to use Blockchain as a service. Service providers combine this task with a generic approach to registering like Amazon AWS, Microsoft Azure, or IBM provide man- services. aged Blockchains to set up a network within a short amount • Penalty Payments. of time. If there is a violation of the SLA’s, a predefined amount • Smart Contracts. is credited to the consumer. This is currently done via a With the use of a general-purpose programming language, variable stored in the ledger that can only be modified based the development of a smart contract is nothing out of the on the retrieved metrics from the oracles. While the credit ordinary. Hyperledger Fabric supports a chaincode SDK for can be considered when creating the invoice, we aim for JavaScript that enables a convenient interaction with the an independent process of transferring funds between the ledger using a so-called transaction context. Other languages users. One approach is to define a penalty token that will be are supported too. Packages can be used without any restric- transferred between the users if SLA’s are violated. Therefore tions. One thing to keep in mind when developing smart we need to replace the logic of increasing the variable with contracts is, that each operation needs to follow a determin- the mechanism to trigger the transfer. The tokens need to be istic behavior. This is necessary that nodes of the network transferred between wallets dedicated to the users to give reach consensus and the states in the ledger are reproducible. them the possibility to have them at one’s disposal later. • Oracles. • Tokens. For the deterministic behavior of the system, we use the mon- Usually, in blockchain networks tokens such as Bitcoins are itoring tools of the service provider as our oracles. Amazon transferred instead of money. They represent compensation as well as Microsoft provides a sophisticated API to query of money and can be transferred and traced in a tamper- current and past states of services based on different metrics. resistant manner. Especially the ability of smart contracts to For AWS we used a JavaScript SDK and for Azure a Rest API. transfer tokens in the program code enables the implementa- Both methods work like intended and can be used to query tion of the introduced monitoring system. On the contrary, information in granularity of one minute. The execution iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand Dienbauer et al.

Figure 4: Registration page of a cloud service that should be monitored by the smart contract deployed on the Hyperledger Fabric Network

Figure 5: Service details page that show the current status of the monitored service - the same information is retrieved by the smart contract A Penalty-Aware Cloud Monitoring System based on Blockchains iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand

if consumers and provider do not execute any other trans- Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems, actions in that blockchain network they have to exchange CHI 2018, Montreal, QC, Canada, April 21-26, 2018. 458. [9] Xiaolin Jiang, Carlo Fischione, and Zhibo Pang. 2017. Poster: Low Latency them for global currencies such as Dollars or Euros. Espe- Networking for Industry 4.0. In Proceedings of the 2017 International Conference on cially for industrial use-cases this comes with currency risks Embedded Wireless Systems and Networks, EWSN 2017, Uppsala, Sweden, February 20-22, 2017. 212–213. as the exchange rate is volatile. State supported Blockchain [10] Olga Labazova, Tobias Dehling, and Ali Sunyaev. 2019. From Hype to Reality: A networks could help to tackle that issue. Taxonomy of Blockchain Applications. In 52nd Hawaii International Conference on System Sciences, HICSS 2019, Grand Wailea, Maui, Hawaii, USA, January 8-11, 2019. 1–10. 6 CONCLUSION [11] Adil Maarouf, Youssef Mifrah, Abderrahim Marzouk, and Abdelkrim Haqiq. 2018. An Autonomic SLA Monitoring Framework Managed by Trusted Third Party in The trend towards dynamic cloud markets where consumers pur- the Cloud Computing. IJCAC 8, 2 (2018), 66–95. chase cloud services from various providers in an ad-hoc manner [12] Michael Mainelli, Mike Smith, et al. 2015. Sharing ledgers for sharing economies: leads to heterogeneous IT-infrastructures. Consumers have to en- an exploration of mutual distributed ledgers (aka blockchain technology). The Journal of Financial Perspectives 3, 3 (2015), 38–69. sure that the service performance conforms to the published service [13] Hiroki Nakashima and Mikio Aoyama. 2017. An Automation Method of SLA specification as violations might lead to penalty payments. Withan Contract of Web APIs and Its Platform Based on Blockchain Concept. In IEEE increasing number of potentially unknown service providers the International Conference on Cognitive Computing, ICCC 2017, Honolulu, HI, USA, June 25-30, 2017. 32–39. https://doi.org/10.1109/IEEE.ICCC.2017.12 penalty management becomes a relevant issue for consumers which [14] Hiroki Nakashima and Mikio Aoyama. 2017. An automation method of sla raises the need of an autonomous penalty-aware cloud monitoring contract of web apis and its platform based on blockchain concept. In 2017 IEEE International Conference on Cognitive Computing (ICCC). IEEE, 32–39. system that ensures transparent penalty management in case of [15] Nils Neidhardt, Carsten Köhler, and Markus Nüttgens. 2018. Cloud Service Billing service violations. and Service Level Agreement Monitoring based on Blockchain. In Proceedings of In the presented paper, we applied blockchain technology for the the 9th International Workshop on Enterprise Modeling and Information Systems Architectures, Rostock, Germany, May 24th - 25th, 2018. 65–69. http://ceur-ws. realization towards such a monitoring system: Traded cloud service org/Vol-2097/paper11.pdf are registered in a smart contract which continuously monitors the [16] Ayman Noor, Devki Nandan Jha, Karan Mitra, Prem Prakash Jayaraman, Arthur performance of the traded cloud service. As soon as a service vio- Souza, Rajiv Ranjan, and Schahram Dustdar. 2019. A Framework for Monitoring Microservice-Oriented Cloud Applications in Heterogeneous Virtualization En- lation is identified, the smart contract transfers penalty payments vironments. In 12th IEEE International Conference on Cloud Computing, CLOUD to the consumer. Consumers profit from an autonomous transfer 2019, Milan, Italy, July 8-13, 2019. 156–163. [17] Benedikt Pittl, Werner Mach, and Erich Schikuta. 2016. A classification of au- of penalty payments while providers profit from a transparent and tonomous bilateral cloud SLA negotiation strategies. In Proceedings of the 18th reasonable assessment of services. Due to the management of the International Conference on Information Integration and Web-based Applications penalty payments in the smart contracts correct payoffs are ensured and Services, iiWAS 2016, Singapore, November 28-30, 2016. 379–388. [18] Eder John Scheid and Burkhard Stiller. 2018. Automatic SLA Compensation based for both, the provider and the consumer. on Smart Contracts. Technical Report. Technical Report No. IFI-2018.02, April. To proof the technical feasibility of the approach, the penalty- [19] Jingchao Sun, Rui Zhang, Jinxue Zhang, and Yanchao Zhang. 2016. PriStream: aware cloud monitoring system was implemented with the IBM Privacy-preserving distributed stream monitoring of thresholded PERCENTILE statistics. In 35th Annual IEEE International Conference on Computer Communica- Hyperledger Fabric framework. The implemented scenario, where tions, INFOCOM 2016, San Francisco, CA, USA, April 10-14, 2016. 1–9. the availability of the virtual machines from Amazon and Azure [20] Rafael Brundo Uriarte, Rocco De Nicola, and Kyriakos Kritikos. 2018. Towards distributed sla management with smart contracts and blockchain. In 2018 IEEE was monitored, illustrates the generic applicability of the intro- International Conference on Cloud Computing Technology and Science (CloudCom). duced approach. For adoption in industry a unification of service IEEE, 266–271. performance metrics is necessary as well as a predictable exchange [21] Rafael Brundo Uriarte, Rocco De Nicola, and Kyriakos Kritikos. 2018. Towards Distributed SLA Management with Smart Contracts and Blockchain. In 2018 IEEE rate for tokens to global currencies. International Conference on Cloud Computing Technology and Science, CloudCom 2018, Nicosia, Cyprus, December 10-13, 2018. 266–271. https://doi.org/10.1109/ CloudCom2018.2018.00059 REFERENCES [22] Gottfried Vossen, Till Haselmann, and Thomas Hoeren. 2012. Cloud Computing [1] Ali Alzubaidi, Ellis Solaiman, Pankesh Patel, and Karan Mitra. 2019. Blockchain- für Unternehmen. Technische, wirtschaftliche, rechtliche und organisatorische based SLA Management in the Context of IoT. IT Professional 21, 4 (2019), 33–40. Aspekte. dpunkt, Heidelberg (2012). [2] Andreas Auinger and René Riedl. 2018. Blockchain and Trust: Refuting Some [23] Yanchun Wang, Qiang He, Dayong Ye, and Yun Yang. 2017. Formulating Widely-held Misconceptions. In Proceedings of the International Conference on Criticality-Based Cost-Effective Monitoring Strategies for Multi-Tenant Service- Information Systems - Bridging the Internet of People, Data, and Things, ICIS 2018, Based Systems. In 2017 IEEE International Conference on Web Services, ICWS 2017, San Francisco, CA, USA, December 13-16, 2018. Honolulu, HI, USA, June 25-30, 2017. 325–332. [3] Massimo Bartoletti and Livio Pompianu. 2017. An empirical analysis of smart [24] A. Welfare. 2019. Commercializing Blockchain: Strategic Applications in the Real contracts: platforms, applications, and design patterns. In International conference World. Wiley. on financial cryptography and data security. Springer, 494–509. [25] Amir Teshome Wonjiga, Sean Peisert, Louis Rilling, and Christine Morin. 2019. [4] Timo Bayer, Lothar Moedel, and Christoph Reich. 2019. A Fog-Cloud Computing Blockchain as a trusted component in cloud SLA verification. In Proceedings Infrastructure for Condition Monitoring and Distributing Industry 4.0 Services. of the 12th IEEE/ACM International Conference on Utility and Cloud Computing In Proceedings of the 9th International Conference on Cloud Computing and Services Companion. 93–100. Science, CLOSER 2019, Heraklion, Crete, Greece, May 2-4, 2019, Víctor Méndez [26] Karl Wüst and Arthur Gervais. 2018. Do you need a Blockchain?. In 2018 Crypto Muñoz, Donald Ferguson, Markus Helfert, and Claus Pahl (Eds.). SciTePress, Valley Conference on Blockchain Technology (CVCBT). IEEE, 45–54. 233–240. [27] Dayong Ye, Qiang He, Yanchun Wang, and Yun Yang. 2017. An Agent-Based [5] Roman Beck. 2018. Beyond bitcoin: The rise of blockchain world. Computer 51, Decentralised Service Monitoring Approach in Multi-Tenant Service-Based Sys- 2 (2018), 54–58. tems. In 2017 IEEE International Conference on Web Services, ICWS 2017, Honolulu, [6] Michael Crosby, Pradan Pattanayak, Sanjeev Verma, Vignesh Kalyanaraman, et al. HI, USA, June 25-30, 2017. 204–211. 2016. Blockchain technology: Beyond bitcoin. Applied Innovation 2, 6-10 (2016), [28] Yanru Zhang, Xiang-Yang Li, and Zhu Han. 2017. Third Party Auditing for Service 71. Assurance in Cloud Computing. In 2017 IEEE Global Communications Conference, [7] Mazin Debe, Khaled Salah, Muhammad Habib Ur Rehman, and Davor Svetinovic. GLOBECOM 2017, Singapore, December 4-8, 2017. 1–6. 2019. IoT public fog nodes reputation system: A decentralized solution using [29] Zibin Zheng, Shaoan Xie, Hong-Ning Dai, Xiangping Chen, and Huaimin Wang. Ethereum blockchain. IEEE Access 7 (2019), 178082–178093. 2018. Blockchain challenges and opportunities: A survey. International Journal [8] Chris Elsden, Arthi Manohar, Jo Briggs, Mike Harding, Chris Speed, and John of Web and Grid Services 14, 4 (2018), 352–375. Vines. 2018. Making Sense of Blockchain Applications: A Typology for HCI. In