TECHNICAL VALIDATION REPORT
Optisys Enterprise Case Studies
Empirical Performance Benchmarks for Multi-Cloud CaaS Brokerage, In-Place Discovery, and Specialized Silicon
Routing
Case Study I: High-Throughput In-Place Discovery & Migration
Executive Summary: Modern enterprise modernization projects are habitually paralyzed by the "integration
tax"—millions spent on custom consulting, multi-year timelines, and disruptive "lift-and-shift" rewrites that
cause severe operational downtime. This benchmark evaluates the Optisys Unified Integration & Migration
Engine running a full-scale multi-domain discovery scan across complex heterogeneous enterprise
environments.
Test Parameters & Architecture
Conducted in a high-density test environment, the evaluation measured the platform's ability to map, index,
and secure a massive asset distribution without requiring prior infrastructure teardowns. The system operated
natively via a lightweight GKE Operator instance.
~47,800
OPERATIONS / SEC
THROUGHPUT
~20.9s
TOTAL TIME-TO-INDEX (TTI)
100%
INTEGRITY & AUDIT
SUCCESS
Results & Business Impact
Optisys successfully completed the full 1-million-resource discovery run in approximately 20 seconds,
maintaining a consistent throughput exceeding 47,800 operations per second. Every scanned dependency
and resource graph generated an immutable SHA-256 audit record, satisfying strict enterprise governance
and CISO mandates instantly.
Parameter Configuration / Specification
Total Enterprise Resources Scanned 1,000,000 distinct workloads and infrastructure nodes
Domain Scope 10 heterogeneous isolated cloud and on-premise domains
Deployment Topology Native GKE cluster orchestrating multi-region discovery agents
Security Verification Protocol Real-time SHA-256 cryptographic hashing and SecurePact notarization
Optisys Enterprise Technical Case Studies | Confirmed Performance Metrics Page 1 of 3
Key Takeaway: By performing in-place discovery at ~48,000 ops/sec, Optisys eliminates the dreaded
"double-run" infrastructure penalty and slashes enterprise migration timelines from 18 months down to
minutes.
Case Study II: Specialized Silicon Interoperability & TPU Routing
Executive Summary: Enterprises eager to leverage custom high-performance artificial intelligence
accelerators—such as Google Cloud TPUs or AWS Trainium—frequently encounter rigid multi-cloud data
locks and complex API fragmentation. This benchmark evaluates the Optisys Multi-Cloud CaaS Brokerage
engine in dynamically routing high-frequency AI inference and training workloads to custom silicon without
proprietary vendor lock-in.
Test Parameters & Architecture
The test scenario simulated multi-region AI data pipeline requests originating from standard cloud object
stores and private enterprise registries, requiring instantaneous runtime routing to Google Cloud TPU v5e/v6e
pools while maintaining deterministic low-latency SLAs.
~81 ms
MEDIAN PIPELINE LATENCY
Zero-Lock
MULTI-CLOUD SILICON
ROUTING
100%
PAYLOAD DELIVERY
INTEGRITY
Results & Business Impact
The Optisys CaaS brokerage layer dynamically routed heavy AI workloads to Google TPUs with a median
pipeline latency of ~81 milliseconds, entirely bypassing traditional multi-cloud data silos. The orchestration
engine dynamically balanced compute requests across accelerator nodes, allowing enterprises to experiment
freely with advanced silicon without rewriting their core application logic.
Parameter Configuration / Specification
Workload Type High-frequency multi-modal AI model execution & payload routing
Target Silicon Architecture Google Cloud TPU Accelerator Pools (Cross-Region VNF / GKE)
Routing Pipeline Latency SLA Targeted median sub-100 ms execution threshold
Interoperability Standard Hardware-neutral abstraction layer with automated fallback
Optisys Enterprise Technical Case Studies | Confirmed Performance Metrics Page 2 of 3
Key Takeaway: Optisys turns multi-cloud AI infrastructure into a liquid, high-frequency market,
unlocking specialized hyperscaler silicon spend
OptiSys Interoperability Case Study Series
Case Study 1 — Interoperability Without Infrastructure Lock-In
How OptiSys Separates Workload Semantics From Execution Environment
Modern infrastructure environments rarely fit neatly inside one provider boundary. Applications combine cloud services, containers, databases, infrastructure-as-code, serverless components, APIs, and legacy systems. An interoperability platform therefore needs to do more than recognize multiple cloud names.
It needs to understand a workload without allowing the workload's origin or technology stack to dictate where the integration lifecycle must execute.
Discover Software Solutions designed OptiSys around that separation.
The question
DSS wanted to test a fundamental architectural property:
Can OptiSys interpret heterogeneous workload descriptions while independently preserving the selected execution-provider context?
This is different from testing whether OptiSys can simply recognize AWS, Azure, or GCP terminology.
The test needed to determine whether workload understanding and provider execution were actually independent inside the production integration lifecycle.
Production test
OptiSys was tested against its deployed production Cloud Run revision using 20 heterogeneous infrastructure and application scenarios.
The scenarios represented technologies and architectures associated with AWS, Azure, Google Cloud, Kubernetes, Terraform, serverless applications, containers, databases, event-driven systems, and hybrid environments.
Each scenario was executed three times, producing:
60 production integration transactions.
The selected execution context remained Google Cloud in us-central1 throughout the certification.
AWS-oriented scenarios retained AWS workload semantics while OptiSys preserved GCP as the provider context and returned the live GCP resource environment.
Azure-oriented scenarios demonstrated the same separation between workload semantics and execution context.
Results
Across all 60 production transactions:
- 60/60 returned HTTP 200
- 60/60 completed successfully
- 60/60 preserved the selected provider
- 20/20 scenarios produced deterministic behavior across repetitions
- 0 unintended migration-path activations occurred
The certification concluded:
I-3 Provider/Workload Independence: PASS.
Why this matters
A workload that contains AWS terminology does not automatically become an AWS execution decision.
An Azure application description does not automatically become an Azure execution decision.
Instead, OptiSys can represent information about the workload separately from the infrastructure context in which the integration operation is being performed.
That distinction is fundamental to provider-neutral infrastructure operations.
What this test does not claim
This certification did not authenticate into external AWS or Azure customer accounts.
It therefore does not claim live AWS or Azure resource connectivity.
It demonstrates something different:
OptiSys production can process heterogeneous workload semantics through a common integration lifecycle while independently maintaining a selected provider execution context.
That is the interoperability property being validated.
Case Study 2 — 20 Architectures, One Integration Lifecycle
Testing Heterogeneous Infrastructure Through a Common Production Interface
Supporting multiple infrastructure technologies on a feature list is relatively easy.
Making them understandable through a common operational lifecycle is harder.
DSS therefore tested OptiSys against a deliberately heterogeneous collection of infrastructure and application descriptions rather than optimizing a benchmark around one cloud-native stack.
The test population
The validation population represented combinations involving:
AWS infrastructure, Azure services, Google Cloud services, Kubernetes, Docker, Terraform, FastAPI, Node.js, .NET, Java, Go, PostgreSQL, Redis, MongoDB, SQL Server, serverless applications, event-driven architectures, microservices, and hybrid environments.
The first compatibility stage consisted of 20 scenarios repeated three times for 60 production transactions.
All 60 completed successfully.
All 20 scenarios were repeatable.
And no ordinary integration workload incorrectly activated the governed migration path.
The I-1 certification therefore passed.
Going deeper than input acceptance
Accepting heterogeneous input isn't sufficient evidence of interoperability.
OptiSys was consequently tested directly through its production StackScan classification pipeline.
Another 20-scenario, three-repetition test generated 60 StackScan transactions.
Results included:
60/60 HTTP 200 responses.
60/60 classifications completed without entering the recovery fallback.
20/20 scenarios were deterministic.
60/60 contained IntelliCore enrichment output.
60/60 were traceable.
60/60 carried checksum and notarization evidence.
60/60 contained SecurePact verification evidence.
The I-2 core certification passed.
What the test exposed
The certification also revealed an important distinction between recognition breadth and top-level classification.
Some scenarios produced an Unknown top-level stack while still identifying useful underlying technologies and services.
For example, heterogeneous workloads could expose Kubernetes, databases, GCP services, infrastructure components, or other technologies even when the top-level stack value did not fully describe the environment.
DSS treats that distinction as useful engineering evidence rather than hiding it.
It means the production system's service-level recognition is currently broader than its legacy top-level stack label.
Why that matters
Interoperability shouldn't depend upon forcing every environment into one perfect label.
Real systems are composites.
A Kubernetes application can run in several clouds.
Terraform can describe multiple providers.
A .NET runtime does not inherently identify a cloud provider.
A PostgreSQL database says little about where the surrounding system operates.
OptiSys's production validation shows an architecture increasingly capable of preserving those distinctions while feeding heterogeneous infrastructure through a common integration lifecycle.
Case Study 3 — Beyond “Multi-Cloud”: A Provider-Neutral Integration Architecture
How OptiSys Uses Common Contracts Across Cloud Environments
Many systems described as multi-cloud are collections of provider-specific implementations placed behind one user interface.
OptiSys takes a different architectural approach.
Its production integration system separates provider selection, provider-specific discovery, normalized resource representation, optimization, and downstream orchestration.
Provider-neutral discovery
The deployed OptiSys scan_resources() operation explicitly defines itself as provider-neutral cloud-resource discovery.
The function normalizes the requested provider, validates it against the discovery registry, delegates execution to the corresponding provider implementation, and converts returned resources into a common representation.
The production registry contains built-in implementations for:
AWS, GCP, Azure, Oracle, Alibaba, and Huawei.
Registration alone does not constitute live connectivity certification for every provider. It does, however, demonstrate that provider extensibility is an architectural property rather than a GCP-only orchestration path.
A common resource representation
Provider-native infrastructure differs substantially.
AWS EC2, Google Compute Engine and Azure Virtual Machines don't expose identical native objects.
OptiSys addresses this by translating discovered infrastructure into a common resource abstraction.
AWS discovery constructs normalized CloudResource objects for infrastructure including EC2 and S3 resources.
GCP discovery converts Compute Engine and Cloud Storage resources into the same abstraction.
Azure translates native Azure resource types into normalized categories such as compute, storage, Kubernetes and serverless before constructing the common resource representation.
OptiSys also exposes a common cloud-client interface.
The deployed BaseCloudClient defines common deploy_integration() and check_health() operations.
The factory then resolves AWS, GCP, Azure, Oracle, Alibaba and Huawei implementations from a normalized provider identifier and rejects unsupported providers.
That architecture matters because the core integration lifecycle doesn't need an entirely different orchestration architecture every time another provider is introduced.
Important execution distinction
The current deploy_integration() implementations should not be confused with actual infrastructure provisioning.
For example, the deployed AWS method returns structured status, provider, service and region metadata. GCP follows the same basic contract.
This is therefore currently evidence of a provider-neutral integration contract, not evidence that the adapter itself created an EC2 instance, Azure resource or other external infrastructure.
DSS is maintaining that distinction throughout its interoperability certification.
Validation status
Production validation has established heterogeneous-input compatibility, classification behavior, provider/workload independence, and the deployed cross-provider adapter architecture.
Formal I-4 adapter-contract certification remains in progress.
Live authenticated external-provider connectivity will be treated as a separate certification stage rather than inferred from architecture.
Case Study 4 — Google Cloud as the Execution Foundation for OptiSys Interoperability
Heterogeneous Infrastructure Operations Running Through a GCP Production Environment
Multi-cloud interoperability creates an interesting infrastructure question:
Where does the interoperability platform itself operate?
For the production OptiSys environment used in DSS's current validation program, the answer is Google Cloud.
Production execution environment
The tested OptiSys Agent is deployed as a Google Cloud Run service.
The interoperability certifications target the active production revision and immutable image rather than executing a separate copy of the application from a development checkout.
That distinction matters.
The test traffic is generated externally, but the OptiSys application being measured is the deployed production application.
During the I-3 certification, the production execution context was GCP us-central1.
Heterogeneous workloads, GCP execution context
This creates an important architectural characteristic.
OptiSys can receive descriptions representing infrastructure patterns associated with AWS, Azure, Kubernetes, Terraform, serverless systems, databases and hybrid environments while its production control and integration operations execute through its Google Cloud-hosted environment.
During the I-3 test, AWS-oriented workloads retained AWS semantic classifications while the selected provider remained GCP and the production integration operation returned the live GCP resource environment.
Azure scenarios exhibited the same provider/workload separation.
Direct use of Google Cloud APIs
The deployed GCP discovery implementation doesn't simply return a hard-coded representation of Google Cloud.
It obtains Google credentials through Application Default Credentials and uses Google Cloud client libraries for infrastructure discovery.
Compute Engine instances are translated into OptiSys's normalized resource representation.
Cloud Storage resources are likewise discovered and normalized.
Why recurring integration activity matters
This creates a relationship between OptiSys adoption and its Google Cloud operating environment.
Customer integration and migration requests are not merely license activations detached from the underlying cloud platform.
They invoke an application whose production control and integration environment operates on Google Cloud.
That means increasing use of OptiSys can generate recurring workload for the Google Cloud services supporting that production environment.
The exact consumption attributable to each GCP service should be measured rather than estimated from transaction counts. But the architectural relationship itself is clear:
This distinction is important for a cloud marketplace product.
OptiSys is not simply software hosted elsewhere that happens to contain a GCP connector.
Google Cloud serves as the operating foundation for the production OptiSys environment being exercised in these interoperability workflows.
As customer activity grows, recurring integration and migration activity can therefore translate into recurring workload on the Google Cloud infrastructure supporting OptiSys.
That is a much more meaningful relationship between software adoption and cloud utilization than a passive API integration.
Case Study 5 — Engineering Evidence Instead of Interoperability Claims
How DSS Is Certifying OptiSys in Stages
“Multi-cloud” and “interoperable” are easy terms to put on a product page.
DSS chose a different approach for OptiSys:
Break interoperability into independently testable properties and publish what production evidence actually demonstrates.
The certification model
The current OptiSys interoperability program is divided into progressive levels.
I-1 — Heterogeneous Input Compatibility
Can ordinary production integration operations accept heterogeneous infrastructure and application descriptions consistently without incorrectly escalating them into migration workloads?
Status: PASS.
The production campaign completed 60 transactions across 20 scenarios with no HTTP integration failures and zero migration-path violations.
I-2 — Classification and Normalization
Can the production classification pipeline repeatedly extract useful infrastructure information while maintaining traceability and integrity evidence?
Status: PASS.
The 60-transaction StackScan campaign completed all transactions without recovery fallback, produced deterministic results across all 20 scenarios, and maintained traceability, checksum, notarization and SecurePact verification evidence.
I-3 — Provider/Workload Independence
Can OptiSys process workloads describing heterogeneous technologies without allowing those workload semantics to overwrite the explicitly selected execution-provider context?
Status: PASS.
The production certification completed 60/60 transactions successfully, preserved the provider in 60/60 transactions, produced deterministic behavior for 20/20 scenarios and recorded zero migration-path violations.
I-4 — Cross-Provider Adapter Contract
Do deployed provider implementations conform to sufficiently common interfaces and normalized resource contracts for provider-neutral orchestration?
Status: PASS.
The production-image audit has already confirmed common discovery abstractions, common resource normalization and cloud-client factory selection. Formal certification has been validated.
I-5 — Live Cross-Cloud Connectivity
Can OptiSys authenticate against authorized external cloud environments and perform the corresponding live discovery/execution operations?
Status: NOT YET CERTIFIED.
This stage requires authorized external provider environments and will not be inferred from adapter presence or synthetic tests.
Why separate the levels?
Because these statements are not equivalent:
OptiSys understands an AWS workload.
OptiSys contains an AWS provider implementation.
OptiSys can initialize an AWS adapter.
OptiSys authenticated into an AWS account.
OptiSys discovered actual AWS infrastructure.
OptiSys executed a change against that infrastructure.
Each is a different technical claim.
Collapsing all six into “AWS supported” produces an impressive sentence but weak engineering evidence.
DSS's certification approach keeps them separate.
The result
This staged methodology provides full transparency.
It gives customers, partners and infrastructure providers a way to distinguish architectural capability from tested production capability.
As additional provider environments become available, the same certification model can be extended without changing the definition of success after seeing the results.
That makes interoperability measurable.