Loading…
Loading…
An overview of supported deployment topologies for the SOAP-2-REST platform, including Docker, Kubernetes, and cloud-native options, and its core service
The SOAP-2-REST platform is designed to run entirely within your own network. It does not expose any public endpoints and is accessed through an ingress you control, such as a cloud Identity-Aware Proxy (IAP), an internal load balancer, or a reverse proxy.
This document provides an overview of the platform's architecture and the supported deployment options to help you choose the best topology for your needs, from initial evaluation to high-availability production workloads. All persistent configuration and state are stored in a single PostgreSQL database, which serves as the system's source of truth.
The platform consists of a set of stateless services that rely on a PostgreSQL database for persistence. This architecture allows for flexible scaling and deployment across different environments.
flowchart TD
subgraph Your Network
subgraph Platform Services
runtime[runtime]
admin_api[admin-api]
admin_ui[admin-ui]
worker[worker]
generic_ingest[generic-ingest]
cloud_adapter[cloud-adapter]
end
subgraph Your Infrastructure
ingress[Your Ingress<br/>(e.g., LB, IAP, Proxy)]
db[(PostgreSQL Database)]
end
ingress --> admin_ui
ingress --> runtime
ingress --> generic_ingest
admin_ui -- Proxies to --> admin_api
admin_ui -- Proxies to --> runtime
admin_api <--> db
runtime <--> db
worker <--> db
generic_ingest --> db
cloud_adapter -- Manages --> external_cloud[Cloud Provider Services<br/>(Object Store, Secrets, etc.)]
end
api_consumer[API Consumer] -- Requests --> ingressThe platform is composed of the following microservices:
| Service | Role |
|---|---|
| admin-api | The control plane for the platform. It handles onboarding, settings configuration, Role-Based Access Control (RBAC), and generation of OpenAPI specifications and WSDL files. This service also owns and applies all database migrations using Flyway upon startup. |
| runtime | The data plane that performs the real-time SOAP-to-REST and REST-to-SOAP conversion for live traffic. |
| worker | Executes background jobs, including traffic aggregation for analytics, discovery derivation, and the curation of learned examples. |
| admin-ui | The web-based user interface for operators. It provides access to the platform's administrative functions by proxying requests to the admin-api and runtime services. |
| generic-ingest | A universal HTTP receiver for traffic logs, used by the generic HTTP connector to ingest traffic data. |
| cloud-adapter | An abstraction layer for interacting with provider-specific services for object storage, compute provisioning, relay VM gateways, and secret stores. Adapters are available for Google Cloud, Azure, and VMware. |
All persistent data, including configuration and operational state, is stored in the PostgreSQL database. All tables created and managed by the platform are prefixed with s2r_.
The following deployment options are generally available as of version 1.0.
| Option | Best For | Status |
|---|---|---|
| Docker Compose (standalone) | The fastest path for a demo, pilot, or a single-host production installation behind your own load balancer or reverse proxy. Runs on any host with Docker. | GA |
| Kubernetes / OpenShift (Helm) | High-availability, cluster-managed workloads in any cloud or on-premises environment. Supports in-cluster or external PostgreSQL. | GA |
| Red Hat OpenShift | A specific configuration of the Helm chart for OCP, using native Routes and the default restricted-v2 SCC without requiring a custom Security Context Constraint. | GA |
| GCP-native | The lowest-touch managed service path on Google Cloud, using Cloud Run, Cloud SQL, Cloud Storage, and Cloud IAP with IAM database authentication and internal-only ingress. | GA |
| GCP Marketplace listing | A one-click deployment onto Google Cloud that uses the GCP-native topology. | GA |
| VM appliance (OVA / VHDX) | VM-only or air-gapped environments without Kubernetes. A downloadable VM image (VMware OVA / Hyper-V VHDX) that is pre-configured and boots the full product. | GA |
NOTE
On the Roadmap Future versions (v1.1+) plan to include Nutanix AHV appliance images and first-class native support for AWS, Azure, and Oracle. Sample Terraform environments for AWS, Azure, and vSphere are available today as a starting point.
Use the following guidelines to select the most appropriate installation method:
For evaluation, a pilot, or a simple single-host deployment: Use the Docker Compose option. It requires a single .env file for configuration and is started with docker compose up. You will need to place your own TLS-terminating proxy or load balancer in front of it.
For high-availability (HA) in a container-orchestrated environment: Use the Helm chart for Kubernetes or OpenShift. This allows you to scale the runtime service horizontally, integrate with a managed PostgreSQL instance, and use your cluster's ingress and OIDC provider.
For a minimal operational footprint on Google Cloud: Use the GCP-native option. This leverages managed services like Cloud Run for autoscaling, Cloud SQL with IAM database authentication, and Cloud IAP for edge security.
All options run the same container images and database schema. You can migrate between deployment types (e.g., from Docker Compose to Helm) by restoring a database backup into the new installation.
Before beginning any installation, you must make several decisions and prepare key assets:
credential key.
IMPORTANT
The credential key is an AES key used to encrypt backend credentials at rest in the database. Securely generate and store this key.
admin-ui after a fresh installation will be granted administrative privileges. Determine the email address(es) for these initial bootstrap administrators.After completing these prerequisites, choose a deployment option from the list above and proceed with its specific instructions.