QFaaS: A Serverless Function-as-a-Service Framework for Quantum Computing

Recent breakthroughs in quantum hardware are creating opportunities for its use in many applications. However, quantum software engineering is still in its infancy with many challenges, especially dealing with the diversity of quantum programming languages and hardware platforms. To alleviate these challenges, we propose QFaaS, a novel Quantum Function-as-a-Service framework, which leverages the advantages of the serverless model and the state-of-the-art software engineering approaches to advance practical quantum computing. Our framework provides essential components of a quantum serverless platform to simplify the software development and adapt to the quantum cloud computing paradigm, such as combining hybrid quantum-classical computation, containerizing functions, and integrating DevOps features. We design QFaaS as a unified quantum computing framework by supporting well-known quantum languages and software development kits (Qiskit, Q#, Cirq, and Braket), executing the quantum tasks on multiple simulators and quantum cloud providers (IBM Quantum and Amazon Braket). This paper proposes architectural design, principal components, the life cycle of hybrid quantum-classical function, operation workflow, and implementation of QFaaS. We present two practical use cases and perform the evaluations on quantum computers and simulators to demonstrate our framework's ability to ease the burden on traditional engineers to expedite the ongoing quantum software transition.


INTRODUCTION
With rapid advances in quantum computing, it is becoming a critical technology attracting significant investment at the global level.In terms of quantum hardware development, IBM is one of the leading companies with the world's most powerful 127-qubit quantum computer based on superconducting technologies released in 2021 [8].They also have a promising roadmap to develop a quantum computer with 1,121 qubits by 2023 [19].Apart from IBM, many other major companies, such as Microsoft, Google, DWave, Rigetti, IonQ, and several research groups worldwide, are also working towards building a large-scale quantum computer with fault-tolerant error correction capabilities.[22].They strive to make quantum computing trustworthy enough to tackle computationally intractable tasks for classical supercomputers.
Therefore, these rapid advancements in quantum hardware trigger more investments in quantum software engineering and quantum algorithms development to maximize the practical use of quantum computers.
There are now legitimate shreds of evidence that quantum computers can solve many complex problems which are challenging to tackle with classical supercomputers, ranging from chemistry problems [36] to machine learning [5], cryptography [46], and finances [25].Some notable algorithms have been proposed in the last few decades, such as Deutsch-Jozsa's [11], Shor's [49], and Grover's [27].We have also witnessed highly sophisticated quantum algorithms such as Quantum Approximate Optimization Algorithm (QAOA) [17] and Variational Quantum Eigensolver (VQE) [44] in recent years.These algorithms have been directly applied to problems of practical relevance, albeit at the proof-of-concept level due to hardware limitations.In terms of quantum software engineering, the number of new quantum programming languages, software development kits (SDKs), and platforms has been accelerating rapidly.
Currently, a user can develop quantum applications using popular SDKs and languages like Qiskit [1], Cirq [12], Q# [41], and Braket [2].Afterward, those quantum applications can be compiled and run on a quantum simulator or sent to a physical quantum computer via cloud-based services such as IBM Quantum [31], and Amazon Braket [23].However, quantum software engineering and quantum cloud computing are still confronting many challenges and some of these are discussed in the next sections.

Challenges for quantum software engineering
Quantum software engineering is a rapidly developing emerging area, and there are many open challenges.First, the development of quantum applications is time-consuming for software engineers, mainly because of the requirement of prior quantum knowledge.Quantum programming is underpinned by the principles of quantum mechanics, which are quite different from the traditional models.Therefore a quantum programmer must overcome the hurdle of learning quantum mechanics to develop applications.A basic example is the difference of the fundamental unit: a classical bit has two states: 0 and 1, whereas a quantum bit (qubit) could also be placed in a "superposition" state, i.e., a combination state of 0 and 1 simultaneously [43].Second, quantum computing is a promising way to solve several intractable tasks even for a classical supercomputer, but it may not entirely replace classical computers.In other words, there are many tasks in which both quantum and classical approaches could have the same performance, such as performing a simple calculation.While classical solutions are still dominant in today's industry, it is challenging to decide which approach is more suitable when transferring the existing classical systems to quantum: whether to replace the entire system with quantum or integrate quantum into the already well-established classical system [26].Besides, the variety of current quantum SDKs and the heterogeneous quantum technologies could confuse software engineers in picking an appropriate technique for their software.Each SDK and language has different environment configuration requirements, syntax, and methods to connect with the quantum simulator or quantum computer.Additionally, there is no wellknown standardization or life cycle in quantum software engineering similar to practices like Agile and DevOps in the traditional realm [54].
Recently, numerous solutions have been proposed to eliminate these burdens and accelerate quantum software development [22].Many studies have focused on developing new quantum SDKs [1,12,47], quantum programming languages [18,39,41], and platforms [29].However, few studies [13] have considered the potential approach of leveraging modern classical techniques and computation models to apply in the quantum realm, which has motivated us to contribute to this research.

Challenges for quantum cloud computing
The most widely adopted way to access today's quantum computers is through a cloud service from external vendors, such as IBM Quantum [31], Amazon Braket [23], Azure Quantum [40], and Google Quantum Computing Service [24].
However, the difference between quantum and classical approaches poses many challenges for the quantum cloud computing paradigm.First, we can not permanently deploy a quantum application on a cloud-based quantum computer as a service for invoking many times from the end-users, similar to what we do with traditional ones.Instead, we need to build a suitable quantum circuit for our application, then deploy them to quantum computers, and wait for the execution result [20].Additionally, quantum cloud providers and customers need to establish a win-win paradigm to maximize quantum advantages while optimizing the budget and the resources.The current pay-per-use pricing model offered by cloud vendors such as Amazon Braket [23] needs to go along with the computing model like serverless, a trending model for the classical cloud, to balance the benefit of both parties.An example of this approach is the concept of Quantum Serverless [35], proposed by IBM in their Quantum Summit 2021, coming up with the development of Qiskit Runtime [32].However, by sticking to a specific quantum vendor and technology, we could encounter another popular challenge known as the "vendor lock-in" problem [28].Therefore, an effort to make a universal quantum serverless platform, working with multiple quantum SDKs and providers, is another pivotal inspiration for our proposed work.

Contributions
In order to address and mitigate the challenges highlighted above, we propose QFaaS (Quantum Function-as-a-Service), a universal quantum serverless framework, which offers the function-as-a-service deployment model for quantum computing.Our framework could ease the quantum software development process, enabling traditional software engineers to quickly adapt to the quantum transition while continuously utilizing their familiar models and techniques.
The key contributions of our proposed research are as follows: • We design a novel framework for developing quantum function as a service, supporting popular quantum SDKs and languages, including Qiskit, Cirq, Q#, and Braket, to perform the computation on classical computers, quantum simulators, and quantum computers provided by multiple vendors (IBM Quantum and Amazon Braket).
• We evaluate the suitability, conduct empirical investigations, and apply state-of-the-art classical technologies and models, such as containerization, GitOps, and function-as-a-service for quantum software engineering.By leveraging the Docker container with Kubernetes as the underlying technique, our framework is portable and scalable for further migration or expansion to a large-scale system.
• We utilize the DevOps techniques in operating QFaaS, including continuous integration and continuous deployment, which supports to automate the quantum software development cycle, from quantum environment setup to hybrid quantum-classical function deployment.
• We introduce a unified 6-stage life cycle for a quantum function, from function development, deployment, pre-processing, backend selection, quantum execution, and post-processing.This lifecycle provides a baseline for a quantum software engineer to plan and organize their software development process.
• We propose two operation workflows for both kinds of users: quantum software engineers and end-users, to utilize our framework for the hybrid quantum-classical applications.The end-users can access the deployed function as a service through the QFaaS API (Application Programming Interface) gateway.Our framework also provides multiple ways for users to interact with the core components, including QFaaS Dashboard (a modern web-based application), QFaaS CLI (an interactive command-line tool), and QFaaS Core APIs.
• We have implemented two application use cases with QFaaS to validate our proposed design and demonstrate how our framework can facilitate quantum software development in practice.We also conduct a set of benchmark tests to evaluate the performance of our framework and offer an insight into the current status of today's quantum computers and simulators.This paper proposes the framework and essential implementation, but we have a viable plan to add additional functionality to the QFaaS platform.Ultimately, our framework is expected to be a universal environment for designing advanced practical quantum-classical applications.
The rest of the paper is organized as follows: After introducing the fundamentals of quantum computing, section 2 presents the current state of quantum software development, quantum computing as a service (QCaaS) model, and serverless quantum computing.Section 3 discusses the related work and briefly compares our framework's benefits with existing work.Section 4 introduces the details of the QFaaS framework, including the design principle, principal components, structure and life cycle of a quantum function, and the operation workflow of our framework.Section 5 describes the design and implementation of QFaaS core components and functions.Then, section 6 demonstrates the operation of QFaaS in two use cases and its performance.Following the discussion of the advantages of our framework for software engineering in section 7, we conclude and present our plan the future work in section 8.

The Fundamentals of Quantum Computing
This section briefly summarizes several essential characteristics and building blocks of gate-based quantum computing before diving into the state-of-the-art development of quantum software engineering and serverless quantum computing.
2.1.1Qubits, Superposition and Entanglement.Quantum computing is based on the theory of quantum mechanics and, therefore, is fundamentally different from classical computing [43].The basic units of classical and quantum computing are strikingly different at the fundamental level: a classical bit and a quantum bit (or qubit).A bit has two states for computation, either 0 or 1.Besides these classical states, a qubit can have a superposition state, i.e., a combination of states 0 and 1 simultaneously.Often quantum algorithms can achieve exponential speed-up by leveraging this characteristic compared with the classical solution.We can describe the general state of a qubit | ⟩ as follows: where ,  ∈ C are complex numbers.However, whenever we measure the superposition state, it could collapse to one of the classical states (i.e., 0 or 1): where || || 2 and || || 2 is the probability of 0 and 1 as a result after measuring qubit | ⟩.Hence, it is not straightforward to design a useful quantum algorithm by only utilizing the superposition attribute.
Another critical characteristic of qubits that could be leveraged to design quantum algorithms is entanglement.
Entanglement is a robust correlation between two qubits, i.We can categorize quantum gates into two main types: single-qubit gates and multiple-qubit gates.Some popular single-qubit gates are Pauli gates (Pauli-X, Pauli-Y, Pauli-Z), the Hadamard (H) gate, and the Phase (P) gate.For example, the Hadamard (H) gate could be represented as the following (with , ,  =  2 , 0, , respectively): We can also apply quantum gates to multiple qubits simultaneously by using multi-qubit gates, such as Controlled- We can create the entangled state (Bell state) by applying the CNOT gate to |0+⟩ state: 2.1.3Quantum Circuits and Quantum Algorithms.When implementing a quantum algorithm using the gate-based approach, we need to connect an appropriate combination of quantum gates to build quantum circuits.A quantum circuit's general operation includes three main stages: 1) Initializing the qubits, 2) Applying the quantum gates, and 3) Performing the measurement.
For example, the quantum circuit shown in Figure 1 implements Deutsch-Jozsa's algorithm [11].The main objective of this algorithm is to determine whether the property of the oracle is constant (i.e., always return 0 or 1) or balanced (i.e., return 0 and 1 with the same probability).The oracle in this circuit is a "black box" where we do not know which binary value is inside.However, when we query it with arbitrary input data, it will return a binary answer, either 0 or 1.
For the traditional approach, we need to interact with the oracle at least two times and at most 2 as Python [1,12] or C++ [39].Fortunately, we have a ton of available quantum software development kits (SDKs) and programming languages to choose from, thanks to the productive work in this field of both the quantum industry and the research community.Some popular SDKs and languages that were originated from well-known companies are: This SDK supports us in writing, manipulating, and optimizing quantum gate-based circuits.Cirq programs can run on built-in simulators (wave functions and density matrices), and Google's quantum processors [24].It is also an underlying SDK for TensorFlow Quantum [6], a high-level library for performing hybrid quantum-classical machine learning tasks.
• Q# [41] is a new programming language from Microsoft for developing and executing quantum algorithms.
It comes along with Microsoft's Quantum Development Kit, which includes a set of toolkits and libraries for quantum software development.Q# also offers many ways to use, by creating standalone programs, using Jupyter notebooks, using the command line, or integrating with host languages such as C# or Python.
• Braket [2] is an emerging Python-based SDK of Amazon to interact with their quantum computing service, named Amazon Braket [23].This SDK provides multiple ways to prototype and develop hybrid quantum applications, then run them on simulators (fully managed and local simulators) or quantum computers (provided by third-party hardware companies D-Wave, Rigetti, and IonQ).
2.2.2 NISQ era and the Hybrid Quantum-Classical model.John Preskill proposed the "Noisy Intermediate-Scale Quantum (NISQ)" term in 2018 [45] to describe the current state of quantum computers.This term indicates two characteristics of today's quantum devices, including "noisy, " i.e., unstable and error-prone quantum state due to the affection of various environmental actions, and "intermediate scale, " i.e., the quantum volume is at the medium level, with about a few tens of qubits [53].The most powerful quantum computer with 127 qubits, Eagle (released by IBM in 2021 [8]) could also be categorized as a NISQ computer.These limitations of current quantum devices pose many challenges for quantum software engineers to develop, execute, and optimize quantum applications.Due to the NISQ nature, the typical pattern for developing today's quantum programs combines quantum and classical parts [38].In this hybrid model, the classical components are mainly used for pre-processing and post-processing the data.In contrast, the remaining part is sent to quantum computers for computation.The quantum execution parts are repeated many times and measure the average values to mitigate the error caused by the noisy quantum environment.An example of the hybrid quantum-classical model is Shor's algorithm [49] to find prime factors of integer numbers.In this algorithm, we execute the period-finding part, leveraging the Quantum Fourier Transform on quantum computers and then performing the classical post-process to measure the prime factors based on the outcome of the quantum computation part.Other hybrid computation examples are the Quantum Approximate Optimization Algorithm (QAOA) [17], or the Variational Quantum Eigensolver (VQE) [44].
2.2.3 Variation of Quantum Software Development Lifecycle.In traditional software development, a lifecycle is an overall procedure of developing and operating an application, involving many steps from designing, executing, maintaining, investigating, and adapting software [53].Standardizing a lifecycle for quantum software development is also inevitably essential to ensure stability and scalability for the long term.Several studies have proposed various software lifecycles for quantum computing recently.
Due to the immature development and lack of standardization, more efforts are still needed to advance this field and adapt to quantum hardware's continuous growth.From the practical point of view, in the design and implementation of the QFaaS framework, we customized and proposed a sample 6-stage lifecycle for quantum function development, which will be described in detail in section 4.3.

Quantum Computing as a Service (QCaaS)
Today's quantum computers are made available to the industry and research community as a cloud service by a quantum cloud provider [20].This scheme is well known as Quantum Computing as a Service (QCaaS or QaaS), which corresponds with well-known paradigms in cloud computing such as Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) [7].In terms of QCaaS, software engineers can develop quantum programs and send them to quantum cloud providers to execute that program on appropriate hardware.After finishing the computation, the users only need to pay for the actual execution time of the quantum program (pay-per-use model).In this way, QCaaS is an efficient way that optimizes the user's budget for using quantum computing services and the provider's resources.
Many popular cloud providers nowadays offer quantum computing services using their quantum hardware, such as IBM Quantum [31], which is publicly accessible for everyone in their early phase.Besides, other quantum computing services (such as Amazon Braket [23], and Azure Quantum [40]) collaborate with other hardware companies such as D-Wave, Rigetti, and IonQ to provide commercial services.For example, Amazon Braket, a new Quantum Computing service of Amazon Web Services (AWS), currently offers the pay-per-use pricing model as Table 1: Table 1.Amazon Braket Pricing for using Quantum Computers (April, 2022) [23] Hardware Provider QPU Family Per-task price ($) Per-shot price ($) Total charges = Task charge + Shots charge = the number of task * per-task price + the number of shots * per-shot price = 0.3*1 + 10,000 * 0.00035 = $3.80 [23].
However, this paradigm still faces many challenges before solving real-world applications due to the limitation of today's NISQ computers [45].These devices have a small number of qubits that are error-prone and limited in capabilities.Therefore, improving the quality and quantity of qubits for quantum computers will accelerate of QCaaS model and quantum software development.

Serverless
Computing and Function as a Service (FaaS).In the classical computing domain, serverless is an emerging model and could be considered a second phase for traditional cloud computing [48].Serverless does not mean the absence of physical servers; it refers to an execution model that simplifies the application development without worrying about setting up the underlying system infrastructure.In other words, serverless implies that the existence of the servers is abstracted away from the software engineers.This computing model fits with modern software architecture, especially the microservice applications, where the overall application is decomposed into multiple small and independent modules [15].The serverless computing concept generally incorporates both Function-as-a-Service (FaaS) and Backend-as-a-Service (BaaS) models [52].FaaS refers to the stateless ephemeral function model where a function is a small and single-purpose artifact with few lines of programming code.BaaS is a concept to describe serverless-based file storage, database, streaming, and authentication service.
As FaaS is a subset of the serverless model, its main objective is to provide a concrete and straightforward way to implement software compared with traditional monolith architecture.FaaS allows the software engineer to focus only on coding rather than environmental setup and infrastructure deployment.A function can be triggered by a database, object storage, or deployed as a REST API and accessed via an HTTP connection.Functions also need to be scalable, i.e., automatically scaling down when idle and scaling up when the request demand increases.In this way, a FaaS platform could be an efficient way to optimize the resource for providers and reduce costs for customers.There are numerous open-source FaaS platforms in the traditional cloud-native landscape, such as OpenFaaS, OpenWhisk, Kubeless, Knative, and also many commercial serverless platforms such as AWS Lambda, Azure Functions, Google Cloud Functions [28].
2.4.2Severless Quantum Computing.In November 2021, along with the 127-qubit quantum computer, IBM also introduced the concept of Quantum Serverless [35], an adapted execution model for combing quantum and classical resources together.This model followed the principles of the traditional serverless platform, which embodies four key characteristics: 1) The only job of software engineers is to focus on their coding without any concern about infrastructure management; 2) All components are cloud-based services; 3) The services are scalable and 4) It fits with the pay-per-use pricing model.IBM also introduced Qiskit Runtime [32] in 2021, which allows users to execute the pre-built circuit by their developer teams, and it could be a premature example of their proposed concept.
A serverless quantum computing model could also be a viable solution for utilizing today's quantum computers effectively.Indeed, by decomposing a monolith application into multiple single-purpose functions, we could distribute them to various backend devices.This approach is well-suited to the current state of NISQ devices, in which each device has limited resources and could be accessed anywhere through the quantum cloud.Besides, we could implement a hybrid quantum-classical model by combining quantum functions and classical functions in a unified application.This approach could leverage the power of existing quantum computers to facilitate new promising techniques, such as hybrid quantum-classical machine learning [5].Although we can adopt the serverless model for quantum computing, the way a traditional service and quantum service can be deployed and executed are different.We can deploy a service directly and permanently to a classical server one time, and it could be invoked many times by the end-users later on.However, we cannot do the same thing with quantum computers, i.e., a quantum program cannot be deployed persistently in a specific quantum computer [20].With today's quantum computer, an appropriate quantum circuit (based on user inputs) needs to be built every time we execute a specific task.Then, that circuit will be transpiled to corresponding quantum system-level languages (such as QASM [9]) before being sent to a quantum cloud service for execution.Therefore, an adaptable serverless model for executing quantum tasks is needed to address this challenge.
By leveraging the ideas of the serverless model and combining quantum and classical parts in a single service, we can adapt to the current nature of quantum cloud services, accelerate the software development process and optimize quantum resource consumption.This kind of computing model could be a potential approach to enable quantum software engineers and end-users can realize the actual advantages of quantum computing and explore more complicated quantum computation in the future.

RELATED WORK
This section discusses the related work in the context of frameworks for developing quantum applications.Table 2 summarizes the difference between QFaaS and related platforms in the context of various capabilities offered by them.
To the best of our knowledge, existing quantum computing platforms lack various capabilities to provide a universal environment for developing service-based quantum applications.In 2018, Sim et al. [50] proposed algo2qpu, a hardware and software agnostic framework that supports designing and testing adaptive hybrid quantum-classical algorithms on the Rigetti cloud-based quantum computer.They implemented two applications in quantum chemistry and quantum machine learning using their proposed framework.This work motivated us to develop a more efficient and flexible framework for hybrid quantum-classical software development.
Strangeworks Quantum Computing (SQC) [51] is an online platform that allows us to use various templates, such as Qiskit, Q#, Cirq, ProjectQ, Ocean, Pennylane, and Forest, to develop quantum programs (using Jupyter Notebook and Python script).These programs can run on IBM Quantum machines and other enterprise quantum hardware.
SQC could be a convenient tool for quantum experiments and visualization.However, the running model of SQC and QFaaS is different.SQC provides a "code-and-run" environment, where we can write our standalone program and run it directly.In contrast, QFaaS provides a function-as-a-service model, where each quantum function is deployed as a service for end-users through an API gateway.This way, we can easily integrate these quantum services into our existing application, following the microservice application scheme.
Another related work applying the serverless model for quantum computing is proposed by Grossi et al. [26].In this work, they proposed an architecture design to integrate a Minimum Viable Product (MVP) solution for merging quantum-classical applications with reusable code.This framework leverages multiple cloud-native technologies provided by IBM Cloud, such as IBM Cloud Functions and IBM Containers, to implement Qiskit programs on IBM Quantum.However, the implementation of this proposed system is not available, and it depends solely on IBM-based platforms, which could lead to the vendor lock-in problem of serverless computing.
Garcia-Alonso et al. [20] proposed the proof of concept about Quantum API Gateway and provided a simple validation using Python and Flask platform on the Amazon Braket platform.QuantumPath, proposed by Hevia et al. [29], is a quantum software development platform aiming to support multiple quantum SDKs and languages, supporting gate-based and annealing quantum applications, and provide multiple design tools for creating a quantum algorithm.
QuantumPath does not support serverless and scalability features for further expansion, and it is still in the preliminary phase without providing performance evaluation to validate the proposed design.X.Fu et al. [18] proposed the overall framework for developing heterogeneous quantum-classical applications, adapting with NISQ devices.Instead of working with popular quantum languages and SDKs, they also proposed a new programming language, called Quingo, to describe the quantum kernel.Although this is an exciting direction for further quantum framework development, it can face many challenges when developing a new programming language compared to improving the well-known languages.
For example, expanding the support for large developer communities, security testing for potential vulnerabilities, and covering all aspects of the quantum and classical computation.
Considering the limitations of the existing platforms, we propose a unified framework for quantum computing that bridges the existing gaps.We focus on building the QFaaS framework by leveraging the advantages of traditional software engineering to quantum computing to alleviate the challenges when developing a hybrid quantum-classical function as a service.Our framework adapts to the NISQ era and is ready for a more stable quantum generation in the near future.

OVERVIEW OF QFAAS FRAMEWORK
This section presents the design principles, main components, function development life cycle, and the operational workflows of QFaaS for developing and using hybrid quantum-classical functions.

Design Principles
We design the QFaaS framework based on the following main principles: • Modularity: The whole framework is built as a combination of multiple modules, where each module manages a specific functionality, thus simplifying further expansion and maintenance.This principle is inspired by the microservice software architecture and "everything-as-a-service" (XaaS) paradigm [14].Therefore, we could easily integrate new functionalities into the current framework without affecting other modules.• Serverless: The quantum software engineers only need to focus on their programming, and the framework automatically carries out the rest of the deployment and execution procedures.Once deployed, the end-users can access the deployed services through the cloud-based API gateway in multiple methods.If a pricing strategy is established, they only need to pay for their actual resource usage.
• Flexibility: The framework allows users to choose their preferred quantum languages, libraries, and quantum providers to avoid potential vendor lock-in situations.The proposed framework supports the current NISQ computers and multiple quantum simulators.Its architecture provides the flexibility to implement possible extensions to support various quantum technologies in the future.
• Seamlessness: The framework supports continuous integration and continuous deployment (CI/CD), which are two of the most essential characteristics of the DevOps life cycle to continuously deliver value to end-users without any interruption.Utilization of this model boosts application development and becomes more reliable when compared with the traditional paradigm [21].
• Reliability: The framework architecture is implemented using state-of-the art technologies to ensure high availability, security, fault tolerance, and trustworthiness of the overall system.
• Scalability: As one of the critical characteristics of the serverless model, the framework is scalable and adapts to the actual user requests to optimize both the performance and the resource consumption, eventually providing the optimum cost for end-users.
• Transparency: The operation workflow of the framework is transparent to both the quantum software engineers and end-users.It also provides information of diagnosing, troubleshooting, logging, and monitoring for further investigations.
• Security: The interactions among different components need to be secure.The framework has in-built identity and access management features to guarantee they have sufficient privileges before performing each operation in the system.

QFaaS Architectural Components
The architecture design of QFaaS comprises a set of principal components, which are pluggable and extendable.We break down QFaaS into six components: the QFaaS Core APIs and API Gateway, the Application Deployment Layer, the Classical Cloud Layer, the Quantum Cloud Layer, the Monitoring Layer, and the User Interface.Figure 2 illustrates the overall design, including the architecture and principal components of our framework.The API gateway serves as an entrance where users can interact with other components.This gateway routes users' requests to suitable components and delivers the result back to the users after completing the processing.

Application Deployment
Layer.This layer serves as a bridge between quantum software engineers and the cloud layers to deploy and publish each function as a service for end-users.It takes the principal responsibility for developing, storing, and deploying quantum functions by combining four key components: • Code Repository is a Git-based platform to store function codes with version control management, which is essential for collaboration in software development.We could deploy this repository privately or publicly with popular Git-based open-source platforms such as Gitlab, Github, and Bitbucket.We employed Kubernetes to orchestrate all the pods (the container-based unit of Kubernetes) for the QFaaS function across all cluster nodes.Each function will be run on a pod and could be scaled up horizontally by replicating the original pod.All quantum SDKs and languages have their built-in quantum simulator, which can run directly inside a pod at the Kubernetes cluster.We call this kind of simulator as the internal quantum simulator, while the external quantum simulator is used to indicate the simulator provided by quantum cloud providers.We also deployed a NoSQL database (MongoDB) on this layer to store the processed job results and information of users, functions, and backends.• QFaaS Dashboard (shown in Figure 4) is a modern web-based user interface built by using ReactJS1 for the frontend and Python 3.10 for its API backend (QFaaS Core APIs).This dashboard allows:

QFaaS API Gateway
(1) Quantum software engineers to develop functions using a built-in code editor or upload their code files; update and manage their functions, templates; monitor the status of function deployment or overall system.
(2) End-users to use the deployed quantum function by invoking (i.e., sending requests), monitoring, and managing their requests and results.

Hybrid Quantum-Classical Function Life Cycle
Inspired from several proposed Quantum Software Life Cycles [18,53,54], we propose an altered 6-phase life cycle of a hybrid quantum-classical function (see Figure 5) for QFaaS as follows:  (2) Function Deployment: The quantum function is deployed at the classical backend (e.g., Kubernetes cluster) by employing modern software engineering technologies and models, such as containerization, continuous integration, and continuous deployment (CI/CD).During the deployment process, some components of the function could be compiled.For example, we use dotnet to compile Q# code into a classical binary, which could be imported into the main function handler.After deployment, the function is published as a service, allowing end-users access through the API gateway.
(3) Classical Pre-Processing: The function executes the classical computation task to pre-process the user's input data and pass all the requested data to the appropriate component in the function handler.
(4) Backend Selection: An appropriate quantum backend must be selected for the quantum execution based on user preference.These quantum backends could be a quantum simulator or a physical quantum computer provided by a quantum cloud computing vendor (such as IBM Quantum, Amazon Braket, and Azure Quantum).In the case of simulators, it could be either the built-in simulator of the corresponding quantum SDK, which runs on top of a classical computer at the Kubernetes cluster (internal quantum simulators), or an external quantum simulator provided by the quantum cloud provider (such as IBMQ QASM Simulator, Amazon Braket SV Simulator).
(5) Quantum Computation: A corresponding quantum circuit will be built and then sent to the selected quantum backend according to user input.Suppose the end-user does not specify a specific quantum backend, QFaaS could automatically choose the best suitable (least busy) backend at the quantum provider to send the quantum circuit for execution.As today's quantum computers are NISQ devices [45], each quantum execution should be run many times (shots) to mitigate the quantum errors.Besides, due to the limited number of available quantum computers, a quantum task (job) needs to be queued at the quantum provider (from seconds to hours) before execution.After the quantum computation is finished, the outcome is sent back to the function handler for post-processing or directly returned to the end-users.-Specify which quantum templates will be used (Qiskit, Cirq, Q#, or Braket); environment variables (such as secrets, annotations, scale factor) for the function.
-Compose Quantum functions using local IDE or the web-based IDE of QFaaS Dashboard.
(2) Push function codes to the Code Repository through the QFaaS API Gateway.
After these first two steps, QFaaS will automatically take responsibility for the rest of the deployment procedure by performing the following steps: (3) The API gateway forwards the function code and pushes it to the Code Repository.
(4) This triggers the Automation components to start the deployment process.We implemented the QFaaS Automation component on top of Gitlab Runner2 .
(5) Pull the function template and combine it with function code to build up and containerize it into a Docker image.Then, those images will be pushed to a Container Registry to be stored for further utilization (such as migrating or scaling up a function).• Monitor functions and system status: The Monitoring layer periodically checks the status of the deployment process, function usage, and system status (such as network status, Kubernetes cluster resource consumption) to provide insights for quantum software engineers on demand.
• Troubleshoot and diagnose the problem: If any issues are discovered during the deployment or invocation, QFaaS will check and provide detailed logs for the engineer to investigate and figure out the problem.Once engineers fix all issues, it will automatically deploy to the cluster to ensure the continuous integration and continuous delivery of the latest version of the function for end-users.

Workflow for invoking quantum functions.
The end-users could invoke (i.e., send their request to) the deployed function in many ways: 1) using the QFaaS Dashboard, 2) using the QFaaS CLI tool, or 3) integrating and calling QFaaS APIs from other applications or third-party API testing tools (such as Postman3 ).
Figure 7 demonstrates the overall workflow for the function invocation, including seven main steps.In this procedure, end-users need to send their request (the first and only step) and then wait for the QFaaS framework to take responsibility for the remaining tasks.(1) Sending request: In the requested data, user can clarify their preferred backend or let the framework automatically select the suitable backend, the result retrieval method, and the number of shots they want to repeat the quantum task.We describe the detailed sample request in section 5.3.2.

Classical Cloud Layer
After receiving the user's requested data, QFaaS will automatically do the rest of the process.
(2) Routing the requests: The API Gateway routes user requests to appropriate available functions.Suppose the function is not started yet or is being scaled down to zero.In that case, QFaaS will initialize and activate this function to process the user request (this situation is also known as cold-start in serverless terminology).
(4) Backend Selection: An appropriate backend is selected based on user requests and the availability at the quantum provider.
(5) Executing the quantum job: A corresponding user's input data is generated and sent to the selected backend device.The quantum backend device could be an internal quantum simulator (5a), an external quantum simulator (5b), or a physical quantum computer (5c).Then, that circuit is compiled to the appropriate quantum system language (such as QASM), and the quantum backend performs the quantum task.After finishing the execution, the outcome from the quantum backend will be sent back to the function handler for further processing.Suppose end-users want to track the response data later on, the function will send back the quantum Job ID and information of the backend device after successfully submitting the quantum circuit to the quantum backend.
(6) Post-processing (optional): The outcome from quantum backends could be analyzed and post-processed before sending back to end-users and storing it to the database.(7) Returning the results: After the previous step, the final result will be returned to end-users via the API Gateway, as the same way when they submit the request.End-users can get the result data, and information about the backend device is used for the quantum execution.The quantum engineers could also add other information and further analysis to help end-users get insight from the execution result.

QFaaS Core APIs
This section provides a detailed design and implementation of the QFaaS Core APIs, which take responsibility for primary functionalities in the QFaaS framework.We have developed this API set using Python 3.10 with FastAPI4 , a high-performance Python-based framework supporting the Asynchronous Server Gateway Interface (ASGI) for concurrent execution.We also used the MongoDB5 database to store the persistent data as JSON schemes.• Provider: The provider class handles a user's authorization to external quantum providers (such as IBM Quantum and Amazon Braket).The design of this class ensures that each user has the specific privilege to access their quantum providers only.
• Backend: A backend is a device, such as a classical computer, a quantum simulator, or a quantum computer, which takes responsibility for the job execution.The Backend class defines the attributes and methods to interact with the backend provided by the classical cluster or external quantum providers.libraries and packages for that SDK.These templates inherit the of-watchdog7 component for initiating and monitoring functions.In this way, quantum functions could be kept "warm" (i.e., running) with low latency and maintain persistent HTTP connections, quickly serving the user's request.

Function Structure.
Each quantum function has a simple working directory, including main components following the common pattern of the serverless platform (such as AWS Lambda [3]): • Function dependencies: We can declare all necessary Python-based libraries in the requirements.txtfile.These libraries will be automatically installed during the function deployment and could be imported for use within the function.
• Function handler: include the source code for the function, including classical parts (using Python) and quantum parts (using Qiskit, Cirq, Q#, and Braket).When end-users invoke the function, QFaaS executes the function handler and starts the computation at an appropriate backend device.Handler for Qiskit and Cirq function could be defined at handler.py file while Q# function requires us to define an additional Q# code at handler.qs file and then import it to the main handler.pyfile.The sample format for each function handler to handle user requests and return the response, with classical pre-processing and post-processing parts, is defined using the general Python syntax as Code 1.
First, we import all necessary quantum libraries (and Q# operation for Q# function only).Then, we define the function methods as follows: • Classical pre-processing and post-processing: In each function, we can optionally define the pre-processing and post-processing methods executed on classical computers (Kubernetes cluster).
• Backend selection: We can also define the custom strategy to allow end-users to select the appropriate quantum backend (internal simulator, external simulator, or quantum computer at cloud providers).
• Main handler method: The primary handle method is similar to AWS Lambda [3], while the user's requests are delivered to the function in two objects: event and context.The event is JSON-based data that comprise user input data, followed by the QFaaS sample format, while context provides HTTP methods (such as GET and POST), HTTP headers, and other properties, which are optional for the request.After finishing all the processing, the function handler could return the result to end-users, including the HTTP Status Code and response data in JSON format.QFaaS uses JSON as a default format to standardize user requests and responses, allowing the quantum software engineer to customize their format if needed.

QFaaS Core Functionalities Implementation
In this section, we describe the implementation of two core functionalities in the QFaaS framework, including function deployment and function invocation.Before launching the deployment process, the dependencyCheck() validates the access token and checks the permission of the current user, who is sending the function deployment request.The deployment process is only triggered if the dependencyCheck() is passed and the function name is valid.First, the function code template is retrieved based on the user selection.Then, the function codes are integrated into that template to create a function package and pushed to the Code Repository for versioning control purposes.The Automation component will be triggered to perform the ContinuousDeployment process whenever new function codes are updated (lines 8 -13).This process starts by containerizing the function package into an appropriate Docker image.Then, it uploads that image to the Container Registry to facilitate the continuous deployment process.Afterward, a container-based service is deployed into the Kubernetes cluster, and a corresponding API endpoint is published.Finally, this service is ready for invocation from authorized users through the QFaaS API gateway.The sequence diagram of a sample function deployment process is shown in Figure 9.  Similar to the function deployment, we perform the dependencyCheck() as a mandatory requirement before each invocation to ensure the framework's security.After passing that validation, the QFaaS API gateway forwards the request to the corresponding service in the cluster.Apart from the input data, end-users can also define: • provider: clarify their preferred quantum backend, either an internal simulator or quantum cloud provider (including IBM Quantum and Amazon Braket).In the case of selecting an external quantum cloud provider, they need to specify the information of their preferred quantum backend in the backendInfo section.If the autoselect variable is true and the expected backend type (internal/external simulator or quantum computer) is set, QFaaS will automatically select the best-suited quantum backend (least busy devices with enough qubits for the computation).The users can also manually select a specific quantum backend by setting this value to false and declaring the backend name in the backendName.
• shots: number of repetition times they want the quantum computation to perform • waitForResult: if this option is set to true, they need to wait at the current session until the function execution is done and receive the result.This waiting time at the quantum cloud provider could be very long (for queuing, transpiling, and executing) due to the current NISQ nature.Otherwise, they have another option by letting QFaaS send their job to the quantum backend device and providing them the Job ID to track the result later.
Based on the functionalities of that service, the pre-processing and post-processing could be performed before and after the execution.Following that optional data processing, a corresponding quantum circuit is built based on the user's input data.Then, the BackendSection will be performed as Algorithm 3.

Algorithm 3: QFaaS Backend Selection
Input : rQ: number of required qubit, be: backend info, token: Token to access external provider (optional) Output : backend: quantum backend object 1 procedure BackendSelection (rQ, be, token): Given the number of required qubits for the quantum circuit, backend preference (such as backend type, manually or automatically selected), and provider access information, an appropriate backend object is returned.Users can allow the framework to automatically select the best-suited backend in a specific type, such as a quantum simulator, quantum computer, or any kind.In that case, QFaaS will inspect and select the least busy backend (i.e., the backend that has the shortest waiting queue) from the provider.After a suitable backend is determined, the function invocation is continued by submitting the quantum circuit to that backend for execution.Then, based on user preference of whether or not to wait until receiving the result, QFaaS will either return the final result (after performing the post-processing -if any) or the job ID for further tracking of the result.The overall interaction between different objects during the function invocation process is shown in Figure 10.To validate the proposed framework, we deployed the core components of QFaaS on a set of four virtual machines (VMs) offered by the Melbourne Research Cloud8 .We set up the Kubernetes cluster with Docker as underlying container technology on three VMs (one master node with 4 vCPU, 16GB RAM, and two worker nodes with 8vCPU, 32 GB RAM each).The QFaaS Code Repository and Automation components are deployed to the last VM (4 vCPU, 16 GB RAM).For the computation layer, we have tested the Qiskit functions with the QASM simulator on both the classical computers at the Kubernetes cluster and quantum backends at the IBM Quantum provider [31] (from the IBMQ hub at the University of Melbourne).For Braket functions, we used their local simulator and Amazon Braket quantum computing service (through the support of Strangeworks Backstage Pass program [51]).For Q# and Cirq functions, we used their built-in quantum simulator and executed it on classical computers in the Kubernetes Cluster.

Case study 1: Quantum Random Number Generators (QRNG)
Random numbers play an essential role in cryptography, cybersecurity, finances, and many other scientific fields.By leveraging quantum principles, Quantum Random Number Generator (QRNG) has been proposed as a reliable way to provide truly randomness, which can not be achieved by using classical computers.This topic has been gaining much interest in the last 20 years [30].To give an example of how to generate quantum random numbers by utilizing the superposition state and demonstrate the workflow of QFaaS in action, we deployed a simple QRNG function in four different quantum SDKs and languages, including Qiskit, Cirq, Q#, and Braket.
6.2.1 Developing QRNG function in multiple quantum SDKs.We used a simple quantum circuit for generating a random number with the number of qubits as the user input.The main idea of this circuit is to leverage the Hadamard gate to create the superposition state of each qubit and then measure to get a random value (0 or 1) with the same possibility (50%).According to the user's request, our functions will dynamically generate an appropriate quantum circuit with the corresponding qubits.Figure 11 shows an example of the quantum circuit for generating a 10-bit random number.Since Qiskit, Cirq and Braket are Python-based SDKs, we need to write quantum code to develop a quantum function in the default handler.pyfile.When using Q#, as it is an independent quantum programming language, we need to develop the function in a handler.qsfile, and the .NET framework will compile this file.Fortunately, it also supports integrating Q# with Python code, and we need to import the operation from the Q# file to the handler.pyfile.QFaaS will take responsibility for the remaining procedure.We can also include several classical processing parts in each quantum function, especially for pre-processing the user input data and post-processing the result from the quantum computation layer.To validate this feature, we implemented simple post-processing for the QRNG function by analyzing all possible outcomes when the function is executed multiple times (shots) and returned the most frequent result to the end-user.The classical processing will be performed on the Kubernetes cluster, which runs on a classical computer after the quantum computation layer completes its processing.6.2.2 Deploying and invoking QRNG Functions.After developing a quantum function, we upload it to QFaaS Code Repository using the QFaaS Dashboard or QFaaS CLI tool.Whenever the QFaaS Automation detects new updates from the Code Repository, it will automatically check, build the Docker images, push that image to the Docker registry and deploy it to the Kubernetes cluster.Before the deployment, we can also integrate some intermediate processes to verify source code quality or perform a security check.Subsequently, QFaaS will release each quantum function with a unique URL accessible to end-users via the API gateway.User request data will be jsonify (i.e., converted to JSON format) and then sent to the API gateway.
The request JSON for invoking the QRNG function using all supported SDKs and languages is similar.After finishing processing, the sample response is as Code 3.This result indicates that the generated random number is 6493 (0001100101011101 in binary), one of the most frequent (2 times occurrence) random numbers generated by the Qiskit QRNG function.Thanks to the post-process, we also have other possible results after running this function 1024 times, i.e., 17990 and 26321.Code 3. Sample response data for returning a random 16-bit number from Qiskit QRNG function 6.2.3 Performance Evaluation on Quantum Simulators.We conducted a series of experiments using the JMeter tool 9 to benchmark the performance of the QRNG function in three different quantum simulators on the QFaaS framework.For a practically fair comparison, we used the default quantum simulator (QASM simulator for Qiskit, braket_sv simulator for Braket, and built-in simulator for Q# and Cirq) of all frameworks for execution.We repeat each experiment 100 times, then measure the average response time and the standard deviation when executing the QRNG function using 1 qubit to 20 qubits in each quantum SDK.
Figure 12 illustrates the average response time of three functions when we increase the number of qubits from 1 to 20.
The Cirq simulator registers the fastest response time in all test cases with a slight increase from 49 ms for generating a 1-qubit random number to 61 ms for a 20-qubit one.A similar trend could also be seen if we look at the Qiskit, Q#, and Braket function figures when the number of qubit increases from 1 to 15.The Qiskit function response time is slightly longer than Cirq and Q# during the 1-to 15-qubit period.However, when the number of qubits reaches 20, the 6.2.4 Scalability evaluation.We could enable the auto-scaling feature to scale up the deployment horizontally (i.e., increase the number of pods), dealing with the scenario when the request workload grows significantly.
To validate the scalability of our framework, we perform a set of evaluations on the 10-qubit Qiskit QRNG function.
In this evaluation, we increase N -the number of concurrent users from 8 to 64, using the JMeter benchmarking tool.In each case, we conduct a set of three different scenarios: non-scale (1 pod/function), scale up to N/2 pods and scale up to N pods (we fixed the number of pods for evaluation purposes only).For example, suppose there are 64 users (N) invoking the function simultaneously.In that case, we will conduct three test cases: 1 pod, 32 pods (N/2), and 64 pods (N) and record the average response time and the standard deviation.
Figure 13 demonstrates the result of our benchmarking.Overall, it is clear that if the function is non-scalable, the average response times for high-demand scenarios significantly increase.The previous section shows that the average response time for the 10-qubit Qiskit QRNG function is 81 ms.This figure jumps dramatically, up to 1703 ms, if 64 users use the function simultaneously.However, thanks to the containerization approach in our framework, we can quickly scale up deployment in seconds to ensure the response time is maintained.We can see that the average response time fluctuates between 87 to 148 ms if we scale up to N pods or from 102 to 180 ms when the number of pods is N/2.6.3.1 Implement the Shor's algorithm as a service using Qiskit API.In this case study, we demonstrate the implementation of Shor's algorithm as a QFaaS function (Shor function) by utilizing the Qiskit Terra API [1].The quantum circuit for Shor's algorithm is also dynamically generated based on the input number that end-users want to factorize.For example, to factorize 15, we need to use 18 qubits for the corresponding quantum circuit (Figure 14).Using the Shor class in qiskit.algorithms10, we need to define a simple code to generate the quantum circuit to factorize the integer N, then execute that circuit at the appropriate backend device selected by QFaaS or through the end-users.For example, we use the following request and submit it to the Shor function, using the 27-qubit quantum computer (ibm_cairo node) at IBM Quantum Provider [31] for factorizing 15 (Code 4).After finishing the execution, the response data is as the following sample at Code 5. We got the prime factors of 15 are 3 and 5 as expected.Due to the limitation of the current NISQ devices, we keep these example data small to demonstrate the viable workflow of developing, deploying, and using functions at QFaaS.We aim to develop a scalable QFaaS framework that could handle large-scale algorithms relevant to practical applications.and the line chart indicates the number of qubits used for each test case in both backend devices.These input numbers need less than 27 qubits to build a corresponding circuit.Regarding the run time, we can see that the QASM simulator is much faster than the quantum computer when the number of required qubits is small, from 18 to 22 (for factorizing 15 and 21).However, we can see the opposite trend when executing 26-qubit circuits to factorize 35, 39, and 55.These circuits cost around 3 minutes to complete in an IBM Cairo quantum computer, whereas the QASM simulator takes 13.5 to 17 minutes to finish the execution.A significant reason for the considerable delay of the QASM Simulator in these test cases could be the complexity of the 26-qubit quantum circuit for the Shor algorithm, which requires a lot of resources to simulate.These results could give us insight into the selection order of current quantum computing services for developing quantum software.We could use the quantum simulator for prototyping and testing phases before entering the production stage with the quantum computers.

DISCUSSION
By designing and developing QFaaS, we found that combining quantum and classical tasks along with the serverlessbased model is possible and even an effective way to deal with the capabilities of current NISQ devices.Our framework provides a seamless quantum software development environment that allows software engineers to quickly develop, build, deploy, and eventually offer their quantum functions to end-users.End-users can also integrate these quantum functions into their existing classical application, especially suitable for microservice applications.
Inspired by the advantages of the Serverless and DevOps models, combined with the Quantum Cloud Computing paradigm, we have designed and implemented QFaaS with a set of essential features for creating a unified environment for developing quantum applications: • Multiple quantum SDKs and languages supported: QFaaS supports four quantum SDKs, and widely popular languages, including Qiskit [1], Cirq [12], Q# [41], and Braket [2].
• Containerized quantum environment: The engineers can develop quantum functions without any concerns about environment setup.The function will be containerized into an appropriate Docker image, including all necessary libraries defined by quantum software engineers.This approach makes the deployment more flexible and allows quantum developers to easily migrate their functions to other systems.
• User-friendly Web UI with built-in IDE: Quantum engineers can easily create, update, delete, manage and monitor their quantum function by using QFaaS Dashboard.We also integrate a built-in IDE in the QFaaS Dashboard, allowing quantum software engineers to write and update their quantum codes directly.
• Local software development environment with CLI tool: Our platform also supports using local IDE such as Visual Code for the development process.Then, they can upload the function codes to QFaaS through the CLI tool with all actions they can do through the Dashboard.
• Hybrid quantum-classical functions: Quantum functions could include both quantum and classical parts (using Python), which supports hybrid computation.Quantum parts can be run on multiple quantum simulators (QASM simulator by Qiskit or built-in simulator by Cirq, Q#, and Braket) or external quantum providers (supported both IBM Quantum [31] and Amazon Braket [23]).Classical parts (pre-processing, post-processing, or other classical processing) can be run on classical computation nodes at the Kubernetes cluster, where quantum functions are deployed.
• Quantum API gateway: After deploying, quantum functions will be published for end-users using an API gateway to use and integrate into their existing microservice application.Each function has a unique URL that allows the end-user to invoke or incorporate into other existing microservice applications as an API.
• Continuous Integration and Continuous Deployment (CI/CD) pipelines: With the DevOps-oriented approach, QFaaS creates a seamless software development process that continuously delivers value to end-users.
After finishing the development process, quantum functions will be automatically compiled, containerized, and deployed to the Kubernetes cluster.When the engineer updates a quantum function, it will also automatically deploy and ensure the updated services are successfully deployed before terminating the old one to guarantee the continuous experience at the end-users side.
• No vendor lock-in: The serverless feature of QFaaS is built on top of OpenFaaS [16] and Kubernetes, both of which are well-known classical platforms.This way, we could provide deployment flexibility and avoid the vendor lock-in problem, i.e., it could be deployed in any cloud cluster.We also demonstrate the ability to use external quantum providers, such as IBM Quantum, to execute quantum tasks and plan to extend QFaaS capabilities to support other providers when they are accessible in our region.
• High scalability and auto-scaling: Ensures high availability and scalability for future expansion by deploying functions on the Kubernetes cluster.QFaaS also leverages the advantages of Kubernetes to support auto-scaling features, i.e., automatically scaling up or down vertically to adapt to the number of user requests.
• Monitor function and system status: The engineer or system manager can monitor the system status and all deployed functions using built-in monitoring components in QFaaS.
These features ease the quantum software development burden, enabling software engineers to focus on developing more complex quantum applications to achieve quantum advantages.Our work contributes to bridging the gaps between classical computing and the future computing model for developing practical quantum applications.

Fig. 1 .
Fig. 1.An example quantum circuit for the Deutsch-Jozsa Algorithm (generated by using Qiskit)

4. 2 . 1
QFaaS APIs and API Gateway.QFaaS comprises two kinds of APIs that expose to the appropriate user, called Service APIs and QFaaS Core APIs.•Service APIs are the set of APIs corresponding to the deployed functions.Each function running on the Kubernetes cluster has a unique API URL accessible to an authorized end-user.•QFaaS Core APIs set is one of the most important components in the QFaaS framework.It comprises a set of secure REST APIs, which provide primary operations among all components of the whole system.These APIs simplify the function development, invocation, management and monitoring.QFaaS Core APIs also facilitate the main functionalities of the QFaaS Dashboard and QFaaS CLI tool.We explain the detailed design and implementation of QFaaS Core APIs in Section 5.1.

4. 2 . 3
Classical Cloud Layer.This layer comprises a cluster of cloud-based classical computers (physical servers or virtual machines), where the QFaaS functions are deployed and executed.All the classical processing tasks, including pre-processing and post-processing, are performed at this layer.

4. 2 . 4
Quantum Cloud Layer.This layer is the external part, indicating the quantum cloud providers (such as IBM Quantum and Amazon Braket), where the quantum job can be executed in a physical quantum computer.Quantum providers can provide either quantum simulators or actual quantum computers through their cloud services and could be accessed from the Classical Cloud layer.4.2.5 MonitoringLayer.This layer includes different components which periodically check the status of other layers:• Quantum job monitoring component periodically checks the job status, queuing information, and quantum job result from external quantum providers.•Function monitoring component provides the current status of deployed quantum functions and function usages (such as the number of invocations).•System monitoring component provides the status of the overall systems, such as network status and resource consumption at the Kubernetes cluster.•Deployment monitoring component tracks the function deployment process to provide the quantum software engineers with helpful information to figure out the issue during the function development process.

4. 2 . 6
User Interface.QFaaS offers two main ways for quantum software engineers and end-users to interact with the core components using a command-line interface (QFaaS CLI) or a friendly user interface (QFaaS Dashboard).

Fig. 4 .
Fig. 4. QFaaS Dashboard Example for invoking a Qiskit function with IBM Quantum provider

( 1 )
Function Development: Quantum Software Engineers develop their quantum function, using quantum SDKs for quantum computation and optionally including classical parts for pre-processing, post-processing, and backend selection.After finishing the development, functions are pushed to a Git-based code repository and the function deployment process is triggered.

( 6 )( 1 )
Classical Post-Processing: This optional step takes place at classical computation nodes to process the outcome from the quantum backend before sending it to the end-user via the API gateway.4.4 Operation Workflows of QFaaS 4.4.1 Workflow for developing and deploying quantum functions.We simplify the function development process for quantum software engineers by using QFaaS.They can follow these workflows to create a new function, update an existing function or figure out the issues during the development process: • Develop a new function: Figure 6 illustrates the function developing process, including seven main steps.The first two steps are the responsibilities of the quantum software engineer, and the QFaaS framework handles the remaining steps.Our simple 2-step procedure to develop a new quantum function is as follows: Create a new function by using the QFaaS Dashboard or the CLI tool:

( 6 )
Deploy the function into the Kubernetes cluster at the classical cloud layer.(7) Expose the service API URL endpoint corresponding to the deployed function.After this stage, the function serves as a service and is ready for invoking from end-users.

Figure 8
Figure 8 depicts the overall class diagram, with attributes and methods of each object in QFaaS Core APIs.

5. 2 . 1
Function Templates.Quantum function templates are Docker images containing the environmental setup for quantum function development.Each quantum SDK has a corresponding Dockerfile; which specifies all necessary

Code 1 .
Sample structure of a hybrid quantum-classical function

5. 3 . 1
Function Deployment.The overall function deployment procedure is implemented following Algorithm 1.

Fig. 11 .
Fig. 11.QRNG circuit for generating 10-bit random number (left -generated using Qiskit) and Sample code snippets to generate the quantum circuit with given integer input (right)

Fig. 12 .
Fig. 12.Average response time evaluation of QRNG function using the simulator of popular quantum SDKs and languages

6. 3
Case study 2: Shor's algorithm with IBM Quantum Cloud Provider Shor's algorithm[49] is one of the most famous quantum algorithms for proving the advantage of quantum computing together with its classical counterpart.It is well-known for finding the prime factors of integers in polynomial time, which raises the severe risk for classical cryptography based on the security of large integers such as RSA.

6. 3 . 2
Deploy and invoke Shor function.The deployment process of the Shor function is similar to the QRNG function in the previous section.
e., one party always knows precisely the state of the other, even if they are very far away.In other words, if a pure state | ⟩  on two systems A and B cannot be written as| ⟩  ⊗ |⟩  , we called it is entangled [33].2.1.2Quantum Gates.To perform the quantum operations on qubits, we apply quantum gates, which is conceptually similar to how we apply classical gates, such as AND, OR, XOR, and NOT on classical bits to perform classical computation.The quantum gates are always reversible, i.e., a qubit does not change its state if we apply the same quantum gate twice between the qubit initialization and the measurement.For example, we could use the Hadamard (H) gate on qubit |0⟩ to create an equal superposition |+⟩ = 1 √ 2 (|0⟩ + |1⟩).If we apply the H gate again, the |+⟩ state will be reversed to the original |0⟩ state.A quantum gate U could be represented by a unitary matric such that  †  = I where I is the identity matrix.The general representation of a single-qubit gate U is as follows:  (, , ) = cos( /2) −  sin( /2) NOT (CNOT) gate and Toffoli gate.CNOT gate, for instance, is a controlled two-qubit gate, i.e., the target qubit will change its state if the control qubit is |1⟩ and will not change its state if the control qubit is |0⟩[33].The matrix representation of the CNOT gates is as follows:

•
[12]it[1]is well-known and probably the most popular (as per the Github repository's star count) Python-based open-source SDK for developing gate-based quantum programs, initially developed by IBM.Qiskit has a wide range of additional libraries and support tools and is best suited to the IBM Quantum Cloud platform[31].We can create a Qiskit program by multiple methods, by writing the Python script, using Jupyter Notebook, or using an online Quantum Composer provided by IBM Quantum.Then, we can run that program by using a built-in simulator (such as Aer Simulator, or QASM simulator) or sending it to execute in an IBM quantum computer.•Cirq[12]isanother prevalent open-source Python software library introduced by Google for quantum computing.

Table 2 .
Feature comparison of QFaaS and Related Work for Quantum Software Development (N/A: No information available)