BLOCKCHAIN FOR INTERNET OF THINGS

HCloud: A Trusted JointCloud Serverless Platform for

IoT Systems with Blockchain
Zheng Huang, Zeyu Mi, Zhichao Hua*
Institute of Parallel and Distributed Systems, Shanghai Jiao Tong University, Shanghai 200240, China
* The corresponding author, email: [email protected]

Abstract: Cloud computing has been exploit- our system can neither fake the cloud status nor
ed in managing large-scale IoT systems. IoT wrongly dispatch the target functions. We have
cloud servers usually handle a large number implemented a prototype of HCloud and evalu-
of requests from various IoT devices. Due to ated it by simulating multiple cloud providers.
the fluctuant and heavy workload, the servers The evaluation results show that HCloud can
require the cloud to provide high scalability, greatly improve the performance of serverless
stable performance, low price and necessary workloads with negligible costs.
functionalities. However, traditional clouds Keywords: IoT; blockchain; serverless; joint-
usually offer computing service with the ab- cloud
straction of virtual machine (VM), which can
hardly meet these requirements. Meanwhile, I. INTRODUCTION
different cloud vendors provide different per-
formance stabilities and price models, which Cloud computing has been exploited in man-
fluctuate according to the dynamic workload. A aging the largescale IoT systems [1]. IoT
single cloud cannot satisfy all the requirements servers usually needs to handle a large number
of the IoT scenario well. The JointCloud com- of requests from various devices, and each of
puting model empowers the cooperation among them may send the request from anywhere, at
multiple public clouds. However, it is still any time. Thus, it is typical that IoT systems
difficult to dynamically schedule the workload require the cloud to provide high scalability,
on different clouds based on the VM abstrac- stable performance and low price.
tion. This paper introduces HCloud, a trusted It is hard for a single cloud to have all of
JointCloud platform for IoT systems using these features. First, since the number and fre-
serverless computing model. HCloud allows quency of IoT requests fluctuate from time to
an IoT server to be implemented with multiple time, it is not practical for a cloud vendor to
serverless functions and schedules these func- maintain enough hardware resources for the
tions on different clouds based on a schedule heaviest workload. Once the workload exceeds
policy. The policy is specified by the client and the capacity of the cloud, it cannot guarantee
includes the required functionalities, execution the performance stability. Second, the prices
resources, latency, price and so on. HCloud of different clouds may differ a lot and keep
collects the status of each cloud and dispatches changing. Choosing the cheapest cloud could
serverless functions to the most suitable cloud directly reduce the cost of the IoT system.
Third, different cloud vendors usually provide Received: Feb. 4, 2020
based on the schedule policy. By leveraging the
various software and hardware features. Using Revised: May 28, 2020
blockchain technology, we further enforce that Editor: Hong-Ning Dai

China Communications • September 2020 1

Authorized licensed use limited to: Carleton University. Downloaded on October 05,2020 at 18:04:49 UTC from IEEE Xplore. Restrictions apply.
 one cloud cannot benefit from all these features. ficiently monitor the fluctuation of the status
We have implemented The JointCloud computing proposes a of a cloud, which is required by HCloud to
a prototype of HCloud cross-cloud cooperation architecture [2]. It perform the scheduling. Third, the HCloud
and evaluated it by offers a great chance to build services by le- takes responsibility to collect the status of
simulating multiple
veraging multiple clouds which is transparent each cloud and perform the serverless function
cloud providers.
to the end-users. However, existing JointCloud scheduling. However, a malicious HCloud ad-
system still uses traditional virtual machine ministrator may fake the cloud status and run
(VM) abstraction, which is not suitable for IoT the target function on a non-suitable cloud.
services, e.g., VM is too heavyweight to be We design HCloud to address all these three
migrated between clouds. challenges. To run the serverless function on
In this paper, we introduce HCloud, a trusted different clouds, HCloud proposes unified
JointCloud serverless platform for IoT systems. APIs and automatically translates the server-
Instead of using VM, the serverless execution less function to different clouds. To detect
model requires an IoT server to be implement- the status fluctuation of each cloud, HCloud
ed with multiple serverless functions. For each assigns a cloud manager for each of them.
user request, the serverless platform will initial- A cloud broker schedules all the serverless
ize a new function instance. More requests will functions on different clouds. A client library
lead to more instances, which provides high is used for each client to get the target clouds
scalability. HCloud allows each IoT device to from the broker and invoke the serverless
specify a schedule policy which includes the re- function. To enforce that HCloud must “cor-
quired functionalities, latency, price, etc. When- rectly” perform the scheduling, we leverage a
ever the device invokes a function, HCloud will witness blockchain to record and verify all the
dynamically schedule it to the most suitable cloud status and the schedule results.
cloud according to the policy. We implement a prototype of HCloud, which
However, it is non-trivial to adjust the uses multiple computers to simulate the be-
serverless computing to a JointCloud system. haviors of different clouds. The cloud manager
First, the interfaces provided by different constructs a serverless platform on these com-
serverless platforms are diverse. As shown in puters. For evaluation, we dynamically change
Figure 1, for the same operation of returning the hardware resource of each emulated cloud
a response, AWS’s lambda requires a callback and use HCloud to schedule serverless function
function, while AliYun allows application to on these clouds. The results show that HCloud
directly return it. Second, it is difficult to ef- can achieve a more stable throughput and can
improve 25% throughput on average.

II. BACKGROUND

2.1 IoT Systems

IoT system is becoming a mainstream infra-
structure, which can help companies to catch
emerging opportunities and improve competitive
advantage. From a networking perspective, an
IoT system represents an ecosystem of inter-con-
nected “things” that are uniquely addressable,
provide specific services and communicate
through standard protocols [3]. “Things” include
sensors, actuators, sensor networks, embedded
Fig. 1. The serverless application examples of different clouds. systems, RFID tags and smart devices, etc.

2 China Communications • September 2020

Authorized licensed use limited to: Carleton University. Downloaded on October 05,2020 at 18:04:49 UTC from IEEE Xplore. Restrictions apply.
 The IoT cloud is used to provide necessary blockchains(e.g., Bitcoin [6], Ethereum [7])
functionalities for each device in an IoT sys- have no rights of entry which means anyone
tem. A cloud can theoretically offer unlimited can join the protocol. In contrast, permissioned
storage, compute and network capabilities, so blockchain (e.g., Quorum [8]) is often set up
it can serve a large amount of IoT devices. among a relatively small number of identi-
fiable participants with strict access control,
2.2 JointCloud
serving as a trusted coordinator and auditor.
With the development of cloud computing, Permissioned blockchain often adopts efficient
more and more cloud vendors appear, such as consensus algorithms like PBFT (Practical
AWS, Azure, Alibaba and IBM. To get ben- Byzantine Fault Tolerance).
efits from different clouds, researchers intro- However, blockchain is a closed and de-
duce JointCloud computing, which consists terministic system so that uncertain behaviors
of multiple clouds. A JointCloud platform can like network I/O are not allowed. Meanwhile,
leverage all the features of different clouds. blockchain cannot efficiently authenticate the
The JointCloud platform can consist entirely input data. Oracle is a kind of data feed ser-
of public clouds or private clouds. It can also vice transferring data from external world to
be a combination of the public clouds and pri- blockchain in a verifiable way. Existing oracle
vate clouds. solutions mainly consists of centralized ora-
Existing JointCloud systems bluntly piece cles (e.g., Oraclize [9], Town Crier [10]) and
together multiple clouds. Therefore, they try decentralized oracles(e.g., Chainlink [11]).
to keep most of the cloud computing features
like live-migration, unified network layer and III. SYSTEM DESIGN
external storage.

2.3 Serverless computing 3. 1 Challenges and goals

Serverless computing is also called FaaS HCloud tries to provide a trusted serverless
(Function as a Service). Users upload their platform, with multiple clouds, for IoT sys-
business functions and providers maintain the tems. IoT application developers can focus on
deployment, traffic routing and scaling. From their application logic and HCloud takes care
a user’s perspective, serverless computing can of scheduling these serverless functions on
simplify the process of deploying code into multiple clouds. There are three challenges of
production. Scaling and capacity planning are HCloud: 1) How to deal with the incompatibil-
hidden from the developer. The developer also ity due to heterogeneous implementations of
does not to consider about how to maintain the different serverless clouds? 2) How to detect
virtual machine (VM). In addition, pricing is the real-time resource utilization of each cloud
based on the actual amount of resources con- and to perform scheduling on them? 3) How
sumed by an application [4][5]. to prevent a malicious HCloud administrator
from faking the status of a cloud and schedule
2.4 Blockchain and oracle
a client invocation to the non-suitable cloud?
Blockchain typically serves as a decentralized HCloud first analyzes existing serverless
and trustless ledger maintained by all partici- APIs and provides unified interfaces for the
pants in a peer-to-peer network. Each compu- developer. Thereafter, we leverage multiple
tation request is executed and validated by all cloud managers and a cloud broker to monitor
the participants commonly known as miners, the real-time status of each cloud and perform
and the network state is organized as a sequen- scheduling according to the user-specified
tial list of blocks, called a blockchain, which schedule policy. Finally, we use a witness
is append-only and traceable. Blockchain is blockchain to log and verify all the cloud sta-
designed for Byzantine fault tolerance. Public tus uploaded by the HCloud and help the user

China Communications • September 2020 3

Authorized licensed use limited to: Carleton University. Downloaded on October 05,2020 at 18:04:49 UTC from IEEE Xplore. Restrictions apply.
 to audit the scheduling result. quest, and returned with an HTTP response.
However, different clouds provide different
3.2 Design overview
interfaces to parse arguments and return
HCloud is a single serverless platform across values. Figure 1 shows the different APIs
different clouds. The HCloud maintainer pro- provided by AWS and AliYun.
vides an accounting model and users only need • R untime API: Different clouds provide
to pay the HCloud maintainer. The maintainer interfaces to access the cloud resources.
further pays the public clouds. Figure 2 shows For example, the AWS allows functions to
the overview of HCloud, which consists of access the S3 storage.
four components. We assign a cloud manager • R untime Dependency and Languages:
for each cloud to monitors the real-time cloud Different clouds support different libraries
status, including the resource utilization and for the function, or support different pro-
price. Meanwhile, the cloud manager helps to gramming languages.
manage the serverless function on each cloud. Table 1 shows the unified interfaces pro-
After that, a centralized cloud broker continu- vided by HCloud. The user inputs are passed
ously gets the cloud status from all cloud man- through the function arguments. Meanwhile,
agers and schedules all user functions on these the response is returned directly. For the run-
clouds. A client library is used by each client time API, currently, HCloud only provides
to cooperate with the cloud broker to specify APIs to access the storage, which is managed
the schedule policy and invoke the target func- as a key-value store. HCloud allows users to
tion. Finally, we use a witness blockchain to 1) develop the function with Python.
record and verify all the cloud status collected Function Translation: To run the server-
by each cloud manager; 2) record the schedule less function on a specific serverless cloud,
behavior of the cloud broker; 3) allows each HCloud needs to translate the function to the
client to audit each schedule behavior. version which uses the platform-specific in-
In the following sections, we will introduce terfaces. We use the cloud interfaces to imple-
the function interfaces provided by HCloud ment HCloud interfaces. For example, to run
and the cross-cloud data sharing method. Af- a function on AWS, we will replace the return
ter that, we will give the detailed design of interface with the callback interface provided
the cloud manager, cloud broker and client by AWS. Currently, HCloud can only use the
library. Finally, we show how to use witness serverless cloud which supports Python to
blockchain to prevent a malicious HCloud ad- write the function.
ministrator from faking the cloud status. Since current clouds often provide plat-
form-specific serverless interfaces, we intro-
3.3 HCloud interfaces
duce HCloud interfaces to allow the serverless
To run the serverless function on different function to be deployed on different public
clouds with different interfaces. HCloud first clouds. However, a better solution is having a
summarizes the serverless interfaces into three serverless computing API standard. We think
types and provide unified interfaces. After the HCloud interfaces could be further extend-
that, we provide a translation method to run ed to define the standard.
the serverless function written with HCloud
3.4 Cross-clouds data sharing
interfaces on different clouds.
Different cloud vendors often provide va- During the execution, a serverless function may
rieties of interfaces for the serverless function persist some data in the platform and allow
developer. All these interfaces can be divided the following functions to access these data.
into three types: However, there exist multiple clouds in HCloud
• Invocation and Return: Serverless func- and each of them has its own storages. The first
tions are invoked by sending an HTTP re- function may store the data in a cloud while the

4 China Communications • September 2020

Authorized licensed use limited to: Carleton University. Downloaded on October 05,2020 at 18:04:49 UTC from IEEE Xplore. Restrictions apply.
second one is executed on another cloud. Table I. Interfaces of HCloud.
Since HCloud allows each client to choose Types Interfaces Description
a cloud for executing a function (introduced handler(event, con- Event and context are used to parse the
Invocation and
in Section III-F), one solution is asking the text) invocation arguments. Directly return the
Return
developer to explicitly specify the dependency return response response.
of different functions and relying on the bro- kv_put(key, value) Put a new (key, value) pair into the storage.
ker to schedule the related functions together. Runtime API kv_get(key) Get a value of the corresponding key.
Besides, HCloud also provides a cross-cloud kv_delete(key) Delete a (key, value) pair in the storage.
storage to solve this problem. We leverage Runtime De-
Developer can write serverless functions
existing techniques, such as GPFS [12], to im- pendency and Python
with Python.
Languages
plement this storage.

3.5 Cloud manager

HCloud assigns a cloud manager to each cloud
to 1) construct a serverless platform, 2) sched-
ule the serverless function and 3) monitor the
status of the cloud.
Figure 3 shows the design of the cloud man-
ager. When receiving a user request, the cloud
manager will create an instance of the calling
function to handle it. We provide two execution
modes: container mode and native mode. The
previous one is implemented by a worker VM.
The worker creates a container for each func-
tion instance. The container mode can be used Fig. 2. The design overview of HCloud.

on any cloud, even when it does not support

serverless model. The latter is based on the na- monitors the resource utilization and the price
tive serverless platform. The serverless function of the cloud.
is developed with HCloud’s API. To run them 3.6 Cloud Broker
in the cloud’s serverless platform, we use a
transfer to do the translation when the function The cloud broker collects all the statuses of
is deployed on the cloud. a cloud and a serverless function. After that,
The cloud manager also uses a scheduler the broker allows the client to specify a sched-
to handle and schedule all the user requests. uling policy and the broker can select a most
Basically, the serverless function will be start- suitable cloud to handle the client requests.
ed in native mode due to its fast startup time Status Collection: The cloud broker needs
and pay-per-invocation price mode. When to collect two kinds of status: the status of
there are lots of user requests, the container each cloud and the status of each serverless
mode will be cheaper. For example, the price function. As mentioned in Section III-E, the
of AWS lambda is 0.20 USD per 1M requests. previous one can be synchronized from the
Consider a serverless function that runs for cloud manager. The latter one includes the
1 second. A client needs to pay $25.60 for 3 version of each deployed serverless function
million invocations. However, a VM instance and its deployed status in each cloud. The
with 2 GB memory only takes $0.0084 per cloud broker first provides APIs for developers
hour. Handling 3 million requests will only to deploy and manage their functions. When a
take $7. When the scheduler detects a heavy developer updates her function, the broker will
workload, it will start up a worker and handle deploy this updating to all cloud managers and
requests in container mode. The scheduler also record current function status.

China Communications • September 2020 5

Authorized licensed use limited to: Carleton University. Downloaded on October 05,2020 at 18:04:49 UTC from IEEE Xplore. Restrictions apply.
 Cloud Scheduling: After collecting the sta- HCloud asks the client to specify the version
tus of all clouds, the cloud broker can choose of the invoked function. The version number
the most suitable one basing on the schedule can be gotten from the cloud broker previously.
policy specified by the client. As shown in After that, the client needs to parse the version
Figure 4, HCloud allows different clients to number for each function invocation. If the
specify its own schedule policy. The client manager doesn’t have the specified version of
C asks the broker to pick the cheapest cloud. function, it will return an error and the client
Meanwhile, both the client A and B want to cloud get a new cloud manager from the broker.
invoke the cloud with the smallest distance.
3.7 Client library
In the JointCloud environment, the distance
between client and the cloud influences the The client library provides four functionalities:
network latency significantly. The longest path Function Management: The library allows
• 
may take hundreds of milliseconds to com- the developer to deploy and update the
plete while the lowest latency is less than 30 serverless function in HCloud.
milliseconds. The broker could measure the Cloud Selection: The library allows a client
• 
distances between a client to all the cloud and to upload a schedule policy to the cloud bro-
choose the shortest path. ker. Meanwhile, the library periodically gets
However, there exists a problem after the the selected cloud from the cloud broker.
developer updating the function. A cloud may Function Invocation: The library helps a
• 
not immediately finish the deployment of the client to invoke the target function on the
new function. Since the client does not know selected cloud.
that the function has been updated, she may Schedule Auditing: HCloud gives a client
• 
still send a request to the cloud with the old ability to verify whether a cloud is selected
version of the function. based on the real status, instead of the faked
one. The library provides interfaces for the
client to audit the schedule log (introduced
in Section III-H).

3.8 Witness blockchain

Risk Introduced by HCloud: When HCloud
is used, a user has to trust HCloud that it will
always perform the scheduling honestly based
on the client-specified schedule policy.
In practical situations, the relation between
different cloud providers maintains competi-
tiveness. They all hope to hold their advantages
Fig. 3. Architecture of cloud manager. and stand on a positive position in the proce-
dure of scheduling, so that they can get more
benefits by selling more computing resources.
Therefore, cloud providers have a strong
motivation to manipulate the behavior of
HCloud and consequently extort the schedule
favoritism. For example:
• Cloud providers could collude with the bro-
ker by bribes and manipulate the schedule
logic privately. And the broker would offer
users a tampered schedule decision accord-
Fig. 4. Different scheduling policies in HCloud. ing to the bade discretion sort, which gives

6 China Communications • September 2020

Authorized licensed use limited to: Carleton University. Downloaded on October 05,2020 at 18:04:49 UTC from IEEE Xplore. Restrictions apply.
 high ranking to the high bidder. lic information, the witness blockchain
• Since managers are running on the cloud, could automatically verify whether the up-
the cloud providers with root privilege loaded status is corresponding to the public
could hack the manager, fake cloud status information. The verification is performed
and induce broker to make biased schedule by a smart contract deployed on the witness
decisions. blockchain. The schedule logging and au-
• Cloud providers could temporarily modify diting should only use the verified status.
the pricing scheme to tempt brokers with Schedule Logging: For each time the cloud
• 
attractive price and acquire the schedule broker performs the scheduling, it should
advantages over a period of time, and then upload the scheduling log to the blockchain.
restore prices to the origin in settlement to The log includes 1) the cloud status used in
guarantee profits. the scheduling; 2) the schedule policy and
Making HCloud to be Trusted: We lever- 3) the schedule result.
age a witness blockchain to enforce that the Schedule Auditing: Whenever the client
• 
cloud status cannot be tampered with and the receives a schedule result from the cloud
cloud broker correctly performs the schedul- broker, the client can audit the result with
ing based on the schedule policy. We choose the help of the witness blockchain. Lever-
permissioned blockchain to implement the aging the scheduling log, the client can
witness blockchain, because it always has verify 1) whether the cloud broker uses the
more practical performance for large-scale correct cloud status; 2) whether it uses the
computation than public blockchain. correct schedule policy and 3) whether it
The architecture of the witness blockchain performs the scheduling correctly.
is shown in Figure 5. The detailed workflow
can be divided into four parts: IV. EVALUATION
• Status Upload: For each time a cloud man-
ager synchronizes the cloud status to the We implement a prototype of HCloud to do the
cloud broker, the manager is required to evaluation. We use three computers to emulate
upload the status to the witness blockchain. three clouds. Each computer has an 8-core Intel
A compromised manager may 1) upload
the faked status; 2) not upload the status to
the blockchain; or 3) upload a correct status
but synchronize the broker with the faked
one. The first malicious behavior can be
prevented by the status verification, and the
latter two can be prevented by the schedule
logging and auditing.
• Public Information Collection: The up-
loaded status should correspond with the
public information of the cloud. For exam-
ple, the uploaded price must be same as the
price published by the cloud. The witness
blockchain needs the public information
to verify the uploaded status. However, a
blockchain is closed which cannot get the
outside data. To solve this problem, we
leverage an oracle to collect the public in-
formation from each cloud.
• Status Verification: After getting the pub- Fig. 5. Architecture of the Witness Blockchain.

China Communications • September 2020 7

Authorized licensed use limited to: Carleton University. Downloaded on October 05,2020 at 18:04:49 UTC from IEEE Xplore. Restrictions apply.
 Core i7-8559U CPU, 8GB memory and 256GB ond, we change the cost of different clouds and
SSD. The client runs on another machine with a analyze how HCloud helps to reduce the cost.
4-core Intel Core i5-7260U CPU, 8GB memory We deploy a serverless function, which adjusts
and 256GB SSD. All the machines are connect- the size of a picture, to do the evaluation.
ed with an H3C 240Gbps switch.
4.1 CPU utilization
In the evaluation, we perform two tests.
First, we change the free CPU utilization rates In this test, we change the free CPU utilization
of different clouds and show how HCloud im- rate of each machine to emulate the perfor-
proves the performance by choosing the cloud mance fluctuates of a cloud. As shown in Fig-
with the highest free CPU utilization rate. Sec- ure 6, we use three functions to emulate the
fluctuation of the free CPU utilization rates:
1.4 • Sine: The rate wave resembles a sine curve.
1.3 sine(cloud-1)
It increases and decreases regularly.
linear(cloud-2)
• Linear: The free CPU utilization rate in-
1.2
Free CPU utilization rate

1.1 const(cloud-3)

1 creases and decreased linearly.

0.9 • Stable: The free CPU utilization rate is a
0.8
0.7
const value.
0.6 We configure the cloud manager to report
0.5
the cloud status every 15 seconds. Meanwhile,
0.4
0 20 40 60 80 100 120 140 160 180
for each cloud, the CPU utilization rate chang-
es slowly following one of the above strate-
Fig. 6. The fluctuation of the free CPU utilization gies. In a real world, the fluctuation is slighter
rate of different clouds.
and more frequent.
We firstly test the throughput of using a single
80 cloud. After that, we measure the throughput of
HCloud
70 Cloud-1(sine) the HCloud which schedules the serverless func-
Cloud-2(linear)
tion on all the three clouds. As shown in Figure
Throughput (op/min)

60 Cloud-3(const)

50 7, HCloud will have a higher throughput.

4.2 Cost analysis

40

30

20
We analyze how HCloud can help the user
to reduce the cost. Same as the previous test,
10
1 2 4
we assume that the cost of each public cloud
fluctuates and each fluctuation wave resembles
Fig. 7. Throughput of different clouds and
different functions (Shown in Figure 8):
HCloud.
• Sine: The cost wave resembles a sine curve.
It increases and decreases regularly.
• Linear: The cost increases and decreased
5.0
sine(cloud-1)
4.5 linear(cloud-2) linearly.
Cost per second (x1 0-5)

4.0
const(cloud-3)
• Stable: The cost is a const value.
3.5 We configure the cloud manager to report
3.0
the cloud status every 15 seconds. And use
a specific serverless function which always
2.5
takes 2s. We further analyze the average cost
2.0
of running this function on a single cloud or
0 20 40 60 80 100 120 140 160 180
on the HCloud platform. Table 2 shows the
Fig. 8. The fluctuation of the cost of different analysis result. The average cost of HCloud is
clouds. smaller than using a single cloud.

8 China Communications • September 2020

Authorized licensed use limited to: Carleton University. Downloaded on October 05,2020 at 18:04:49 UTC from IEEE Xplore. Restrictions apply.
V. RELATED WORK Table II. The average cost of each invocation on different clouds.
HCloud Cloud-1(Sine) Cloud-2(Linear) Cloud-3(Stable)
Average Cost 4.83×10-5 5.72×10-5 5.68×10-5 5.66×10-5
5.1 Serverless
The serverless computing has been applied to
a variety of use cases. PyWren [13] lever- ages VI. CONCLUSION
AWS Lambda functions for linear algebra and
machine learning optimization. Werner et.al In this paper, we have presented HCloud, a
[14] propose to implement distributed matrix trusted JointCloud serverless platform, with
multiplication by using serverless platform. blockchain technology, for IoT systems.
MapReduce [15] and Spark [16] have also HCloud allows each IoT server to be imple-
been ported to serverless versions via this way. mented with multiple serverless functions. Af-
A real-world application usually has rich ter that, HCloud will schedule these functions
functionalities and all its modules cooperates among different clouds to achieve high scalabil-
and communication with each other during ity, stable performance, low price, rich func-
runtime. ExCamera [17] processes a frame- tionalities and so on. To achieve this goal, we
work (called mu) to create over 3,000 worker first provide unified interfaces to implement the
functions to encode video in just a few min- serverless function, as well as a transformation
utes. Based on the mu framework, Sprocket method to run the function on different clouds.
[18] is a system that efficiently processes Meanwhile, a cloud manager is assigned to
video, which allows developers to program a each cloud for collecting the cloud status and
series of pipeline operations. HCloud targets a centralized cloud broker schedules serverless
the IoT scenario, which also requires a com- functions among these clouds basing on the
plex IoT server application to serve all the IoT schedule policy. To ensure that HCloud always
devices. Meanwhile, HCloud can schedule performs the scheduling correctly, we leverage
serverless functions among different clouds to a witness blockchain to audit each schedule be-
enjoy all the benefits of them. havior. We implement the prototype of HCloud
and perform an evaluation by emulating the
5.2 Serverless optimization
behaviors of different clouds. For a client who
Serverless functions are mainly deployed wants to use the cloud with the highest free
within containers or VMs. A line of research- CPU utilization rate, HCloud can help her im-
es target to optimize the booting procedure prove 25% performance on average.
of serverless functions. OpenWhisk [19] can
pre-launch Node.js containers if observing ACKNOWLEDGMENT
the workload is based on Node.js. SOCK [20]
takes a similar approach for Python functions. This work was supported by the Nation-
To optimize the storage performance of al Key Research & Development Program
serverless functions, Pocket [21] leverages (No.2016YFB1000104).
multi-tier storage including DRAM, SSD, and
References
HDD. Pocket proposes a controller to right-
[1] M. M. Hassan, B. Song, and E.-N. Huh. “A frame-
size the resource allocation according to the
work of sensor-cloud integration opportunities
properties of server- less functions and current and challenges.” Proc. ACM 3rd international con-
conditions of resource utilizations. Crail [22] ference on Ubiquitous information management
is aimed at storing and exchanging large-scale and communication, pp. 618–626.
[2] H. Wang, P. Shi, and Y. Zhang. “Jointcloud: A
temporary data. But it targets for high band-
cross-cloud cooperation architecture for inte-
width and low latency. HCloud’s design can grated internet service customization.” Proc. IEEE
be used together with these optimizations. 37th International Conference on Distributed
Computing Systems (ICDCS), pp. 1846–1855.

China Communications • September 2020 9

Authorized licensed use limited to: Carleton University. Downloaded on October 05,2020 at 18:04:49 UTC from IEEE Xplore. Restrictions apply.
 [3] D. Bandyopadhyay and J. Sen. “Internet of things: “Sprocket: A serverless video processing frame-
Applications and challenges in technology and work.” In Proceedings of the ACM Symposium
standardization.” Wireless personal communica- on Cloud Computing, SoCC ’18, pages 263–274,
tions, 58(1):49–69, 2011. New York, NY, USA, 2018. ACM.
[4] R. Miller. “Aws lambda makes ser verless [19] M. Tho m ̈ mes. Squeezing the milliseconds: How
applications a reality.” https://techcrunch. to make serverless platforms blazing fast, 2017.
com/2015/11/24/ aws-lamda-makes-server- [20] E. Oakes, L. Yang, D. Zhou, K. Houck, T. Harter,
less-applications-a-reality/, 2015. A. C. ArpaciDusseau, and R. H. Arpaci-Dusseau.
[5] R. Miller. “Amazon launches lambda, an “Sock: Rapid task provisioning with server-
event-driven compute service.” https://tech- less-optimized containers.” In Proceedings of the
crunch.com/2014/11/13/ amazon-launch- 2018 USENIX Conference on Usenix Annual Tech-
es-lambda-an-event-driven-compute-service/, nical Conference, USENIX ATC ’18, pages 57–69,
2015. Berkeley, CA, USA, 2018. USENIX Association.
[6] S. Nakamoto et al. “Bitcoin: A peer-to-peer elec- [21] A. Klimovic, Y. Wang, P. Stuedi, A. Trivedi, J. Pfef-
tronic cash system.” 2008. ferle, and C. Kozyrakis. “Pocket: Elastic ephemeral
[7] G. Wood et al. “Ethereum: A secure decentralised storage for serverless analytics.” In Proceedings
generalised transaction ledger. ”Ethereum project of the 12th USENIX Conference on Operating
yellow paper, 151(2014):1–32, 2014. Systems Design and Implementation, OSDI’18,
[8] J. Morgan. “Quorum: A permissioned implemen- pages 427–444, Berkeley, CA, USA, 2018. USENIX
tation of ethereum supporting data privacy,” Association.
september 2016. [22] P. Stuedi, A. Trivedi, J. Pfefferle, A. Klimovic, A.
[9] Oraclize. “the provable blockchain oracle for Schuepbach, and B. Metzler. “Unification of tem-
modern dapps.” http:// provable.xyz, 2016. porary storage in the nodekernel architecture.”
[10] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. In Proceedings of the 2019 USENIX Conference on
Shi. “Town crier: An authenticated data feed for Usenix Annual Technical Conference, USENIX ATC
smart contracts.” Proc. ACM SIGSAC conference ’19, pages 767–781, Berkeley, CA, USA, 2019.
on computer and communications security, pp. USENIX Association.
270–282.
[11] S. Ellis, A. Juels, and S. Nazarov. “Chainlink: A Biographies
decentralized oracle network.” Retrieved March, Zheng Huang, received the BS
11:2018, 2017. degree in software engineering
[12] F. B. Schmuck and R. L. Haskin. “Gpfs: A shared- in 2019, from Shanghai Jiao
disk file system for large computing clusters.? In Tong University. He is now a
FAST, volume 2, 2002. master student at the Institute
[13] E. Jonas, Q. Pu, S. Venkataraman, I. Stoica, and B. of Parallel and Distributed Sys-
Recht. “Occupy the cloud: Distributed computing tems at School of Software,
for the 99%.” Proc. 2017 Symposium on Cloud Shanghai Jiao Tong University.
Computing, SoCC ’17, pp 445–451. His research interests include blockchain system and
[14] S. Werner, J. Kuhlenkamp, M. Klems, J. Mu ̈ller, system security.
and S. Tai. “Serverless big data processing using
matrix multiplication as example.” In 2018 IEEE Zeyu Mi, received a Ph.D de-
International Conference on Big Data (Big Data), gree in computer science from
pages 358– 365, Dec 2018. Shanghai Jiao Tong University
[15] Amazon. “Ad hoc big data processing made in 2020. He is currently a re-
simple with serverless mapreduce.” https://aws. search assistant professor at
amazon.com/blogs/compute/ ad- hoc- big- School of Software, Shanghai
data- processing- made- simplewith- serverless- Jiao Tong University. His re-
mapreduce/, 2016. search interests include operat-
[16] Github. “Apache spark on aws lambda. ”https:// ing system, system virtualization and system security.
github.com/qubole/ spark-on-lambda/.
[17] S. Fouladi, R. S. Wahby, B. Shacklett, K. V. Bala- Zhichao Hua, received a Ph.D
subramaniam, W. Zeng, R. Bhalerao, A. Sivara- degree in computer science
man, G. Porter, and K. Winstein. “Encoding, fast from Shanghai Jiao Tong Uni-
and slow: Low-latency video processing using versity in 2020. He is currently
thousands of tiny threads.” In Proceedings of the a research assistant professor
14th USENIX Conference on Networked Systems at School of Software, Shang-
Design and Implementation, NSDI’17, pages hai Jiao Tong University. His re-
363–376, Berkeley, CA, USA, 2017. USENIX Asso- search interests include operat-
ciation. ing system, virtualization and security.
[18] L. Ao, L. Izhikevich, G. M. Voelker, and G. Porter.

10 China Communications • September 2020

Authorized licensed use limited to: Carleton University. Downloaded on October 05,2020 at 18:04:49 UTC from IEEE Xplore. Restrictions apply.