Table of Links Abstract and 1 Introduction 2 Background and Motivation 2.1 Decentralized Computing Infrastructure and Cloud 2.2 Advantages of DeFaaS 2.3 System Requirements 3 Overview of DeFaaS 4 Detailed Design of DeFaaS and 4.1 Decentralized Scheduling and Load Balancing 4.2 Decentralized Event Distribution 4.3 API Registration and Access Control 4.4 OAuth2.0 Support 4.5 Logging and Billing and 4.6 Trust Management 4.7 Supporting Multi-Cloud Service Mesh 5 Implementation and Evaluation 5.1 Implementations 5.2 Experiments 5.3 Evaluation 6 Related Work 7 Conclusions and References 4.5 Logging and Billing Our platform enables decentralized logging for the services in multi-cloud data centers. For performance reason, instead of on-chain logging, the decision is to use off-chain logging. It is preferred to use decentralized logging infrastructure. Fortunately, IPFS [Benet(2014)] has been proposed and experimented in the past as decentralized logging infrastructure[3]. The API gateway nodes and API end-point providers may bill the users. For billing, the gateway nodes can keep track of the number of requests from each user, success and response for each request including function execution triggered by the events, and the involved end-point providers. Later, the gateway nodes can bill the users by sending requests and receipts to the management blockchain. If an end-point is offered as a service, the gateway nodes can bill the users on behalf of the end-point providers. For performance reasons, billing is not at per request level. The gateway nodes can accumulate statistics, and bill the users when the amount reaches certain threshold or when the time interval reaches a billing cycle (e.g., a month). This means that billing is asynchronous. Such design significantly reduces the overhead comparing with the alternative that requires on-chain payment transaction for each API call. Users need to provide wallet address and/or make deposit to the management blockchain. For instance, a user may deposit USDC to a designated smart contract first for the next billing cycle[4]. The gateway nodes keep a cache of each user’s balance. To avoid negative balance, gateway nodes can use a watermark value. When the accumulated bill reaches the watermark, it will send a billing receipt to the management chain. On the other hand, in order to prevent a gateway node from overcharging the user, the system requires the gateway node to keep a copy of processed requests. Each request includes a nonce and the user creates a digital signature on the request. Therefore, the gateway node cannot create fake requests and the user cannot deny a submitted request. 4.6 Trust Management Trust management is necessary for a decentralized system. Some of the main entities involved in the system include: cloud providers, API gateway nodes, FaaS end-point providers, blockchain nodes, and users. As described earlier, cloud providers are somewhat trusted. Note that in our current design, FaaS is mainly for off-chain applications and off-chain processing. The management blockchain (Besu) can be Proof-of-Stake based. Trust management of other entities like gateway nodes and end-point providers can be stake based, reputation based or a hybrid combining stake and reputation. For instance, staking can be required for the gateway nodes. Entities that deviate from the protocol or act maliciously can be penalized (e.g., slashing). To minimize impact to performance, dispute resolution based process can be applied. The system stores all the API calls and responses in decentralized logs. When there is a dispute, a user can raise a claim against either the involved gateway node or end-point service provider. Then on-chain governance can be used to resolve the dispute. Such mechanism can be found in many blockchain projects like blockchain insurance and on-chain governance of protocol participants. 4.7 Supporting Multi-Cloud Service Mesh The concept of service mesh [Li et al.(2019)] is an extension of micro service. With service mesh, a group of micro services are connected to form a processing pipeline. Existing design and implementation of service mesh adopts the idea of software-defined network (SDN) to separate common functions and service specific functions. This separation greatly improves micro services from various perspectives, such as efficient management and flexible deployment. However, existing service mesh architecture does not support multi-cloud. This greatly limits the use and adoption of service mesh when an application relies on micro services that belong to multiple cloud service providers. DeFaaS provides all the essential functions to support service mesh cross multiple cloud service providers. From architecture perspective, the DeFaaS management blockchain serves as the coordinator of multiple control planes. These control planes are managed by different cloud service providers, and each of them manages its own service mesh. When a request is sent to a service provider, but its corresponding control plane cannot resolve corresponding information, it can query the management blockchain. Authors:
(1) Rabimba Karanjai, Department of Computer Science, University of Houston (rkaranjai@uh.edu);
(2) Lei Xu, Department of Computer Science, Kent State University;
(3) Lin Chen, Department of Computer Science, Texas Texh University;
(4) Nour Diallo, Department of Computer Science, University Of Houston;
(5) Weidong Shi, Department of Computer Science, University Of Houston. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. [3] To protect confidentiality, logs are encrypted when stored over IPFS. [4] Note that this step may involve cross-chain transactions. Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Background and Motivation 2.1 Decentralized Computing Infrastructure and Cloud 2.1 Decentralized Computing Infrastructure and Cloud 2.2 Advantages of DeFaaS 2.2 Advantages of DeFaaS 2.3 System Requirements 2.3 System Requirements 3 Overview of DeFaaS 3 Overview of DeFaaS 4 Detailed Design of DeFaaS and 4.1 Decentralized Scheduling and Load Balancing 4 Detailed Design of DeFaaS and 4.1 Decentralized Scheduling and Load Balancing 4.2 Decentralized Event Distribution 4.2 Decentralized Event Distribution 4.3 API Registration and Access Control 4.3 API Registration and Access Control 4.4 OAuth2.0 Support 4.4 OAuth2.0 Support 4.5 Logging and Billing and 4.6 Trust Management 4.5 Logging and Billing and 4.6 Trust Management 4.7 Supporting Multi-Cloud Service Mesh 4.7 Supporting Multi-Cloud Service Mesh 5 Implementation and Evaluation 5.1 Implementations 5.1 Implementations 5.2 Experiments 5.2 Experiments 5.3 Evaluation 5.3 Evaluation 6 Related Work 6 Related Work 7 Conclusions and References 7 Conclusions and References 4.5 Logging and Billing Our platform enables decentralized logging for the services in multi-cloud data centers. For performance reason, instead of on-chain logging, the decision is to use off-chain logging. It is preferred to use decentralized logging infrastructure. Fortunately, IPFS [Benet(2014)] has been proposed and experimented in the past as decentralized logging infrastructure[3]. The API gateway nodes and API end-point providers may bill the users. For billing, the gateway nodes can keep track of the number of requests from each user, success and response for each request including function execution triggered by the events, and the involved end-point providers. Later, the gateway nodes can bill the users by sending requests and receipts to the management blockchain. If an end-point is offered as a service, the gateway nodes can bill the users on behalf of the end-point providers. For performance reasons, billing is not at per request level. The gateway nodes can accumulate statistics, and bill the users when the amount reaches certain threshold or when the time interval reaches a billing cycle (e.g., a month). This means that billing is asynchronous. Such design significantly reduces the overhead comparing with the alternative that requires on-chain payment transaction for each API call. Users need to provide wallet address and/or make deposit to the management blockchain. For instance, a user may deposit USDC to a designated smart contract first for the next billing cycle[4]. The gateway nodes keep a cache of each user’s balance. To avoid negative balance, gateway nodes can use a watermark value. When the accumulated bill reaches the watermark, it will send a billing receipt to the management chain. On the other hand, in order to prevent a gateway node from overcharging the user, the system requires the gateway node to keep a copy of processed requests. Each request includes a nonce and the user creates a digital signature on the request. Therefore, the gateway node cannot create fake requests and the user cannot deny a submitted request. 4.6 Trust Management Trust management is necessary for a decentralized system. Some of the main entities involved in the system include: cloud providers, API gateway nodes, FaaS end-point providers, blockchain nodes, and users. As described earlier, cloud providers are somewhat trusted. Note that in our current design, FaaS is mainly for off-chain applications and off-chain processing. The management blockchain (Besu) can be Proof-of-Stake based. Trust management of other entities like gateway nodes and end-point providers can be stake based, reputation based or a hybrid combining stake and reputation. For instance, staking can be required for the gateway nodes. Entities that deviate from the protocol or act maliciously can be penalized (e.g., slashing). To minimize impact to performance, dispute resolution based process can be applied. The system stores all the API calls and responses in decentralized logs. When there is a dispute, a user can raise a claim against either the involved gateway node or end-point service provider. Then on-chain governance can be used to resolve the dispute. Such mechanism can be found in many blockchain projects like blockchain insurance and on-chain governance of protocol participants. cloud providers, API gateway nodes, FaaS end-point providers, blockchain nodes, and users. 4.7 Supporting Multi-Cloud Service Mesh The concept of service mesh [Li et al.(2019)] is an extension of micro service. With service mesh, a group of micro services are connected to form a processing pipeline. Existing design and implementation of service mesh adopts the idea of software-defined network (SDN) to separate common functions and service specific functions. This separation greatly improves micro services from various perspectives, such as efficient management and flexible deployment. However, existing service mesh architecture does not support multi-cloud. This greatly limits the use and adoption of service mesh when an application relies on micro services that belong to multiple cloud service providers. DeFaaS provides all the essential functions to support service mesh cross multiple cloud service providers. From architecture perspective, the DeFaaS management blockchain serves as the coordinator of multiple control planes. These control planes are managed by different cloud service providers, and each of them manages its own service mesh. When a request is sent to a service provider, but its corresponding control plane cannot resolve corresponding information, it can query the management blockchain. Authors: (1) Rabimba Karanjai, Department of Computer Science, University of Houston (rkaranjai@uh.edu); (2) Lei Xu, Department of Computer Science, Kent State University; (3) Lin Chen, Department of Computer Science, Texas Texh University; (4) Nour Diallo, Department of Computer Science, University Of Houston; (5) Weidong Shi, Department of Computer Science, University Of Houston. Authors: Authors: (1) Rabimba Karanjai, Department of Computer Science, University of Houston (rkaranjai@uh.edu); (2) Lei Xu, Department of Computer Science, Kent State University; (3) Lin Chen, Department of Computer Science, Texas Texh University; (4) Nour Diallo, Department of Computer Science, University Of Houston; (5) Weidong Shi, Department of Computer Science, University Of Houston. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv available on arxiv [3] To protect confidentiality, logs are encrypted when stored over IPFS. [4] Note that this step may involve cross-chain transactions.

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

How DeFaaS Makes Cloud Functions Work Across Multiple Providers

Understanding Decentralized Event Distribution

Blockchainize.TECH

Too Long; Didn't Read

CTA: Download the FREE AI Productivity Shift report

What Makes DeFaaS a Game Changer in Multi-Cloud Service Coordination?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Optimizing NFT Experiences: Insights from Performance & Usability Studies

The Metaverse - Opportunities and Challenges

Exploring Blockchain Use Cases in Solving Agricultural Distress

Win Your Share of 15,000 USDT in the Spacecoin Writing Contest by Spacecoin and HackerNoon

Why the Blockchain Struggles to Grow and How to Fix It

Optimizing NFT Experiences: Insights from Performance & Usability Studies

The Metaverse - Opportunities and Challenges

Exploring Blockchain Use Cases in Solving Agricultural Distress

Win Your Share of 15,000 USDT in the Spacecoin Writing Contest by Spacecoin and HackerNoon

Why the Blockchain Struggles to Grow and How to Fix It

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps