Trials and Tribulations of Developing Hybrid Quantum-Classical Microservices Systems

I. INTRODUCTION

• Hybrid systems require classical and quantum services to coexist and interact, making service engineering a natural framework for their collaboration.The paper notes that microservices can provide distributed, cohesive processes that communicate through messages.Source: §I · pp. 1–2
• Current quantum platforms tightly couple services to quantum code and hardware, expose hardware-specific results and errors, and limit orchestration through unavailable intermediate verification.These constraints make agnostic invocation impossible and put composability, maintainability, reusability, and modularity at risk.Source: §I · p. 2
• The paper implements a Traveling Salesman Problem quantum microservice on Amazon Braket and tests it across the quantum hardware supported by the platform.The authors use the results to identify lost service-computing benefits and compare current technology with the desired state of quantum service engineering.Source: §I · p. 2

II. BACKGROUND

• Microservices encapsulate data and logic in remotely exposed services that can be deployed, changed, substituted, and scaled independently.Implementations can mix programming languages and storage paradigms, and commonly use REST HTTP or asynchronous message queues.Source: §II · p. 2
• Cloud deployment aligns with microservices through elasticity, distribution, automated management, and loose coupling; continuous delivery and DevOps are also commonly used.The microservice architecture can improve deployability and modifiability, mitigating barriers to those approaches.Source: §II · p. 2
• Quantum Computing as a Service provides cloud access to quantum computers, but still depends heavily on the specific hardware and its underlying details.The paper describes efforts to raise abstraction beyond QCaaS, including Quantum application as a Service and a TOSCA extension for quantum-service deployment.Source: §II · p. 3
• Braket supports adiabatic D-Wave and circuit-based IonQ and Rigetti hardware, whose distinct programming requirements complicate independent, maintainable, hardware-agnostic services.Annealing requires reformulating a problem as a quantum annealing specification, while circuit-based systems require knowledge of gates and circuit adaptation.Source: §II · p. 3
• The authors report that, to their knowledge, prior proposals had not addressed the challenges of creating quantum microservices for hybrid solutions.They cite quantum software-engineering work, including proposals for QaaS and quantum-service deployment through TOSCA.Source: §II · p. 3

III. TRAVELING SALESMAN PROBLEM

• TSP seeks a minimum-distance route visiting every city, and the number of possible routes grows from 12 for 5 cities to 3.1 × 10^23 for 25 cities.The paper notes extensions including the Capacitated Vehicle Routing Problem and TSP with Time Windows.Source: §III · p. 3
• Classical methods for these optimization problems have limitations, while quantum TSP algorithms have been developed for both adiabatic and gate-based computing.The paper cites adiabatic approaches and gate-based approaches [25], [26].Source: §III · p. 3

A. Formulation of the TSP problem

• A TSP instance is a directed graph whose nodes are cities and arcs are roads connecting each pair of cities.Each road has a traversal cost, generally interpreted as travel time.Source: A. Formulation of the TSP problem · p. 3
• A tour is an ordered city sequence that starts and ends at depot 0 and visits each other city exactly once.The formulation assumes the listed sequence is a feasible tour.Source: A. Formulation of the TSP problem · pp. 3–4
• The objective is to minimize the sum of arc traversal costs along a feasible tour.The formulation follows previous works,.Source: A. Formulation of the TSP problem · p. 3

B. TSP on Quantum Computing Architectures

• Adiabatic quantum computing suits TSP optimization, while gate-based solutions require a more challenging circuit-based approach.Source: B. TSP on Quantum Computing… · p. 4

1) TSP on Adiabatic Quantum Computing:

• The adiabatic proposal encodes the graph as an Ising model or QUBO, then applies quantum annealing to seek minimum travel cost.Source: 1) TSP on Adiabatic Quantum Computing · p. 4
• The algorithm takes a matrix of intercity travel costs and returns the lowest-cost Hamiltonian cycle; the starting city does not affect route equivalence.For an undirected graph, the passage gives (N −1)!/2 possible routes, compared with (N −1)! for a directed graph; the illustrated output omits the return to the starting point.Source: 1) TSP on Adiabatic Quantum Computing · p. 4

2) TSP on Gate-based Quantum Computing:

• Gate-based TSP is more complicated than adiabatic optimization because circuits that work across problem instances are difficult to define.Source: 2) TSP on Gate-based Quantum Computing · p. 4
• The chosen QPE approach calculates a phase for each candidate Hamiltonian-cycle eigenstate, with the optimal path corresponding to the minimum phase.The phases are checked using another quantum algorithm, such as minimum finding.Source: 2) TSP on Gate-based Quantum Computing · p. 4
• The implementation prepares each eigenstate, applies controlled-U gates, then a QFT dagger, and measures the results.The unitary matrices encode graph costs after normalizing the cost matrix to the 0-to-2π range.Source: 2) TSP on Gate-based Quantum Computing · p. 4
• Unlike the annealing solution, the gate-based circuit is not generic: one circuit is generated per eigenstate and is tied to a concrete graph.Changing any graph element requires changing the circuit; generic parameterized-circuit proposals were not used because solving a given TSP sufficed for these experiments.Source: 2) TSP on Gate-based Quantum Computing · p. 5
• Classical computation selects the eigenstate with the smallest measured phase and returns its associated Hamiltonian cycle.Source: 2) TSP on Gate-based Quantum Computing · p. 5

IV. QUANTUM MICROSERVICES

• The microservice has two endpoints, one invoking the gate-based TSP solution and the other the adiabatic solution.Source: §IV · p. 6
• Braket offers D-Wave 2000Q and Advantage for adiabatic execution, and simulators or IonQ and Rigetti hardware for gate-based execution.Results are stored in Amazon S3 except for LocalSimulator.Source: §IV · p. 6
• Both endpoints use a device query parameter to select the hardware or simulator for quantum execution.Source: §IV · p. 6

A. Adiabatic quantum computing endpoint

• Figure 6 shows code for the adiabatic-solution endpoint.Source: A. Adiabatic quantum computing endpoint · p. 6, Figure 6 · p. 6
• The endpoint takes a .txt file containing the matrix weights and a device query parameter.Source: A. Adiabatic quantum computing endpoint · p. 6
• Its JSON response contains the best route found for the TSP and the distance to cover that route.Source: A. Adiabatic quantum computing endpoint · p. 6

B. Gate-based quantum computing endpoint

• Figure 7 shows the code for the circuit-based solution endpoint.Source: B. Gate-based quantum computing endpoint · p. 6, Figure 7 · p. 7
• For real quantum runs, results are stored in S3 and the endpoint waits internally for them to become available.The time to availability is undefined.Source: B. Gate-based quantum computing endpoint · p. 7
• Quantum tasks move through CREATED, QUEUED, and RUNNING before COMPLETED, CANCELLED, or FAILED; a poll timeout prevents blocking.Source: B. Gate-based quantum computing endpoint · p. 7
• A device query parameter selects the execution machine, but the circuit uses one fixed graph and cannot run on different networks.Source: B. Gate-based quantum computing endpoint · p. 7
• The endpoint returns the optimal path but not its cost because the algorithm does not know the path weights.Source: B. Gate-based quantum computing endpoint · p. 7

Number of qubits

• 14 qubits are required by the gate-based TSP implementation, exceeding IonQ’s 11-qubit capacity; the available D-Wave machines could run the annealing version.The evaluation also argues that services need mechanisms to determine qubit requirements, which are not straightforward across architectures and can affect cost and response time.Source: §V · pp. 7–8, Table II · p. 8

Precision of results

• More than 100 shots were needed in simulation for an acceptably certain correct result, while several hardware runs were unavailable, unexecuted, or inconsistent.The authors argue that shot-count and precision decisions should not be left to clients, since they affect service cost, quality, and financial profitability.Source: §V · p. 8

Response times

• The LocalSimulator took about 3 seconds at 1,000 and 10,000 shots and about 7 seconds at 100,000 shots; SV1 averaged 27 seconds, while D-Wave runs exceeded 20 seconds or took 25 seconds.The authors conclude that sending code for execution incurs the highest time cost, possibly because of queue waiting, and that unreliable response times impede customer acceptance.Source: §V · p. 8

Economic cost

• Amazon Braket charges a fixed price per quantum task plus a hardware-specific per-shot charge, but uncertainty in service availability, response time, uptime, and quantum-system state complicates service-quality guarantees.The authors say these uncertainties also affect the financial profitability of future quantum services.Source: §V · p. 8

Abstractions

• A generic endpoint could adapt an abstract TSP representation to adiabatic or gate-based hardware, but the proposed approach would still depend on Braket.The authors argue that platform-side handling of architecture and problem formulation matters because delegating those choices to clients tightens coupling and reduces service-engineering benefits.Source: §V · pp. 8–9

Platform limitations

• Current platforms tightly couple services to quantum code and hardware, lack transparent implementation replacement and execution-time optimization, and provide no orchestration mechanisms; this evaluation involved only one service.The authors identify resulting limits on composability, maintainability, reusability, and modularity, and call for further quantum service-engineering research.Source: §V · p. 9

Quantum services

• Research on quantum services in the cloud identifies challenges including hardware-specific algorithm implementations and quantum-service deployment.Quantum software engineering remains young, and work focused specifically on quantum microservices or hybrid microservice architectures is sparse.Source: §VI · p. 9

Deployment

• A TOSCA extension addresses quantum-software deployment, while another cloud deployment technique compiles circuit-based algorithms for specific computers [33].The paper’s implementation instead wraps quantum algorithms in a classical web service and exposes them as endpoints.Source: §VI · p. 9

Hardware adaptation

• Parameterized quantum circuits can adapt circuits to different hardware or problems, but do not apply to quantum annealing hardware [25], [31].Source: §VI · p. 9

Platforms and tools

• Azure Quantum, IBM Quantum, and other high-level toolkits seek to simplify or homogenize quantum access, but the authors know of no specific advantage for quantum microservices over Braket.The paper notes that service engineering beyond development and deployment also matters.Source: §VI · p. 9

Orchestration and operations

• Related work addresses hardware-based orchestration, reliability checks for selecting suitable hardware, and trust and security in quantum services [40].The authors say software orchestration solutions are still needed for quantum microservices to be used as easily as classical services.Source: §VI · p. 9

Research needs

• Taken together, these efforts indicate that more research is needed to develop an effective quantum service-engineering discipline.Source: §VI · p. 9

• The paper implements a quantum microservice, examines its integration into a hybrid microservices architecture, and tests it through Amazon Braket on quantum hardware from three vendors.Source: §VII · p. 10
• Experiments expose limitations in current quantum-computer platforms for developing and exploiting quantum microservices, and substantial research remains necessary to bring service-oriented and microservices benefits to quantum computing.Source: §VII · p. 10
• Because quantum software engineering remains young, classical microservice techniques cannot be assumed to work flawlessly; new knowledge, techniques, and methodologies are needed to bridge the paradigms.Source: §VII · p. 10