1 Introduction

The construction of the first quantum computer capable of implementing qubits (Chuang et al., 1998), as well as the concepts of superposition and entanglement, allowed us to manage all possible states of a computer at the same time. This increase in computing power not only makes it possible to solve problems in less time than with classical computers, but it also makes it possible to address high complexity problems that were not solvable in a reasonable time (Zhou et al., 2020). Thanks to the convergence of different disciplines such as quantum mechanics, mathematics, and computer science, a new paradigm of software development and computing has emerged, the so-called quantum computing, which is still in its early stages of development (Piattini et al., 2021).

As an early stage research topic, quantum computing is continuously being tested, corrected, and improved and, therefore, it has created lots of interest in the community (Zhao, 2020). Consequently, many research centers, big companies, and countries have seen the relevance and impact that this technology could have in future society. Therefore, quantum computing is starting to establish itself as a commercial reality (MacQuarrie et al., 2020). Companies such as IBM, Amazon or Google are making great efforts to develop technologies that bring quantum computing to the market, to create significant value for industries.

As a result, in a few decades this field is starting to get a relevance that will make it as popular and well-known as classical computing is nowadays (Gyongyosi & Imre, 2019). This, coupled with the increasingly wide range of applications of this type of computing, makes quantum computing very attractive for technology companies and researchers.

In this context, several major computing corporations have already built working quantum computers. All this is thanks to the fact that great efforts and investments have been made in the construction of quantum computers, where processors with a higher number of qubits are being built and solutions to mitigate random noise or loss of information are being proposed (Grumbling and Horowitz, 2019). For example, IBM has recently launched the 433-qubit Osprey processor and for the year 2023, it has announced that it will launch the Condor processor with more than 1000 qubits.Footnote 1

In addition to quantum hardware, the new quantum computing paradigm also includes new quantum programming languages, which are fundamental in the development of quantum software. Consequently, there are tens of quantum programming languages and simulators, and real quantum computers can already be used by the general public through the cloud. All this is motivating software development companies to take the first steps by launching their proposals for the integral development of quantum software (Pérez-Castillo et al., 2020; Bergholm et al., 2018; Wille et al., 2019).

Following this approach, this paper provides an empirical analysis of the current status of quantum computing service providers from a software engineering perspective. From this point of view, the number of companies offering quantum services has increased considerably, as well as the number of quantum computers and other alternatives available to execute quantum algorithms and/or quantum tasks. With so many alternatives on the market, the process of selecting the best technology to execute a given task is not trivial. Therefore, the objective of this work is to analyze and compare the existing technological alternatives under the same criteria. Subsequently, based on the results obtained and the problems detected, we propose an extension of a previous work (Garcia-Alonso et al., 2022) where a quantum approach to the API Gateway pattern is established as an agnostic tool for the development of applications that make use of quantum tasks.

In order to do that, the rest of the paper is organized as follows. Section 2 introduces the motivations for carrying out this work. Section 3 presents the compilation of different quantum computing service providers and contains the results and analysis of the experiments performed from the algorithm executions in each quantum machine. Section 4 presents the extension of the API Gateway Service-Oriented Pattern as a solution to recommend the best quantum computer to run a specific quantum service at run time, among the main quantum providers. Finally, conclusions to this work are presented in Section 5.

2 Motivation

Quantum computing has already been a breakthrough in solving problems that were impossible to solve in a reasonable time by any classical computer. This is due to the computational power provided by the new concepts of qubit, superposition, and entanglement, which can be roughly defined respectively as the equivalent of the classical bit, the quantum state of the bit, and the relationship between two qubits whereby the value of one affects the value of the other (Bernstein & Vazirani, 1997).

The availability of quantum machines is leading to the emergence of more and more projects related to this technology, opening up a whole world of possibilities in health, cybersecurity, or artificial intelligence sectors (Rasool et al., 2022). This availability is possible thanks to cloud computing, where quantum computers are currently offered as PaaS (Soeparno & Perbangsa, 2021). This is all besides that many large tech companies have already invested heavily in quantum technologies, which are increasingly focusing on cloud services. However, the evolution of this quantum software and technologies without following standards that establish the technical requirements, specifications, and guidelines to be followed is causing a vendor lock-in effect. Therefore, efforts should focus on unifying access to quantum computers from different providers and facilitating quantum software development. This is one of the main motivations that have led to this work.

As follows, from a service engineering point of view, the integration of quantum software should not be very different from that of classical services (Rojo et al., 2021). There are already proposals that address this problem by proposing Quantum Computing as a Service (Rahaman & Islam, 2015; Moguel et al., 2022). In this way, microservices encapsulating quantum software would be offered, which could be invoked from classical machines, thus making available the potential of quantum computing with existing communication and invocation mechanisms. Such architectures, where quantum and classical computing collaborates to solve problems and provide solutions to users, are called hybrid classical-quantum architectures.

One of the possible uses of this type of architecture will be to solve real-time problems such as traffic management in cities, where the well-known Travelling Salesman Problem (TSP) (Srinivasan et al., 2018) can be used to calculate the best routes for vehicles. But this is where we face one of the problems of quantum computing, the development of software that is compatible with different providers. Today, implementing the same algorithm for different quantum computing providers means having different source codes, implemented using the SDKs of each provider. This problem implies, in some cases, having to redesign the algorithm because the implementation is not compatible with a given provider (De Stefano et al., 2022).

Generally, few studies analyze in depth the different quantum computing providers. We can find some studies such as those by Zhao (2020) and Serrano et al. (2021) that offer an overview of the current state of this type of systems, analyzing the circuit programming languages they use, the technology that is available for the different phases of the quantum software life cycle, and comparing them with each other. However, they do not perform an empirical analysis of current systems where parameters such as cost or execution time are measured for a specific practical case. In this paper, we present the results and conclusions obtained from an empirical study that focuses on an analysis of the main quantum computing providers through the execution of a real problem.

3 Quantum computing providers

This section analyzes the current situation regarding the different options and possibilities that exist today to develop a quantum software solution. To achieve this, a Quantum Phase Estimation (QPE) algorithm to resolve the TSP has been chosen as a case study to be developed, deployed, and executed in different quantum machines using different technologies.

3.1 Travelling salesman problem

The chosen problem remains the same throughout all the tests and executions performed to ensure that the results have the same root and that the comparison can be performed properly. This problem, known as the Travelling Salesman Problem (TSP), is commonly used as an example for explanations and conceptual testing.

According to Karp (1972) the TSP belongs to the NP-hard problem class. In this set of problems, if the algorithm is decomposed into smaller problems, each one will be at least as complex as the original one. This is one of the reasons for the selection of this problem since it has no optimal solution yet found in classical computing. They have a peculiarity that is the root of the complexity—as the problem size increases so do the possible solutions, usually in an exponential way.

This problem was first approached in classical computing by using brute force, which was proven very inefficient as the problem size increased beyond a specific point. Other approaches like branching and bound algorithms or heuristics were used, improving the results obtained significantly, but still far from being optimal in every case (Srinivasan et al., 2018). While quantum algorithms cannot solve NP-hard problems in polynomial time, they can provide exponential speedup compared to classical algorithms for certain types of problems.

Consequently, as mentioned above, TSP is a well-known optimization problem, and a classical algorithm requires an exponential amount of time to solve for large inputs. Therefore, we have considered the exact solution as the main requirement and chose a QPE algorithm. This choice is because—apart from Grover’s algorithm—this kind of algorithm is known to provide exact solutions for certain types of problems, including TSP, and provides exponential speedup compared to classical algorithms.

To formulate this problem, we have based on the definitions given by Papalitsas et al. (2019) and Ohlmann and Thomas (2007), which are commonly accepted as a standard in the relevant literature.

In these works, the problem is defined using a directed graph \(G = (N, A)\), where N represents the set of cities and A represents the set of roads connecting them. The cost of traversing a road (u, v) is denoted by \(c_{u,v}\). To facilitate the formulation of the problem, the city at index 0 is defined as the depot, and every tour must begin and end at the depot. A tour is represented as an ordered list \(P = (p_{0},p_{1},...,p_{n},p_{n+1})\), where \(p_{i}\) is the index of the city in the \(i^{th}\) position of the tour, and \(p_{0} = p_{n+1} = 0\).

Therefore, in the classical formulation of the TSP, the objective is to minimize the sum of the arc traversal costs along the tour, and can be summarized as:

$$\begin{aligned} min \sum_{i=1}^{n+1} c_{p_{i-1},{p}_{i}} \end{aligned}$$
(1)

In Eq. (1), it is assumed that \((p_{0},p_{1},...,p_{n},p_{n+1})\) is a feasible route.

In recent years, with the advances of quantum computing, this problem has been approached from the quantum point of view from the perspective of both adiabatic and gate-based quantum computing—the two models that currently exist for quantum computing (Albash & Lidar, 2018; Humble et al., 2019). It is important to remark that in this paper we will focus on the quantum gate-based model because it is the most extended among the major companies.

The way this algorithm is going to be implemented will vary depending on each technology used. However, the purpose of this work is to follow the same approach for all of them when possible. This approach is the one described by Srinivasan et al. (2018), which is based on the Quantum Phase Estimator (QPE) algorithm, that calculates a phase for each of the eigenstates considered since it offers a very efficient yet simple way of implementing the TSP.

As the above TSP definition states, the objective of this algorithm is to find the path with the minimum cost/distance/time. Therefore, in the implementation of the problem, in order to keep it simple and small, there will be a total of 4 different cities (N = 4). Moreover, given the distance between each of the cities, denoted by \(\phi _{i,j}\)—cost of travelling from city i to city j—an input matrix B will be created, where \(B_{i,j} = e^{i(\phi _{i,j})}\). Next, unitaries \(U_{j}\) will be constructed from matrix B, which will be diagonal unitary matrices. The elements of these diagonal unitary matrices \(U_{j}\) are then initialized to zero, and the eigenvalues of this matrix are estimated using the phase estimation algorithm. These phases can be normalized to be within 0 and \(2\pi\) which are the range of distances between cities given in the problem. U is then created by taking a tensor product of all these unitaries (\(U_{j}\)).

The representation of the TSP using a graph can be seen in Fig. 1.

Fig. 1
figure 1

Representation of the TSP using a graph

Full size image

To really want to solve the TSP and obtain the best route, we need to repeat the above process for each eigenstate, creating a different circuit for each one and, after each circuit has been executed, collect all the results and determine which eigenstate has the phase with the smallest value to obtain the associated Hamiltonian cycle that would provide the final answer. Therefore, there are \((N-1)!\) eigenstates of U with eigenvalues, which are the total cost of the corresponding Hamiltonian cycle as a phase.

More information about the mathematical proof and reasoning behind the quantum implementation of the TSP can be found in Srinivasan et al. (2018).

3.2 Quantum service providers analysis

We now proceed with analyzing some of the most popular and innovative solutions for developing and executing quantum software in the market, prioritizing the integrated tools and options for quantum circuit development that those platforms offer over local alternatives when possible.

The main providers that we have analyzed are IBM QuantumFootnote 2, Google Quantum AIFootnote 3, Azure QuantumFootnote 4, and Amazon BraketFootnote 5. Other quantum platforms and service providers were initially selected to be part of this analysis but were discarded either because they differed too much from the architecture of the gate-based model used by the rest of the quantum computers, and the comparison would not be fair—D-Wave SystemFootnote 6—or because they were not exactly quantum service providers, but relied completely on other platforms to provide a quantum computer on which to run algorithms—QC Ware ForgeFootnote 7.

Another quantum platform that was discarded was Stim (Gidney, 2021), which can be used to simulate the behavior of stabilizer circuits. However, it is important to note that Stim is not a quantum service provider like IBM Quantum or Azure Quantum. Rather, it is a software tool that can be used to simulate the behavior of quantum circuits. While Stim may not be directly comparable to the gate-based model used by other quantum computers, it may still be a valuable resource for those interested in quantum computing.

Fig. 2
figure 2

Overview of quantum providers solutions

Full size image

Figure 2 shows an initial review of the main providers, mentioned above, that have been included in this study. The figure not only highlights the many quantum computers and simulators offered by these providers, but it also includes the main languages and libraries they offer for the development of quantum algorithms. Therefore, it can be observed that companies are making great efforts in quantum computing, especially in the construction of quantum computers and processors with a higher number of qubits, as well as offering multiple simulators that allow the study of a quantum system in a programmable way. In addition to quantum hardware, the new quantum computing paradigm also includes new quantum programming languages and libraries, which are fundamental in the development of quantum software, with Python being the most common language among the analyzed providers (Silva, 2018).

The comparison included in the following sections takes place on different levels, analyzing the providers themselves along with the services offered, and finally developing a quantum algorithm in each of them and executing that algorithm in the quantum hardware provided. Although we have included simulators in the comparison, in order to analyze the performance and capabilities of these quantum providers we have exclusively used real quantum computers provided by the analyzed providers.

To find out the best time to run experiments on the quantum machines of these suppliers, we have consulted each provider’s specific guidelines and recommendations as to what is the best time of day to perform runs on their quantum machines. In addition, we have also considered factors such as the working hours of the provider’s technical support team, the availability of computing resources, and the workload on the quantum machine at that time. All this is to achieve more accurate results and make the comparison of providers fair.

The implementation of the algorithm for each of the providers analyzed can be found in the Bitbucket repositoryFootnote 8.

3.2.1 IBM quantum

IBM QuantumFootnote 9 provides multiple quantum computers in a cloud-based service, tools like Qiskit Runtime, and a graphic user interface to allow users to build several quantum algorithms. These algorithms based on quantum circuits can be defined in OpenQASM or Qiskit languages or with the mentioned web quantum composer.

Table 1 General aspects analysis of IBM Quantum
Full size table

As a company, IBM has been established for many years, however, it wasn’t until 2016 that they made their first quantum computer available to the world via their quantum cloud service IBM Cloud. But despite being around for just 6 years as a quantum computing provider they are one of the most important ones, with the largest set of quantum processors and simulators in the market nowadays accessible via their cloud service, plus many on-site installations all around the world in countries like Japan, Germany or USA. Furthermore, it offers one of the most versatile development kits and tools for creating quantum algorithms and circuits.

With respect to quantum computers, the majority of the 20+ qubits quantum systems that IBM Quantum makes available are based on superconductors, that use cryogenic components to keep super cold temperatures on the system, which has been proven to be a very efficient way of creating a quantum system, but which has the drawback of needing special facilities and equipment to hold these systems.

Table 1 summarizes the analysis of the general aspects of IBM Quantum.

The circuit representing the TSP has been implemented using Qiskit, an open-source SDK for programming quantum circuits based on Python, accessed via Jupyter Notebooks hosted in the IBM Quantum Lab, and by the Pay-As-You-Go Plan. In order to be able to use also the quantum composition tool, the circuit has also been transformed from a Qiskit format to an OpenQASM 2.0 format. The visual representation of a fragment of the circuit is depicted in Fig. 3.

Fig. 3
figure 3

Partial representation of the TSP implemented in with Qiskit in IBM Quantum

Full size image

The process of creating this quantum circuit involves defining 6 qubits named “unit”, 8 qubits named “eigen”, and 6 classical bits to store measured results. The “unit” qubits represent the distances between cities, which are encoded as phases. The “eigen” qubits represent the computational basis states that have eigenvalues associated with them. These eigenvalues correspond to the diagonal elements of U, which is a matrix created by taking the product of all unitary matrices (\(U_{j}\)). Quantum gates are then applied to the circuit, including X-Gates to select input eigenvalues and Hadamard Gates to create a superposition state. Also, multiple unitary gates are applied to corresponding qubits before the QFT gate is applied to the “unit” qubits, which are then measured, storing the results in the 6 classical bits. The complete description of the design of the circuit can be found on Qiskit’s official websiteFootnote 10.

Then, we set the number of shots needed to execute the algorithm to 8192—in quantum computing, a shot refers to a single execution of a quantum circuit on a quantum computer.

The number of shots required in a quantum machine to execute the TSP depends on various factors such as the size of the problem instance, the specific algorithm used to solve it, the qubit connectivity of the quantum hardware, and the level of noise in the quantum system. However, the number of shots used for the execution has been decided to be 8192 in every provider, since this is the limit set by providers to offer a good quality of service to users and to maintain consistency between the different executions at the different providers (Mandviwalla et al., 2018).

As explained in the definition of the TSP, we repeated this circuit six times, once for each eigenstate. The eigenstates correspond to the different routes. After each circuit has been executed, we gathered all the results and determined which eigenstate has the smallest phase value and then checked which particular eigenstate it corresponds, to obtain the associated Hamiltonian cycle that would give us the final answer. This process has been carried out for each provider.

This vendor provides up to 127 qubits to execute a circuit on. We executed our circuit 8192 times (shots in the terminology of the vendor). Using their pay-as-go plan, the vendor charged $8.32 for the use of their service. After running the algorithm on the different machines provided by IBM, the average running time was 5.2 s and a queue time of 11.2 s.

3.2.2 Google quantum AI

Google has a significant research effort in Quantum Computing. Its Google Quantum AIFootnote 11 product deals with quantum computing, providing its machines to researchers so they can develop tests on them. One of the latest notable advances in Google’s QPU technology is its quantum processor, called Bristlecone, which contains 72 qubits.

In addition to hardware development, Google is also focused on developing quantum algorithms that can be used to solve problems that cannot be solved with classical computers. In this way, Google is moving forward focusing mainly on complex problems such as quantum machine learning or pattern recognition. Moreover, they have developed their development framework, called Cirq. This open-source quantum framework has been designed by Google to experiment with NISQ algorithms, where the details of the hardware in which the software will be executed are essential.

Table 2 summarizes the analysis of the general aspects of Google Quantum AI.

Table 2 General aspects analysis of Google Quantum AI
Full size table

The implementation of the TSP circuit using the Google Quantum AI platform and the Cirq framework is very similar to the implementation done in IBM Quantum. The main differences lie in the fact that the qubits with Cirq can be defined in three different ways: as labelled by any name, labelled by a number in a linear array, or labelled by two numbers in a rectangular lattice. Then, gates can be applied to these previously defined qubits and although gates cannot be defined as in other frameworks like Qiskit there is something similar called a “Moment” that allows applying a set of quantum gates to a set of qubits. Finally, the measuring is done over the qubits in a regular way as in the previous case.

However, when attempting to run a specific circuit on a real quantum processor (which are called “Devices” in Cirq) with Google Quantum AI, there is a particularity related to the topology of the quantum processors. The topology refers to the physical layout of qubits and the connectivity between them, which can have a significant impact on the efficiency and accuracy of the computation. Google Quantum AI uses a variety of different quantum processors, each with its own unique topology. For example, the Sycamore processor has a square grid layout, while the Bristlecone processor has a linear layout. Therefore, when we designed the quantum circuit for the TSP for a specific quantum processor, we had to take into account internally the topology and connectivity of the processors where it was going to be executed.

This provider allows up to 72 qubits for circuit execution, and 8192 shots were used with the Free plan resulting in no execution cost. After running the algorithm on various processors offered by Google Quantum AI, the average total run time was 8.935 s, which included a queue time of 8.1 s.

3.2.3 Azure quantum

Azure QuantumFootnote 12 is the quantum computing cloud service of Azure developed by Microsoft, with a diverse set of quantum solutions and technologies. It provides access to quantum computers from IonQ and Quantinuum and will soon add Rigetti and Quantum Circuits Inc. In addition, it provides a Quantum Development Kit (QDK) which is a complete SDK that includes a quantum-specific language called Q# and enables anyone to write quantum programs, simulate those programs on a classical computer, and then execute the program on the quantum computer connected to Azure. Thus, Azure Quantum ensures an open, flexible, and future-proofed path to quantum computing that adapts to your way of working and accelerates your progress.

Table 3 summarizes the analysis of the general aspects of Azure Quantum.

Table 3 General aspects analysis of Azure Quantum
Full size table

The implementation of quantum circuits in Azure Quantum goes along with Jupyter Notebooks. Furthermore, this platform has a higher level of customization since it is possible to choose the core of the notebook between two options: Python or Q#, and also choose the provider against which to run the jobs, again between two options: IONQ or Quantinuum.

However, some adjustments and modifications need to be done for the program to be ready to execute in IONQ’s quantum hardware:

Firstly, it is necessary to get the AzureQuantumProvider, by calling the method passing the ID of our resources and the region where it is located, to obtain the different providers that are available. In Azure Quantum, a resource is an entity managed by Azure. To use the Azure Quantum provider we need several resources, like an Azure Quantum workspace—where quantum programs are managed—and we need to obtain the specific provider’s quantum hardware ID and specify it when running our quantum program. In addition, a region is a specific geographic location where Azure Quantum resources are hosted. When we create an Azure Quantum workspace, we must choose a region where we want to deploy the resources associated with the workspace. The region selected will determine the location of the quantum hardware providers we can access. Secondly, to implement the TSP circuit, we need to define different gates. This circuit implementation is very similar to those used in other providers. Finally, the execution of the circuit is performed on the different machines, modifying the number of qubits of the circuit according to the maximum number of qubits of each machine respectively.

With this provider, it is possible to run a circuit using up to a maximum of 29 qubits. For this case, 8192 shots were used with a pay-as-you-go plan, resulting in an execution cost of $0.0143. After running the algorithm on different machines offered by Azure Quantum, the average runtime was 5.15 s, with a queue time of 17 s included.

3.2.4 Amazon braket

Amazon BraketFootnote 13 is a fully managed quantum computing service created by Amazon Web Services (AWS) and designed to help speed up scientific research and software development for quantum computing.

Table 4 General aspects analysis of Amazon Braket
Full size table

It offers a single point of access to a variety of quantum computing technologies, and can also be used in hybrid approaches.

Table 4 summarizes the analysis of the general aspects of Azure Quantum.

Amazon Braket offers a Platform as a Service (PaaS) for implementing and executing quantum algorithms that integrates with classical software and can also handle hybrid software. In this context, hybrid software refers to applications or algorithms that combine classical and quantum computing elements to solve complex problems. Using this service, AWS users can access a group of different quantum simulators developed by Amazon, including four simulators for different purposes, and several quantum computers from different providers, as can be seen in Table 4. With its hybrid computing capabilities, Amazon Braket provides a powerful platform for building, testing, and deploying quantum-classical applications in the cloud.

To implement the TSP algorithm, since Amazon Braket has its own syntax, different from Qiskit, and not all the gates originally used are supported by the Rigetti hardware, it was necessary to look for an alternative to developing the TSP circuit on this platform. For this purpose, there is a Qiskit provider for Amazon Braket and Amazon gives support to use it within their SDK. The implementation of the algorithm can be found in the Bitbucket repositoryFootnote 14.

This provider supports circuit execution with up to 80 qubits. For this particular case, the circuit was executed using 8192 shots with a pay-as-you-go plan, resulting in an execution cost of $3.17. The algorithm was then run on various machines offered by Amazon Braket, with an average total run time of 9.95 s, including a queue time of 30 s.

3.3 Threats to validity

While the previous section has provided an overview of the quantum service providers analyzed in this study, it is important to acknowledge the potential threats to validity that could impact the accuracy and generalizability of the findings.

It is important to note, as a first point, that some functionalities of quantum providers, which have not been analyzed in depth in the above comparison, are those related to platform-specific functionalities. For example, the availability of specific quantum algorithms, quantum error correction techniques, and quantum networking capabilities may be critical for certain projects. Therefore, they have not been deeply taken into account because it is possible to make a fair comparison.

In this way, this study provides an overview of quantum service providers, focusing mainly on their performance and capabilities using real quantum machines. Therefore, for this study, we do not consider quantum simulators either, and although they could be of interest to software developers, the results obtained under the criteria established at the beginning of the study could devirtualize the entire study, and affect the accuracy and generality of the conclusions.

The next steps to improve this study would be the inclusion of new service providers and quantum machines, regardless of the entry point to them, and the addition of evaluation criteria that would allow us to compare the results of quantum machines versus software deployed in quantum simulators.

3.4 Analysis and comparison of results

After analyzing all these providers, using them to develop and execute the TSP algorithm, the first conclusion that can be drawn is that, even though they are all platforms directed towards a similar objective, each one has been designed with different technology and different criteria in mind, which in the end results in each platform serving a specific purpose and fitting more some projects than others.

Table 5 shows the entries for all the experiments performed on the providers. In summary, the number of shots used for the execution—the number of a single execution of a quantum algorithm on a QPU—has been decided to be 8192 in every provider, since this is the limit set by providers to offer a good quality of service to users (Mandviwalla et al., 2018), and a good distribution of the results in case there was noise. During the execution of the algorithm on the different quantum computers, it has been able to identify that the number of shots is better if it is high like the one we have used since there will be noise and some shots will get wrong results, due to the signal noise that still has this kind of technology in development.

Another thing that we can easily observe is the maximum number of qubits based on the machines they offer. Currently, IBM Quantum is the provider that supplies the largest number of qubits, followed by Amazon Braket, although this is quite variable depending on the progress of the technologies and the machines they offer respectively.

One more conclusion that can be drawn is the price of running the experiments, which is highly variable from one provider to another, the least expensive being Azure Quantum and Google Quantum AI which is free. These prices differ depending on the chosen payment plan and the number of shots mostly.

Table 5 Overview of the inputs for all experiments
Full size table

Other factors to consider when choosing a quantum platform for a project is the specific application or use case. Different quantum platforms offer various functionalities that cater to specific applications. For instance, IBM Quantum has developed a range of software development kits (SDKs) that provide access to different domains such as quantum chemistry, optimization, and finance. On the other hand, Google Quantum AI has developed the TensorFlow Quantum library, which enables developers to build and train quantum machine learning models. Similarly, Azure Quantum provides access to the Quantum Development Kit, which includes Q# programming language and quantum simulators, while Amazon Braket offers integration with different classical computing tools and access to different types of quantum hardware. We know that these factors can influence the decision to choose a quantum platform for specific projects, but they have not been analyzed in depth in the above comparison, because they are more platform-specific, so it is not possible to make a fair comparison.

With regard to the results, as can be seen in Table 6, we can check that the results are “100100” for all the experiments. Despite the inherently probabilistic nature of the TSP algorithm in quantum computing, which arises from the probabilistic nature of quantum mechanics rather than just noise or errors, we obtained consistent results in the executions of the algorithm (Srinivasan et al., 2018).

The result “100100” in the context of the TSP on quantum machines is the solution that is represented as an eigenstate of the quantum system, as a binary representation of a solution to the TSP problem, where each digit represents the visit order of a city in the tour. Concretely, it means that the salesperson visits cities 1, 2, 3, 4, and 1 in that order. Moreover, these results are consistent because the same result is obtained in all experiments. Consistency is an important property of any computational result, including those obtained through quantum algorithms, because it indicates that the result is reliable and reproducible, as it is in this case. Furthermore, can be seen that the time elapsed from the moment the execution is launched on each platform is different. Although these times are indicative and variable, as it depends on the number of users that are sending jobs to the machines at a given moment.

Table 6 Overview of the results for all experiments
Full size table

We also can notice that the execution times are similar, and where we can find the biggest difference is in the queue times. These times make the difference from one provider to another. Specifically, the compile times of IBM Quantum, Google Quantum AI, Azure Quantum, and Amazon Braket are similar. The same happens for the execution times, however, for the queue times, can be observed that Amazon Braket’s is almost double the maximum of the three previous ones. From this, we can conclude that the queue time is the time that makes the difference between all providers. This could be due to the number of concurrent users that each of them has.

Furthermore, after analyzing the implementation of the TSP in each supplier, we deduce that it is difficult to work with machines from different suppliers, without having extensive knowledge about the operation of all of them. We even face this problem within the same supplier, where, depending on the machine to be used, the circuit must be implemented differently. In other words, there is a limitation in terms of the programming language—SDK—and the topology of the quantum processor used by the machine to be used for execution.

This means that there is the problem that the providers are independent, which is against what is traditionally known, where the same program, even if it has been implemented in different languages, can be executed on any classical computer.

Therefore, there is a need for middleware that allows the user to connect with all quantum machines agnostically, such as the Quantum API Gateway pattern proposed by Garcia-Alonso et al. (2022). Based on the knowledge obtained from the previous executions and comparative, we can state that currently quantum service providers, while still offering some kind of abstraction, are quite low-level. The question arises as to whether it is possible to get some abstraction and greater scalability from quantum mechanics and machines in the same way that classical programming languages allowed us to abstract from gates and transistors to generate binary information. In this way, the quantum software would be defined in a standard language. Consequently, when calling the microservice, this middleware depending on the restrictions indicated by the user would translate the software to the SDK of the corresponding provider. And last, would deploy it on one of its machines, returning the response to the request in a standard format.

4 Quantum providers through quantum API gateway

An API Gateway is a pattern used for the composition of microservices in applications. It serves as input to the system and to the routes where the microservices are located, as well as being able to apply filters to requests, aggregate results, or even implement logic. This last is what is proposed in Garcia-Alonso et al. (2022), where a machine learning model is implemented to recommend the best quantum machine depending on the parameters indicated by the user in the request. In short, it allows for optimizing the deployment strategy of a quantum service at runtime.

The Quantum API Gateway is developed in Python, specifically using the Flask library to define the API with the different endpoints. The project is currently deployed on an AWS server and is presented with a reference implementation for Amazon Braket.

We have performed tests with the Amazon Braket implementation reference, and we have extended this tool to cover other providers, such as IBM Quantum, one of the providers discussed in the previous section.

Through the integration of multiple providers with the Quantum API Gateway, and using the TSP algorithm to validate the new implementation thoroughly, we have successfully validated its technological capabilities. The integration with Google and Microsoft platforms is currently under development to obtain the system shown in Fig. 4, which significantly improves the deployment and execution of quantum services.

Fig. 4
figure 4

Quantum providers solutions through Quantum API Gateway

Full size image

In the extension we have made on this tool, it now uses the information provided by the providers about the state of the execution queues on their machines, and deploys the quantum service on the best machine on the best platform based on the user’s constraints. In this way, the Quantum API Gateway agnostically deploys quantum services in a constraint-aware way, and after receiving the user’s requests, returns the response in a standard format for all providers.

Fig. 5
figure 5

Quantum API Gateway process

Full size image

The execution process—graphically depicted in Fig. 5—starts with a classical machine that wants to invoke a quantum service (step 1). This service call includes input and optimization parameters for the quantum machine, such as the number of qubits, the maximum price to be paid for execution, and the type of machine needed for execution—annealing or gate-based. When the Quantum API Gateway receives the call to the service, it requests information about the status of the machines to the QCaaS Provider (step 2) and, through its recommender, chooses the most optimal one to deploy the service (step 3). Once the machine is chosen, it launches the service (step 4) and returns the response in a standard format to the classic machine (step 5). Once the execution is finished, the quantum machine recommender is fed back with the data obtained during the execution (step 6).

Therefore, with this process and by choosing the best computer for each task, the Quantum API Gateway provides advantages over existing methods for using quantum services. For example, it offers developers the flexibility to select at runtime between different providers, depending on the type of code the developers want to run. This takes into account the number of qubits required for the computation to ensure that only machines with sufficient computational power are used. This information is generally provided by the providers, being available as static data—in the case of Amazon Braket—and as backend information—IBM Quantum (this information is specific to each service provider). In addition, the tool allows the flexibility to select from gate-based or annealing-based machines, assuming both quantum service implementations are available. This feature allows for greater efficiency and accuracy in quantum computing.

Besides the number of qubits, the Quantum API Gateway also evaluates the cost of running the chosen computer, taking into account several factors. These include the number of shots the developer needs, the maximum cost threshold the developer is willing to pay, and the cost per shot. In this context, shots refer to the number of iterations needed for finding the solution and obtaining the results of the service execution.

To calculate the service execution cost, the tool combines the cost per run with the cost per shot, multiplied by the number of shots. Only machines that meet the cost threshold are selected, and this information is easily accessible from some providers such as Amazon Braket. However, other providers currently do not offer this type of information at runtime. For these cases, a cost estimate is made from the technical specifications. In this latter instance, the choice of supplier is then made based on availability, as explained below.

Once the developer selects the machines that meet the cost threshold, the Quantum API Gateway checks the availability of quantum computers that meet all these requirements. It then calculates the estimated execution time for each machine, which provides the developer with valuable information to make an informed decision. This is done based on the context of the execution that was also established during the comparison of the providers—the day of the week, the start time of the execution, and the actual time taken by previous executions performed on that computer.

Overall, this process ensures the selection of the most cost-effective and efficient machine to run the quantum service. Therefore, with these tool improvements, we ensure that the optimal machine is selected for each service call. By providing a standard format for service responses and incorporating a feedback mechanism for the quantum machine recommender among multiple providers, streamlining the entire execution process, and allowing developers to abstract from both quantum machines and providers.

5 Conclusion

Nowadays, many important companies and research institutions have developed quantum computers, along with new start-ups solely dedicated to this field, and offered access to them to researchers, developers, and other companies through cloud services. For this reason, as the complexity of quantum software increases, the more challenging it becomes for quantum software programmers.

In the absence of a standard, each quantum computer has its own topology and restrictions and is developed with different technology, resulting in qubits of different natures that behave in different ways. Similarly, many quantum languages, frameworks, and libraries have been developed, each one with a different purpose and hardware for building quantum circuits and algorithms. As a result, if the topic of quantum computing was already complex and required some background knowledge to dive into it, the initiation and learning curve has been getting steeper with the diversification of quantum developing tools and quantum hardware

From the outcomes retrieved and the comparisons and analysis performed in this paper, it should be easier and clearer which quantum platform to choose depending on the requirements and objectives of the project. Therefore, it will be possible to reduce considerably the time spent on researching the market for the most suitable option by taking into account and analyzing as many characteristics in each provider as possible.

In addition, the use of the API Gateway service-oriented pattern, for the invocation of quantum services, would simplify the development times of quantum algorithms, since it would be responsible for translating the service for each machine of the different providers. Additionally, it would provide unified access to quantum computers from various vendors and help the development of hybrid systems that include quantum services.

This proposal, beyond technological validation, would facilitate access to new service providers, access to this technology for any developer of classical or quantum software, and the development of classical applications that at some point in their workflow require the execution of a fragment of quantum code. All this would make it possible to take full advantage of this technology without the need to have an exhaustive knowledge of each of the providers and machines that can be found in the market.