At RELI, we not only develop practical solutions to address customer needs today, but we also proactively research and monitor the evolution of the technology landscape and how it is going to influence future solutions. Recently, my colleague at RELI, Jason Balser, wrote a blog post titled “What is Quantum Computing?,” which outlines how leaders and organizations should prepare for its impact. In this article, I am going to explore what the “Quantum Era” looks like for teams building and maintaining critical technology solutions.
Many make the mistake of only viewing Quantum Computing as a niche platform for scientific research requiring high powered computing. While its scale is indeed built for high-complexity simulations, the ripple effects of QC demand more awareness of the changing rules of software resiliency and architectural design and a willingness to consider a fundamental shift in design principles, when appropriate.
The Security Shift: Post-Quantum Cryptography (PQC)
The immediate impact of QC is the threat it poses to asymmetric encryption. Standard encryption algorithms, which have protected applications and data for years, are now vulnerable to QC’s exponentially bigger scale of computing and its ability to break these algorithms.
As a result, we are entering the era of Crypto-Agility. Resilient design must now allow for the rapid swapping of cryptographic primitives without breaking the entire system. The team must plan to move towards PQC standards like ML-KEM (FIPS-203) for encryption and ML-DSA (FIPS-204) for signatures. Why? Because attacks known as “Harvest Now, Decrypt Later” (HNDL) are happening today. Bad actors are exfiltrating encrypted data today, betting that they can decrypt it in a few years as QPU (Quantum Processing Unit) fidelity increases. Proactively implementing PQC would help you protect against a future wave of HNDL attacks.
To implement crypto-agility, one must start by creating an inventory of where the encrypted data lives. Next, the security layer should be modularized (if not already done) so that there is a clean separation of business logic from the encryption layer. This allows you to swap out the encryption layer through a configuration option, instead of touching or refactoring the code. Even after crypto-agility is implemented, one must continue to audit the tech stack to identify the parts which could be disrupted or improved by QC.
The Architectural Shift: The Hybrid Model
As mentioned earlier, QC is not the best fit for every application. Classical computing will continue to work well for most applications. However, we will start entering the era of Hybrid Classical-Quantum Architectures. In this model, the quantum computer acts like a specialized co-processor, similar to how a GPU handles graphics.
Orchestrator Design Pattern
In the current state of QC, the Quantum processor would rarely be customer facing. It would usually live behind the classical orchestrator. i.e. You build your “regular” application software (Python, Java etc.) as the orchestrator. When a heavy optimization or simulation task is needed where QC can make a very significant impact, the application makes an API call to a Quantum-as-a-Service (QaaS) provider like Azure, AWS or IBM.
The Quantum API may simulate hundreds (or thousands) of complex scenarios and return those results to the orchestrator, which would pick the best “option” possible. Examples may include highly complex supply chain simulations or detection of very complex Fraud, Waste, Abuse (FWA) patterns, which may escape the current Machine learning models. The nature of this architecture pattern, and QC in general, makes it more suitable for use cases which must pick probabilistic “best option”, or the “most optimized solution”, or “most likely scenario”, rather than a deterministic yes/no answer or to execute a very specific transaction.
It is important to emphasize that this hybrid architecture, while feasible and likely to become more common, adds some complexity to the architecture, as noted below. The design decision should be driven by an assessment of whether the additional complexity is compensated by the benefits of QC for a specific high complexity, computation intensive task. It is prudent for the forward-looking application development teams to become more familiar with SDKs, like Qiskit, Amazon Braket, CUDA-Q, which allow you to write “Quantum Ready” code and implement these design patterns in languages like Python.
Resiliency Patterns
Because quantum calls can have high latency and higher failure rates (due to “noise”), some Circuit Breaker patterns are emerging. If the quantum service is slow or unstable, the software “breaks the circuit” and falls back to a classical approximation. It may sound complex to switch to classical computing, but the circuit breakers are being implemented at the infrastructure layer so that the same code can be executed on classical computing. This ensures that while the answer might be slightly less optimized during a failover, the application remains online and functional. As QC matures further to become more fault-tolerant, it may help to simplify the resiliency patterns by eliminating any “bridge” patterns needed today due to limitations.
The Logic Shift: Deterministic vs. Probabilistic
Regular software is deterministic whereas Quantum software is probabilistic, which returns a distribution of possible answers. So, using hybrid architecture, as described above, will have an impact on the Quality engineering approach. Does it make Quality engineering harder? Possibly yes, but it doesn’t make it unpredictable. It does represent a shift in approach. In classical computing, we test for equality (result = a specific value), whereas in QC, we test for “confidence score.” If a quantum result has low fidelity (i.e. Confidence score is below a threshold), the system can be built to automatically trigger a Classical Fallback. This is the ultimate form of resiliency: the system knows when its “brain” is fuzzy and switches to simpler logic.
The Path Forward
Application development teams must take a pragmatic approach to Quantum Computing. They must understand the potential risks and benefits and be very practical when to use it. While QC is still maturing, teams must be proactive and start preparing and upskilling themselves (with Proof of Concepts) to mitigate risks and be able to fully leverage QC in specific scenarios.
At RELI, have a roadmap for creating best practices of implementing crypto-agility and PQC standards, as well as implementing hybrid classical-quantum models (using the available SDKs) so that we can help our customers implement them efficiently. We will prove these patterns in our RELI Labs, so that they are ready for implementation. The winners of this era won’t necessarily be the ones with the most qubits. Instead, they will be the teams with the most flexible architectures, those capable of absorbing the “noise” of quantum logic while delivering the “certainty” that the users and citizens demand.
