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

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.

[3] To protect confidentiality, logs are encrypted when stored over IPFS.

[4] Note that this step may involve cross-chain transactions.