Quantum computing integration with classical apps

Some computational problems are impractical or intractable to solve on classical computers, even on large supercomputers. For some of these problems, a quantum algorithm can reach a solution using far fewer resources than the best known classical approach. A quantum computer uses quantum-mechanical effects, such as superposition and entanglement, to represent and process information in ways that a classical computer can't.

Quantum programs run on quantum providers that you reach by submitting jobs. Quantum targets expose different target profiles. Some profiles allow only quantum operations, and the classical logic you can run on them is limited. Other profiles allow both quantum and classical operations to run together on the provider.

Regardless of the target profile, classical compute components handle the surrounding application integration. Even when a quantum target accepts classical operations, you reach the target by submitting a job and waiting for the results. This article describes and compares two orchestration models for integrating quantum work with classical applications.

In practice, running a quantum program is a service call. Your classical application or client code submits a job to a target, waits for it to run, and retrieves the results. One or more classical compute components orchestrate each quantum job by doing the following activities:

• Preparing input data
• Submitting quantum computing jobs to a target quantum environment
• Monitoring job execution
• Postprocessing job results

Quantum integration models

You integrate quantum work with a classical application by using one of two orchestration patterns:

• Direct quantum integration. A client application or lightweight classical harness interacts directly with the Azure Quantum workspace. The client owns input preparation, job submission, monitoring, result handling, and the classical logic that surrounds the quantum execution.

• Workflow-orchestrated quantum integration. A workflow orchestrator owns the overall state and transitions. Quantum execution occurs in workflow steps that run alongside steps running on high-performance computing (HPC) or graphics processing unit (GPU) compute.

For a given application integration boundary, these patterns are alternatives. Either the client integrates directly with the workspace, or a broader workflow owns the quantum step. This article describes the implementation of each pattern.

The integration choice is independent of where the classical computation runs. Depending on the target profile and workload, classical logic can run within the quantum program, in the client harness between quantum executions, in the workflow orchestrator, or in a classical workflow step on HPC or GPU compute.

Decision matrix

Use the following decision matrix to guide your choice of integration patterns:

If your workload has these characteristics	Use this approach
One application or lightweight harness owns the full quantum job lifecycle, and the input preparation and result processing fit inside that client.	Direct quantum integration
You explore the properties of quantum hardware with handwritten quantum code, and one application or a small set of related applications consumes the results.	Direct quantum integration
The classical side is heavyweight and consumes quantum as one step among many, in a multistage pipeline whose stages each run on the back end that fits them, such as HPC, GPU, or a quantum target.	Workflow-orchestrated quantum integration
Quantum executions repeat, and the result of one execution generates the next quantum program or determines its parameters.	Workflow-orchestrated quantum integration

Scenario details

Both workflows implement the Asynchronous Request-Reply pattern and the steps defined for the Azure Quantum job lifecycle.

Quantum targets, especially quantum hardware, are limited resources. Azure Quantum allocates these resources through a job queue. When you submit a job, the job enters the queue for the target that you select and runs after that target finishes the earlier entries. To see the expected wait time, list the available targets. Calculate your full response time as the queue wait plus the job execution time.

The capabilities of a quantum target also vary. Some targets accept quantum operations only, while others run classical logic with quantum operations in a single job. This model supports algorithms that adapt during execution. Before you commit to a target, confirm that it supports the operations that your algorithm needs. For more information about how classical and quantum instructions run together, see Introduction to hybrid quantum computing.

Direct quantum integration

The following sections describe the direct integration model for integrating quantum work with a classical application.

Architecture

Download a PowerPoint file of this architecture.

Data flow

The following data flow corresponds to the preceding diagram:

1. A signed-in user triggers quantum job execution via a classical client application.

2. The client application inputs data into Azure Storage.

3. The client application submits the job to an Azure Quantum workspace, specifying the execution target or targets.

   The client identifies the workspace from its configuration and authenticates to the workspace by using a Microsoft Entra identity. A client that runs on an Azure-hosted resource can use a managed identity. A local client application authenticates with another Microsoft Entra identity, like a service principal or an interactive user sign-in.

4. A quantum provider runs the job on a target environment.

5. The client application monitors job execution by polling job status.

6. As soon as the quantum job finishes, the client application gets the compute result from Storage.

Components

• Azure Quantum provides a workspace, accessible from the Azure portal, for assets associated with running quantum jobs on various targets. Jobs run on quantum simulators or quantum hardware, depending on the provider you choose.
• Microsoft Entra ID coordinates user authentication and helps protect access to the Azure Quantum workspace.
• Storage provides storage for input data and results from the quantum provider.

Direct integration potential use cases

The direct quantum integration pattern fits the following use cases:

• One client application or lightweight classical harness owns the complete quantum job lifecycle without a broader workflow.
• The client can run surrounding classical work, such as input preparation and result processing.
• You explore the properties of quantum hardware, so you typically handwrite the quantum code rather than generate it dynamically.
• Use of the quantum components is limited to a single application or a small set of related applications.
• The quantum job represents a specialized solution, such as a molecular simulation, that only one specialized classical application uses.

Workflow-orchestrated quantum integration

The following sections describe the workflow-orchestrated model for integrating quantum work with a classical application.

Architecture

The workflow logic doesn't depend on any specific host or provider. The following flowchart shows the state machine: a single input, a loop over the steps, and the per-step phases. The quantum branch can include an optional program generation and optimization phase that classical steps don't use.

The back-end selector in the preceding flowchart is a logical phase rather than a required component, and can be a configuration lookup that routes each step to a fixed back-end type.

You can host this workflow on Azure with a set of classical services that submit and monitor the quantum work. The following diagram shows an example topology:

Download a PowerPoint file of this architecture.

Data flow

The following data flow corresponds to the deployment topology:

1. A client application submits a request through API Management, which authenticates the caller with Microsoft Entra ID and applies throttling before the request reaches the compute tier.
2. API Management forwards the request to the Input API, an HTTP-triggered function that validates it and starts the workflow orchestrator.
3. For a step that runs classically, the orchestrator routes the execution to a classical back end, such as an HPC cluster or GPU compute.
4. The classical back end writes its results and the updated pipeline state to Storage.
5. For a step that runs on quantum, the orchestrator routes the execution through the quantum path. The quantum path prepares the step's program, generating and optimizing it from the step's input or using a fixed implementation, and submits the job to the Azure Quantum workspace. The submission authenticates via managed identity.
6. The workspace runs the job on the selected quantum target.
7. The quantum target writes its results to Storage.
8. The orchestrator reads the updated state Storage and evaluates the pipeline's transition logic. If a convergence or iteration condition requires another quantum execution, the orchestrator uses the result to determine parameters for the next quantum program or to provide inputs that generate the next program. The pipeline then loops back to the appropriate step.
9. The client polls the Status API through API Management to track progress and retrieve the final results when the pipeline reaches a terminal state.

Components

• Durable Functions acts as the workflow orchestrator to run the pipeline as a state machine, coordinate the steps, and select the quantum or other compute type back end for each step's execution. You can implement the orchestrator with Durable Functions or another workflow engine.
• Azure HPC and GPU classical compute back ends run the non-quantum steps.
• Azure Functions hosts the HTTP APIs that start and monitor the workflow, along with the orchestrator that runs it.
• API Management is the entry point for client requests. It authenticates callers and applies throttling. To prevent the function app from being called directly, use Azure Functions networking options, such as inbound access restrictions or a private endpoint, so that it accepts traffic only from API Management.
• Azure Quantum provides a workspace for assets associated with running quantum jobs. Jobs run on quantum simulators or quantum hardware, depending on the target you choose.
• Microsoft Entra ID coordinates authentication and helps protect access to the Azure Quantum workspace.
• Storage stores input data, intermediate pipeline state, and results.

Alternatives

The architectures in this article run part of a compute task on a quantum target. For some compute challenges, existing services built to perform high-performance computing or provide AI functionality might be alternatives.

For scientific R&D workloads, Microsoft Discovery uses AI to orchestrate complex tasks across models, tools, and compute resources. Microsoft Discovery can coordinate various tools across multistep pipelines and is extensible, so you can connect your own tools and agents instead of building and operating the orchestration yourself. Integration with quantum capabilities, including running quantum steps, could use AI to take on the orchestration that this pattern builds by hand.

Workflow-orchestrated scenario details

In this pattern, a workflow orchestrator runs the workload as a pipeline of steps. The orchestrator behaves like a state machine in which steps repeat and loop until a termination or convergence condition is met. Each step follows the same shape: It prepares its input, executes, and processes the output.

The orchestrator selects the back end that runs each step. This selection is part of orchestration logic, not a separate service, and can be as simple as reading the target back end for each step from configuration. A step runs on a quantum back end or on classical compute, such as an HPC cluster or GPU compute. A lightweight classical step can run in the orchestrator itself. When quantum steps repeat, the workflow processes the result of one quantum execution to determine parameters for the next quantum program or to provide inputs that generate the next program.

A step that runs on a quantum back end can add one phase that classical steps don't have. That phase generates and optimizes the quantum program before execution. This phase is optional. The program can generate dynamically from the step's input, or it can come from a fixed implementation that skips this phase. A step that's eligible for quantum might still run on a classical back end when that fits the input better.

Quantum chemistry is a representative example. A typical pipeline uses classical steps to prepare a molecular system: Geometry optimization, a self-consistent field calculation, and active-space selection. The pipeline then computes a target property, such as the ground-state energy of a molecule. The energy-computing step keeps the same intent whether it runs on a classical approximation or on a quantum algorithm. You choose the back end based on the accuracy you need and the size of the problem.

The QDK/Chemistry library supports pipelines like these. The library provides modular components for the classical preparation steps and for generating a state-preparation circuit from the classically computed wavefunction, which a quantum back end then uses to estimate the energy with an algorithm such as quantum phase estimation. This circuit-generation capability is a concrete example of producing the quantum program dynamically from a step's input.

Potential use cases

The workflow-orchestrated quantum integration pattern fits these use cases:

• The classical side is heavyweight and problem-state-logic oriented, and it consumes the quantum capability as one step or several steps among many.
• The workload is a multistage pipeline that is often iterative, like a state machine. Each stage runs on the compute back end that best fits it: HPC, GPU, or a quantum target. Quantum computing is one option for one or more stages.
• A quantum step represents a well-defined building block, such as a scientific calculation that computes a molecular property. The precise quantum code might even be generated and optimized dynamically to fit the actual inputs.
• The workflow orchestrator owns multiple self-contained quantum executions and the classical processing between them. The result of one execution determines parameters for the next quantum program or provides inputs that generate the next program. Iterative phase estimation fits this structure, as do variational algorithms such as the Variational Quantum Eigensolver (VQE) and the Quantum Approximate Optimization Algorithm (QAOA).

Considerations

These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that you can use to improve the quality of a workload. For more information, see Well-Architected Framework.

Reliability

Reliability helps ensure that your application can meet the commitments that you make to your customers. For more information, see Design review checklist for Reliability.

Quantum jobs run on remote, shared targets, so job execution can fail from transient errors, such as a target timeout. Regardless of the integration pattern you choose, monitor job execution so that you can surface job status to the user. When a job fails because of a transient error, apply the Retry pattern. Submit jobs through asynchronous calls and poll for the result so that you don't block the calling client.

Availability of the quantum compute functionality depends highly on the availability and capacity characteristics of the quantum computing provider. Depending on the compute target, the classical client application might experience long delays or unavailability of the target.

For the surrounding Azure services, the usual availability considerations apply. If necessary, consider using the replication options in Azure Storage redundancy.

Reliability for workflow-orchestrated integration

• For high availability in workflow-orchestrated integration, deploy API Management across availability zones or multiple regions. Zone redundancy requires the Premium or Premium v2 tier, and multiregion deployment requires the Premium tier.

• If you implement the orchestrator with Durable Functions, plan its disaster recovery as a unit rather than treating the function app and its state as independent services. Durable functions persist all orchestration state in a task hub in a storage back end, which is Azure Storage by default. Because the runtime state and the compute are coupled through that task hub, provisioning the function app in a second region and replicating Storage separately doesn't define a safe failover. Orchestrations can pause, lose recent transactions, or read a cross-region task hub, depending on the topology.

  For a safe failover, use an active-passive configuration that fails over to a secondary region, fronted by a global load-balancing service such as Azure Front Door or Azure Traffic Manager. Confirm that the service health probes can reach the function app under your networking restrictions, because the same controls that limit the app to API Management traffic can also block those probes. Choose the topology that matches your tolerance for data loss and cross-region latency. For the coordinated options and their tradeoffs, see Disaster recovery and geo-distribution in Durable Functions.

Security

Security provides assurances against deliberate attacks and the misuse of your valuable data and systems. For more information, see Design review checklist for Security.

Apply the following hardening practices to the classical services that surround the quantum job, regardless of the integration pattern you choose:

• Authenticate to Azure Quantum and the surrounding services by using Microsoft Entra identities, and turn off local authentication where the service supports it. Use managed identities wherever the hosting environment supports them. For a client that can't use a managed identity, authenticate with another Microsoft Entra identity, such as a service principal or an interactive user sign-in.

• Grant each component that accesses Storage the data-plane access it needs through Azure role-based access control (Azure RBAC) with Microsoft Entra ID, scoped to that component. Don't embed storage account keys in application code.

In general, apply the Well-Architected Framework security recommendations when appropriate.

Security for direct quantum integration

Unlike workflow-orchestrated quantum integration, this pattern assumes that a single client accesses the Azure Quantum workspace. The client is typically a lightweight classical harness that focuses on job submission and operation rather than broader workflow state. This scenario leads to the following configurations:

• Because the client is known, you can give it a fixed identity. When the client runs on an Azure-hosted resource, associate a managed identity with it. When the client runs outside Azure, use a service principal or an interactive user sign-in.

• You can implement request throttling and result caching in the client itself.

Security for workflow-orchestrated integration

Unlike direct quantum integration, this pattern puts a classical service tier in front of the quantum work. API Management is the front door for that tier, so the security configurations emphasize protecting the entry point and the path to the quantum workspace.

• Clients must authenticate to the API. Implement this authentication by using authentication policies.

• You can implement authentication of the Azure functions via managed identities associated with the functions. You use those identities to authenticate outbound calls to the Azure Quantum workspace.

• API Management can apply request throttling to protect the quantum back end and limit the use of quantum resources. For more information, see API Management request throttling.

• Depending on the request pattern, you might be able to implement the caching of quantum computing results by using API Management caching policies.

Cost Optimization

Cost Optimization focuses on ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Design review checklist for Cost Optimization.

The overall cost of this solution depends on the quantum computing target that you select to run the quantum job. The classical components are straightforward to estimate. For a representative deployment of the workflow-orchestrated pattern, see this example cost estimate, which covers the classical components, including API Management, Azure Functions, and Storage. The direct integration pattern is lighter, but its classical costs still include Storage and any hosting, networking, and monitoring that the client application uses.

You can consume quantum computing providers for Azure Quantum via a Microsoft Marketplace offering. Pricing depends on the type of resource (simulator or hardware), the SKU, and your usage. For more information, access the reference page for your scenario's provider from Quantum computing providers on Azure Quantum.

Contributors

Microsoft maintains this article. The following contributor wrote this article.

Principal author:

• Zander Chocron | Principal Software Engineer, Microsoft Quantum

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps

• For an overview of the Microsoft quantum computing ecosystem, see the Microsoft Quantum website and complete the Quantum computing foundations learning path.
• For more information about the Azure Quantum service, see What is Azure Quantum?.
• For general information about Azure Quantum job management, see Work with Azure Quantum jobs.
• For information about combining classical and quantum instructions in a job, see Introduction to hybrid quantum computing.

Related resources

• Operational Excellence design principles
• Asynchronous Request-Reply pattern